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 100150

Article: 100150
Subject: Re: PCB Bypass Caps
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 04 Apr 2006 09:15:49 -0700
Links: << >>  << T >>  << A >>
John,

Very nice looking pcb.

SI is not quite all science (just yet).  There is still some art.  By 
that, I mean some designs work just fine, yet violate some "basic rule" 
that "everyone" feels must be observed.

A good example of this is a fiber optic transmission system I built that 
had a basic optical threshold at the photon detection limit (basically ~ 
100 photons = a '1).  I made a "mistake" on the layout, and after we had 
qualified the board, and we were shipping, the boss insisted I modify 
the layout to remove the "mistake."

The modified layout worked terribly.  Even though it was "correct" its 
performance was awful.  The boss was livid.

I am sure that a complete E&M analysis using something like Ansoft would 
have revealed why my "mistake" was in fact a noise isolation clever 
trick (which probably broke up a plane resonance), but in the real 
world, sometimes you accept your success, and move on.

As Xilinx, we have a slightly different requirement:  we have to 
recommend techniques that are 99.99975% likely to work perfectly, all 
the time.  As such, we must error on the side of being overly cautious, 
and must support what we say with theory, simulation, and measurement.

You see this theme repeated in the Howard Johnson online presentations.

If the apps group can't get those three to agree, it is not suitable for 
publication.

This is why we have the ppc, mgt, network, and memory systems demo pcbs: 
  they are each examples of our theories and practices made real.

Austin

Article: 100151
Subject: Re: Looking for chebychev equation
From: "robert bristow-johnson" <rbj@audioimagination.com>
Date: 4 Apr 2006 09:50:35 -0700
Links: << >>  << T >>  << A >>
Roger Bourne wrote:

> The equations look rather daunting, but I'll take a crack at them.

pretend that you're an electrical engineering student taking a class in
digital and analog filtering.

> However, I want to ask you again this question:
> Q: The equations ARE for a cascaded structure of biquad 2nd order
> (chebychev) IIR filters, Right ?

sure.  when you express transfer functions that multiply each other,
that means the filters that are represented by such transfer functions
are in cascade.

> The reason why I am asking you the question is that upon scanning the
> equations, I cannot seem to locate the different DCgains of the
> individual biquad filters in the cascade structure on the analog set of
> equations...According to my intuition, it is the fact that some of the
> filters (in the cascacded structure) start to attenuate sooner (than
> other filters) and the fact that some of the filters have a positive
> DCgain and others negative DCgain and the fact that some (almost all)
> of the filters have some kind of shaping (underdamping) about them THAT
> we observe on the output of the cascaded structure a very sharp &
> immediate & steady reponse at the intended cutoff frequency (or maybe a
> little bit higher than the intended higher frequency). I know, from
> online-applet experience, that for N=8, the 4 filters obtained were all
> different and gave a great output response.

the analog filter prototype for each 2nd order stage that was spelled
out in the previous posts all have a DC gain of 1 (or 0 dB).   when
you're at DC, w=0, so s= jw = 0 also.  plug s=0 into the filter
prototype H(s) and see what you get.

> However, I have faith that it is my newbieism that is probably the
> center of the misunderstanding.

perhaps.  to get as far as you have, have you had any formal training
in linear system theory (where one learns about transfer functions,
frequency response, and the like)

> I also want to confirm the following:
> Is the basic procedure for obtaining coeffcients the following (at
> least for analog-prototype equivalent filters, Chebbychev, Cauer,
> Butterworth....):
> 1. Obtain Filter Analog Equation

yeah, Cauer (or "elliptical") is a complete bitch.  i do not have
closed form expressions for those.  Butterworth, Tchebyshev (type 1),
Inverse Tchebyshev (type2), all have closed form expressions.

> 2. Go through some normalization process of the analog equation

usually it is in normalized form when you first create it.  if not, and
the "significant frequency" (usually the corner frequency or the
passband edge or stopband edge), is "W0", then arrange the equation so
that every occurance of s is divided by W0 and replace "s/W0" with just
"s" to normalize.

> 3. Perform the Bilinear Transform

when your analog prototype is normalized the BLT mapping that also maps
the analog "significant frequency" (which is w=1 for normalized analog)
to w0 = 2*pi*f0/Fs is:

The bilinear transform (with compensation for frequency warping)
substitutes:

                                  1         1 - z^-1
      (normalized)   s  <--  ----------- * ----------
                              tan(w0/2)     1 + z^-1

and i would recommend making the trig substitution suggested in the
cookbook.

r b-j


Article: 100152
Subject: Re: about the low power design
From: Rene Tschaggelar <none@none.net>
Date: Tue, 04 Apr 2006 18:58:56 +0200
Links: << >>  << T >>  << A >>
bjzhangwn wrote:

> Can some have the material ahout the power design in fpga,and how to
> estimate the power in fpga,as I know the flash based and antifuse based
> fpga have the low power,but the design require reconfiguration.And have
> some other reason,we must use the sram based fpga,cyclone  and spartan
> 3e has the low power,and I didn't konw how to estimate the power in the
> project,and the power only I can use is in 300mw.Can someone give some
> advice?

If power is the ultimate requirement, the you can
just lower the clock to fit the power source.

Datasheets and the free tools may also give some
information on power requirements. Some manufacturer
cheat by assuming only 10% or so of the cells to be
active.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 100153
Subject: Re: a problem with coolrunner CPLD (XC2C256) GCK0 pin
From: "Arash Majd" <arash_majd@ee.sharif.edu>
Date: 4 Apr 2006 10:16:19 -0700
Links: << >>  << T >>  << A >>
I just set the output slew rate to slow (for all pins) in Xilinx ISE
"implement design properties" (considering the fact that its default
was on fast) and it became O.K. I don't know what you mean by clock IP
node?
Jim Granville wrote:
> Arash Majd wrote:
> > Hello Dear friends
> > Thanks for all your careful attentions.
> > I found the solutions. I have set the slew rate setting to slow instead
> > of fast. When I did this,The jitter came down to .05 UIpp.
> >
> > Arash Majd
>
> Good to hear you did not need a new PCB design :)
>   The fast/slow is not well explained in most data, as it also means
> HiDrive/LoDrive, and thus more ground bounce can come from Fast(HiDrive).
>   ie unless the last ns matters on long lines, use Slow...
>
>   Did you try fast only on the ClkOUT pin, and Hysteresis on/off on
> the clock IP node ?
> 
> -jg


