Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
There have been a number of posts over the last few months about availability, or not, of PC104+ FPGA boards. In a couple of weeks time and with a little bit of luck we should be showing Hollybush1 at DATE for those that are interested in this board type. The board has a nice easy expansion capability and if anyone has particular wish lists for features do let me know. The board itself already has support for RS232, RS485 and CAN Bus before anyone asks for those. We are already looking one add-on module, based on Virtex2-Pro, that will give PowerPC and MGT capability for this board for those interested. Any other wishes now is your chance to ask for them. John Adair Enterpoint Ltd. - Home of MINI-CAN. The Spartan-3 CAN Bus Development Board. http://www.enterpoint.co.ukArticle: 97201
Since you are writing this from a University email address, I'll suggest you contact the Xilinx University Program (XUP) at http://www.xilinx.com/univ/ to inquire about a donation of the ISE Simulator to your University. They are usually quite generous. Paul Hendra wrote: > > What is the price for ISE Simulator? There is no mention of it in > Xilinx Online Store. How does it compare to ModelSim Xilinx Edition > III? > > HendraArticle: 97202
>>>>I have a hardmacro that's quite small (2 slices) and that have 2 LUTs in >>>>them and I'd like to be able to choose the INIT string of theses two >>>>luts when I instanciate them. Is this somehow possible ? >>>> >>>>I have to instanciate quite a few of them with different parameters and >>>>I'd _hate_ to have to make as many hardmacro as I need different LUT4 >>>>config ... >>>> >>> >>>convert .NMC to XDL and back, maybe it works that way >>> >>>(NMC is same format as NCD) >> >>How is that gonna help me ? >> >>What I'd like to do is when I instanciate in my VHDL code, be able to >>use generic to pass the INIT string of my two LUT4 like >> >>inst_I: my_hard_macro >>generic map ( >>INIT_LUT4_1 => x"0123", >>INIT_LUT4_2 => x"1234" >>) >>port map ( >>-- my ports, ... >>); >> > you cant do that ASFAIK, > so XDL may be the only possibility to change an existing hardmacro, sure it > involves some scripting to be done, etc, > > Antti Oh ... that sucks ... And if I remove the two lut4 out of the blackbock, and instanciate them separatly, will the tool we smart enough ? The thing is that these two lut4's output must go the the F5 of the slice, then to the FX on that same slice (and I have to keep the FX in that slice because the other FX input comes from the slice above and that one must be 'hardcoded' ...). Well, I guess I'm gonna have to try ... Damn sometimes the tools really get in the way of gettng things done ... SylvainArticle: 97203
Allan Herriman wrote: > On Sat, 18 Feb 2006 06:23:28 -0600, "maxascent" > <maxascent@yahoo.co.uk> wrote: > > >>The system I am designing is a pc scope. I guess I will know the trigger >>point. What I dont really understand is how you can generate precise >>offsets from the trigger if you want to sample in the GHz region as you >>are talking about picosecond values. I guess I dont fully understand the >>procedure > > > One solution for triggering is to have a fast, continuous time trigger > comparator start an analog ramp voltage (like in a monostable). This > ramp voltage is then digitised with an ADC similar to the ones > digitising the input voltages. > > Inspecting the values of the digitised ramp voltage will allow you to > estimate the trigger point with respect to the sample instants. > > The accuracy is limited by the comparator jitter, which might be as > low as some picoseconds. > > Regards, > Allan And an extension to that: for a single point per trigger acquisition, the trigger comparator could start the precise ramp and another comparator (with a programmable comparison) gives the trip point on that ramp for a precise delay. This allows the position of the single point to be deterministic. If I were to design an eye-diagram scope, I'd probably use a two-channel DDS to phase shift the sample clock precisely through an IQ modulator. I love the technique; it provides a precise phase shift of high frequency clocks though it does need a little extra RF-type work to get the harmonics and such eliminated.Article: 97204
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag news:43f752c9$0$27776$ba620e4c@news.skynet.be... >>>>>I have a hardmacro that's quite small (2 slices) and that have 2 LUTs >>>>>in >>>>>them and I'd like to be able to choose the INIT string of theses two >>>>>luts when I instanciate them. Is this somehow possible ? >>>>> >>>>>I have to instanciate quite a few of them with different parameters and >>>>>I'd _hate_ to have to make as many hardmacro as I need different LUT4 >>>>>config ... >>>>> >>>> >>>>convert .NMC to XDL and back, maybe it works that way >>>> >>>>(NMC is same format as NCD) >>> >>>How is that gonna help me ? >>> >>>What I'd like to do is when I instanciate in my VHDL code, be able to >>>use generic to pass the INIT string of my two LUT4 like >>> >>>inst_I: my_hard_macro >>>generic map ( >>>INIT_LUT4_1 => x"0123", >>>INIT_LUT4_2 => x"1234" >>>) >>>port map ( >>>-- my ports, ... >>>); >>> >> you cant do that ASFAIK, >> so XDL may be the only possibility to change an existing hardmacro, sure >> it >> involves some scripting to be done, etc, >> >> Antti > > > Oh ... that sucks ... > > And if I remove the two lut4 out of the blackbock, and instanciate them > separatly, will the tool we smart enough ? The thing is that these two > lut4's output must go the the F5 of the slice, then to the FX on that > same slice (and I have to keep the FX in that slice because the other FX > input comes from the slice above and that one must be 'hardcoded' ...). > > Well, I guess I'm gonna have to try ... Damn sometimes the tools really > get in the way of gettng things done ... > > > Sylvain ha ! you dont need a hardmacro for this, make a module where you instantiate the lut and muxf5 directly and place LOC constraints on them, its a little playing around but you should be able to get it all constrained properly!! AnttiArticle: 97205
Antti Lukats wrote: > "Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag > news:43f752c9$0$27776$ba620e4c@news.skynet.be... > >>>>>>I have a hardmacro that's quite small (2 slices) and that have 2 LUTs >>>>>>in >>>>>>them and I'd like to be able to choose the INIT string of theses two >>>>>>luts when I instanciate them. Is this somehow possible ? >>>>>> >>>>>>I have to instanciate quite a few of them with different parameters and >>>>>>I'd _hate_ to have to make as many hardmacro as I need different LUT4 >>>>>>config ... >>>>>> >>>>> >>>>>convert .NMC to XDL and back, maybe it works that way >>>>> >>>>>(NMC is same format as NCD) >>>> >>>>How is that gonna help me ? >>>> >>>>What I'd like to do is when I instanciate in my VHDL code, be able to >>>>use generic to pass the INIT string of my two LUT4 like >>>> >>>>inst_I: my_hard_macro >>>>generic map ( >>>>INIT_LUT4_1 => x"0123", >>>>INIT_LUT4_2 => x"1234" >>>>) >>>>port map ( >>>>-- my ports, ... >>>>); >>>> >>> >>>you cant do that ASFAIK, >>>so XDL may be the only possibility to change an existing hardmacro, sure >>>it >>>involves some scripting to be done, etc, >>> >>>Antti >> >> >>Oh ... that sucks ... >> >>And if I remove the two lut4 out of the blackbock, and instanciate them >>separatly, will the tool we smart enough ? The thing is that these two >>lut4's output must go the the F5 of the slice, then to the FX on that >>same slice (and I have to keep the FX in that slice because the other FX >>input comes from the slice above and that one must be 'hardcoded' ...). >> >>Well, I guess I'm gonna have to try ... Damn sometimes the tools really >>get in the way of gettng things done ... >> >> >>Sylvain > > > ha ! you dont need a hardmacro for this, make a module where you instantiate > the lut and muxf5 directly and place LOC constraints on them, its a little > playing around but you should be able to get it all constrained properly!! > > > Antti Yes I do (or at least I didn't figure how to do without it ...) Look at my thread "Xilinx Tight Packing : ..." http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/5ed4f26566b8650/79f1ea3cfe5534df?lnk=st&q=Xilinx+Tight+PAcking&rnum=1&hl=en#79f1ea3cfe5534df SylvainArticle: 97206
Thanks for your comments. It doesn't sound like there's an obvious answer to this one. I thought someone from Xilinx might post a comment. Rog. "Roger" <enquiries@rwconcepts.co.uk> wrote in message news:TAoJf.39670$K42.16607@newsfe7-win.ntli.net... >I have a design with an Aurora RocketIO core and in the UCF file I've >added the following lines: > > INST Inst_rio0_top/Inst_rio0/lane_0_phase_align_i/phase_align_flops_r* > AREA_GROUP="PHASE_ALIGN_0_GRP"; > > # Place RIO0 lane_0_mgt_i at location X0Y1 > INST Inst_rio0_top/Inst_rio0/lane_0_mgt_i LOC=GT_X0Y1; > > AREA_GROUP "PHASE_ALIGN_0_GRP" RANGE=SLICE_X14Y152:SLICE_X15Y153; > > When I use PACE to modify a pin assignment or something equally trivial > and save the UCF, the AREA_GROUP "PHASE_ ..........;" line has > disappeared. Although the Aurora core does still seem to work, I thought > that the placement of the phase alignment FFs was important and was > explicitly indicated for good reason. Can anyone tell me what's going on > here please? Even if there's some setting somewhere that's telling the PAR > to ignore this type of constraint, why does it disappear? Is it something > to do with the fact that except for the pin assignments, all the UCF file > has been added textually i.e. not via PACE or the Constraints Editor? > > TIA, > > Rog. > >Article: 97207
Thanks for your thoughts. Would it not be possible to implement this purely in software using the fpga rather than have to design additional hardware? JonArticle: 97208
Hi, Can some one give an insight about the *approximate* values of power and area consumption of a 1-bit SRAM cell for 0.13 micron technology. We need to approximate the area of 4-input LUT and our synthesis tool does not support SRAM standard cells in its library. It synthesises a DFF as memory element. How far will it be sensible to calculate the area of 4-input LUT through the tool and subsitute the dff's area by a SRAM cell's area ? Kindly help. Thanks.Article: 97209
maxascent wrote: > Thanks for your thoughts. Would it not be possible to implement this purely > in software using the fpga rather than have to design additional hardware? > > Jon No. You need something in the way of extra hardware. Either precision ramps or I/Q modulators - both hardware elements to interface with the trigger logic.Article: 97210
Sylvain Munaut wrote:
> John_H wrote:
> > I couldn't find my notes quickly so I'll just ask the question:
> >
> > Are you certain that the dob_i and doa_i signals from the dual-port CLB
> > SelectRAM - DPO and SPO, respectively - are on the correct pins (I1/I0) for
> > the MUXF5? You could just try swapping I1/I0 for a quick check to see if
> > the orientation is inverted from what you expect.
> No I'm not sure it's correct in the version I gave (I think so though),
> but I did try different swapping of the pins for the MUXF5 and MUXF6,
> none worked.
Sylvain, try again (hope you haven't started writing a lot of scripts
yet). The code below packs correctly into two slices without the
location constraint and init attributes (even using 6.3.03i), I'd be
surprised if adding them makes it fail to pack. I think John_H gave you
good advice. It did take me an hour to work out correctly... now I can
get to today's Sudoku puzzle...
Regards,
Just John
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_arith.ALL;
-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
library UNISIM;
use UNISIM.VComponents.all;
entity Sylvains_poser is
Port (
clk : in std_logic;
we : in std_logic;
di : in std_logic;
addr_a : in std_logic_vector( 3 downto 0 );
addr_b : in std_logic_vector( 3 downto 0 );
imm : in std_logic_vector( 3 downto 0 );
sel_imm : in std_logic_vector( 1 downto 0 );
sel_ab : in std_logic;
sel_rm : in std_logic;
dout : out std_logic;
dout_a : out std_logic;
dout_b : out std_logic
);
end Sylvains_poser;
architecture Behavioral of Sylvains_poser is
signal doa : std_logic;
signal dob : std_logic;
signal mux_ram : std_logic;
signal mux_imm : std_logic;
signal out_sel : std_logic_vector( 1 downto 0 );
signal dp_16x1 : std_logic_vector( 0 to 15 ) := x"1234";
begin
-- process( clk )
-- begin
-- if RISING_EDGE( clk ) then
-- if we = '1' then
-- dp_16x1( conv_integer( UNSIGNED( addr_b ))) <= di;
-- end if; end if;
-- end process;
-- doa <= dp_16x1( conv_integer( UNSIGNED( addr_a )));
-- dob <= dp_16x1( conv_integer( UNSIGNED( addr_b )));
dout_a <= doa;
dout_b <= dob;
memcell_I: RAM16X1D
port map (
DPO => doa,
SPO => dob,
A0 => addr_b(0),
A1 => addr_b(1),
A2 => addr_b(2),
A3 => addr_b(3),
D => di,
DPRA0 => addr_a(0),
DPRA1 => addr_a(1),
DPRA2 => addr_a(2),
DPRA3 => addr_a(3),
WCLK => clk,
WE => we
);
with sel_imm select mux_imm <=
imm(0) when "00",
imm(1) when "01",
imm(2) when "10",
imm(3) when "11",
'-' when others;
RAM_Mux : MUXF5
port map (
O => mux_ram,
I0 => dob,
I1 => doa,
S => sel_ab);
Mux_RM : MUXF6
port map (
O => dout,
I0 => mux_ram,
I1 => mux_imm,
S => sel_rm);
end Behavioral;
Article: 97211
The ISE 7.1i Simulator has trouble displaying the array in the code below.
Specifically when the mem array is added to wave, and the + is clicked
to explode the memory contents, the individual bytes are not segmented
and what you see is the entire mem array as if you had not clicked the +.
Am I doing something wrong or is there a work around? The free
ModelSim XE Starter has no issue here. This happens only with the
ISE simulator.
Brad Smallridge
Ai Vision
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity mem is
PORT (
clk : in std_logic;
data : in std_logic_vector(7 downto 0);
q : out std_logic_vector(7 downto 0)
);
end mem;
architecture Behavioral of mem is
TYPE memory_array IS ARRAY ( 0 TO 3 ) OF std_logic_vector(7 DOWNTO 0 );
signal mem: memory_array;
begin
process(clk)
begin
if clk'event and clk='1' then
mem(0) <= "00000000";
mem(2) <= data;
q <= mem(2);
end if;
end process;
end Behavioral;
Article: 97212JustJohn wrote: > Sylvain Munaut wrote: > >>John_H wrote: >> >>>I couldn't find my notes quickly so I'll just ask the question: >>> >>> Are you certain that the dob_i and doa_i signals from the dual-port CLB >>>SelectRAM - DPO and SPO, respectively - are on the correct pins (I1/I0) for >>>the MUXF5? You could just try swapping I1/I0 for a quick check to see if >>>the orientation is inverted from what you expect. >> >>No I'm not sure it's correct in the version I gave (I think so though), >>but I did try different swapping of the pins for the MUXF5 and MUXF6, >>none worked. > > > Sylvain, try again (hope you haven't started writing a lot of scripts > yet). The code below packs correctly into two slices without the > location constraint and init attributes (even using 6.3.03i), I'd be > surprised if adding them makes it fail to pack. I think John_H gave you > good advice. It did take me an hour to work out correctly... now I can > get to today's Sudoku puzzle... > > Regards, > Just John > > ... code snipped ... THANK YOU ! Damn you're right, I must have missed that particular mux config, I probably tried one combination two times ... I already made a hardmacro test but I like the HDL better ;) especially since you apparently can't "configure" a hardmacro, I would have had to do 16 differents hardmacro cells ... Well, the tools did get it after all, it was me who failed ;) SylvainArticle: 97213
Does anyone know if MontaVista Linux or other distributions support SMP in Virtex-II Pro and Virtex-4? Thanks.Article: 97214
On Sat, 18 Feb 2006 06:23:28 -0600, "maxascent" <maxascent@yahoo.co.uk> wrote: >The system I am designing is a pc scope. I guess I will know the trigger >point. What I dont really understand is how you can generate precise >offsets from the trigger if you want to sample in the GHz region as you >are talking about picosecond values. I guess I dont fully understand the >procedure In a general purpose scope, the trigger event arrives as a surprise, i.e. the scope does not know when the trigger event will occur. Typically you want to capture data immediately after the trigger event, and usually you would like to see some data before the trigger event. To see stuff before the trigger event, you must have been already sampling the data, or you need an analog delay line (high quality coax of suitable length) to delay the signal by the amount of pre-trigger acquisition you want. 10's of nanoseconds is doable. Microseconds/miliseconds probably not. Since you don't know when the trigger will occur, there is no relationship between your clock that you are using for sampling and the instant of triggering. (Note that you could theoretically have a clock that is stalled until the trigger event, and then is started synchronous with the trigger event, but such clocks do not have instant startup to stable precision frequency, which is a requirement for this type of application). So lets say you have a 100 MHz acquisition clock and a really great A/D that has a really really really great S/H in front of it. The S/H and A/D are running continuously at 100 MHz, and dumping data to memory set up as a ring buffer. Lets say the ring buffer is 10K long. When the trigger occurs, you record the current ring buffer address, and take 5K more samples, then stop. Your FPGA+CPU can now go digging through the ring buffer and re-arange the data to show you 5K * 10 ns of pretrigger info and 5K of post trigger info. But there is the problem that you have 10 ns of jitter in your system, because the trigger could have happened anywhere in between two ticks of your 10 ns clock. Here are two solution to this issue that also can guide you to an equivalent time sampling system that can get you into equivalent sample rates in the gigahertz. (Your bandwidth is still limited by the S/H and A/D). Technique 1). Since you know the exact level of the trigger voltage, look at the samples before and after the trigger event, and interpolate between the samples imediately before and after the trigger event to find the virtual sample that occured at the trigger voltage, and the virtual sample time. For example (trivial example), trigger voltage is 2.0V. Sample before trigger is 1.0V, and sample after trigger event is 5.0V . Samples 10ns apart. Assuming a straight line between the samples, we will have crossed through 2.0V at 2.5ns after the sample at 1.0V. Better curve fitting than straight line is possible. We could therefore treat ALL the samples of this acquisition as 7.5 ns late, which effectively shifts all the samples in time. Now do multiple acquisitions. Each one will interpolate the trigger point to some random time between two samples. As you take more acquisitions, you get to fill in your virtual acquisition buffer with samples that have been time aligned to much finer resolution than the 10ns of your acquisition clock. In fact this system depends on the fact that the trigger and acquisition clock are uncorrelated, to give you the random interpolation delays that let you have the interleaved acquisition waveforms. Technique 2). Concurrent with your 100 MHz acquisition clock you run a 100 MHz sawtooth waveform. I.E. a ramp that repeats at the same rate as your acquisition clock. At the time of the trigger, use a S/H to sample the sawtooth, and it has its own A/D. The result of sampling the sawtooth wave form tells you what the delta time of the trigger versus the 100 MHz clock is. i.e. the sawtooth runs from 1.0V to 2.0V and magically drops back to 1.0V in 0.0000 ps, and repeats. At the time of the signal passing through our trigger level (what ever it is) the S/H takes a snapshot of the sawtooth. The A/D on this S/H reports 1.35V . So we can say that the trigger actually occured 6.5 ns before we took the first sample after the trigger event. Reconstruct the equivalent time sampling data the same was as Technique 1. This should keep you busy, Philip Freidin Philip Freidin FliptronicsArticle: 97215
No, the PowerPC405 caches in the current Xilinx FPGAs are not cache coherent and so do not support SMP. Paul Osnet wrote: > > Does anyone know if MontaVista Linux or other distributions support SMP > in Virtex-II Pro and Virtex-4? Thanks.Article: 97216
Xilinx XC3S1000-4FG456I Altera EP2C20F484I8 Lattice ECP2-12E-5F484I I find that the differences between the parts are not so great that I want to exclude any of them. I would like to get an idea of how the pricing compares. I am looking for other than the list prices which tell me more about the distributor's markup than it does the price I can otherwise get. I figure asking here might be quicker than waiting for a price quote.Article: 97217
Philip Freidin wrote: <snip> > Technique 2). Concurrent with your 100 MHz acquisition clock you > run a 100 MHz sawtooth waveform. I.E. a ramp that repeats at the same > rate as your acquisition clock. At the time of the trigger, use a S/H > to sample the sawtooth, and it has its own A/D. The result of > sampling the sawtooth wave form tells you what the delta time of the > trigger versus the 100 MHz clock is. i.e. the sawtooth runs from > 1.0V to 2.0V and magically drops back to 1.0V in 0.0000 ps, and > repeats. At the time of the signal passing through our trigger > level (what ever it is) the S/H takes a snapshot of the sawtooth. > The A/D on this S/H reports 1.35V . So we can say that the trigger > actually occured 6.5 ns before we took the first sample after the > trigger event. Reconstruct the equivalent time sampling data the same <snip> Rather than a sawtooth where "turning the corner" leaves you with an unknown voltage-to-time conversion, a sine and cosine at the sample clock rate can be sampled by the trigger. The phase is extracted readily. Another method used is to start a precision ramp after the trigger and sample it at two spots after the ramp is established. They can give a precise timestamp as well.Article: 97218
ahh but you are out of luck. Whichever disti first quotes you on a part is the best price anyone else can give. Call it a conspiracy but that's the disti way. Your best bet is to just ask a disti. If you are ordering small quantities, sometimes you can get a good price by piggybacking your order on someone else's order. For instance, I saw on Toms Hardware that the latest video card uses a 3S400. Chances are they are buying hundreds of thousand parts, so their disti could give a good price by ordering one extra tray every now and again for you. We did the same to get a 3S1000 at the same price as a 2S200E. If your product is selling a million a month or year, then the price you will get has absolutely no reflection on reality. it comes down to how cheaply and efficiently Xilinx or Altera or Lattice can produce the FPGA for you... and they will produce it for you too. In that volume you just about get to name your own price. Simon "rickman" <spamgoeshere4@yahoo.com> wrote in message news:1140318351.652961.327590@g47g2000cwa.googlegroups.com... > Xilinx XC3S1000-4FG456I > Altera EP2C20F484I8 > Lattice ECP2-12E-5F484I > > I find that the differences between the parts are not so great that I > want to exclude any of them. I would like to get an idea of how the > pricing compares. I am looking for other than the list prices which > tell me more about the distributor's markup than it does the price I > can otherwise get. I figure asking here might be quicker than waiting > for a price quote. >Article: 97219
My guess is since ModelSim is a pure simulator and not a synthesis tool, it will run simulation for your code as long as it is free from syntax error. ISE Simulator, on the other hand, demands that your circuit must be SYNTHESIZABLE, in addition of being syntactically correct. Your code is not synthesizable. It's missing something. What happens to mem(1) and mem(3) at every rising edge of the clock? You need to define that. If your tool doesn't like 2D array, try to think how would you make a 2D array in hardware and implement that in VHDL. HendraArticle: 97220
I'm just doing my research on it.Want to find a way different from dsp/MCU based control. In my opinion paralled calculation is a great advantage. But will it bring us a new digital control arithmetic?Article: 97221
> Osnet wrote: >>Does anyone know if MontaVista Linux or other distributions support SMP >>in Virtex-II Pro and Virtex-4? Thanks. Paul Hartke wrote: > No, the PowerPC405 caches in the current Xilinx FPGAs are not cache > coherent and so do not support SMP. > I don't really get the relation between the two facts ... The OS could enforce coherency in software, by forcing a cache flush during task switching I think ... SylvainArticle: 97222
rickman <spamgoeshere4@yahoo.com> wrote: > Xilinx XC3S1000-4FG456I > Altera EP2C20F484I8 > Lattice ECP2-12E-5F484I > I find that the differences between the parts are not so great that I > want to exclude any of them. I would like to get an idea of how the > pricing compares. I am looking for other than the list prices which > tell me more about the distributor's markup than it does the price I > can otherwise get. I figure asking here might be quicker than waiting > for a price quote. To get a feeling for Xilinx price, try the Xilinx webshop, nuhorizons and digikey. They all have on-line prices. Are there any online prices for the Altera/Lattice parts? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 97223
Very much what Simon said is that the distributors are working from a price book unless you get supported pricing for your project. Here in EEC I believe by law they can't enforce centrally fixed prices and the disti can vary prices out of their margin. Margins are tight nowadays and here in the UK we don't even have a choice of distributor for Xilinx to get a competative quote. The other vendors are not much better in having choice of whom to buy from. So pressure to give competative pricing isn't high unless you fall into the area of interest for the FPGA vendors. If your project is reasonable volume, or FPGA value, then talk to your distributor and get supported pricing whoever's silicon you choose to use. If you don't have either of these attributes in your project you may be better to a third company like ourselves to manufacture . It may be cheaper than even doing it yourself because of the better FPGA pricing that can be obtained by volume users of FPGA silicon. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development Board. http://www.enterpoint.co.uk "rickman" <spamgoeshere4@yahoo.com> wrote in message news:1140318351.652961.327590@g47g2000cwa.googlegroups.com... > Xilinx XC3S1000-4FG456I > Altera EP2C20F484I8 > Lattice ECP2-12E-5F484I > > I find that the differences between the parts are not so great that I > want to exclude any of them. I would like to get an idea of how the > pricing compares. I am looking for other than the list prices which > tell me more about the distributor's markup than it does the price I > can otherwise get. I figure asking here might be quicker than waiting > for a price quote. >Article: 97224
In article <43f849af$0$2132$ba620e4c@news.skynet.be>, Sylvain Munaut <com.246tNt@tnt> writes: |> Paul Hartke wrote: |> > No, the PowerPC405 caches in the current Xilinx FPGAs are not cache |> > coherent and so do not support SMP. |> |> I don't really get the relation between the two facts ... The OS could |> enforce coherency in software, by forcing a cache flush during task |> switching I think ... The idea of having caches also means that they are transparent so that you do *not* need any sort of special treatment by the programmer or operating system. Besides, flushing with task switching wouldn't help as memory write accesses will occur independently from task switches, so your OS would need to keep track of memory accesses of all CPUs in your SMP system to block reads to "dirty" addresses until they have been written back by the "dirtying" CPU, i.e. the OS would have to establish a cache coherency protocol entirely in software and without typical hardware assist as required for cache coherency protocols in hardware like MESI. Rainer
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z