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
Hi, I've gone over to the dark side and am implementing some *asynchronous* logic in a Xilinx Virtex-E FPGA. What are the conditions under which a LUT is guaranteed *not* to generate a glitch? I'm fairly sure this works if only one input is changing at a time. There used to be a statement about this in the databook (about XC3000 vintage, I think). What if multiple inputs are changing at the same time (i.e. within one LUT delay)? It's just a simple mux structure. I can separate the AND-OR structure of the mux into separate LUTs if I have to. The output is clocking an external device, so I really want to avoid glitches, at the same time as trying to keep the jitter low (i.e. I want the minimum number of LUTs in the signal path). Thanks, Allan.Article: 35751
The xilinx FFT core won't fit in a spartanII, as you have probably already
discovered. We've got an FFT implementation that would allow a 1K FFT (16-20
bits) to fit easily into an XC2S200. Transform time would be on the order of
about 10 uS (back of the envelope calc) in a -5 part. Some work is needed on
our part to get it into a form where you could drop it into your design. Our
implementation can also provide a phase-magnitude output.
mounther wrote:
> hi
> Has anybody stumbled upon vhdl code for a non-complex 1024 point FFT for a
> Spartan2?
> I am not sure that the SPARTAN2 has enough logic for this but then there
> might be an implementation out there?!
> Cheers
> Mo
--
--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: 35752
And there in lies the rub. AFAIK, there are no netlists provided for the
macros, other than the ones generated by coregen. I'm not sure if there are
even RTL models you could use to generate your own.
hamish@cloud.net.au wrote:
> In comp.arch.fpga Ray Andraka <ray@andraka.com> wrote:
> > hamish@cloud.net.au wrote:
> >> In my experience, you can't instantiate Xilinx macros in your
> >> HDL code. Ngdbuild doesn't know anything about them (only
> >> primitives).
>
> > You can, but the edif files for any macros you use have to be found by
> > ngdbuild.
>
> That makes sense. Do you get netlists for each macro with the tools?
> I couldn't find them in Alliance 3.x, but they could be in Foundation.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 35753--------------432C8FFB8D8F4D41FE84959F Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Here is what I wrote ten years ago ( you can find it, among other places, in the 1994 data book, page 9-5: "Function Generator Avoids Glitches ... Note that there can never be a decoding glitch when only one select input changes. Even a non-overlapping decoder cannot generate a glitch problem, since the node capacitance would retain the previous logic level... When more than one input changes "simultaneously", the user should analyze the logic output for any intermediate code. If any such code produces a different result, the user must assume that such a glitch might occur, and must make the system design immune to it... If none of the address codes contained in the "simultaneously" changing inputs produces a different output, the user can be sure that there will be no glitch...." This still applies today. Peter Alfke, Xilinx Applications ============================================= Allan Herriman wrote: > Hi, > > I've gone over to the dark side and am implementing some > *asynchronous* logic in a Xilinx Virtex-E FPGA. > > What are the conditions under which a LUT is guaranteed *not* to > generate a glitch? > > I'm fairly sure this works if only one input is changing at a time. > There used to be a statement about this in the databook (about XC3000 > vintage, I think). > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? > > It's just a simple mux structure. I can separate the AND-OR structure > of the mux into separate LUTs if I have to. > > The output is clocking an external device, so I really want to avoid > glitches, at the same time as trying to keep the jitter low (i.e. I > want the minimum number of LUTs in the signal path). > > Thanks, > Allan. --------------432C8FFB8D8F4D41FE84959F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Here is what I wrote ten years ago ( you can find it, among other places, in the 1994 data book, page 9-5: <p>"Function Generator Avoids Glitches <br>... <br>Note that there can never be a decoding glitch when only one select input changes. Even a non-overlapping decoder cannot generate a glitch problem, since the node capacitance would retain the previous logic level... <br>When more than one input changes "simultaneously", the user should analyze the logic output for any intermediate code. If any such code produces a different result, the user must assume that such a glitch might occur, and must make the system design immune to it... <br><b>If none of the address codes contained in the "simultaneously" changing inputs produces a different output, the user can be sure that there will be no glitch...."</b><b></b> <p>This still applies today. <p>Peter Alfke, Xilinx Applications <br>============================================= <br>Allan Herriman wrote: <blockquote TYPE=CITE>Hi, <p>I've gone over to the dark side and am implementing some <br>*asynchronous* logic in a Xilinx Virtex-E FPGA. <p>What are the conditions under which a LUT is guaranteed *not* to <br>generate a glitch? <p>I'm fairly sure this works if only one input is changing at a time. <br>There used to be a statement about this in the databook (about XC3000 <br>vintage, I think). <p>What if multiple inputs are changing at the same time (i.e. within one <br>LUT delay)? <p>It's just a simple mux structure. I can separate the AND-OR structure <br>of the mux into separate LUTs if I have to. <p>The output is clocking an external device, so I really want to avoid <br>glitches, at the same time as trying to keep the jitter low (i.e. I <br>want the minimum number of LUTs in the signal path). <p>Thanks, <br>Allan.</blockquote> </html> --------------432C8FFB8D8F4D41FE84959F--Article: 35754
fred wrote: > IIRC, conventional constraints apply rising to rising edge (and so will also > meet falling to falling) but not guarantee rise to fall or fall to rise. A PERIOD constraint on your clock net is really what you want. All flops clocked on the same edge (rising-to-rising, or falling-to-falling) by that clock will be constrained by the full period. If you go from a flop clocked on one edge to a flop clocked on the opposite edge (rising-to-falling or falling-to-rising), the P+R tool detects this as a two-phase clock, and cuts the PERIOD in half to get the proper constraint. In other words, setting one constraint -- the period constraint -- does all of what you want. This is an fsck of a lot easier than setting different TIMEGRPs for each group of flops and all that! Of course, it does not handle crossing clock domains. --aArticle: 35755
Brian Davis wrote: > JUDGE: For your offense, and in the light of your excessive > alliteration of words beginning with the letter "C", I hereby > sentence you to use FPGA Express for all future synthesis work. > Bailiff, take him away. Thus endeth your career as an FPGA designer! -aArticle: 35756
hamish@cloud.net.au writes: > In comp.arch.fpga Marko <cantsay@here.com> wrote: > > I instantiate a design element macro in my Verilog code such as .. > > [..] > > > This doesn't happen with "primitives," only with "macros." > > What am I doing wrong? > > In my experience, you can't instantiate Xilinx macros in your > HDL code. Ngdbuild doesn't know anything about them (only > primitives). I use ngdbuild -sd <directory> to locate netlists (e.g. from coregen) which I instantiate in my design. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 35757
Hi group
i'm looking for a pci-card with a large Virtex2 FPGA and memory on it, to
implement a signal processing design. The application has to receive its
data through an external connector and deliver its data to the host pc
system (using the pci bus).
Which cards/vendors should i look at? Do any of you have experience with
such cards?
thanx in advance
cheers,
Seb
Article: 35758Allan Herriman schrieb: > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? I would be VERY carefull about this. Why? Because the LUTs and the FF inside the FPGA are DAMM fast. Just wait some days, I did some experiments and will publish them in a few days. You will be scared (I think). -- MFG FalkArticle: 35759
Hi, I just read Xilinx Application Note #258, using BlockRAM for FIFO in Virtex-II. I wondered if the Verilog codes of the note is correct or not. The write enable signal to the BlockRAM (write port) is the one after a FF, it is always a clock cycle later than the fifo_wr_en appeared on the module port. A quick simulation verified what I thought. Why is the Write_Enable signal driving BlockRAM's EN pin, instead of WE pin? I have been using Virtex/-E BlockRAM alot, especially using BlockRAM for Synch and Asynch FIFOs. Is this application note really erroneous? Or, do I still miss something here, because it is my first design for Virtex-II? If this application note is indeed a mistake? how did it come out several releases of revisions without being found? I mean this mistake (if I am not wrong) is very obvious and it wouldn't pass simulation or had no way to generate the timing diagrams in the paper. -qlyArticle: 35760
I'm a different Peter, but I'll give this a shot anyway... Here's the feature list from the PLLs in Altera's PLLs: Output frequency as a function of input frequency is m/(n * k) where m and k are integer values between 1 and 160 and n is an integer between 1 and 16. Or in Mr. Alfke's words "(almost) any arbitrary conversion factor". There's also two special conversions (256/193 and 193/256) for E1-T1 and T1-E1 conversions. There is both corse (90, 180, 270 degree) and fine (0.5ns to 1.0ns resolution depending on input frequency) phase shift on the PLL outputs. Input frequency ranges are 1.5 to 420MHz. Ouput frequency ranges are 1.5 to 335 MHz and 12.5 to 335 MHz on the two outputs that each PLL feeds back into the internal logic and up to 420MHz on the outputs that feed an external pin. -Pete- Gautam <gautam_awasthi@yahoo.co.in> wrote in message news:d10cf32c.0110160507.42e50998@posting.google.com... > Dear Peter > Your Explanations on DLL & PLL clarified most of my doubts barring a > few: > 1. Are the Features(mentioned by You) Unique to DLL(or Xilinx)? 'coz > Recently I read somewhere that ALTERA also provides Fine Phase > Shifting capabilities in its APEX II Family......PLEASE COMMENT.... > 2. What is the Usage of the 50% Duty-Cycle Correction Capability > offered by Virtex II DCM? > > Regards > > Gautam > > Peter Alfke <peter.alfke@xilinx.com> wrote in message news:<3BCB161F.6E691E11@xilinx.com>... > > Falk wrote: > > > > > The PLL in the ALTERA ICs is a (P)hase locked loop, which uses a VCO to generate the output signal. A PLL can do clock rate conversion with (almost) any arbitrary conversion factor, where the DLL (D)elay locked loop in the Xilinx devices can only divide by 1.5,2,2.5,3,4,5,8,16 and double the input frequency. <snip> > > > > Let me correct some misconceptions here. > > > > PLLs or DLLs had to be added to the ever larger FPGAs to combat ( = completely eliminate ) the clock distribution delay. Without PLL/DLLs, the larger chips would have unpredictable input set-up/hold times, and abominably long clock-to-output delays. But that is all fixed now; big chips can be as fast as small ones, since the clock distribution delay can be eliminated. > > > > As to the difference between PLL and DLL, it is undisputed that a well-designed PLL in a low-noise environment ( the caveats show my Xilinx background here ) can reduce input jitter, while a DLL inherently passes the jitter on. It is also undisputed that a DLL is inherently more robust, less sensitive to ground and Vcc noise, and does not require its private supply connections. > > > > I just finished writing an article for our techXclusives and we just updated the Virtex-II Handbook ( data sheet and user guide. See it on the web next week ). > > > > So, here is what the Virtex-II Digital Clock Manager can do ( and there are between 4 and 12 identical but independent DCMs on a Virtex-II chip ): > > > > •eliminate the clock distribution delay and, with clock mirroring, perhaps even the board delay, > > •correct the clock duty cycle to 50-50, > > •provide four clock phases ( 0, 90, 180, 270 degrees ) > > •provide two double-frequency outputs with opposite phase > > •keep all these independent outputs phase-aligned > > •on a separate output divide the clock by either 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 8, 9, 10, 11, 12, 13, 14, 15, or 16. > > •on another output multiply and divide the input frequency simultaneously by any integer multiplier and divisor from 2 to 32. ( for example multiply a 200 MHz input by 32 and divide it by 25 for a 256 MHz output ) > > •and - best of all- create a programmable phase shift, described as a multiple of the clock period divided by 256, that affects all outputs simultaneously. And this phase shift can even be incremented and decremented during operation. Interesting possibilities to adjust input or output clocks either by configuration, or adaptively, to optimize I/O performance. > > > > Sorry for the long posting, but I find this really exciting. It's more than just a DLL. > > And, please, don't accuse me of marketing. This is meant to be engineering information ! > > > > Peter Alfke, Xilinx ApplicationsArticle: 35761
As you've probably already figured out from the other posts here, the programmable logic "gate" counts have lost a lot of their credibility. In what appears to be an admission of their uselessness, Altera's newest programmable logic family, APEX II, goes by the part numbers EP2Axx, where xx is the number of LUTs/FFs in thousands (EP2A70 is approx. 70K LUTs/FFs), rather than trying to count "gates". -Pete- Dennis <sacrosantus@yahoo.com> wrote in message news:24f80317.0110152020.5d055699@posting.google.com... > I am an ASIC Designer trying to understand FPGAs. While going through > Xilinx Datasheets, I got some clues (although not fully understood) > about the definition of System Gates Capability of a particular > product. I wish to understand, How much Silicon is sacrificed for the > sake of Programmability? , for example: For a 315K equivalent Gates in > XC2V300, How Many ASIC Gates(2 input NAND) have been put in the > Silicon????Article: 35762
On Tue, 16 Oct 2001 09:58:20 -0700, Peter Alfke <peter.alfke@xilinx.com> wrote: >Here is what I wrote ten years ago ( you can find it, among other places, in the >1994 data book, page 9-5: > >"Function Generator Avoids Glitches >... >Note that there can never be a decoding glitch when only one select input >changes. Even a non-overlapping decoder cannot generate a glitch problem, since >the node capacitance would retain the previous logic level... >When more than one input changes "simultaneously", the user should analyze the >logic output for any intermediate code. If any such code produces a different >result, the user must assume that such a glitch might occur, and must make the >system design immune to it... >If none of the address codes contained in the "simultaneously" changing inputs >produces a different output, the user can be sure that there will be no >glitch...." > >This still applies today. Thankyou. Marc Baker from Xilinx emailed and pointed out that this is also in http://www.xilinx.com/xapp/xapp024.pdf Regards, Allan. >Allan Herriman wrote: > >> Hi, >> >> I've gone over to the dark side and am implementing some >> *asynchronous* logic in a Xilinx Virtex-E FPGA. >> >> What are the conditions under which a LUT is guaranteed *not* to >> generate a glitch? >> >> I'm fairly sure this works if only one input is changing at a time. >> There used to be a statement about this in the databook (about XC3000 >> vintage, I think). >> >> What if multiple inputs are changing at the same time (i.e. within one >> LUT delay)? >> >> It's just a simple mux structure. I can separate the AND-OR structure >> of the mux into separate LUTs if I have to. >> >> The output is clocking an external device, so I really want to avoid >> glitches, at the same time as trying to keep the jitter low (i.e. I >> want the minimum number of LUTs in the signal path). >> >> Thanks, >> Allan.Article: 35763
Peter, with a nice name like this, you should be more careful when quoting. It was Falk ( not "Mr. Alfke" ) who wrote " (almost) any arbitrary conversion actor", and he was referring to Altera PLLs, not to Xilinx DLLs. "A girl has to watch her reputation..." Greetings Peter Alfke =============================== Peter Ormsby wrote: > I'm a different Peter, but I'll give this a shot anyway... > > Here's the feature list from the PLLs in Altera's PLLs: > > Output frequency as a function of input frequency is m/(n * k) where m and k > are integer values between 1 and 160 and n is an integer between 1 and 16. > Or in Mr. Alfke's words "(almost) any arbitrary conversion factor". There's > also two special conversions (256/193 and 193/256) for E1-T1 and T1-E1 > conversions. > > There is both corse (90, 180, 270 degree) and fine (0.5ns to 1.0ns > resolution depending on input frequency) phase shift on the PLL outputs. > > Input frequency ranges are 1.5 to 420MHz. > > Ouput frequency ranges are 1.5 to 335 MHz and 12.5 to 335 MHz on the two > outputs that each PLL feeds back into the internal logic and up to 420MHz on > the outputs that feed an external pin. > > -Pete- > > Gautam <gautam_awasthi@yahoo.co.in> wrote in message > news:d10cf32c.0110160507.42e50998@posting.google.com... > > Dear Peter > > Your Explanations on DLL & PLL clarified most of my doubts barring a > > few: > > 1. Are the Features(mentioned by You) Unique to DLL(or Xilinx)? 'coz > > Recently I read somewhere that ALTERA also provides Fine Phase > > Shifting capabilities in its APEX II Family......PLEASE COMMENT.... > > 2. What is the Usage of the 50% Duty-Cycle Correction Capability > > offered by Virtex II DCM? > > > > Regards > > > > Gautam > > > > Peter Alfke <peter.alfke@xilinx.com> wrote in message > news:<3BCB161F.6E691E11@xilinx.com>... > > > Falk wrote: > > > > > > > The PLL in the ALTERA ICs is a (P)hase locked loop, which uses a VCO > to generate the output signal. A PLL can do clock rate conversion with > (almost) any arbitrary conversion factor, where the DLL (D)elay locked loop > in the Xilinx devices can only divide by 1.5,2,2.5,3,4,5,8,16 and double the > input frequency. <snip> > > > > > > Let me correct some misconceptions here. > > > > > > PLLs or DLLs had to be added to the ever larger FPGAs to combat ( = > completely eliminate ) the clock distribution delay. Without PLL/DLLs, the > larger chips would have unpredictable input set-up/hold times, and > abominably long clock-to-output delays. But that is all fixed now; big chips > can be as fast as small ones, since the clock distribution delay can be > eliminated. > > > > > > As to the difference between PLL and DLL, it is undisputed that a > well-designed PLL in a low-noise environment ( the caveats show my Xilinx > background here ) can reduce input jitter, while a DLL inherently passes the > jitter on. It is also undisputed that a DLL is inherently more robust, less > sensitive to ground and Vcc noise, and does not require its private supply > connections. > > > > > > I just finished writing an article for our techXclusives and we just > updated the Virtex-II Handbook ( data sheet and user guide. See it on the > web next week ). > > > > > > So, here is what the Virtex-II Digital Clock Manager can do ( and there > are between 4 and 12 identical but independent DCMs on a Virtex-II chip ): > > > > > > •eliminate the clock distribution delay and, with clock mirroring, > perhaps even the board delay, > > > •correct the clock duty cycle to 50-50, > > > •provide four clock phases ( 0, 90, 180, 270 degrees ) > > > •provide two double-frequency outputs with opposite phase > > > •keep all these independent outputs phase-aligned > > > •on a separate output divide the clock by either 1.5, 2, 2.5, 3, > 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 8, 9, 10, 11, 12, 13, 14, 15, or 16. > > > •on another output multiply and divide the input frequency > simultaneously by any integer multiplier and divisor from 2 to 32. ( for > example multiply a 200 MHz input by 32 and divide it by 25 for a 256 MHz > output ) > > > •and - best of all- create a programmable phase shift, described > as a multiple of the clock period divided by 256, that affects all outputs > simultaneously. And this phase shift can even be incremented and decremented > during operation. Interesting possibilities to adjust input or output > clocks either by configuration, or adaptively, to optimize I/O performance. > > > > > > Sorry for the long posting, but I find this really exciting. It's more > than just a DLL. > > > And, please, don't accuse me of marketing. This is meant to be > engineering information ! > > > > > > Peter Alfke, Xilinx ApplicationsArticle: 35764
Falk Brunner wrote: > Allan Herriman schrieb: > > > > What if multiple inputs are changing at the same time (i.e. within one > > LUT delay)? > > I would be VERY carefull about this. Why? Because the LUTs and the FF > inside the FPGA are DAMM fast. > Just wait some days, I did some experiments and will publish them in a > few days. Interesting, but my posted answer covers all speeds up to and including infinity. So there is no additional caveat. Still, always looking forward to experimental data... Peter AlfkeArticle: 35765
I stand corrected. Sorry Peter. BTW, I did realize that Mr. Falk was speaking of Altera PLLs. In my discussion, I was trying to acknowledge that Mr. Falk's description was accurate despite my slightly more rigorous explanation. -Pete- Peter Alfke <palfke@earthlink.net> wrote in message news:3BCCE8B1.2D615002@earthlink.net... > Peter, > with a nice name like this, you should be more careful when quoting. > It was Falk ( not "Mr. Alfke" ) who wrote " (almost) any arbitrary conversion > actor", and he was referring to Altera PLLs, not to Xilinx DLLs. > > "A girl has to watch her reputation..." > > Greetings > Peter Alfke > =============================== > Peter Ormsby wrote: > > > I'm a different Peter, but I'll give this a shot anyway... > > > > Here's the feature list from the PLLs in Altera's PLLs: > > > > Output frequency as a function of input frequency is m/(n * k) where m and k > > are integer values between 1 and 160 and n is an integer between 1 and 16. > > Or in Mr. Alfke's words "(almost) any arbitrary conversion factor". There's > > also two special conversions (256/193 and 193/256) for E1-T1 and T1-E1 > > conversions. > > > > There is both corse (90, 180, 270 degree) and fine (0.5ns to 1.0ns > > resolution depending on input frequency) phase shift on the PLL outputs. > > > > Input frequency ranges are 1.5 to 420MHz. > > > > Ouput frequency ranges are 1.5 to 335 MHz and 12.5 to 335 MHz on the two > > outputs that each PLL feeds back into the internal logic and up to 420MHz on > > the outputs that feed an external pin. > > > > -Pete- > > > > Gautam <gautam_awasthi@yahoo.co.in> wrote in message > > news:d10cf32c.0110160507.42e50998@posting.google.com... > > > Dear Peter > > > Your Explanations on DLL & PLL clarified most of my doubts barring a > > > few: > > > 1. Are the Features(mentioned by You) Unique to DLL(or Xilinx)? 'coz > > > Recently I read somewhere that ALTERA also provides Fine Phase > > > Shifting capabilities in its APEX II Family......PLEASE COMMENT.... > > > 2. What is the Usage of the 50% Duty-Cycle Correction Capability > > > offered by Virtex II DCM? > > > > > > Regards > > > > > > Gautam > > > > > > Peter Alfke <peter.alfke@xilinx.com> wrote in message > > news:<3BCB161F.6E691E11@xilinx.com>... > > > > Falk wrote: > > > > > > > > > The PLL in the ALTERA ICs is a (P)hase locked loop, which uses a VCO > > to generate the output signal. A PLL can do clock rate conversion with > > (almost) any arbitrary conversion factor, where the DLL (D)elay locked loop > > in the Xilinx devices can only divide by 1.5,2,2.5,3,4,5,8,16 and double the > > input frequency. <snip> > > > > > > > > Let me correct some misconceptions here. > > > > > > > > PLLs or DLLs had to be added to the ever larger FPGAs to combat ( = > > completely eliminate ) the clock distribution delay. Without PLL/DLLs, the > > larger chips would have unpredictable input set-up/hold times, and > > abominably long clock-to-output delays. But that is all fixed now; big chips > > can be as fast as small ones, since the clock distribution delay can be > > eliminated. > > > > > > > > As to the difference between PLL and DLL, it is undisputed that a > > well-designed PLL in a low-noise environment ( the caveats show my Xilinx > > background here ) can reduce input jitter, while a DLL inherently passes the > > jitter on. It is also undisputed that a DLL is inherently more robust, less > > sensitive to ground and Vcc noise, and does not require its private supply > > connections. > > > > > > > > I just finished writing an article for our techXclusives and we just > > updated the Virtex-II Handbook ( data sheet and user guide. See it on the > > web next week ). > > > > > > > > So, here is what the Virtex-II Digital Clock Manager can do ( and there > > are between 4 and 12 identical but independent DCMs on a Virtex-II chip ): > > > > > > > > •eliminate the clock distribution delay and, with clock mirroring, > > perhaps even the board delay, > > > > •correct the clock duty cycle to 50-50, > > > > •provide four clock phases ( 0, 90, 180, 270 degrees ) > > > > •provide two double-frequency outputs with opposite phase > > > > •keep all these independent outputs phase-aligned > > > > •on a separate output divide the clock by either 1.5, 2, 2.5, 3, > > 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 8, 9, 10, 11, 12, 13, 14, 15, or 16. > > > > •on another output multiply and divide the input frequency > > simultaneously by any integer multiplier and divisor from 2 to 32. ( for > > example multiply a 200 MHz input by 32 and divide it by 25 for a 256 MHz > > output ) > > > > •and - best of all- create a programmable phase shift, described > > as a multiple of the clock period divided by 256, that affects all outputs > > simultaneously. And this phase shift can even be incremented and decremented > > during operation. Interesting possibilities to adjust input or output > > clocks either by configuration, or adaptively, to optimize I/O performance. > > > > > > > > Sorry for the long posting, but I find this really exciting. It's more > > than just a DLL. > > > > And, please, don't accuse me of marketing. This is meant to be > > engineering information ! > > > > > > > > Peter Alfke, Xilinx Applications >Article: 35766
Allan Herriman wrote: > > Hi, > > I've gone over to the dark side and am implementing some > *asynchronous* logic in a Xilinx Virtex-E FPGA. > > What are the conditions under which a LUT is guaranteed *not* to > generate a glitch? > > I'm fairly sure this works if only one input is changing at a time. > There used to be a statement about this in the databook (about XC3000 > vintage, I think). > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? > > It's just a simple mux structure. I can separate the AND-OR structure > of the mux into separate LUTs if I have to. > > The output is clocking an external device, so I really want to avoid > glitches, at the same time as trying to keep the jitter low (i.e. I > want the minimum number of LUTs in the signal path). > > Thanks, > Allan. We've done this in CPLD, not FPGA, but the concept is portable: - you can make glitch filters, from tapped delay lines, and a majority vote scheme. - When creating clocks from delay logic, it is possible, in theory, to have more than one stable 'traveling-wave', so to avoid this we Gate the osc to start from a known state - The tools need to be watched, sometimes they will optimise out important delay element(s) :-) - We had one interesting bench setup, to self test a delay-osc, and the LSB's of the display were in the femto-second region. Of sourse, they moved around, but it was stable to < 10ps which I thought was quite impressive. ( at a given Temp/Vcc ) The 'delay' quantizer in these PLDs (ATF1504) was 2.7ns - your FPGA numbers will be << 1ns -jgArticle: 35767
Hi, Anyone have a working example of the 64 point FFT in XilinxCoreLib using FPGA Advantage 5.1? I have compiled the library and it was succesfull. Some Cores such as FIFO, Adder can be generated and simulated as well. However when I try to simulate the generated 64-point FFT core the following error message occur : "vfft64_rtl.vhd",line 52: Error, unit 'xilinxcorelib.vfft64_comp' was not found or has errors (possibly in a dependency). I saw the vfft64_comp directory is available in Modeltech/XilinxCorelib directory. I still can not figure out how this error occur. I run under Win98 OS Platform. Anyone can give any idea ? Thanks basuki_ep@yahoo.comArticle: 35768
Hi, Jan Gray wrote: > "Dennis" <sacrosantus@yahoo.com> wrote in message > news:24f80317.0110152020.5d055699@posting.google.com... > > sake of Programmability? , for example: For a 315K equivalent Gates in > > XC2V300, How Many ASIC Gates(2 input NAND) have been put in the > > Silicon???? > let's say a tile with 4 4-LUTs, and its programmable interconnect, could > require 8,000 transistors -- that's to implement about 40-something ASIC > gates of logic and wiring -- call it 200 transistors per ASIC gate. > If you figure a CMOS 2-input NAND is four transistors, then at 200 > transistors per NAND, it works out to a 50-1 'transistor overhead' for There are designs, where your counting may be right, but in practice you have a lot problems in comparing FPGA and cell based designs (ASIC is the wrong word in my opinion, because a FPGA is as well an Application Specific IC) First you don't find a FPGA with exactly your needs, so you are forced to buy the next bigger FPGA, that fits your needs, in cell based designs is it normaly no problem. Second: In FPGA based on LUT you need very comlex logic functions with less inputs to get good results in order to compare with cell based. A 32 bit XOR for Parity is the dead of all FPGA-marketing. In practice I learned to have a look at the number of inputs for logic functions plus the number of FF because that's normaly my limit. bye Thomas -- Thomas Stanka Bosch SatCom GmbH BC/EMD4 D-71522 Backnang Tel. +49 7191 930-1690 Gerberstr. 49 Fax. +49 7191 930-21690 Zi. 10/528 Thomas.Stanka@de.bosch.comArticle: 35769
Hi, Was wondering if anyone can recommend either (a.) a newsgroup, or (b.) an answer to my question. I am trying to search for a fast (>50MHz) microcontroller with about 256-512 kB SRAM on board and would like to know if anyone has any ideas. Preferably quite cheap. I found the ATMEL AT91FR40816 but unfortunately it is out of my price range - will be needing quite a lot. Does anyone know if any cheaper alternatives. I will be using the microcontroller as a backend to a Spartan II. thanks adrianArticle: 35770
> > let's say a tile with 4 4-LUTs, and its programmable interconnect, could
> > require 8,000 transistors -- that's to implement about 40-something ASIC
> > gates of logic and wiring -- call it 200 transistors per ASIC gate.
>
> > If you figure a CMOS 2-input NAND is four transistors, then at 200
> > transistors per NAND, it works out to a 50-1 'transistor overhead' for
>
> There are designs, where your counting may be right, but in practice you
> have a lot problems in comparing FPGA and cell based designs (ASIC is
> the wrong word in my opinion, because a FPGA is as well an Application
> Specific IC)
>
> First you don't find a FPGA with exactly your needs, so you are forced
> to buy the next bigger FPGA, that fits your needs, in cell based designs
> is it normaly no problem.
But there are also factors that work in the opposite direction.
1. Moder designs are likely to be pad limited. In a modern technology a 160
I/O design with
10 kGates kann well need the same chip area as a design with 250 kGates.
2. There is no chance that an avarage company gains access to the top notch
technologies used in FPGAs. At the moment you need very high quantities to
use anything better than quarter micron.
3. Your ASIC design will usually not fit exactly your needs but will be an
overkill because it must also
meet future needs.
This does not meen that FPGAs are more area efficient than full custom or gate
array designs,
but I wanted to make the point that it is not sufficient to compare the
number of physical gates per lut.
Kolja Sulimma
Article: 35771Try to post it in comp.arch.embedded group. Jan > Hi, > > Was wondering if anyone can recommend either (a.) a newsgroup, or (b.) an > answer to my question. I am trying to search for a fast (>50MHz) > microcontroller with about 256-512 kB SRAM on board and would like to know > if anyone has any ideas. Preferably quite cheap. I found the ATMEL > AT91FR40816 but unfortunately it is out of my price range - will be needing > quite a lot. Does anyone know if any cheaper alternatives. I will be using > the microcontroller as a backend to a Spartan II. > > thanks > adrian > > >Article: 35772
Related to the recent DLL/PLL discussions, are there any measured figures on phase noise performance for the DLL/PLL. Are phase noise figures specific to the divide/multiply ratios & frequencies used? From a quick look at the jitter figures, I doubt they are suitable to directly drive eg a DAC in a direct IF synthesis scheme for high resolution systems. Comments? Paul T. CAE Inc [at home]Article: 35773
try www.nallatech.com "Seb" <someone@microsoft.com> wrote in message news:u01z7.148720$y7.2039796@dbsch1.home.nl... > Hi group > > i'm looking for a pci-card with a large Virtex2 FPGA and memory on it, to > implement a signal processing design. The application has to receive its > data through an external connector and deliver its data to the host pc > system (using the pci bus). > > Which cards/vendors should i look at? Do any of you have experience with > such cards? > > thanx in advance > cheers, > Seb > >Article: 35774
Your problem is probally that you have not updated your "xilinxcorelib" library. Xilinx update cores such there several cores with the same root name but also have a version number included in the model name (you should see this in your instantiation of the simulation only model in your code). You probally don't have the latest version model of the core you are generating in Xilinxcorelib. If your are a registered user you can download the component models from Xilinx see www.xilinx.com/support/support.htm . This download usually has a file list attached from which it is possible to make a compile script to run in Modelsim and update your library. If this does not fix there are some problems that occur with model instantiation dependent on your version of simulator/synthesis tools. John Adair Enterpoint Ltd. Unit 4 Malvern Hills Science Park Geraldine Road Malvern Worcestershire United Kingdom www.enterpoint.co.uk The views expressed in this message are those of the writer and not necessarily those of Enterpoint Ltd.. The use of information in this message is without warranty and persons using the information are advised to make their own checks as to it's validity. No responsibility will be accepted for any incorrect, inaccurate or missleading information supplied. #BASUKI ENDAH PRIYANTO# <PH892987@ntu.edu.sg> wrote in message news:8D5C8824989A21458FFF1C3CE9902036058AF140@mail12.main.ntu.edu.sg... > Hi, > > Anyone have a working example of the 64 point FFT in XilinxCoreLib using > FPGA Advantage 5.1? > I have compiled the library and it was succesfull. Some Cores such as > FIFO, Adder can be generated and simulated as well. However when I try > to simulate the generated 64-point FFT core the following error message > occur : > > "vfft64_rtl.vhd",line 52: Error, unit 'xilinxcorelib.vfft64_comp' was > not found or has errors (possibly in a dependency). > > I saw the vfft64_comp directory is available in Modeltech/XilinxCorelib > directory. I still can not figure out how this error occur. > > I run under Win98 OS Platform. > > Anyone can give any idea ? > > Thanks > > basuki_ep@yahoo.com >
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