Article: 100154
Subject: ISE under 64-bit Linux?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 4 Apr 2006 17:54:28 GMT
Links: << >>  << T >>  << A >>
Just got an Athlon64 system.  I want to be able to run the Xilinx ISE tool 
suite on this box under Linux.  I'd also like to install a 64-bit Linux on it - 
are there any issues with running xst under 64-bit linux?  I suspect there 
might be driver issues with downloading bitstreams, but I'm thinking of 
using one of the open source tools for downloading bitstreams.



Phil

Article: 100155
Subject: Re: XUPV2P
From: Paul Hartke <phartke@Stanford.EDU>
Date: Tue, 04 Apr 2006 10:57:50 -0700
Links: << >>  << T >>  << A >>
Hi Paul,

The XUPV2P is directly supported by Impact which is part of the Xilinx
ISE tools.  I don't believe you can use adept with the XUPV2P.  

Paul

Paul Lee wrote:
> 
> Hi,
> 
> I have just received the XUPV2P board and trying to install the adept
> software to program it but the problem I seem to experience is the
> installer is interrupted and requires a restart.
> 
> Originally I thought the problem stems from using the service pack 2
> for Windows 2000 and old version of the installer so I have upgraded my
> machine with service pack 4 and the latest windows installer 3.1 but
> that doesn't seem to make any difference as the installation still get
> interrupted.
> 
> I was wondering if anyone has experience this problem before.
> 
> Cheers
> Paul

Article: 100156
Subject: Re: ISE under 64-bit Linux?
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Tue, 04 Apr 2006 14:19:12 -0400
Links: << >>  << T >>  << A >>
On Tue, 04 Apr 2006 17:54:28 +0000, Phil Tomson wrote:

> Just got an Athlon64 system.  I want to be able to run the Xilinx ISE tool
> suite on this box under Linux.  I'd also like to install a 64-bit Linux on
> it - are there any issues with running xst under 64-bit linux?  I suspect
> there might be driver issues with downloading bitstreams, but I'm thinking
> of using one of the open source tools for downloading bitstreams.
> 
> 
> 
> Phil

I'm running it on 64 bit FC4 on an X2 4400+, works fine. You need to put
the following into your .cshrc

setenv LD_ASSUME_KERNEL 2.4.7

Article: 100157
Subject: Altera Stratix II GX LVDS max speed
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 4 Apr 2006 11:34:58 -0700
Links: << >>  << T >>  << A >>
I had spoke with Charley Pryor at Altera a few months back and had
asked about running a 16-bit data bus into a Stratix II and what sort
of speeds we could expext to run it at.  He had made the statement that
they had designs running in the 1GHz range and that they had some
in-house designs running at 2GHz.  Looking at the data sheets from Jan.
05. they show the LVDS only being rated to 840 Mbps.   Interesting
enough I am having a hard time finding any designs where people have
used the Altera parts at these speeds.

