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
"rat" <rattt@col.edu.cn> skrev i en meddelelse news:cbnvnr$2od0$1@mail.cn99.com... > Hi,friends, > To meet the Tsu requirement in my design, I think I should try to add some > clock delay to the input register, how can I do that in CPLD? (not FPGA, > without PLL,DLL) Hey You could use a simple bianry counter.... bit 1 = IN Bit 2 = In/2 Bit 3 = In/4 and so on... KasperArticle: 70776
> when I did my timing simulation, I got the warning message: > # ** Warning: /X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK; > # Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns > > Can someone tell me more about the X_FF component from the simprim > library? Or is there any link for the explanation. I failed to find > out any in the past 60 minutes. Thanks for your help. > This looks like a setup & hold type violation. Is the signal into the flip-flop asynchronous to its clock? most likely. So pass the signal thru several stages of FFs to reduce meta stability. You'll still get the above message though. The massage can be turned off but it's probably better to leave it on & check that each one really is a meta stability issue. (Unless of course you have an incredibly fast clock, like GHz range). Anyway, that's what I think, others are wlecome to correct me or re-enforce!Article: 70777
rat wrote: > Hi,friends, > To meet the Tsu requirement in my design, I think I should try to add some > clock delay to the input register, how can I do that in CPLD? (not FPGA, > without PLL,DLL) It depends on your signals. Sometimes, you can use the opposite clock edge, to ensure stable sampling points. If that is too coarse, you can use delay passes, but they need real care. Nodes can be removed/optimised away by tool flows, or revisions in tool flows, and the delays are process dependant. ie use only when all else fails. -jgArticle: 70778
Jim Granville <no.spam@designtools.co.nz> wrote: : rat wrote: : > Hi,friends, : > To meet the Tsu requirement in my design, I think I should try to add some : > clock delay to the input register, how can I do that in CPLD? (not FPGA, : > without PLL,DLL) : It depends on your signals. : Sometimes, you can use the opposite clock edge, to ensure stable : sampling points. : If that is too coarse, you can use delay passes, but they : need real care. Nodes can be removed/optimised away by tool flows, : or revisions in tool flows, and the delays are process dependant. : ie use only when all else fails. Going off- and on-chip again gives also some delay that no optimizer will optimize away, at the expense of two pins... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 70779
Dear All, In my functional simulation result of modelsim, after a frame is transmitted by GMAC in HALF Duplex Mode, the flag "SUCCESSFUL_FRAME, bit 0" of Transmitter Statistics is not '1'. What's wrong? It will be set to '1' in FULL Duplex Mode. Please help me... BTW, tx_underrun, tx_retransmit, tx_collision are all zero. Regards, SeyiorArticle: 70780
According to the Xilinx documentation the GT10_PCI_EXPRESS_n primitive is only "supported for Virtex-II Pro X but not for Virtex-II or Virtex-II Pro". Does this mean that you can't use the Virtex-II Pro in a PCI-Express application? Is this related to the electrical idle, or are there other reasons? Thanks Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 70781
Hal Murray wrote: >>what is the fanout of the IOpins in Virtex2 to devices > > The details are in the data sheet. It depends upon which > IO standard you are using. > > I haven't seen the term "fanout" in data sheets for a long time. > It doesn't really make much sense with modern logic. > > CMOS has almost 0 load current so you can drive hundreds of > loads if you don't care about speed. The data sheet will > give you the switching times for a specified load capacitance. > If you have more capacitance it takes longer. Though, you have to care for input rise and fall time requirements of the attached receivers. Regards, MarioArticle: 70782
Hello, I have seen similar behaviour. What I found is that if the main loop is very tight, the interrupt handler will not get called ... very bizarre. ie: if I have a main loop of: while (1); // loop infinitely, waiting for a HW interrupt ... the ISR does not get called. However: while (1) printf( "." ); // loop, printing a dot each time around ... allows the ISR to be called. IIRC, even doing a small delay causes the ISR not to be called, until the delay is sufficiently large. ie: while (1) for (i=0; i<DELAY; i++); // loop after waiting a bit I verified the compiler did not optimize the delay out and that caching was disabled. For reasons I don't understand, the tight loop causes the calling of the ISR to fail. Perhaps you have a similar situation. Also make sure that the HW interrupt is asserted while outside of any currently-running ISR, as Nios has to see it level-high. Other than this wierd case, I haven't had ISR problems. I believe I tested this with Nios 3.2 or maybe 3.01. -- Pete tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>... > QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4. > > I have the Nios32 @ 30mhz working fine with my user logic modules, but > any ISR I try works a random number of times (1 to 30 times?) and then > stops getting called. By bringing out some internal signals to pins, I > can see that the irq signal from my module is asserted, but the ISR just > does not get called. This is the first time I have tried using Nios > interrupts, but I am getting it straight from the examples. > > As a test, I wrote an ISR that just increments and prints a count value, > and does not clear the interrupt. There is no foreground code other than > installing the vector and enabling interrupts. I would expect my ISR to > get called indefinitely, (context save, execute, context restore), but > it just works a random # of times and stops. > > This is the only handler I have installed, but I know the spurious > handler is installed by default (it works), as well as the CWP handler > (dont know if it works - how to test?). The behavior suggests > stack/memory corruption from the context save/restore. I don't re-enable > interrupts in my ISR, so I don't expect nested interrupts. > > I have seen weird behaviors whenever the systhesis does not match the > assembled libraries used to compile (forgot to use 'Generate'), but I > have triple-checked. Any ideas/new errata?Article: 70783
Compile-time constants would be something like, out <= 11 / 7; where the compiler replaces it whit a constant like out <= 1.5....; and the other case when the right argument is a power of 2 is something like out <= B / 8; which would be replace whit a shift right out <= B >> 3; neither of these examples would result in any division hardware But your example out <= A / B; doesn't fit either of these. If this is what you really need you would have to implement your own division. Hope this helps // JonasArticle: 70784
Yes I remember now that how often the ISR was reliably called was inversely proportional to how tight my main loop was ... ie, sometimes I would see sporadic interrupt trapping like you are. -- Pete tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>... > QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4. > > I have the Nios32 @ 30mhz working fine with my user logic modules, but > any ISR I try works a random number of times (1 to 30 times?) and then > stops getting called. By bringing out some internal signals to pins, I > can see that the irq signal from my module is asserted, but the ISR just > does not get called. This is the first time I have tried using Nios > interrupts, but I am getting it straight from the examples. > > As a test, I wrote an ISR that just increments and prints a count value, > and does not clear the interrupt. There is no foreground code other than > installing the vector and enabling interrupts. I would expect my ISR to > get called indefinitely, (context save, execute, context restore), but > it just works a random # of times and stops. > > This is the only handler I have installed, but I know the spurious > handler is installed by default (it works), as well as the CWP handler > (dont know if it works - how to test?). The behavior suggests > stack/memory corruption from the context save/restore. I don't re-enable > interrupts in my ISR, so I don't expect nested interrupts. > > I have seen weird behaviors whenever the systhesis does not match the > assembled libraries used to compile (forgot to use 'Generate'), but I > have triple-checked. Any ideas/new errata?Article: 70785
Hi newsgroup users, can someone tell me how to define the programming time of a EP1C12 Cyclone when using PL-BYTEBLASTER2 cable in comparison to PL-USB-BLASTER cable? Thank you for your help. RgdsArticle: 70786
> Going off- and on-chip again gives also some delay that no optimizer will > optimize away, at the expense of two pins... Good idea :) But it seems that it is hard to do the simulation and timing analysisArticle: 70787
I have an 8ms delay in my main loop now, and I still have the problem so it does not seem like the same one. I can try adding more code to my loop. Still, neither the behavior you describe nor the one I am seeing are correct so what's the root cause? My user logic module clears the IRQ whenever I read a register. Normally this is done in the ISR. Eventually the IRQ does not clear because the ISR is not called. (This does not seem to be the case of the ISR getting called, but not clearing the IRQ for some reason). I tried adding a read of the same clearing register in my main loop every 100ms. This 'kick starts' the Nios when it is ignoring IRQs, but probably at a cost of a lost IRQ - it works, but is not acceptable. I can also exit my main loop (via a terminal key press), and perform a manual read of the clearing register. This does clear the asserted IRQ signal, but does NOT restore the system to normal operation. Even though main line code runs OK, subsequent IRQs are still ignored. The only way to re-enable interrupts is to reset everything. This really sounds like an IRQ is being blocked in the Nios core kinda like interrupts were never re-enabled internally during the previous context restore (or vector table corruption or...). I guess I need to try the debugger so I can look at stack pointers, status registers, etc. I read about an option on the CWP manager that selects between HW & SW handling of overflows on the register window but I don't see this choice on any tool dialog. Peter Sommerfeld wrote: > Yes I remember now that how often the ISR was reliably called was > inversely proportional to how tight my main loop was ... ie, sometimes > I would see sporadic interrupt trapping like you are. > > -- Pete > > tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>... > >>QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4. >> >>I have the Nios32 @ 30mhz working fine with my user logic modules, but >>any ISR I try works a random number of times (1 to 30 times?) and then >>stops getting called. By bringing out some internal signals to pins, I >>can see that the irq signal from my module is asserted, but the ISR just >>does not get called. This is the first time I have tried using Nios >>interrupts, but I am getting it straight from the examples. >> >>As a test, I wrote an ISR that just increments and prints a count value, >>and does not clear the interrupt. There is no foreground code other than >>installing the vector and enabling interrupts. I would expect my ISR to >>get called indefinitely, (context save, execute, context restore), but >>it just works a random # of times and stops. >> >>This is the only handler I have installed, but I know the spurious >>handler is installed by default (it works), as well as the CWP handler >>(dont know if it works - how to test?). The behavior suggests >>stack/memory corruption from the context save/restore. I don't re-enable >>interrupts in my ISR, so I don't expect nested interrupts. >> >>I have seen weird behaviors whenever the systhesis does not match the >>assembled libraries used to compile (forgot to use 'Generate'), but I >>have triple-checked. Any ideas/new errata?Article: 70788
Finn, I take issue with the unsupported spin by competitors accusing us of introducing a product "too early." First of all, very few products get introduced totally problem free. Yes, we have had an errata sheet with a new product, but that is a service, not something to be ashamed of. In fact, compared to others in this industry, our errata sheet is at least less than a couple of pages, and most often a single sheet. Others have in excess of 20 or more known bugs, with many different mask revisions, which is hell to keep track of. So are we too early when we have a few errata, but we do not force a customer to live through three mask revisions? That to me is too early: announcing a product that is too buggy, and isn't ready. What does it matter that it is "on the shelf?" Secondly, there has been incredible unexpected business in Spartan 3. So, did we not have enough supply? Yes. Did we intentionally introduce it too early so we would make people unhappy? No. Third, I can say nothing about the software (not my area), so no defense offered here. I will let them offer one, or an apology, whichever is appropriate. Fourth, and lastly, Virtex 4 was announced today being shipped to early access customers. That means it is real. Now comes the fun part, making lots more, and sampling them. I will not disagree that the sampling phase will be a real challenge, but who else has a triple oxide 500 MHz FPGA with IBM Power PC's, 10 Gbs transceivers, FIFO BRAM, 48bit DSP with MAC...... no one. It isn't called the "bleeding edge" for nothing. But if you are not there (on the edge of the technology juggernaut), you are nowhere. AustinArticle: 70789
rat <rattt@col.edu.cn> wrote: : > Going off- and on-chip again gives also some delay that no optimizer will : > optimize away, at the expense of two pins... : Good idea :) But it seems that it is hard to do the simulation and timing : analysis Put the delay, taken from the data sheet, into the test bench... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 70790
We had to fix our first prototype the same way... a "universal solution" :-)Article: 70791
You can treat the inputs to the BlockRAM just as if it were a register. Give it all its information and then apply the right clock edge. It's as simple as that. But an asynchronous FIFO is not simple, especially if you are after high clock rates. The problem is detecting EMPTY reliably, and that involves the use of Gray counters etc. As you may have read in today's press announcement, we took care of that in Virtex-4, where we incorporated a FIFO controller with all the bells and whistles and impressive speed... Peter Alfke > From: "Arnaud" <arnaud@trisky.com> > Organization: Guest of ProXad - France > Newsgroups: comp.arch.fpga,comp.lang.vhdl > Date: Sat, 26 Jun 2004 09:34:40 +0200 > Subject: Re: Using a BlockRam in an async FIFO for bus width conversion ? > > Thanks Peter, > > I was thinking,the behaviour was: > - on the clock_write rising edge : I setup Address, data, Write Enable and > ENable, as setup time is not valid, BlockRam doesn't take them into account > - on the next clock_write rising edge, I setup the new value, and the > BlockRam gets the previous value (line above), and set the memory cell > - and so on.. > > It works fine in behavioral not in post place and route, it seems, that some > part of the value changed at the rising edge are taken from the "before > rising edge" values, while others are taken from the "after rising edge" > values, in post place and route. > > To do what you told me "at least a set-up time before", I changed my block > Ram to react on FallingEdge, while my logical set all the values at the > RisingEdge.... > But I don't know if it's the "good way"... > > I didn't succeed to find any trivial example about the use of DualPort > BlockRam... if anyone has one, I would love to get it. > > Many thanks, > > Arnaud > > "Peter Alfke" <peter@xilinx.com> a écrit dans le message de > news:BD01EB55.71BA%peter@xilinx.com... >> Remember, all BlockRAM operations are synchronous, activated by the clock >> edge (your choice of clock polarity). >> That means all inputs must be there at least a set-up time before that > clock >> edge. >> "All" means: Address, Data, Write Enable, and ENable. >> >> Peter Alfke, Xilinx Applications >> >>> From: "Arnaud" <arnaud@trisky.com> >>> Organization: Guest of ProXad - France >>> Newsgroups: comp.arch.fpga,comp.lang.vhdl >>> Date: Fri, 25 Jun 2004 22:11:03 +0200 >>> Subject: Using a BlockRam in an async FIFO for bus width conversion ? >>> >>> Hi all, >>> First of all, I'm a newbie in FPGA, so sorry if my questions are not > very >>> smart... :-) >>> In a larger design, I try to use a Xilinx BlockRam for a data width >>> conversion between 2 clocks domains. >>> I look through the different Xilinx example (xapp131, xapp258, ..). As > my >>> needs was much more simpler I try to make mine (mostly to understand). >>> >>> During behavioral or post-translate simulation everything is ok. But > during >>> Post-Place & Route Simulation. It doesn't work. >>> I try 2 write 2 32bits words from one side and to get on the other side > a >>> 64bits word. >>> In my test bench, I write >>> 1st - 0x00000000 and 0x00000001 >>> and the read side I get 0x0000000100000000 >>> 2nd - 0x00000002 and 0x00000003 >>> and the read side I get 0x0000000300000002 >>> and so on. >>> >>> BUT in place and route simulation I have >>> In my test bench, I write >>> 1st - 0x00000000 and 0x00000001 >>> and the read side I get 0x0000000000000000 >>> 2nd - 0x00000002 and 0x00000003 >>> and the read side I get 0x0000000200000001 >>> 2nd - 0x00000004 and 0x00000005 >>> and the read side I get 0x0000000400000003 >>> and so on. >>> >>> >>> Basically, I always miss the first value, as It is not taken into > account, >>> and the "word" are reordered (so with the wrong pair association). >>> >>> I saw on the newsgroups, that maybe I have to set the WriteEnable > _before_ >>> the rising edge, but I don't understand how and why if it's the case ? >>> >>> I have isolated my problem in the two following file (testbench and >>> "converter") >>> >>> Thanks a lot. >>> >>> Arnaud >>> >>> >>> >>> Converter >> >> -------------------------------------------------------------------------- > -- >>> ---------------------------- >>> library IEEE; >>> use IEEE.STD_LOGIC_1164.ALL; >>> use IEEE.STD_LOGIC_ARITH.ALL; >>> use IEEE.STD_LOGIC_UNSIGNED.ALL; >>> >>> -- Uncomment the following lines to use the declarations that are >>> -- provided for instantiating Xilinx primitive components. >>> library UNISIM; >>> use UNISIM.VComponents.all; >>> >>> entity test_fifo is >>> Port ( clk_wr_in : in std_logic; >>> clk_rd_in : in std_logic; >>> bus_in : in std_logic_vector(31 downto 0); >>> bus_out : out std_logic_vector(63 downto 0); >>> wr : in std_logic; >>> rd : in std_logic; >>> sr : in std_logic); >>> end test_fifo; >>> >>> architecture Behavioral of test_fifo is >>> >>> component bram_w32_r64 >>> port ( >>> addra: IN std_logic_VECTOR(4 downto 0); >>> addrb: IN std_logic_VECTOR(3 downto 0); >>> clka: IN std_logic; >>> clkb: IN std_logic; >>> dina: IN std_logic_VECTOR(31 downto 0); >>> doutb: OUT std_logic_VECTOR(63 downto 0); >>> ena: IN std_logic; >>> enb: IN std_logic; >>> wea: IN std_logic); >>> end component; >>> >>> >>> signal addra: std_logic_VECTOR(4 downto 0); >>> signal addrb: std_logic_VECTOR(3 downto 0); >>> >>> >>> >>> signal clk_rd: std_logic; >>> signal clk_wr: std_logic; >>> >>> signal rst : std_logic; >>> >>> begin >>> >>> >>> gclk1: BUFGP port map (I => clk_rd_in, O => clk_rd); >>> gclk2: BUFGP port map (I => clk_wr_in, O => clk_wr); >>> >>> rst <= not sr; >>> >>> bram : bram_w32_r64 >>> port map ( >>> addra => addra, >>> addrb => addrb, >>> clka => clk_wr, >>> clkb => clk_rd, >>> dina => bus_in, >>> doutb => bus_out, >>> ena => wr, >>> enb => rst, >>> wea => '1'); >>> >>> >>> writer: process(sr, clk_wr) >>> begin >>> if ( sr = '1' ) then >>> >>> addra <= (others => '0'); >>> >>> elsif (rising_edge(clk_wr)) then >>> >>> if ( wr = '1' ) then >>> addra <= addra + 1 ; >>> end if; >>> >>> end if; >>> >>> end process writer; >>> >>> >>> >>> reader: process(sr, clk_rd) >>> begin >>> if ( sr = '1' ) then >>> >>> addrb <= (others => '0'); >>> >>> elsif (rising_edge(clk_rd)) then >>> if (rd = '1') then >>> addrb <= addrb + 1 ; >>> end if; >>> >>> end if; >>> >>> end process reader; >>> >>> end Behavioral; >>> >>> >>> TEST_BENCH >> >> -------------------------------------------------------------------------- > -- >>> ---------------------------- >>> LIBRARY ieee; >>> USE ieee.std_logic_1164.ALL; >>> USE ieee.numeric_std.ALL; >>> use IEEE.STD_LOGIC_UNSIGNED.ALL; >>> >>> >>> ENTITY test_fifo_tb IS >>> END test_fifo_tb; >>> >>> ARCHITECTURE behavior OF test_fifo_tb IS >>> >>> COMPONENT test_fifo >>> PORT( >>> clk_wr_in : IN std_logic; >>> clk_rd_in : IN std_logic; >>> bus_in : IN std_logic_vector(31 downto 0); >>> bus_out : out std_logic_vector(63 downto 0); >>> wr : IN std_logic; >>> rd : IN std_logic; >>> sr : IN std_logic >>> ); >>> END COMPONENT; >>> >>> SIGNAL clk_wr : std_logic := '0'; >>> SIGNAL clk_rd : std_logic := '0'; >>> SIGNAL bus_in : std_logic_vector(31 downto 0):= (others => '0'); >>> SIGNAL bus_out : std_logic_vector(63 downto 0):= (others => '0'); >>> SIGNAL wr : std_logic :='0'; >>> SIGNAL rd : std_logic := '0'; >>> SIGNAL sr : std_logic := '1'; >>> >>> BEGIN >>> >>> uut: test_fifo PORT MAP( >>> clk_wr_in => clk_wr, >>> clk_rd_in => clk_rd, >>> bus_in => bus_in, >>> bus_out => bus_out, >>> wr => wr, >>> rd => rd, >>> sr => sr >>> ); >>> >>> >>> -- *** Test Bench - User Defined Section *** >>> >>> clk_wr <= not clk_wr after 30 ns / 2; >>> clk_rd <= not clk_rd after 15 ns / 2; >>> sr <= transport '0' after 120 ns; >>> >>> tb : PROCESS >>> BEGIN >>> wait; -- will wait forever >>> END PROCESS; >>> -- *** End Test Bench - User Defined Section *** >>> >>> writer: process( clk_wr, sr) >>> begin >>> >>> if ( sr ='1' ) then >>> >>> bus_in <= (others => '1'); >>> >>> elsif (rising_edge(clk_wr)) then >>> >>> if ( bus_out /= 8 ) then >>> rd <= '0'; >>> wr <= '1'; >>> bus_in <= bus_in + 1; >>> else >>> wr <= '0'; >>> rd <= '1'; >>> end if; >>> >>> end if; >>> >>> end process writer; >>> END; >>> >>> >>> >>> >> > >Article: 70792
Hello, > According to the Xilinx documentation the GT10_PCI_EXPRESS_n > primitive is only "supported for Virtex-II Pro X but not for > Virtex-II or Virtex-II Pro". The GT10_PCI_EXPRESS_n primitives are based on the GT10 primitive that is only available in Virtex-II ProX. The protocol specific primitives are "convenience macros" that use the transceiver primitives and have all the attributes set for the specific protocol, so you don't need to figure it out yourself. In Virtex-II Pro, you can use the GT primitive, and there are some "convenience macros" for ethernet, fibre channel, and infiniband. However, there isn't one for PCI Express, so you would need to use the GT primitive and then set all the attributes to get the desired result. Your next question would probably be, "Why?" and I'm not sure so I'll file an enhancement CR on this issue. I suspect it is due to the Virtex-II Pro library being developed before PCI Express specifications were final. (And this is not the case for Virtex-II ProX...) > Does this mean that you can't use the Virtex-II Pro in > a PCI-Express application? No. You can use Virtex-II Pro for PCI Express, and we do! If you want to read more about it, you can check out our IP datasheet for the PCI Express endpoint core, at: http://www.xilinx.com/systemio/pciexpress/index.htm > Is this related to the electrical idle, or are there > other reasons? Unrelated. Hope that helps, EricArticle: 70793
Austin Lesea wrote: > > I am told that distributors do have part/package combinations in stock > on the shelf. I am also told that some devices are still in short > supply. We are fab'ing as many wafers as we possibly can to catch up > (projecting ahead), but demand is ramping faster. I asked for an update on the XC3S400-4FG456C and was told 12 weeks (that's three months, right?) or "open order entry" for the ES version. They did not say they had had even the ES parts on the shelf. Can you give me a heads up on who might have stock on this part? Also, what exactly is the difference between the production and ES parts at this point? I believe the 3S400 parts are claimed to be in "production" for many months now. Where do the ES parts come from at this late stage? > PS: I did not intend to put "words in your mouth". Poetic license > #23210098 issued 5/14/53 When replying to my posts, please keep your poetic license in your pocket. This is prose, not poetry. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 70794
OK, the next-generation parts at both application grades from both manufacturers are now announced. I've not been around for long enough to know how long to expect between announcement and availability at the hobbyist level; is Christmas 2005 for Cyclone II (announced today) dev boards reasonable? It's nice to see reasonably serious levels of DSP appearing at the low-end parts, though I'm a little disappointed that we're not seeing seas of floating-point units in the high end, even in the Virtex 4SX; those can be so much smaller as macrocells than built out of logic. What _is_ the business about "maximum toggle frequency 500MHz (for export control)" in the Spartan3 datasheet? I was contemplating real-time fractal generators, and it's not clear that a 4+50 x 4+50 -> 4+50 fixed-point triple-precision multiplier built in a Spartan 3 would be price-competitive with small piles of PCs; rough summing of propagation delays suggest you can get three, with 10-15ns propagation, into an XC3S1000. Which is 200-300Mflops, and with small-volume costs and board-building charges I don't see I could get the price below the $100 required to compete on price/performance with Athlon64. Whatever happens, these will be wonderful things to play with; many thanks to everybody involved in bringing on the Era of Programmable Hardware! TomArticle: 70795
Hi, I will finish the University within the next months. Now I am looking for companies in Germany in the field of FPGA. I have found some companies specialized in FPGA design and consulting - El Camino - Polar Design - Array Electronics Are there any other FPGA design/consulting companys in Germany ? Which companys employ FPGAs in their products and therefore could be a potential employer for me ? Thank you very much.Article: 70796
> From: Thomas Womack <twomack@chiark.greenend.org.uk> > Organization: Linux Unlimited > Newsgroups: comp.arch.fpga > Date: 28 Jun 2004 20:03:20 +0100 (BST) > Subject: Battle of the Vapours > > > What _is_ the business about "maximum toggle frequency 500MHz (for > export control)" in the Spartan3 datasheet? > There are restrictions on exporting (from the US) devices above a certain level of sophistication. And the government measures that as toggle rate. (The idea was to avoid helping the "evil empire" develop better missile guidance systems). The Cold War lives forever... Peter AlfkeArticle: 70797
Rick, ---snip---- > I asked for an update on the XC3S400-4FG456C and was told 12 weeks > (that's three months, right?) or "open order entry" for the ES version. > They did not say they had had even the ES parts on the shelf. Can you > give me a heads up on who might have stock on this part? Sorry, I suspect that S3 ES parts are available only through Xilinx, which means that we have stock, and are awaiting a disti order. Only those disti's that want to (we can not force them) will buy ES material, as they do not want to be "stuck" with ES stock (as then they have to write it). > Also, what exactly is the difference between the production and ES parts > at this point? Basically none. After the first masks of the first family members, errata are fixed, and the second or third masks made are just awaiting the HTOL (high temperature operating life), ESD, and other reliability tests before they can be officially called production. Same silicon, more paper pedigree. Again, contact you disti and FAE for exact details on any specific part. One good way is to request the errata sheet for the two parts. If there is no errata sheet for a part, it has no problems, and that usually means it is the second mask made in the family, as the first one's errata are fixed (if any). > I believe the 3S400 parts are claimed to be in > "production" for many months now. Where do the ES parts come from at > this late stage? As soon as we have production, no one wants the ES anymore. Sometimes we have to write off a lot of ES material as it can not be sold (or donate it to schools and universities -- see the Xilinx University Program online! Do not email me for the parts!).Article: 70798
In article <BD05CC88.7201%peter@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: > > >> From: Thomas Womack <twomack@chiark.greenend.org.uk> >> Organization: Linux Unlimited >> Newsgroups: comp.arch.fpga >> Date: 28 Jun 2004 20:03:20 +0100 (BST) >> Subject: Battle of the Vapours >> >> > What _is_ the business about "maximum toggle frequency 500MHz (for >> export control)" in the Spartan3 datasheet? >There are restrictions on exporting (from the US) devices above a certain >level of sophistication. And the government measures that as toggle rate. >(The idea was to avoid helping the "evil empire" develop better missile >guidance systems). OK, I suppose that makes a certain degree of sense; I wonder slightly how the big microprocessor vendors get round that issue. There were those Apple adverts saying that their machine was by export-control standards a supercomputer, but I've seen plenty of dual-G5 boxes on my side of the Atlantic. With my Dr Evil hat on, I wonder slightly how you set a maximum toggle frequency when the LUT propagation time is already down to 700ps or so -- I wonder if it's a matter of refraining from heroic engineering efforts to keep parasitic capacitance down in the flip-flops, or a couple of lines in the depths of the hardware-compiler? TomArticle: 70799
Thomas Womack wrote: > OK, the next-generation parts at both application grades from both > manufacturers are now announced. I've not been around for long enough > to know how long to expect between announcement and availability at > the hobbyist level; is Christmas 2005 for Cyclone II (announced today) > dev boards reasonable? Probably, as Altera mention Q2 2005 for samples of most devices. Lattice also have a new family, with their prices quoted at 1K ( compared with the others of 18 months out, and asymptope volumes :) Lattice also say first samples in July 2004, (yes, next month, not next year...) > It's nice to see reasonably serious levels of DSP appearing at the > low-end parts, though I'm a little disappointed that we're not seeing > seas of floating-point units in the high end, even in the Virtex 4SX; > those can be so much smaller as macrocells than built out of logic. > > What _is_ the business about "maximum toggle frequency 500MHz (for > export control)" in the Spartan3 datasheet? > > I was contemplating real-time fractal generators, and it's not clear > that a 4+50 x 4+50 -> 4+50 fixed-point triple-precision multiplier > built in a Spartan 3 would be price-competitive with small piles of > PCs; rough summing of propagation delays suggest you can get three, > with 10-15ns propagation, into an XC3S1000. Which is 200-300Mflops, > and with small-volume costs and board-building charges I don't see I > could get the price below the $100 required to compete on > price/performance with Athlon64. AMD has announced a lower cost MPU, still no word on Price/Bits, but it will be real well in advance of the vapor-FPGAs. Hard to imagine it not being 64bit, given the [marketing advantage/silicon cost] ratios... -jg
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