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
WebPack Projects are not accepted by CoreGen. Maybe I miss something. Anyway... I hope to get Foundation ISE 4.1 soon THX -ManfredArticle: 35551
Hello, I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I can use, I have to count an external recovered clock of 155MHz in a 32 bit counter and set the result in a register and when software requires the value can read it. I would like to connect the 155 MHz clock to an IBUFG and then to a DLL (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I can read with my 33.33 MHz clock. The other possibility is avoiding this "high" frequency using an external divider by 4 i.e. and get a 38.75 clock to a DLL (CLKDLL) and divide by 2 i.e. Any suggestions? In the Spartan II Datasheets the maximum frequency for a CLKDLLHF is 180 MHz. Is it too close? My previous experience with Spartan II DLL is quite good so I trust it, but I would like if someone could give some idea. Thank you in advance. Ulises Hernandez ECS TechnologyArticle: 35553
--------------A34FA2E82DD47EF2394C7588 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Himanshu, I agree that data sheets don't answer the question so ---- Virtex II circuits support clocks running at 420 MHz on the global buffers. That does not mean that you can make the entire design run that fast, but small selected portions can certainly operate that fast. Two techniques used commonly with the Virtex II are the use of the DCM to provide clock multiplication, so the external clock is lower than the internal clock, and the use of the duty cycle correction features (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted, and CLKFX and CLKFX180 are always duty cycle corrected) allow for Double Data Rate (DDR) internal design techniques, doubling the work per clock cycle (using both edges of the clock). Thus selected portions of the chip may process information at 840 Mb/s. Typical larger designs are running in the ~300 MHz range without too much effort, as compared to ~ 180 MHz for Virtex E, and ~ 100 MHz for Virtex. (Typical driver, typical course, no special instructions required: your results may vary with effort and expertise!) Getting the data in and out is the next problem after the internal processing, and the LVDS IO allows for data buses of ~16 bits running at ~700 Mb/s DDR rates, and the 840 Mb/s rates with some careful placement. One major warning is that this is now a microwave world! Signal integrity at these frequencies is serious business, and I warn all developers to make a concerted effort to get smart fast by reading Howard Johnson's book on signal integrity, taking a class, and then simulating and learning. These classes and books are the best we have, but remember, they are teaching, and they have not been designing with 400 MHz clocks, as we are now, so some of their information is out of date, obsolete, and just plain wrong -- but most is very useful! As well, the quality of results from the software has been steadily improving, with the latest clock speeds getting easier to implement as the tools get better. 4.1i has set a new performance watermark, and re-running old Virtex E designs has led to significant performance (>10%, or a speed grade) improvements for some customers. Again, it all depends on your design, and how it is architected, but Virtex II has been very well accepted, and I continually hear from customers how "Virtex II now makes life interesting as it competes with the ASICs I was planning on having to design." Austin Speedy Zero Two wrote: > Do they not provide that in the datasheet? > > "himanshu" <himan_2000@indiatimes.com> wrote in message > news:adf7cebe.0110080015.832fe8d@posting.google.com... > > Hi, > > can any body tell me what is the maximum clock speed at which xilinx > > virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock > > rate they can provide. do i have to divide that frequency for clock > > stability? > > Thanks in advance > > Himanshu --------------A34FA2E82DD47EF2394C7588 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Himanshu, <p>I agree that data sheets don't answer the question so ---- <p>Virtex II circuits support clocks running at 420 MHz on the global buffers. <p>That does not mean that you can make the entire design run that fast, but small selected portions can certainly operate that fast. <p>Two techniques used commonly with the Virtex II are the use of the DCM to provide clock multiplication, so the external clock is lower than the internal clock, and the use of the duty cycle correction features (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted, and CLKFX and CLKFX180 are always duty cycle corrected) allow for Double Data Rate (DDR) internal design techniques, doubling the work per clock cycle (using both edges of the clock). <p>Thus selected portions of the chip may process information at 840 Mb/s. <p>Typical larger designs are running in the ~300 MHz range without too much effort, as compared to ~ 180 MHz for Virtex E, and ~ 100 MHz for Virtex. <p>(Typical driver, typical course, no special instructions required: your results may vary with effort and expertise!) <p>Getting the data in and out is the next problem after the internal processing, and the LVDS IO allows for data buses of ~16 bits running at ~700 Mb/s DDR rates, and the 840 Mb/s rates with some careful placement. <p>One major warning is that this is now a <b>microwave world!</b> Signal integrity at these frequencies is serious business, and I warn all developers to make a concerted effort to get smart fast by reading Howard Johnson's book on signal integrity, taking a class, and then simulating and learning. These classes and books are the best we have, but remember, they are teaching, and they have not been designing with 400 MHz clocks, as we are now, so some of their information is out of date, obsolete, and just plain wrong -- but most is very useful! <p>As well, the quality of results from the software has been steadily improving, with the latest clock speeds getting easier to implement as the tools get better. 4.1i has set a new performance watermark, and re-running old Virtex E designs has led to significant performance (>10%, or a speed grade) improvements for some customers. <p>Again, it all depends on your design, and how it is architected, but Virtex II has been very well accepted, and I continually hear from customers how "Virtex II now makes life interesting as it competes with the ASICs I was planning on having to design." <p>Austin <p>Speedy Zero Two wrote: <blockquote TYPE=CITE>Do they not provide that in the datasheet? <p>"himanshu" <himan_2000@indiatimes.com> wrote in message <br><a href="news:adf7cebe.0110080015.832fe8d@posting.google.com">news:adf7cebe.0110080015.832fe8d@posting.google.com</a>... <br>> Hi, <br>> can any body tell me what is the maximum clock speed at which xilinx <br>> virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock <br>> rate they can provide. do i have to divide that frequency for clock <br>> stability? <br>> Thanks in advance <br>> Himanshu</blockquote> </html> --------------A34FA2E82DD47EF2394C7588--Article: 35554
Andrew Gray wrote:
> When I compile the project Maxplus generates the error:
> Warning: Ignored unneccessary INPUT pin 'Data_Train'
>
Sounds like there is a missing signal
declaration and/or assignment.
Post your code.
Consider using simulation before synthesis.
--Mike Treseler
Article: 35555Clock recovery is a very important part of receivers and is discussed pretty much in every communications text. There are various methods to perform this function, but some of the common methods are well described (Ray just described one using PLLs). If you want to perform this block in real time at that kind of data rates...FPGAs/ASICs are your only choice. But if you can store a large amount of data and post process this, you can probably do this on a DSP. Search for key words like clock recovery, Costas Loop, etc. I doubt if you will find detailed examples of implementation other than descriptions on how this is typically done. -- Cheers Bhaskar Note: I do *not* check the listed email address. "eas" <eas@bi.net.tr> wrote in message news:99802a4d.0110100621.43365016@posting.google.com... > Dear All, > I have obtained the I and Q signals using a qpsk demodulator IC. > What I need is to derive the clock from the I Q data. This must be a > simple task, but could not find any examples. The data rate is > >10Mbps. What kind of DSP-FPGA combination is needed? Are there any > DSP or VHDL sources? > > ThanksArticle: 35556
Peter, I think I talked to you when we were having the problem about 10 years ago. All of our designs have a reset controller anyhow, so this was a mod with only moderate pain (figuring it out, however, is a different level of pain). I drive the DONE pin with the reset controller thru a Shottky diode. This, in turn, is the reset input to the rest of the logic/processor, guaranteeing that the FPGA is configured before the processor starts running. Tom Peter Alfke <palfke@earthlink.net> wrote in message news:<3BC3AC3C.3007C379@earthlink.net>... > Did you make the recommended connection: INIT driving the SPROM Reset ? > Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way > back in the XC3000 data sheet. ( I remember, I was the one putting it in, and even explaining the reason > > why ). Without that connection you can encounter all sorts of grief... > With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it > is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs. > But I am listening...One never stops learning. > > Peter Alfke, Xilinx Applications > =============================== > > Tom Seim wrote: > > > My greatest grief with Xilinx (right after the blunder Xilinx made > > switching suppliers of the serial proms - the new supplier couldn't > > deliver as scheduled and the old one had been axed) has been the > > power-up sequencing. The FPGAs and serial proms have internal power-up > > sequencing circuitry so you think: "I'm ok using that". Wrong. > > I have seen the serial prom & FPGA get out of sync due to either too > > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong > > moment. The serial prom's address counter will keep going & eventually > > recycle, but this takes forever! I've ALWAYS used a seperate power > > reset circuit after that. > > > > "Austin Franklin" <austin@darkroom88.com> wrote in message news:<ts62seat66qg87@corp.supernews.com>... > > > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > > > it is dedicated copper...and can be used for nothing else. If you do NOT > > > use GSR, and have a reset in your design (as you probably should) you are > > > using regular routing resources for this possibly very prolific global net. > > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > > > attached to GSR, or it will use regular routing resources. > > > > > > Why are using regular routing resources bad? If your design is quite full, > > > it can significantly impact timing and tool run time. One design I had in > > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > > > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > > > and design such that this does not create any problems with your design. It > > > just takes a little understanding of how your design works, and a bit of > > > engineering. > > > > > > "jas" <jasjasjasjas@hotmail.com> wrote in message > > > news:fe3da0d7.0110082249.42642566@posting.google.com... > > > > Hi, > > > > > > > > Are there timing issues on a Spartan device if the reset is > > > > asynchronous to the system clock, i.e could a problem occur where by > > > > the device is taken out of reset on the active clock edge, hence > > > > certain registers in the device remain in reset and the others are > > > > not. If so how is this solved, by registering the reset and not > > > > reseting that register?. > > > > > > > > Thanks > > > > > > > > jonArticle: 35557
Maybe we can make the lawyers do logic design & we can dream up contracts to make their collective lives miserable. "Austin Franklin" <austin@dar87kroom.com> wrote in message news:<ts7f3mcvi2r3e5@corp.supernews.com>... > I know this is "controversial" but this kind of crap just really "irks" > me... > > > I have been advised that the sharing of benchmark data concerning at > > least one of these two products is a violation of the license agreement of > > that product, and this may be true of the other product. > > I am curious who "advised" you? > > I'm also curious as to the actual enforceable legality of such an inclusion > into the license agreement. An agreement can contain anything it wants > (they can even ask you to agree to not pick your nose while using their > tools), but whether it's legally enforceable is another matter entirely. > > This is my take on it...and is only my opinion. If this purported violation > even has any legal grounds... It's certainly not a criminal activity...and > not being such, it has to fall into civil litigation. In civil cases, you > have to prove damages...and as far as I know, stating something that is > factually true, unless done maliciously, does not give grounds for damages. > > Can you imagine a company suing someone because they published a benchmark > that showed that their product actually sucked? > > Anyone know anything about this...aside from that it's childish to even put > such a clause in a license agreement in the first place... > > Imagine buying a car (or a pencil for that matter) that came with a "license > agreement" that you could not "share" the comparison of your car (or pencil) > with any other car...think about how, well, just plain silly (and pathetic) > that is.Article: 35558
Austin Lesea schrieb: > > Himanshu, > > I agree that data sheets don't answer the question so ---- > > Virtex II circuits support clocks running at 420 MHz on the global > buffers. > > That does not mean that you can make the entire design run that fast, > but small selected portions can certainly operate that fast. Hmm, but If I have a design, heavy pipelined, well floorplanned (its getting theoretical ;-), just 2 LUT levels between FFs, can this run @400 MHz? Or even 500, when just 1 LUT is used between FFs? > Two techniques used commonly with the Virtex II are the use of the DCM > to provide clock multiplication, so the external clock is lower than > the internal clock, and the use of the duty cycle correction features > (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted, > and CLKFX and CLKFX180 are always duty cycle corrected) allow for > Double Data Rate (DDR) internal design techniques, doubling the work > per clock cycle (using both edges of the clock). Hmm, very good point. Does anybody here has informationas about DDR basics, design and common pitfalls (and how to avoid them). Also DDR Xmission on board level? > > Thus selected portions of the chip may process information at 840 > Mb/s. No problem with a 64 bit bus inside, its just 13 MHz ;-) > One major warning is that this is now a microwave world! Signal > integrity at these frequencies is serious business, and I warn all > developers to make a concerted effort to get smart fast by reading > Howard Johnson's book on signal integrity, taking a class, and then > simulating and learning. These classes and books are the best we > have, but remember, they are teaching, and they have not been > designing with 400 MHz clocks, as we are now, so some of their > information is out of date, obsolete, and just plain wrong -- but most > is very useful! Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about an new issue, updated with todays devices (and their problems) ?? > As well, the quality of results from the software has been steadily > improving, with the latest clock speeds getting easier to implement as > the tools get better. 4.1i has set a new performance watermark, and > re-running old Virtex E designs has led to significant performance > (>10%, or a speed grade) improvements for some customers. Hmm but this is getting into the marketing stuff . . . .;-) Even the new software cant beat an engineer with real understanding of the FPGA structures, and much worse it cant fix the problems caused by an really unexpierienced designer. Or am I wrong? > Again, it all depends on your design, and how it is architected, but > Virtex II has been very well accepted, and I continually hear from > customers how "Virtex II now makes life interesting as it competes > with the ASICs I was planning on having to design." He did it AGAIN. Marketing alert ;-) Serious, I can believe that the Virtex-II is a very nice device althrough up to now I had no possibility to use one for a design :-( -- MFG FalkArticle: 35559
Ulises Hernandez schrieb: > > Hello, > > I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I > can use, I have to count an external recovered clock of 155MHz in a 32 bit > counter and set the result in a register and when software requires the > value can read it. > > I would like to connect the 155 MHz clock to an IBUFG and then to a DLL > (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I > can read with my 33.33 MHz clock. Why do you want to divide it down? As far as I can see, you want some kind of frequncy counter? Ok, a 32 bit counter on 155 MHz cant be directly created in a Spatan-II, you have to use some kind of pipelining/carry bit registering. But the 155 Mhz inside the Spartan-II for such a simple task is Non-critical to me. Just use a global clock buffer to avoid pitfalls. -- MFG FalkArticle: 35560
Falk Brunner wrote: > Ulises Hernandez schrieb: > > > > Hello, > > > > I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I > > can use, I have to count an external recovered clock of 155MHz in a 32 bit > > counter and set the result in a register and when software requires the > > value can read it. > > > > I would like to connect the 155 MHz clock to an IBUFG and then to a DLL > > (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I > > can read with my 33.33 MHz clock. > > Why do you want to divide it down? As far as I can see, you want some > kind of frequncy counter? > Ok, a 32 bit counter on 155 MHz cant be directly created in a Spatan-II, > you have to use some kind of pipelining/carry bit registering. > But the 155 Mhz inside the Spartan-II for such a simple task is > Non-critical to me. Just use a global clock buffer to avoid pitfalls. As I understand it, the problem is how to interface values that are computed using the 155 MHz Clock to logic running at the PCI Clock that is asynchronous to the fast clock. There are some metastability wizards in this newsgroup that propably can better explain the possible solutions than I can. Kolja SulimmaArticle: 35561
You are now describing something different, and it seems to work well. I was addressing your original complaint about SPROM and FPGA getting out of sync with respect to each other. That should never occur if INIT resets the SPROM. Peter Alfke, Xilinx Applications =============================== Tom Seim wrote: > Peter, > > I think I talked to you when we were having the problem about 10 years > ago. All of our designs have a reset controller anyhow, so this was a > mod with only moderate pain (figuring it out, however, is a different > level of pain). I drive the DONE pin with the reset controller thru a > Shottky diode. This, in turn, is the reset input to the rest of the > logic/processor, guaranteeing that the FPGA is configured before the > processor starts running. > > Tom > > Peter Alfke <palfke@earthlink.net> wrote in message news:<3BC3AC3C.3007C379@earthlink.net>... > > Did you make the recommended connection: INIT driving the SPROM Reset ? > > Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way > > back in the XC3000 data sheet. ( I remember, I was the one putting it in, and even explaining the reason > > > > why ). Without that connection you can encounter all sorts of grief... > > With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it > > is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs. > > But I am listening...One never stops learning. > > > > Peter Alfke, Xilinx Applications > > =============================== > > > > Tom Seim wrote: > > > > > My greatest grief with Xilinx (right after the blunder Xilinx made > > > switching suppliers of the serial proms - the new supplier couldn't > > > deliver as scheduled and the old one had been axed) has been the > > > power-up sequencing. The FPGAs and serial proms have internal power-up > > > sequencing circuitry so you think: "I'm ok using that". Wrong. > > > I have seen the serial prom & FPGA get out of sync due to either too > > > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong > > > moment. The serial prom's address counter will keep going & eventually > > > recycle, but this takes forever! I've ALWAYS used a seperate power > > > reset circuit after that. > > > > > > "Austin Franklin" <austin@darkroom88.com> wrote in message news:<ts62seat66qg87@corp.supernews.com>... > > > > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > > > > it is dedicated copper...and can be used for nothing else. If you do NOT > > > > use GSR, and have a reset in your design (as you probably should) you are > > > > using regular routing resources for this possibly very prolific global net. > > > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > > > > attached to GSR, or it will use regular routing resources. > > > > > > > > Why are using regular routing resources bad? If your design is quite full, > > > > it can significantly impact timing and tool run time. One design I had in > > > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > > > > > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > > > > and design such that this does not create any problems with your design. It > > > > just takes a little understanding of how your design works, and a bit of > > > > engineering. > > > > > > > > "jas" <jasjasjasjas@hotmail.com> wrote in message > > > > news:fe3da0d7.0110082249.42642566@posting.google.com... > > > > > Hi, > > > > > > > > > > Are there timing issues on a Spartan device if the reset is > > > > > asynchronous to the system clock, i.e could a problem occur where by > > > > > the device is taken out of reset on the active clock edge, hence > > > > > certain registers in the device remain in reset and the others are > > > > > not. If so how is this solved, by registering the reset and not > > > > > reseting that register?. > > > > > > > > > > Thanks > > > > > > > > > > jonArticle: 35562
The Spartan II DLL will indeed run at 155MHz, although you may find you are
better off supplying a 1/2x clock externally and doubling it with the PLL. You
may have trouble getting a 155MHz board level clock into the chip cleanly.
Once inside, I am assuming you are dealing with a 155 mbit serial stream which
you need to somehow capture and reliably sync to your PCI clock at 33.33 MHz.
Use a shift register clocked at the 155 Mbits to turn that into a 16 bit
parallel word, copying it to a parallel register every 16th cycle of the 155 MHz
clock. Toggle a T flip-flop at the same time you load the register, synchronize
that toggle signal to the 33 mHz domain, then with a state machine running at
33MHz, use the edges of the synchronized toggle signal to enable a transfer of
data from the holding register in the 155 to a second register in the 33 mHz
domain. You may need a pipeline register in the data path to make sure the data
is stable around the 33 MHz enable signal. That enable signal, delayed by 1
clock becomes your data valid out.
Alternatively, you can use a block RAM to do your rate matching. You won't get
the BRAM to run at 155, but you can write two bits at a time so that it runs at
the 76MHz on the write side. On the read side, you can pull data out 16 bits at
a time easily on the PCI clock. YOu'll need some logic to generate your status
flags. IIRC, the Xilinx async fifos have the same width on both sides of the
fifo so you can't use them directly. You can however use bit 2 of your write
pointer, synchronize it to the 33 MHz domain to generate a 1 cycle wide pulse
that increments an up down counter to track how many words are in the buffer.
Ulises Hernandez wrote:
> Hello,
>
> I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I
> can use, I have to count an external recovered clock of 155MHz in a 32 bit
> counter and set the result in a register and when software requires the
> value can read it.
>
> I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
> (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I
> can read with my 33.33 MHz clock.
> The other possibility is avoiding this "high" frequency using an external
> divider by 4 i.e. and get a 38.75 clock to a DLL (CLKDLL) and divide by 2
> i.e.
>
> Any suggestions? In the Spartan II Datasheets the maximum frequency for a
> CLKDLLHF is 180 MHz. Is it too close? My previous experience with Spartan II
> DLL is quite good so I trust it, but I would like if someone could give some
> idea.
>
> Thank you in advance.
>
> Ulises Hernandez
> ECS Technology
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35563
That 10% is definitely a marketing number. 4.1 does that, and perhaps even
a little more for a design that is, well... average (perhaps mediocre would
be a better word). For well executed, floorplanned designs, it seems to not
do quite as well as 3.3sp8, although that is a very small sample set at the
moment. So the initial indication is that perhaps it has improved
placement, but perhaps something got degraded in routing as part of the
compile time vs. results trade. Overall, the 4.1 seems to be a sizable
improvement for the average user.
Falk Brunner wrote:
> Austin Lesea schrieb:
> >
> > Himanshu,
> >
> > I agree that data sheets don't answer the question so ----
> >
> > Virtex II circuits support clocks running at 420 MHz on the global
> > buffers.
> >
> > That does not mean that you can make the entire design run that fast,
> > but small selected portions can certainly operate that fast.
>
> Hmm, but If I have a design, heavy pipelined, well floorplanned (its
> getting theoretical ;-), just 2 LUT levels between FFs, can this run
> @400 MHz? Or even 500, when just 1 LUT is used between FFs?
>
> > Two techniques used commonly with the Virtex II are the use of the DCM
> > to provide clock multiplication, so the external clock is lower than
> > the internal clock, and the use of the duty cycle correction features
> > (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted,
> > and CLKFX and CLKFX180 are always duty cycle corrected) allow for
> > Double Data Rate (DDR) internal design techniques, doubling the work
> > per clock cycle (using both edges of the clock).
>
> Hmm, very good point. Does anybody here has informationas about DDR
> basics, design and common pitfalls (and how to avoid them).
> Also DDR Xmission on board level?
>
> >
> > Thus selected portions of the chip may process information at 840
> > Mb/s.
>
> No problem with a 64 bit bus inside, its just 13 MHz ;-)
>
>
> > One major warning is that this is now a microwave world! Signal
> > integrity at these frequencies is serious business, and I warn all
> > developers to make a concerted effort to get smart fast by reading
> > Howard Johnson's book on signal integrity, taking a class, and then
> > simulating and learning. These classes and books are the best we
> > have, but remember, they are teaching, and they have not been
> > designing with 400 MHz clocks, as we are now, so some of their
> > information is out of date, obsolete, and just plain wrong -- but most
> > is very useful!
>
> Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about
> an new issue, updated with todays devices (and their problems) ??
>
> > As well, the quality of results from the software has been steadily
> > improving, with the latest clock speeds getting easier to implement as
> > the tools get better. 4.1i has set a new performance watermark, and
> > re-running old Virtex E designs has led to significant performance
> > (>10%, or a speed grade) improvements for some customers.
>
> Hmm but this is getting into the marketing stuff . . . .;-)
> Even the new software cant beat an engineer with real understanding of
> the FPGA structures, and much worse it cant fix the problems caused by
> an really unexpierienced designer.
> Or am I wrong?
>
> > Again, it all depends on your design, and how it is architected, but
> > Virtex II has been very well accepted, and I continually hear from
> > customers how "Virtex II now makes life interesting as it competes
> > with the ASICs I was planning on having to design."
>
> He did it AGAIN. Marketing alert ;-)
>
> Serious, I can believe that the Virtex-II is a very nice device
> althrough up to now I had no possibility to use one for a design :-(
>
> --
> MFG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35564Kolja Sulimma schrieb: > > > Non-critical to me. Just use a global clock buffer to avoid pitfalls. > > As I understand it, the problem is how to interface values that are computed using > the 155 MHz Clock to logic running at the PCI Clock that is > asynchronous to the fast clock. > There are some metastability wizards in this newsgroup that propably can better > explain the possible solutions than I can. This is another thing, but for a frequency counter its not too hard, even for Non-Metastability Wizzards ;-) My proposal. Use a counter on the 33 MHz clock to generate a gate pulse (lets say 1 second). Drive this gate pulse directly with a FF to the 155 Mhz circuty. Use 1 two or three cascaded FF on the 155 MHz clock to sychronize the gate pulse to the 155 Mhz clock. Use it thereafter as an clock enable for the 155 MHz counters. Thats almost all. When the gate pulse on the 33 MHz clock goes low, wait some more cycles (lets say 10) to be sure the 155 MHz counter is really stopped. Now read the content of the 155 Mhz counter. -- MFG FalkArticle: 35565
"S. Ramirez" wrote: > Dear Newsgroup Members, > I have been advised that the sharing of benchmark data concerning at > least one of these two products is a violation of the license agreement of > that product, and this may be true of the other product. > Please do not send me any benchmarking data that you may have obtained > in any manner from these products. > Thank you very much. > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA > > That's outrageous and I sympathise. From the way your email's been phrased, the lawyers for X or Y have told you not even to identify which of the two is behaving in this appalling fashion so we can ``name & shame''. Do they share a law firm with R****S ? What company apparachiks like this don't realise is that the information will come out anyway but in a much more damaging fashion.Article: 35566
Tom Seim wrote: > Maybe we can make the lawyers do logic design & we can dream up > contracts to make their collective lives miserable. > > You would end up with FFs that have to be paid $100's for each toggle.Article: 35567
Rick Filipkiewicz wrote: > > Tom Seim wrote: > > > Maybe we can make the lawyers do logic design & we can dream up > > contracts to make their collective lives miserable. > > > > > > You would end up with FFs that have to be paid $100's for each toggle. Close, but incorrect :-) You would end up with FFs that have to be paid $100's for each side of the toggle/not toggle argument, but an actual toggle would not necessairly result. -jgArticle: 35568
Jim Granville wrote: > Rick Filipkiewicz wrote: > > > > Tom Seim wrote: > > > > > Maybe we can make the lawyers do logic design & we can dream up > > > contracts to make their collective lives miserable. > > > > > > > > > > You would end up with FFs that have to be paid $100's for each toggle. > > Close, but incorrect :-) > > You would end up with FFs that have to be paid $100's for each side > of the toggle/not toggle argument, but an actual toggle would > not necessairly result. > > -jg Closer :-)) Definition: Metastable - That state in which lawyers tend to remain for as long as the money holds out.Article: 35569
More wacky synthesis results from Synplicity:
(Note that this sort of thing isn't specific to
Synplicity. Leonardo does a lot of wacky things too.
Sadly, Synplicity is probably the better tool.)
You'd think a simple 56-bit counter would be no
problem. The code below should synthesize to
1 logic level using 56 LUTs, 56 FFs and a carry chain.
Instead, Synplicity adds an extra 57 LUTs and an extra
level of logic.
module Cnt56(K, CE, R, Out);
input K, CE, R;
output [55:0] Out;
reg [55:0] Q;
assign Out= Q;
always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
// if (R) Q <= 0; // This doesn't work either
// else if (CE) Q <= Q+1;
endmodule
Why? Instead of running the R signal directly to the
reset pin of the flip flop, Synplicity merges it into
the equations for Q and CE. So we get:
module Cnt56(K, CE, R, Out);
input K, CE, R;
output [55:0] Out;
reg [55:0] Q;
assign Out= Q;
wire [55:0] Q_plus_1 = Q+1;
wire [55:0] Q_and_R = R ? Q_plus_1 : 0;
wire CE_or_R = CE | R;
always @(posedge K) if (CE_or_R) Q <= Q_and_R;
endmodule
Workaround? I guess I have to instantiate an array of
56 flip flops and connect the signals the correct way.
This is really ugly, and makes my design Xilinx-specific.
If I want to use an Altera chip, I have to re-write the
code.
Which brings me to my point:
High level, abstract synthesis will never work well. I realize
this is an extreme statement, but if today's synthesizers can't
do better than a factor of 2 for really simple code, it's
hard to imagine a synthesizer in the near future that can
compile complex code efficiently.
Article: 35570Don Husby wrote: > More wacky synthesis results from Synplicity: > > (Note that this sort of thing isn't specific to > Synplicity. Leonardo does a lot of wacky things too. > Sadly, Synplicity is probably the better tool.) > > You'd think a simple 56-bit counter would be no > problem. The code below should synthesize to > 1 logic level using 56 LUTs, 56 FFs and a carry chain. > Instead, Synplicity adds an extra 57 LUTs and an extra > level of logic. > > module Cnt56(K, CE, R, Out); > input K, CE, R; > output [55:0] Out; > reg [55:0] Q; > assign Out= Q; > always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q; > // if (R) Q <= 0; // This doesn't work either > // else if (CE) Q <= Q+1; > endmodule > > Why? Instead of running the R signal directly to the > reset pin of the flip flop, Synplicity merges it into > the equations for Q and CE. So we get: > > module Cnt56(K, CE, R, Out); > input K, CE, R; > output [55:0] Out; > reg [55:0] Q; > assign Out= Q; > > wire [55:0] Q_plus_1 = Q+1; > wire [55:0] Q_and_R = R ? Q_plus_1 : 0; > wire CE_or_R = CE | R; > > always @(posedge K) if (CE_or_R) Q <= Q_and_R; > endmodule > > Workaround? I guess I have to instantiate an array of > 56 flip flops and connect the signals the correct way. > This is really ugly, and makes my design Xilinx-specific. > If I want to use an Altera chip, I have to re-write the > code. > > Which brings me to my point: > High level, abstract synthesis will never work well. I realize > this is an extreme statement, but if today's synthesizers can't > do better than a factor of 2 for really simple code, it's > hard to imagine a synthesizer in the near future that can > compile complex code efficiently. On the specific point you are right in that Synplify doesn't appear to be using resources efficiently in this case. Esp since it does the reset function by first inverting the reset input and then feeding the inverted value into the adder LUTs - missing a clear opportunity to optimise. The MAP program may do this for you later on. A work-around is to use an async reset. On the more general case IMO you are missing some of the idea behind synthesis from HDLs. This is to get the results you need from the most portable/maintainable/reuseable/retargetable source format. This is very much in the spirit of the `C' vs. Assembler debate of long ago. Memory got bigger and cheaper, uPs got faster, and compilers got better => Assembler went Dodo for all but a handful of special cases. Similarly FPGA and ASICs are getting bigger and faster so the inefficiencies of synthesised code will become less important [synth tools are getting better as well, as are FPGA/ASIC P&R tools]. Again IMO the question you need to ask is whether the synth'ed result meets your needs in terms of speed/timing. If not then the second level question is whether, in a time2market dominated industry, going up a speed grade is better than spending a lot of time hand-tuning the logic. Its always possible to hand-craft technology specific logic that goes faster - the question is whether its worth it. YMMV.Article: 35571
Hi folks! I'm a student and i need a free PCI-Core wich is written in vhdl. Where could I download it ? Greets Rasit -- Posted from alcatraz148.wohnheim.uni-kl.de [131.246.107.157] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 35572
I never saw the original question, but when Falk mentions frequencycounter,it caught my attention. The best way to count a frequency is a ripple counter with the first flip-flop count-enabled by the gate signal. Don't even use the carry chain, it serves no purpose in this scheme. It also makes more sense to concatenate dibits, since the two flip-flops in a slice share a common clock. After the end of the gate time ( 1 sec?) wait a little ( 16 ripples might take 50 ns ) Then the counter outputs are stable and there are no metastability issues when you read it at any frequency. Reading a running counter on-the-fly with a different clock from its count clock is almost impossible, but that does not seem to be the problem here. Peter Alfke ( working on a 1-GHz frequency-counter design ) . The only synchronization "problem" is in the counter LSB. But since that is a single flip-flop, it either toggles or it does not, and that represents the unavoidable LSB uncertainty. Falk Brunner wrote: > Kolja Sulimma schrieb: > > > > > Non-critical to me. Just use a global clock buffer to avoid pitfalls. > > > > As I understand it, the problem is how to interface values that are computed using > > the 155 MHz Clock to logic running at the PCI Clock that is > > asynchronous to the fast clock. > > There are some metastability wizards in this newsgroup that propably can better > > explain the possible solutions than I can. > > This is another thing, but for a frequency counter its not too hard, > even for Non-Metastability Wizzards ;-) > > My proposal. Use a counter on the 33 MHz clock to generate a gate pulse > (lets say 1 second). > Drive this gate pulse directly with a FF to the 155 Mhz circuty. Use 1 > two or three cascaded FF on the 155 MHz clock to sychronize the gate > pulse to the 155 Mhz clock. Use it thereafter as an clock enable for the > 155 MHz counters. > Thats almost all. When the gate pulse on the 33 MHz clock goes low, wait > some more cycles (lets say 10) to be sure the 155 MHz counter is really > stopped. Now read the content of the 155 Mhz counter. > > -- > MFG > FalkArticle: 35574
Falk, I will comment below, Austin Falk Brunner wrote: > Austin Lesea schrieb: > > > > Himanshu, > > > > I agree that data sheets don't answer the question so ---- > > > > Virtex II circuits support clocks running at 420 MHz on the global > > buffers. > > > > That does not mean that you can make the entire design run that fast, > > but small selected portions can certainly operate that fast. > > Hmm, but If I have a design, heavy pipelined, well floorplanned (its > getting theoretical ;-), just 2 LUT levels between FFs, can this run > @400 MHz? Or even 500, when just 1 LUT is used between FFs? Hand placement leads to wonderful performance, but it leads to unmaintainable designs. > > > > Two techniques used commonly with the Virtex II are the use of the DCM > > to provide clock multiplication, so the external clock is lower than > > the internal clock, and the use of the duty cycle correction features > > (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted, > > and CLKFX and CLKFX180 are always duty cycle corrected) allow for > > Double Data Rate (DDR) internal design techniques, doubling the work > > per clock cycle (using both edges of the clock). > > Hmm, very good point. Does anybody here has informationas about DDR > basics, design and common pitfalls (and how to avoid them). > Also DDR Xmission on board level? All good points, and we are woefully behind on the supporting applications notes. They are in progress, but late. Basically, duty cycle is as important as jitter (because it directly affects the eye sampling point), jitter must be minimized on the incoming clock signal, all signals must be matched receivers and drivers, as any reflections will kill your timing budget, cross talk induced delay is importnat as it creates inter-symbol inteference in busses, and skew int eh bus must be kept under control (probably the easiest requirement as this is just physical distance). One really neat feature is the variable phase shift, which one uses to verify the eye opening! Oops, I'm sorry, that sounded like marketing....but I plead that it is still a really neat engineering feature to verify the eye opening without having to buy a $$$$$$$ instrument. > > > > > > Thus selected portions of the chip may process information at 840 > > Mb/s. > > No problem with a 64 bit bus inside, its just 13 MHz ;-) > Per wire. > > > > One major warning is that this is now a microwave world! Signal > > integrity at these frequencies is serious business, and I warn all > > developers to make a concerted effort to get smart fast by reading > > Howard Johnson's book on signal integrity, taking a class, and then > > simulating and learning. These classes and books are the best we > > have, but remember, they are teaching, and they have not been > > designing with 400 MHz clocks, as we are now, so some of their > > information is out of date, obsolete, and just plain wrong -- but most > > is very useful! > > Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about > an new issue, updated with todays devices (and their problems) ?? > We are working on selected critical issues: advanced bypassing techniques, control of jitter, high speed bus issues (alluded to above), living with extremely low voltage Vccint vs high voltage IO's (1.5 vs 3.3 and getting "worse"). As an example, Johnson says that if 8 capacitors are adequate at 100 MHz, at twice the frequency, you need to multiply by FOUR the capacitance to bypass. Well, people have run out of places to bypass the parts. There are other ways to design bypass than brute force. > > > As well, the quality of results from the software has been steadily > > improving, with the latest clock speeds getting easier to implement as > > the tools get better. 4.1i has set a new performance watermark, and > > re-running old Virtex E designs has led to significant performance > > (>10%, or a speed grade) improvements for some customers. > > Hmm but this is getting into the marketing stuff . . . .;-) > Even the new software cant beat an engineer with real understanding of > the FPGA structures, and much worse it cant fix the problems caused by > an really unexpierienced designer. > Or am I wrong? A really good engineer who knows the structure may (only may) get a better result. That is because the engineer does not really know the structure. A good example is the FPGA editor view which is a simplistic representation of the chip -- not at all how it is really implemented. The synthesis tools now know all of the tricks and truly know the structures, and their costs. A really bad designer can have a terrible result from the tools....garbage in, garbage out. The tools are deesigned for the vast number of VHDL/verilog coders who do a decent professional job, look at the quality of results, read a little, check out structual improvements, and generally do a quality job. We allow these designers to have an excellent result by not burdening them with special knowledge. OOPS Marketing Alert! But again, if 95% of the designs are HDL, and they are successful, haven't we targeted the right market? > > > > Again, it all depends on your design, and how it is architected, but > > Virtex II has been very well accepted, and I continually hear from > > customers how "Virtex II now makes life interesting as it competes > > with the ASICs I was planning on having to design." > > He did it AGAIN. Marketing alert ;-) No, worse than that, a sales pitch. > > > Serious, I can believe that the Virtex-II is a very nice device > althrough up to now I had no possibility to use one for a design :-( I hope you (soon) encounter a requirement where Virtex II is a suitable choice. > > > -- > MFG > Falk
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