I am curious if any of you have run any wide busses into a Stratix II
near the rated speed and what results you had.  Did you use the Altera
synthisis tool?  Was there any hidden problems to get the design to
work?   Any information would be helpful.  Thanks


Article: 100158
Subject: Re: PCB Bypass Caps
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 04 Apr 2006 11:41:36 -0700
Links: << >>  << T >>  << A >>
On Tue, 04 Apr 2006 09:15:49 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>John,
>
>Very nice looking pcb.


It has two 4000-series Xilinx chips clocking at 77 MHz, one running
some really complex microengine stuff. All done with the old
Foundation software, all schematic entry!

John



Article: 100159
Subject: Lattice ispLever Starter Download
From: "Maki" <prase.ruzicasto@gmail.com>
Date: 4 Apr 2006 12:01:31 -0700
Links: << >>  << T >>  << A >>
Hello friends,

It appears that I can't download ispLever. I get a message that file
isn't available.
Is it working at Your side? Wherever You may be :o)

Thanks,
Maki


Article: 100160
Subject: Re: spartan FPGA with PLCC package
From: Satoru Uzawa <satoru_u_removeme@berkeley.edu>
Date: Tue, 4 Apr 2006 19:05:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

 I thought one can synthesize for Spartan and Spartan XL with Icarus
Verilog then tranfer EDIF file to ISE Classic to complete the project.
 Am I wrong?  
 By the way, the advice here stands too true.  Don't start a new
project with devices not supported by ISE WebPACK just because you
can buy them cheap...

 Regards,
 Satoru
  
ghelbig@lycos.com wrote:
> The PLCC Spartan/SpartanXL is NOT going to be the least costly.
> 
> Xilinx no longer supports them.  To synthesize, you'll need FPGA
> Express, and the last time I checked, it ran about $15,000.00 - 15K
> will buy a lot of time at your local stuffing house.
> 
> "If it ain't supported in a current web-pack, don't use it."
> 

Article: 100161
Subject: Streamlining FIRs in System Generator
From: "Ira Thorpe" <ithorpe@backpacker.com>
Date: 4 Apr 2006 12:46:57 -0700
Links: << >>  << T >>  << A >>
Hello,
    I'm working on an FPGA implementation of a digital reciever.  I
decided to use Xilinx's Systen Generator for MATLAB Simulink since I
have little experience programming FPGAs and just want to get something
working.  In my design, I used the Xilinx FIR block, which implements a
distributed arithmetic filter, for a couple of low-pass filters with 16
to 64 taps. The design simulates well but I seem to be utilizing a ton
of FPGA resources and want to trim the design down a bit. What is the
most efficient implementation of a FIR for this application?  The part
is an XC2VP50 running with a 100MHz clock rate.  I'd like to keep the
sample rate at 100MHz as well. One thing I noticed is that the input
data type is 32.30 but the output data type is 50.47, which I then cast
back down as a 32.30.  Obviously this seems like a waste of resources
but I don't see anywhere to specify the interal precision for the
accumulators/multipliers.  Thanks for your time,
-Ira Thorpe
 UF Physics


Article: 100162
Subject: Re: spartan FPGA with PLCC package
From: Stephen Williams <spamtrap@icarus.com>
Date: Tue, 04 Apr 2006 12:59:30 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


You are right, although the -tfpga target for 0.8 is a little rusty
compared to current CVS of v0_8-branch, and -tfpga is non-functional
on the devel trunk. Because the main trunk and synthesis have diverged
recently, I've been considering keeping synthesis in the v0_8 branch
and fixing/maintaining it there. A fork, if you will.

And supporting abandoned parts like this is a excellent use of open
source software. Might even be a business opportunity;-)

Satoru Uzawa wrote:
> Hi,
> 
>  I thought one can synthesize for Spartan and Spartan XL with Icarus
> Verilog then tranfer EDIF file to ISE Classic to complete the project.
>  Am I wrong?  
>  By the way, the advice here stands too true.  Don't start a new
> project with devices not supported by ISE WebPACK just because you
> can buy them cheap...
> 
>  Regards,
>  Satoru
>   
> ghelbig@lycos.com wrote:
>> The PLCC Spartan/SpartanXL is NOT going to be the least costly.
>>
>> Xilinx no longer supports them.  To synthesize, you'll need FPGA
>> Express, and the last time I checked, it ran about $15,000.00 - 15K
>> will buy a lot of time at your local stuffing house.
>>
>> "If it ain't supported in a current web-pack, don't use it."
>>


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEMtAirPt1Sc2b3ikRAizDAKDuLIxpg2KLqURVoeKMGnnijvL5/QCgtejX
qhHYQHIVKHwBKJD5zQitYbE=
=hhK2
-----END PGP SIGNATURE-----

