Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 35750

Article: 35750
Subject: LUT Glitches
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 16 Oct 2001 15:23:06 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 1024 point non-complex FFT on a SPARTAN2
From: Ray Andraka <ray@andraka.com>
Date: Tue, 16 Oct 2001 16:37:51 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Instantiating Virtex II library macros.
From: Ray Andraka <ray@andraka.com>
Date: Tue, 16 Oct 2001 16:43:52 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: LUT Glitches
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 16 Oct 2001 09:58:20 -0700
Links: << >>  << T >>  << A >>

--------------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.&nbsp; 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
Subject: Re: Timing constraints for unrelated clocks?
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Tue, 16 Oct 2001 19:12:05 GMT
Links: << >>  << T >>  << A >>
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.

--a

Article: 35755
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Tue, 16 Oct 2001 19:18:53 GMT
Links: << >>  << T >>  << A >>
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!

-a

Article: 35756
Subject: Re: Instantiating Virtex II library macros.
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 16 Oct 2001 22:35:11 +0200
Links: << >>  << T >>  << A >>
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.com

Article: 35757
Subject: pci-card with Virtex2?
From: "Seb" <someone@microsoft.com>
Date: Tue, 16 Oct 2001 20:46:18 GMT
Links: << >>  << T >>  << A >>
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: 35758
Subject: Re: LUT Glitches
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Tue, 16 Oct 2001 23:09:12 +0200
Links: << >>  << T >>  << A >>
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.
You will be scared (I think).

-- 
MFG
Falk



Article: 35759
Subject: Is Xilinx AppNote#258 correctly documented ?
From: qlyus@yahoo.com (qlyus)
Date: 16 Oct 2001 16:47:36 -0700
Links: << >>  << T >>  << A >>
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.

-qly

Article: 35760
Subject: Re: PLLs & DLLs
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Wed, 17 Oct 2001 01:35:10 GMT
Links: << >>  << T >>  << A >>
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 ):
> >
> > &#8226;eliminate the clock distribution delay and, with clock mirroring,
perhaps even the board delay,
> > &#8226;correct the clock duty cycle to 50-50,
> > &#8226;provide four clock phases ( 0, 90, 180, 270 degrees )
> > &#8226;provide two double-frequency outputs with opposite phase
> > &#8226;keep all these independent outputs phase-aligned
> > &#8226;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.
> > &#8226;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 )
> > &#8226;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: 35761
Subject: Re: System Gates
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Wed, 17 Oct 2001 01:43:02 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: LUT Glitches
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 17 Oct 2001 01:53:43 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: PLLs & DLLs
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 17 Oct 2001 02:11:05 GMT
Links: << >>  << T >>  << A >>
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 ):
> > >
> > > &#8226;eliminate the clock distribution delay and, with clock mirroring,
> perhaps even the board delay,
> > > &#8226;correct the clock duty cycle to 50-50,
> > > &#8226;provide four clock phases ( 0, 90, 180, 270 degrees )
> > > &#8226;provide two double-frequency outputs with opposite phase
> > > &#8226;keep all these independent outputs phase-aligned
> > > &#8226;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.
> > > &#8226;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 )
> > > &#8226;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: 35764
Subject: Re: LUT Glitches
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 17 Oct 2001 02:16:43 GMT
Links: << >>  << T >>  << A >>


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 Alfke


Article: 35765
Subject: Re: PLLs & DLLs
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Wed, 17 Oct 2001 02:19:03 GMT
Links: << >>  << T >>  << A >>
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 ):
> > > >
> > > > &#8226;eliminate the clock distribution delay and, with clock
mirroring,
> > perhaps even the board delay,
> > > > &#8226;correct the clock duty cycle to 50-50,
> > > > &#8226;provide four clock phases ( 0, 90, 180, 270 degrees )
> > > > &#8226;provide two double-frequency outputs with opposite phase
> > > > &#8226;keep all these independent outputs phase-aligned
> > > > &#8226;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.
> > > > &#8226;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 )
> > > > &#8226;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
Subject: Re: LUT Glitches
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 17 Oct 2001 16:47:20 +1300
Links: << >>  << T >>  << A >>
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

-jg

Article: 35767
Subject: Xilinx 64 Point FFT Core Problem
From: #BASUKI ENDAH PRIYANTO# <PH892987@ntu.edu.sg>
Date: Wed, 17 Oct 2001 14:41:35 +0800
Links: << >>  << T >>  << A >>
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


Article: 35768
Subject: Re: System Gates
From: Thomas Stanka <Thomas.Stanka@de.bosch.com>
Date: Wed, 17 Oct 2001 08:58:51 +0200
Links: << >>  << T >>  << A >>
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.com

Article: 35769
Subject: Recommended Newsgroup
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Wed, 17 Oct 2001 10:02:58 +0200
Links: << >>  << T >>  << A >>
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: 35770
Subject: Re: System Gates
From: Kolja Sulimm <kolja@sulimma.de>
Date: Wed, 17 Oct 2001 10:09:39 +0200
Links: << >>  << T >>  << A >>
> > 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: 35771
Subject: Re: Recommended Newsgroup
From: "Jan Pech" <j.pech@sh.cvut.cz>
Date: Wed, 17 Oct 2001 10:38:01 +0200
Links: << >>  << T >>  << A >>
Try 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
Subject: Phase noise of Xilinx/Altera DLL/PLL
From: "Paul Teagle" <pteagle@bigpond.net.au>
Date: Wed, 17 Oct 2001 08:56:36 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: pci-card with Virtex2?
From: "Ken" <aeu96186@yahoo.co.uk>
Date: Wed, 17 Oct 2001 10:32:07 +0100
Links: << >>  << T >>  << A >>

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
Subject: Re: Xilinx 64 Point FFT Core Problem
From: "John Adair" <newsanswer@removethisenterpoint.co.uk>
Date: Wed, 17 Oct 2001 10:56:55 +0100
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search