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
????? What was Intel building 10 years ago? Can you buy it today? The 2000 series FPGA's were obsoleted just two years ago. 15 years of support! It may be that a lot of FPGAs won't be available a few years from now: that is why you need to choose the leading manufacturer of FPGA's. Xilinx and their partners offer many 'soft' core microprocessors for use in their FPGA's. One of my favorites is the 8 bit RISC that is optimized for Virtex FPGA's and is extremely useful for simple control tasks, and also uses a tiny amount of resources. http://www.support.xilinx.com/xapp/xapp213.pdf There are larger and more powerful processors as well, Austin Muzaffer Kal wrote: > On Tue, 28 Nov 2000 08:50:09 +0100, "Pierre VERNEL" > <vernel@ensem.u-nancy.fr> wrote: > > >For a product which will be manufactured in medium quantity but over a long > >period of time (> 10 years) we have to use a System On Chip > > > >We plan to use an FPGA and we have the choice to use an hard core (like > >Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > > > >We think that the first solution is less expensive, but the other will > >garantee us a better availability > > > >can you give us your opinion about this choice? > > I think one thing is pretty much certain: no fpga available today will > be available for purchase in 10 years. So you have to buy end-of-life > parts within three years or so which makes the availability issue > moot. But if you get the NIOS version, you can make enhancements if > you need to. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.comArticle: 27551
Austin Lesea wrote: > > ????? > > What was Intel building 10 years ago? Can you buy it today? 8051 and derivitives are way over 10 years old. These are still available, possibly not from Intel. The same goes for the 80186, though I believe they're still available from Intel's embedded group. Sure, these are stone-aged devices, but still useful. ---- KeithArticle: 27552
Write the program in C. Write proper drivers for the H/W peripherals. Create backup H/W peripherals in FPGA technology. You can then easily port ANY application to a new technology. A big advantage of a "standard" processor, may be the available support (compiler, debugger, RTOS, emulator etc). There may be other advantages like power consumption. Basically some people need some features and other need other features which may make them go different directions. --=20 Best Regards Ulf at atmel dot com These comment are intended to be my own personal view and may or may not be shared by my Employer Atmel Sweden. "Pierre VERNEL" <vernel@ensem.u-nancy.fr> skrev i meddelandet = news:8vvoif$igp$1@arcturus.ciril.fr... > For a product which will be manufactured in medium quantity but over a = long > period of time (> 10 years) we have to use a System On Chip >=20 > We plan to use an FPGA and we have the choice to use an hard core = (like > Triscend or ATMEL FPSLIC) or a soft core (like NIOS) >=20 > We think that the first solution is less expensive, but the other will > garantee us a better availability >=20 > can you give us your opinion about this choice? >=20 > -- > Pierre VERNEL >=20 > ENSEM - INPL > 2 avenue de la foret de Haye > F 54516 VANDOEUVRE les NANCY > Tel : +33 (0)3 83 59 55 70 > Fax: +33 (0)3 83 59 55 73 > Email:vernel@ensem.u-nancy.fr >=20 >=20 >=20Article: 27553
> (Note that the FIFO specifically allows > you to assert REn or WEn when the FIFO is empty of full, respectively; it > internal gates the signals so that they're ignored when neeeded.) > I'd be curious to know if anybody else has had this experience. You are not the first one to encounter troubles in that area. That's a feature/bug that the FIFO manufacturers have been pushing ever since I started reading their data sheets. The problem is that it only works if you meet the setup and hold times, and that's very hard to do if the read and write clocks are asynchronous. Stop and think about it for a while. This quickly gets into a metastability issue. Xilinx doesn't even publish any data for their recent chips. How are you going to evaluate the failure rate of your FIFO design? Every time I design in a FIFO, I make sure my design doesn't write to a full FIFO or read from an empty one. That's using my logic that I can understand and get right. -- These are my opinions, not necessarily my employers. I hate spam.Article: 27554
Yes the power pins are different from the outside the reason being not to force a board spin but to force a re compile as the internal pad bondings are different so your expected IO's would appear on different pins. Regards Nick "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de> wrote in message news:8u129n$119$00$1@news.t-online.com... > Hi, > > "Ashok Chotai" <Ashok.Chotai@xilinx.com> schrieb im Newsbeitrag > news:3A035133.9706DA1D@xilinx.com... > > Hello Martin, > > Same features, except the pinout. So, for example, FLEX 10K30E device is > > NOT pin compatible with ACEX 1K30 device. > > Ashok > > > I recently checked the pinouts of the EP1K100QC208 208pinner > against the 10KE device. Every I/O pin and configuration pin > was identically, they just switched some VCCIO / GND / VCCINT > pins to prevent changing the device. Functionally you wouldn't > get problems, but a 10K would cause a short between power > supply in 1K layouts and vice versa... > > CU, Carlhermann > >Article: 27555
Nios a great solution for those wanting a 32bit RISC processor and competes well on speed and cost, have you seen the Altera Nios dev kit, it sells for under $1000 complete with software and hardware and comes ready for you to start running C code on. One cool bit of kit. Nick <longwayhome@my-deja.com> wrote in message news:8vumqu$e52$1@nnrp1.deja.com... > Hi > I'm finally going to bite the bullet and buy a board - just want to > double check that my final selection is ok for what i want to do. > > Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for > hardware evolution, has anyone actually used it for that purpose ? I'd > like to be able to program it with a C or Java API, is there suitable > for that ? All suggestions welcome. > > Thanks > > David > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 27556
Nios a great solution for those wanting a 32bit RISC processor and competes well on speed and cost, have you seen the Altera Nios dev kit, it sells for under $1000 complete with software and hardware. One cool bit of kit. Nick "Pierre VERNEL" <vernel@ensem.u-nancy.fr> wrote in message news:8vvoif$igp$1@arcturus.ciril.fr... > For a product which will be manufactured in medium quantity but over a long > period of time (> 10 years) we have to use a System On Chip > > We plan to use an FPGA and we have the choice to use an hard core (like > Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > > We think that the first solution is less expensive, but the other will > garantee us a better availability > > can you give us your opinion about this choice? > > -- > Pierre VERNEL > > ENSEM - INPL > 2 avenue de la foret de Haye > F 54516 VANDOEUVRE les NANCY > Tel : +33 (0)3 83 59 55 70 > Fax: +33 (0)3 83 59 55 73 > Email:vernel@ensem.u-nancy.fr > > >Article: 27557
PLL will give better results Nick "Anshuman Sharma" <gte600f@prism.gatech.edu> wrote in message news:8uahch$91$1@news-int.gatech.edu... > I'm working on designing a low level packet filter on an FPGA. Since it > needs run at very high speeds, which would be more advisable to use, PLL > or a DLL? > > -- > Anshuman Sharma > Georgia Institute of TechnologyArticle: 27558
You could always move the design to Altera, general lead-time 2 to 4 weeks try taking a look at 1K30ATC144-3 Nick Bruty Impact Memec "Leon Heller" <leon_heller@hotmail.com> wrote in message news:8tmloj$ode$1@nnrp1.deja.com... > In article <39EDDC34.E81D3E2E@andraka.com>, > Ray Andraka <ray@andraka.com> wrote: > .> Yep. Try Nu Horizons or Insight. We got them from one of the two > (not sure > > which now). We got XC2S50-5FG256 > > I've just been quoted 14-18 weeks lead-time for some XC2S50-5TQ144C by > our distributor, Insight Memec, in the UK > > Leon > -- > Leon Heller, G1HSM > Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 > Email: leon_heller@hotmail.com > Web: http://www.geocities.com/SiliconValley/Code/1835 > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 27559
I have heard that a UK distributor is telling customers that Xilinx Coolrunner parts are going obsolete? Any comments Xilinx? If any customers are in this position many of the parts are pin for pin with Altera Max 7K & 3K families, it's what Philips used as a selling point for Coolrunner, at least if your parts are going we can help. For UK customers please drop me a email and I'll happily help you convert the designs free. Regards Nick Bruty Altera FAE Impact Memec ex Philips Coolrunner FAEArticle: 27560
Joel Kolstad wrote: > > "Jason Daughenbaugh" <jad@aedinc.net> wrote in message > news:ee6ed1a.2@WebX.sUN8CHnE... > > Asynchronous FIFOs are quite possibly one of the most difficult modules to > implement. In order to get water-mark flags to work properly (half-full, > etc) you really need to use gray codes. The Xilinx app notes describe this > well. > > One problem we had with the Xilinx app note FIFOs is that they use pipelined > counters -- keeping around what the current gray count is, the next gray > count, etc., and incrementing them in lock step -- and on a somewhat random > basis the full and/or empty flags would go active when, indeed, we knew we > hadn't really overflowed or underflowed the FIFO. Our best guess as to the > cause of this was that we were using GSR as the reset input to the FIFO but > also asserting either REn or WEn just as GSR went inactive, and one of those > pipelined counters was getting corrupted (i.e., there was a race condition > between the various counter bits with GSR going inactive and a clock > arriving with REn or WEn active). (Note that the FIFO specifically allows > you to assert REn or WEn when the FIFO is empty of full, respectively; it > internal gates the signals so that they're ignored when neeeded.) > > I'd be curious to know if anybody else has had this experience. > > We ended up adding additional logic to make darn sure our REn and WEn > signals were inactive until well after GSR had gone inactive, and that > appeared to have solved the problem. I don't consider this as 100% proof > that we really know what the problem was in the first place, however. :-) Joel, Are you sure you weren't being screwed by the simulation model? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27561
Nick, Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of the 20KE had us smiling all around, If you are going to mess with analog PLL's on the same chip as the digital stuff: caveat emptor! Austin Nick Bruty wrote: > PLL will give better results > > Nick > > "Anshuman Sharma" <gte600f@prism.gatech.edu> wrote in message > news:8uahch$91$1@news-int.gatech.edu... > > I'm working on designing a low level packet filter on an FPGA. Since it > > needs run at very high speeds, which would be more advisable to use, PLL > > or a DLL? > > > > -- > > Anshuman Sharma > > Georgia Institute of TechnologyArticle: 27562
Hello All, I am trying to use an XCV300e-8ES part to transmit and receive 16bit by 622MHz sonet frames but I think I may be having problems with the DLL's at that frequency. The chip has two 311MHz clocks coming into it, one for transmit and one for receive. In order to indicate that my fpga is alive I am dividing the two clocks by roughly 311,000,000 and flashing two LED's at about 1Hz. I have noticed that after a while my LED's will stop flashing even though the 311MHz input clocks are still present. On the transmit side I don't really care about the clock to Q times because I'm sending a clock out with the data. This allowed me to eliminate the DLL on the transmit clock and now my divider never stops flashing on that side. On the receive side I must retain the DLL because input timing must be controlled and the receive side LED still stops flashing after a few minutes. Does anyone know if the Virtex E DLL's are marginal at 311MHz? I am working with engineering sample, ES, parts. What is the chance that these parts are marginal and the problem would go away with real -8 parts? Any comments along this line would be appreciated. Thanks, -- Pete Dudley Sandia Labs Albuquerque, NM padudle@sandia.govArticle: 27563
This is a multi-part message in MIME format. --------------587EF0BA7C3D56D89BBFCA98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nick, It is true that Xilinx has had to shorten the lifecycle of the 'legacy' Philips parts due to lack of fab capacity. As you probably know, Xilinx has strategic partnerships with a couple of fabs, but unfortunately not with the fabs where these devices are manufactured. Hence the end of life notice. It has always been in the plans to move the newest CoolRunner XPLA3 family to a strategic fab partner, and that is in the works now. The XPLA3 family is the next generation CoolRunner, sporting even lower power consumption than the legacy products, and a full PLA structure that allows for more logic flexibility and excellent pin-locking capability. The XPLA3 family is also pin compatible with the parts going end of life. If anyone would like more information on the legacy devices, your local Xilinx sales representative or hotline support personnel would be happy to help you convert to an even lower power CoolRunner XPLA3 device. Regards Betsy Thibault Xilinx Product Manager ex Philips Product Manager Nick Bruty wrote: > I have heard that a UK distributor is telling customers that Xilinx > Coolrunner parts are going obsolete? Any comments Xilinx? > > If any customers are in this position many of the parts are pin for pin with > Altera Max 7K & 3K families, it's what Philips used as a selling point for > Coolrunner, at least if your parts are going we can help. > > For UK customers please drop me a email and I'll happily help you convert > the designs free. > > Regards > > Nick Bruty > Altera FAE > Impact Memec > > ex Philips Coolrunner FAE --------------587EF0BA7C3D56D89BBFCA98 Content-Type: text/x-vcard; charset=us-ascii; name="betsyt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for betsy thibault Content-Disposition: attachment; filename="betsyt.vcf" begin:vcard n:Thibault;Betsy tel;cell:(408) 206-4491 tel;fax:(505) 858-3106 tel;work:(505) 798-4810 x-mozilla-html:FALSE org:<img src=http://www.xilinx.com/images/xlogoc.gif> adr:;;7801 Jefferson Street NE;Albuquerque;NM;87109;USA version:2.1 email;internet:Betsy.Thibault@xilinx.com title:CoolRunner Marketing fn:Betsy Thibault end:vcard --------------587EF0BA7C3D56D89BBFCA98--Article: 27564
Jonas Thor <thor@NOSPAMsm.luth.se> writes: > On Mon, 27 Nov 2000 22:22:32 GMT, longwayhome@my-deja.com wrote: > > >Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for > >hardware evolution, has anyone actually used it for that purpose ? What do you exactly mean with "hardware evolution". Improving hardware for some project? Or are you trying to used genetic algorithms to generate FPGA configurations? Or using FPGAs as co-processors to compute GAs for something else? Or? Perhaps if you tried to describe what you are trying to do, people here could help you in selecting. > >like to be able to program it with a C or Java API, is there suitable > >for that ? All suggestions welcome. Usual thing for programming FPGAs seems to be VHDL or Verilog. C: exists as Algorithm->FPGA (Handel-C, commercial) which is a sneered on method around here, and as C++ instantiate FPGA elements (CNets, open source, but still at beginning of development). Java: Xilinx has their JBits API/library, which is a low level (direct bitstrem manipulation) tool. But this only works with Virtex, not XC4000 nor VirtexE, according to jbits@xilinx.com. That would need the Xess XSV boards, not XS40 boards. I will be installing JBits tomorrow, now that I have recovered from the server HD trashed a week ago. > I supposed you have noticed that there is a JBITs interface avaiable > for that board? You can download it from XESS 'examples' web page. JBits for the XS40? Xilinx says JBits is not for XC4000 (it once was, but this support has been dropped). Hmmm, I just went to http://www.xess.com/ho03000.html (Example Designs). There are Jbits XHWIF for XS40-005XL and XSV-100. Does Xilinx not even know its own software? Looks like tomorrow is going to be interesting. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, MysticArticle: 27565
"Joel Kolstad" <JoelKolstad@Earthlink.Net> writes: > One problem we had with the Xilinx app note FIFOs is that they use pipelined > counters -- keeping around what the current gray count is, the next gray > count, etc., and incrementing them in lock step -- and on a somewhat random > basis the full and/or empty flags would go active when, indeed, we knew we > hadn't really overflowed or underflowed the FIFO. Our best guess as to the > cause of this was that we were using GSR as the reset input to the FIFO but > also asserting either REn or WEn just as GSR went inactive, and one of those > pipelined counters was getting corrupted (i.e., there was a race condition > between the various counter bits with GSR going inactive and a clock > arriving with REn or WEn active). (Note that the FIFO specifically allows > you to assert REn or WEn when the FIFO is empty of full, respectively; it > internal gates the signals so that they're ignored when neeeded.) > > I'd be curious to know if anybody else has had this experience. Well, to be honest, I studied that app note, and decided that it was just too damn complicated. There was another one there on FIFO design that used a latch <gasp!>, and I've decided to lean that way. I have grey counters for read and write pointers; obviously, asserting full is synchronous to the write clock, and deasserting it is synchronous to the read clock. And, of course, it's only logic using the write clock that cares if it's full. What I'm doing is latching the Full signal when my write clock is 'high'. That gives me a worst case of a half-clock-cycle for metastability events to settle, with the only caveat that Full might be deasserted one clock cycle late. But nobody cares about that, right? And, I'm internally gating the write operation with the Full signal, so that if my logic outside the Fifo doesn't want to look at the Full signal, it doesn't have to. If this is a nice and safe way to do it, then you're welcome! If it isn't, somebody please let me know! -KentArticle: 27566
Hi, everyone. I'm looking to impement a wide trinary compare function (32 bits), in once clock cycle. The bit-wise compare function consist of three bits; a Data bit (D), a Comparand bit (C), and a Mask bit (M). If the bit is masked with M, then the bit match is always a success. Otherwise it's a success only if D = C. This is easy enough, and takes up almost no logic. If all of the bitwise compare functions are a success, then the compare itself is a success, wheras if one fails, then the compare fails. This is basically a big 'ole and gate. Seeing as I want to do this in one clock cycle, and *really* don't want to pipeline it, is there a fancy way of implementing a wide AND-function? I was thinking of something along the lines of 32 trisate drivers and a pull-up. If one of them failes, it drives the common bus low; if none of them fail, the bus is pulled high, and a 'success' is registered. Unless I'm missing something (which is entirely possible), there is nothing like this on the inside of a Virtex/SpartanII FPGA. Does anyone have any other ideas or suggestions? Thanks a bunch, Kent.Article: 27567
Dear all,
after reading the thread
http://x58.deja.com/viewthread.xp?AN=694955633&search=thread&svcclass=dncurrent&ST=PS&CONTEXT=975460744.1523515397&HIT_CONTEXT=975460744.1523515397&HIT_NUM=10&recnum=%3c3A15D7F9.64FAD382@andraka.com%3e%231/1&group=comp.arch.fpga&frpage=viewthread.xp&back=clarinet
entitled "VHDL & Spartan: How to power-up a Register to '1'", I am
still confused. There are clearly two methods to initialize the flops:
either by putting an INIT attribute, like Ray suggested:
attribute INIT : string;
attribute INIT of FD1 : label is "S";
or by inferring a register from a process with an async reset driven
by GSR:
Reg : process (Clk, GSR)
begin
if Reset = '1' -- If asynchronous reset
then widget <= (others => '1');-- then set flop to one
elseif rising_edge(Clk) -- else if clock
then -- then whatever
...
end if;
end process;
These methods are obviously equivalent from a logic point of view,
but it's not clear if they turn into the same physical implementation.
The poster who started the thread was looking for a way to ensure that
after the end of FPGA configuration the register would hold the
specified set/reset values independently of any transition on GSR
line. I think that this is a relevant question since the use of GSR
as a driver for Reset has been deprecated in this group and by Xilinx
itself.
Any comments?
Best,
-Arrigo
Article: 27568Kent Orthner wrote: > > Hi, everyone. > > I'm looking to impement a wide trinary compare > function (32 bits), in once clock cycle. > > The bit-wise compare function consist of three > bits; a Data bit (D), a Comparand bit (C), and > a Mask bit (M). > > If the bit is masked with M, then the bit match > is always a success. Otherwise it's a success > only if D = C. This is easy enough, and takes > up almost no logic. > > If all of the bitwise compare functions are a > success, then the compare itself is a success, > wheras if one fails, then the compare fails. > This is basically a big 'ole and gate. > > Seeing as I want to do this in one clock cycle, > and *really* don't want to pipeline it, is > there a fancy way of implementing a wide > AND-function? I was thinking of something along > the lines of 32 trisate drivers and a pull-up. > If one of them failes, it drives the common bus > low; if none of them fail, the bus is pulled high, > and a 'success' is registered. Unless I'm missing > something (which is entirely possible), there is > nothing like this on the inside of a Virtex/SpartanII > FPGA. Actually, there is. For clues, take a look in the Libraries guide at the Virtex/SpartanII implementation of the COMPMC8. Basically what you would do would be to implement the logic for the three bits in the LUT, and use the output to control the S select of the MUXCY in the ripple carry chain. This chain is very fast, and should easily handle 32 bits for all but very fast clocks. The way I have done almost the exact same thing in one of my designs is to connect GND to all the DI inputs of the MUXCYs in the chain and connect VCC to the CI input of the first MUXCY in the chain. The rest are chained together the standard way with O of one MUXCY going to CI of the next one. At the top of the chain, the of the last MUXCY is low if any of the bit tests failed, else the VCC from the first MUX ripples all the way through and the result is a high. -- My real email is akamail.com@dclark (or something like that).Article: 27569
Arrigo Benedetti wrote: > > Dear all, > > after reading the thread > > http://x58.deja.com/viewthread.xp?AN=694955633&search=thread&svcclass=dncurrent&ST=PS&CONTEXT=975460744.1523515397&HIT_CONTEXT=975460744.1523515397&HIT_NUM=10&recnum=%3c3A15D7F9.64FAD382@andraka.com%3e%231/1&group=comp.arch.fpga&frpage=viewthread.xp&back=clarinet > > entitled "VHDL & Spartan: How to power-up a Register to '1'", I am > still confused. There are clearly two methods to initialize the flops: > either by putting an INIT attribute, like Ray suggested: > > attribute INIT : string; > attribute INIT of FD1 : label is "S"; > > or by inferring a register from a process with an async reset driven > by GSR: > > Reg : process (Clk, GSR) > begin > if Reset = '1' -- If asynchronous reset > then widget <= (others => '1');-- then set flop to one > elseif rising_edge(Clk) -- else if clock > then -- then whatever > ... > end if; > end process; > > These methods are obviously equivalent from a logic point of view, > but it's not clear if they turn into the same physical implementation. > The poster who started the thread was looking for a way to ensure that > after the end of FPGA configuration the register would hold the > specified set/reset values independently of any transition on GSR > line. I think that this is a relevant question since the use of GSR > as a driver for Reset has been deprecated in this group and by Xilinx > itself. > > Any comments? > > Best, > -Arrigo To the best of my knowledge, once you get this working correctly, they will produce an equivalent circuit in the FPGA. Some people think that adding the reset to every FF in your code will create a long signal that snakes through the design. But this signal is replaced by the GSR net in the FPGA. The GSR net is what puts all the FFs in a defined state when coming out of configuration. If you wish, you can use this as an external reset as well by bringing it to a pin. But that is not required. -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.comArticle: 27570
On Tue, 28 Nov 2000 09:43:23 -0800, "Walter Haas" <walter_haas@pmc-sierra.com> wrote: >Hi all, > >I access this forum through the Xilinx Support page, but I was hoping someone could tell me how I can access it through Netscape Navigator. > >Some fairly explicit instructions on what to set up in Navigator would be very helpful. > >Cheers, > >Wally Wally, you might consider using Forte Agent (or the free version Free Agent) as a newsreader. It's much better, faster, and more reliable than Netscape for accessing newsgroups. JohnArticle: 27571
Pete, Early ES material did not meet our speed targets. Production material does. I sent you some comments from the designer of the DLL to figure out if this is a slow ES part, or some other issue (as a non-newsgroup email). In future, you might also try the hotline as they could also answer the question of the actual performance of the lot of ES that you have. If you have the date code, I could also do that, but it might take me a little longer, Austin Lesea IC DES Xilinx Pete Dudley wrote: > Hello All, > > I am trying to use an XCV300e-8ES part to transmit and receive 16bit by > 622MHz sonet frames but I think I may be having problems with the DLL's at > that frequency. > > The chip has two 311MHz clocks coming into it, one for transmit and one for > receive. In order to indicate that my fpga is alive I am dividing the two > clocks by roughly 311,000,000 and flashing two LED's at about 1Hz. I have > noticed that after a while my LED's will stop flashing even though the > 311MHz input clocks are still present. > > On the transmit side I don't really care about the clock to Q times because > I'm sending a clock out with the data. This allowed me to eliminate the DLL > on the transmit clock and now my divider never stops flashing on that side. > On the receive side I must retain the DLL because input timing must be > controlled and the receive side LED still stops flashing after a few > minutes. > > Does anyone know if the Virtex E DLL's are marginal at 311MHz? > > I am working with engineering sample, ES, parts. What is the chance that > these parts are marginal and the problem would go away with real -8 parts? > > Any comments along this line would be appreciated. > > Thanks, > > -- > Pete Dudley > Sandia Labs > Albuquerque, NM > padudle@sandia.govArticle: 27572
> Kent Orthner wrote: > > > > Seeing as I want to do this in one clock cycle, > > and *really* don't want to pipeline it, is > > there a fancy way of implementing a wide <snip> > > nothing like this on the inside of a Virtex/SpartanII > > FPGA. > Duane <junkmail@junkmail.com> writes: > Actually, there is. For clues, take a look in the Libraries guide at the <snip> > the way through and the result is a high. Duane, Thanks. This is exactly the kind of "Fancy way" that I was looking for. In the data book it shown Cin to Cout delay to be 0.2ns max, which should give me 6.4 ns for the entire thing. I'm hoping for 9.6ns for everything, including the compare, but maybe I'm being too optimistic. (I'm stuck with the cheapest speed grade, after all.) Maybe I'll run it as a tree of CinCout chains or something; we'll see. Thanks for the advice. On a side note, when I look at the CY Muxes, do you know what the 'BX' input is, and what it's for? -KentArticle: 27573
"Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message news:901ckf$2h1q$1@noao.edu... > Are you sure you weren't being screwed by the simulation model? No, it worked fine in simulation, it was the real design PARed on the real live PCB that had problems! ---JoelArticle: 27574
why not use an already debugged FIFO core? Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I believe). "j" <j@j.com> wrote in message news:8vrkt0$fk8$1@uranium.btinternet.com... > Hi, > I am new to vhdl/FPGA design, I am designing a FIFO who's read and > write ports operate on different clocks at different frequencies. I am > keeping track of how full/empty the FIFO is by using a counter that > increments during a write and decrements during a read. This presents a > problem as when a read and write occur simultaneously the counter will not > function correctly. > How do I solve this, should I adopt a different approach to keep a count to > generate the full and half full flags ? > > Thanks > > J > >
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