Article: 100163
Subject: Re: Sharing BRAM between Xilinx PowerPC's (on data-OCM ports)
From: "Joseph" <joeylrios@gmail.com>
Date: 4 Apr 2006 13:01:15 -0700
Links: << >>  << T >>  << A >>
Jeff,

Well, your surprise at my clocking was warranted... I checked and I
seem to be running everything at 100Mhz now.  Now I am curious if I can
get the speeds up as well.  My processors do communicate well over the
OCM still.  I think what happened for me was that I saw the 4:1 ratio
in the block reference guide and realized that my different clocks were
causing a problem.  I probably, at that point, made everything run at
100Mhz and gave BRAMDSOCMCLK the same clock as the processor to be
certain I would get 1:1. When I posted to the group, I got the ratio
backwards (upside-down?).  Thanks for setting me straight!

Like you, I have moved on and around this problem a bit.  I was
surprised to see the clock values I had in my system.  If I get time, I
may adjust them... maybe try the whole system at 200Mhz and see what
happens.  Or just try 4:1 to see if things work.  Speed isn't as
important in my system as it seems to be in yours, just the coherent
communcation is what matters. Oh, those touchy OCMs...

Joey


Article: 100164
Subject: Re: need your comments
From: dale.prather@gmail.com
Date: 4 Apr 2006 13:08:32 -0700
Links: << >>  << T >>  << A >>
Marco,
I have Init_B pulled up to 3.3V with a 4.75k resistor, but I'm not
using it as a GPIO.  I also have Done pulled up with a 330R.  The
others are not pulled up.

Why are you doing anything with the TMS, TDI, TCK and TDO signals?
These signals are for configuring the FPGA through the JTAG port.  Are
you setting up the FPGA to also be configured by JTAG as a backup plan?
 Probably not a bad idea, at least for prototypes.

I don't know your background, so I'm sorry if I stated something
obvious.

Dale


Article: 100165
Subject: Re: about the low power design
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Tue, 04 Apr 2006 23:11:29 +0200
Links: << >>  << T >>  << A >>
bjzhangwn wrote:

> Can some have the material ahout the power design in fpga,and how to
> estimate the power in fpga,as I know the flash based and antifuse based
> fpga have the low power,but the design require reconfiguration.And have
> some other reason,we must use the sram based fpga,cyclone  and spartan
> 3e has the low power,and I didn't konw how to estimate the power in the
> project,and the power only I can use is in 300mw.Can someone give some
> advice?

Altera Quartus II (5.0 and up) - at least the non-free version - has fairly
accurate power estimation when given a representative simulation output
file.

300mW sounds doable in an EP1C3 or EP2C5 with high utlization and clock
speed.

Best regards,


Ben


Article: 100166
Subject: How does the DCM phase shifting circuitry work? Xilinx Spartan 3
From: "Craig Yarbrough" <hyarbr01@harris.com>
Date: 4 Apr 2006 14:18:18 -0700
Links: << >>  << T >>  << A >>
Essentially I need to know, for any given DCM configuration, how much
the DCM outputs will shift in phase for each time I nail PSINCDEC. I'm
thinking that if I understand better how the PS part of the DCM circuit
works I can answer this for myself. I've got a case in with Xilinx but
either they're not understanding my question, or they're not sure how
to answer, or who knows. Any help would be greatly appreciated. Here's
the correspondence so far:

----------------------
Me:
I'm using some DCMs in dynamic phase-shift mode in a Spartan 3 and I'm
trying to understand how the granularity of each dynamic phase shift is
tied to the period of CLKIN. Does the phase shift feature use a fixed
tap delay? If so, the phase shift granularity would not be dependent on
the period of CLKIN. Also, after reading XAPP462 I surmised that the
longer the period of CLKIN (slower the CLKIN frequency) the less number
of effective phase shift steps. This seems counter-intuitive. Can you
help me to understand how the dynamic phase shifting is implemented in
the DCM?
-----------------
Xilinx:
Craig,
The DCM can always delay ~10ns.  When your clock period is slower than
~100Mhz (10ns period), you will not be able to phase shift the full360
degrees.  Additionally for slower frequencies, taps are combined as per
XAPP462, such that you may not have 256 tap changes, but will still
have 10ns of delay to work with. It's a little confusing, but the
circuitry basically does not allow the same resolution at slow speeds
as it does at high.
Hope this clears things up.
------------------
Me:
Thanks for your very quick response. I'm beginning to understand a
little better. The goal is for us to know, for any given DCM config,
how much dynamic phase shift occurs each time we nail PSINCDEC. For a
DCM that has a max shift of 10ns and 512 steps or taps, is it safe to
say that each tap is about 20ps? I understand that for slower CLKIN
frequencies the taps could be combined to give 40ps, 60ps, etc. per
step, and thus you'd have less than 255 steps in either direction. Is
there a way to tell if the DCM we're using is combining taps, and how
many taps per step? Thanks!
-------------------
Xilinx:
Craig,
There will never be 512 taps, there are max 256 and each is around
40ps.  The weight of each unit of increment will depend on the
frequency of clk in.  This is where XAPP462's equations come in.
Sounds like you got it from there.
------------------------
Me:
No not quite. The 512 taps/steps I got from equation 4 (pg 42), where
TCLKIN is less than 10 ns and the phase shift limits are +/-255.
However that's for fixed phase shifting. For variable phase shifting
there's 256 taps/steps when the shift limits are +/-128. Still, are you
sure there's only 256 taps in the delay line, since there's +/-255
steps available in fixed phase shifting?

Also, if CLKIN is 250MHz and I step PSINCDEC once, will the output
clock shift in phase by 40ps (or one tap delay)? What if CLKIN is
300MHz and I step once, will the output clock shift in phase by the
same 40ps, or some multiple? Here I'm still confused as to how each
unit of increment is tied to the frequency of CLKIN. Equation 9 (pg 45)
doesn't hold true.
--------------------


Article: 100167
Subject: Re: ISE under 64-bit Linux?
From: Eric Smith <eric@brouhaha.com>
Date: 04 Apr 2006 14:54:08 -0700
Links: << >>  << T >>  << A >>
ptkwt@aracnet.com (Phil Tomson) writes:
> Just got an Athlon64 system.  I want to be able to run the Xilinx ISE tool 
> suite on this box under Linux.  I'd also like to install a 64-bit Linux on it - 
> are there any issues with running xst under 64-bit linux?  I suspect there 
> might be driver issues with downloading bitstreams, but I'm thinking of 
> using one of the open source tools for downloading bitstreams.

XST works fine, but the ISE Simulator is not available in the 64-bit
version, nor, as you suspected, are cable drivers for programming.

I'm hoping that they can get the 64-bit cable drivers into the next release
(8.2i?  9.0i?).  I looked into building them myself, but it's not feasible
because even though the WinDriver demo kit supports 64-bit, Xilinx supplies
their portion of the driver as a 32-bit object file.

If Xilinx would release docs on the driver API, I expect that an open
source version would get developed quickly.  I don't see what down side
this would have for Xilinx; anything that makes it easier for people to
develop using Xilinx parts should be a good thing.

Article: 100168
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan 3
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 04 Apr 2006 21:54:46 GMT
Links: << >>  << T >>  << A >>
The DCM is covered well in the data sheets.

The Spartan3 DC & Switching data sheet specifies a tap resolution of 30 to 
60 ps.

The variable phase shift is different between Spartan3 and Spartan3E.  Since 
you're using Spartan3, the "older" style of variable phase shift is used: 
each PSINCDEC event is 1/256 of the CLKIN, not 1 tap delay.  The Spartan3 
Functional data sheet has 3 paragraphs on Variable Phase Shift mode that 
talks about the 1/256 increment.  What might not be clear is that there is a 
period after the PSINCDEC event before the next event can be applied, 
providing a fundamental limit to the speed of phase adjustment the system 
can attain.  Those details are also mentioned in the same paragraphs.

Each PSINCDEC event *might not* result in a tap change since ~40 ps 
corresponds to 10 ns.  Faster than ~100 MHz will have more than one event 
per tap change on average.  Slower than ~100 MHz (the DCM is good to 25 MHz) 
you get more than one tap changed per event on average.  The transition 
point is dependent on the actual tap delay.

Happy reading!


"Craig Yarbrough" <hyarbr01@harris.com> wrote in message 
news:1144185498.329325.55690@e56g2000cwe.googlegroups.com...
> Essentially I need to know, for any given DCM configuration, how much
> the DCM outputs will shift in phase for each time I nail PSINCDEC. I'm
> thinking that if I understand better how the PS part of the DCM circuit
> works I can answer this for myself. I've got a case in with Xilinx but
> either they're not understanding my question, or they're not sure how
> to answer, or who knows. Any help would be greatly appreciated. Here's
> the correspondence so far:
>
> ----------------------
> Me:
> I'm using some DCMs in dynamic phase-shift mode in a Spartan 3 and I'm
> trying to understand how the granularity of each dynamic phase shift is
> tied to the period of CLKIN. Does the phase shift feature use a fixed
> tap delay? If so, the phase shift granularity would not be dependent on
> the period of CLKIN. Also, after reading XAPP462 I surmised that the
> longer the period of CLKIN (slower the CLKIN frequency) the less number
> of effective phase shift steps. This seems counter-intuitive. Can you
> help me to understand how the dynamic phase shifting is implemented in
> the DCM?
> -----------------
> Xilinx:
> Craig,
> The DCM can always delay ~10ns.  When your clock period is slower than
> ~100Mhz (10ns period), you will not be able to phase shift the full360
> degrees.  Additionally for slower frequencies, taps are combined as per
> XAPP462, such that you may not have 256 tap changes, but will still
> have 10ns of delay to work with. It's a little confusing, but the
> circuitry basically does not allow the same resolution at slow speeds
> as it does at high.
> Hope this clears things up.
> ------------------
> Me:
> Thanks for your very quick response. I'm beginning to understand a
> little better. The goal is for us to know, for any given DCM config,
> how much dynamic phase shift occurs each time we nail PSINCDEC. For a
> DCM that has a max shift of 10ns and 512 steps or taps, is it safe to
> say that each tap is about 20ps? I understand that for slower CLKIN
> frequencies the taps could be combined to give 40ps, 60ps, etc. per
> step, and thus you'd have less than 255 steps in either direction. Is
> there a way to tell if the DCM we're using is combining taps, and how
> many taps per step? Thanks!
> -------------------
> Xilinx:
> Craig,
> There will never be 512 taps, there are max 256 and each is around
> 40ps.  The weight of each unit of increment will depend on the
> frequency of clk in.  This is where XAPP462's equations come in.
> Sounds like you got it from there.
> ------------------------
> Me:
> No not quite. The 512 taps/steps I got from equation 4 (pg 42), where
> TCLKIN is less than 10 ns and the phase shift limits are +/-255.
> However that's for fixed phase shifting. For variable phase shifting
> there's 256 taps/steps when the shift limits are +/-128. Still, are you
> sure there's only 256 taps in the delay line, since there's +/-255
> steps available in fixed phase shifting?
>
> Also, if CLKIN is 250MHz and I step PSINCDEC once, will the output
> clock shift in phase by 40ps (or one tap delay)? What if CLKIN is
> 300MHz and I step once, will the output clock shift in phase by the
> same 40ps, or some multiple? Here I'm still confused as to how each
> unit of increment is tied to the frequency of CLKIN. Equation 9 (pg 45)
> doesn't hold true.
> --------------------
> 



Article: 100169
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 05 Apr 2006 09:57:03 +1200
Links: << >>  << T >>  << A >>
Craig Yarbrough wrote:
> Essentially I need to know, for any given DCM configuration, how much
> the DCM outputs will shift in phase for each time I nail PSINCDEC. I'm
> thinking that if I understand better how the PS part of the DCM circuit
> works I can answer this for myself. I've got a case in with Xilinx but
> either they're not understanding my question, or they're not sure how
> to answer, or who knows. Any help would be greatly appreciated. Here's
> the correspondence so far:

Peter A. can probably help.
  It sounds like you are looking for a simple controlled delay line, 
with predictable behaviour ?

  The DCM is a lot more than that: when you see signals like 'locked'
and PSDONE, and mention of negative delays, then there is more
'under the hood' than a simple delay line.

  Thus you are likely to see jitter, but ISTR Peter A. has mentioned
there are ways to 'dumb down' the DCM, to a simpler subset, but more 
predictable operation.

ie your challenge is likely to be (somehow) turning off the features
you do not need :)

-jg


> 
> ----------------------
> Me:
> I'm using some DCMs in dynamic phase-shift mode in a Spartan 3 and I'm
> trying to understand how the granularity of each dynamic phase shift is
> tied to the period of CLKIN. Does the phase shift feature use a fixed
> tap delay? If so, the phase shift granularity would not be dependent on
> the period of CLKIN. Also, after reading XAPP462 I surmised that the
> longer the period of CLKIN (slower the CLKIN frequency) the less number
> of effective phase shift steps. This seems counter-intuitive. Can you
> help me to understand how the dynamic phase shifting is implemented in
> the DCM?
> -----------------
> Xilinx:
> Craig,
> The DCM can always delay ~10ns.  When your clock period is slower than
> ~100Mhz (10ns period), you will not be able to phase shift the full360
> degrees.  Additionally for slower frequencies, taps are combined as per
> XAPP462, such that you may not have 256 tap changes, but will still
> have 10ns of delay to work with. It's a little confusing, but the
> circuitry basically does not allow the same resolution at slow speeds
> as it does at high.
> Hope this clears things up.
> ------------------
> Me:
> Thanks for your very quick response. I'm beginning to understand a
> little better. The goal is for us to know, for any given DCM config,
> how much dynamic phase shift occurs each time we nail PSINCDEC. For a
> DCM that has a max shift of 10ns and 512 steps or taps, is it safe to
> say that each tap is about 20ps? I understand that for slower CLKIN
> frequencies the taps could be combined to give 40ps, 60ps, etc. per
> step, and thus you'd have less than 255 steps in either direction. Is
> there a way to tell if the DCM we're using is combining taps, and how
> many taps per step? Thanks!
> -------------------
> Xilinx:
> Craig,
> There will never be 512 taps, there are max 256 and each is around
> 40ps.  The weight of each unit of increment will depend on the
> frequency of clk in.  This is where XAPP462's equations come in.
> Sounds like you got it from there.
> ------------------------
> Me:
> No not quite. The 512 taps/steps I got from equation 4 (pg 42), where
> TCLKIN is less than 10 ns and the phase shift limits are +/-255.
> However that's for fixed phase shifting. For variable phase shifting
> there's 256 taps/steps when the shift limits are +/-128. Still, are you
> sure there's only 256 taps in the delay line, since there's +/-255
> steps available in fixed phase shifting?
> 
> Also, if CLKIN is 250MHz and I step PSINCDEC once, will the output
> clock shift in phase by 40ps (or one tap delay)? What if CLKIN is
> 300MHz and I step once, will the output clock shift in phase by the
> same 40ps, or some multiple? Here I'm still confused as to how each
> unit of increment is tied to the frequency of CLKIN. Equation 9 (pg 45)
> doesn't hold true.
> --------------------
> 


Article: 100170
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 04 Apr 2006 14:58:01 -0700
Links: << >>  << T >>  << A >>
Craig,

The delay line has many taps, but the phase shifter has only 256 
possible settings (from 0/256 to 255/256 of one period).

So, if you increment, or decrement, you will phase shift by 1/256 of a 
period, or by nothing at all (if 1/256 of a period is less than one tap 
of the physical delay line).

Take a "simple" case of 39.063 MHz (25.6 ns period):

1/256 of 25.6 ns = 100 ps

Each increment or decrement will phase shift by 100 ps (or the nearest 
tap granularity to the desired phase).

Austin

Craig Yarbrough wrote:

> Essentially I need to know, for any given DCM configuration, how much
> the DCM outputs will shift in phase for each time I nail PSINCDEC. I'm
> thinking that if I understand better how the PS part of the DCM circuit
> works I can answer this for myself. I've got a case in with Xilinx but
> either they're not understanding my question, or they're not sure how
> to answer, or who knows. Any help would be greatly appreciated. Here's
> the correspondence so far:
> 
> ----------------------
> Me:
> I'm using some DCMs in dynamic phase-shift mode in a Spartan 3 and I'm
> trying to understand how the granularity of each dynamic phase shift is
> tied to the period of CLKIN. Does the phase shift feature use a fixed
> tap delay? If so, the phase shift granularity would not be dependent on
> the period of CLKIN. Also, after reading XAPP462 I surmised that the
> longer the period of CLKIN (slower the CLKIN frequency) the less number
> of effective phase shift steps. This seems counter-intuitive. Can you
> help me to understand how the dynamic phase shifting is implemented in
> the DCM?
> -----------------
> Xilinx:
> Craig,
> The DCM can always delay ~10ns.  When your clock period is slower than
> ~100Mhz (10ns period), you will not be able to phase shift the full360
> degrees.  Additionally for slower frequencies, taps are combined as per
> XAPP462, such that you may not have 256 tap changes, but will still
> have 10ns of delay to work with. It's a little confusing, but the
> circuitry basically does not allow the same resolution at slow speeds
> as it does at high.
> Hope this clears things up.
> ------------------
> Me:
> Thanks for your very quick response. I'm beginning to understand a
> little better. The goal is for us to know, for any given DCM config,
> how much dynamic phase shift occurs each time we nail PSINCDEC. For a
> DCM that has a max shift of 10ns and 512 steps or taps, is it safe to
> say that each tap is about 20ps? I understand that for slower CLKIN
> frequencies the taps could be combined to give 40ps, 60ps, etc. per
> step, and thus you'd have less than 255 steps in either direction. Is
> there a way to tell if the DCM we're using is combining taps, and how
> many taps per step? Thanks!
> -------------------
> Xilinx:
> Craig,
> There will never be 512 taps, there are max 256 and each is around
> 40ps.  The weight of each unit of increment will depend on the
> frequency of clk in.  This is where XAPP462's equations come in.
> Sounds like you got it from there.
> ------------------------
> Me:
> No not quite. The 512 taps/steps I got from equation 4 (pg 42), where
> TCLKIN is less than 10 ns and the phase shift limits are +/-255.
> However that's for fixed phase shifting. For variable phase shifting
> there's 256 taps/steps when the shift limits are +/-128. Still, are you
> sure there's only 256 taps in the delay line, since there's +/-255
> steps available in fixed phase shifting?
> 
> Also, if CLKIN is 250MHz and I step PSINCDEC once, will the output
> clock shift in phase by 40ps (or one tap delay)? What if CLKIN is
> 300MHz and I step once, will the output clock shift in phase by the
> same 40ps, or some multiple? Here I'm still confused as to how each
> unit of increment is tied to the frequency of CLKIN. Equation 9 (pg 45)
> doesn't hold true.
> --------------------
> 

Article: 100171
Subject: Source-synchronous IO constraints in Synplify
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Wed, 05 Apr 2006 10:07:28 +1200
Links: << >>  << T >>  << A >>
Does anybody know how to do source-synchronous I/O constraints in 
Synplify?  (That get forwarded to the Xilinx backend tools).

I hit the problem every so often where I have a reference clock coming 
in on a pin, and that clock is used to clock a source synchronous 
interface where the clock is forwarded.

The output constraints all relate the output data bits (at the pin) to 
the input reference clock (at the pin).  An ideal situation would be to 
be able to constrain the output data relative to the forwarded clock, 
but I'd settle for just being able to nuke the I/O constraints relating 
the data outputs to the reference clock.

Thanks,
Jeremy

Article: 100172
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan 3
From: "Craig Yarbrough" <hyarbr01@harris.com>
Date: 4 Apr 2006 15:31:59 -0700
Links: << >>  << T >>  << A >>
Thanks for the responses. That clears things up quite a bit. One
followup question, is the ratio of tap increment/decrement to the CLKIN
frequency fixed at DCM creation, or is it dynamic? If during normal
operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio
remain the same? Or will I see a proportionally larger phase shift with
the faster clock?

- Craig


Article: 100173
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan 3
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 4 Apr 2006 16:29:43 -0700
Links: << >>  << T >>  << A >>

Craig Yarbrough wrote:
> Thanks for the responses. That clears things up quite a bit. One
> followup question, is the ratio of tap increment/decrement to the CLKIN
> frequency fixed at DCM creation, or is it dynamic? If during normal
> operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio
> remain the same? Or will I see a proportionally larger phase shift with
> the faster clock?
>
> - Craig

For Spartan-3 FPGAs, the VARIABLE phase shift is _always_ a fraction
(1/256th) of the input clock period--the equivalent of about 1.4
degrees or pi/128 radians.  In Spartan-3 FPGAs, the DCM logic converts
this value to the appropriate number of tap delays, with each tap being
between 30 to 60 ps.

Assume a 166.667 MHz clock, which has a 6 ns clock period.  Each
PSINCDEC increment/decrement step is 6/265 ns = ~23 ps, less than a tap
delay.  The DCM control logic will decide wether or not to actually
shift when the shift value falls below the tap resolution.

Or, let's take your specific example.

If CLKIN is 39.063 MHz, then the clock period is ~26 ns.  Each PSINCDEC
value is 26/256 ns = ~102 ps.

If you changed the input clock to 51.723 MHz (please reset the DCM when
changing input frequencies please), then the clock period shrinks to
~19.33 ns.  Now each PSINCDEC value is 19.33/256 ns = ~75.5 ps.  On
Spartan-3, the size of the PSINCDEC value changes according to the
input clock frequency.  Spartan-3E FPGAs behave differently.

Did this sufficiently answer your question?

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100174
Subject: Re: Altera Stratix II GX LVDS max speed
From: "KJ" <kkjennings@sbcglobal.net>
Date: Tue, 04 Apr 2006 23:30:40 GMT
Links: << >>  << T >>  << A >>
> I am curious if any of you have run any wide busses into a Stratix II
> near the rated speed and what results you had.  Did you use the Altera
> synthisis tool?  Was there any hidden problems to get the design to
> work?   Any information would be helpful.  Thanks
>
My design  has two FPGAs each with 10 input and 10 output SERDES channels 
running 8:1 @ 100 MHz for 800 Mbps per channel.  The two FPGAs are both 
Stratix II devices (2S30 and 2S60) on the same circuit board ~1 inch apart. 
So adding it all up I guess that would be 16 Gbps going back and forth. 
Since the connection was physically so short and on the same circuit board 
it was darn near the ideal setting for running high speed signals.

For the most part everything worked just fine, my only gotcha was that the 
relationship between when a particular bit comes out and the clock is not 
defined on the receiver side (although to me looking at the spec it 
certainly seemed to be to be).  This required adding in some code to get the 
receivers 'bit aligned' properly.  The good thing was that I was able to 
find this really early on in simulation long before I had a board.  See the 
'Doubt about SERDES' thread from 3/31 for more on that.  Other than that it 
all seems to be working.

I used Quartus 4.x and 5.x with no problems related to SERDES.

KJ 





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