EDK : FSL macros defined by Xilinx are wrong

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.
--------------------
Click to expand...
 
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
 
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
Click to expand...
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.
 
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
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.
Click to expand...
Would it be correct to also add this ?
- Chooses the nearest physical [~40ns] tap, to the desired delay (N x
102ps, or N x 75.5ps)
- Saturates at nom 10ns


Spartan-3E FPGAs behave differently.
Click to expand...
Whilst we are on this subject, to this detail,
can you give some info on how does Spartan 3E differ, and why ?

-jg
 
In article <qhd5fxdn27.fsf@ruckus.brouhaha.com>,
Eric Smith <eric@brouhaha.com> wrote:
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
Click to expand...
That's fine. I use ghdl.

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.
Click to expand...
I seem to recall that there are some open source bitstream downloaders
available for Linux... don't have any URL handy right at the moment, though.

Phil
 
Ok, thanks Joey, I just wanted to make sure I wasn't missing something
obvious with this OCM problem. At least it works on your system! What I'll
probably try is to do a place-and-route with just the PowerPC's and OCMs in
the system. The last time I tried that on an otherwise empty system the
memory worked just fine. Then, I can use the FPGA editor to capture that
routing to a UCF file and just lock the placement down. (Some other post
mentioned a "Directed Routing Constraints" command to try).

Wish me luck...

Jeff


"Joseph" <joeylrios@gmail.com> wrote in message
news:1144180875.234496.109560@j33g2000cwa.googlegroups.com...
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
Click to expand...
 
Craig,

Remains the same.

Austin

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
Click to expand...
 
Jim,

Yes, nearest tap to actual value, and as for how Spartan stuff works, I
have to defer to those engineers (as they did things differently).

Austin


Jim Granville wrote:

Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:

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.


Would it be correct to also add this ?
- Chooses the nearest physical [~40ns] tap, to the desired delay (N x
102ps, or N x 75.5ps)
- Saturates at nom 10ns


Spartan-3E FPGAs behave differently.


Whilst we are on this subject, to this detail,
can you give some info on how does Spartan 3E differ, and why ?

-jg
Click to expand...
 
A somewhat related question: I have simulated (behavioural) a Spartan 3
DCM with the PHASE_SHIFT parameter initialized to zero. I am using the
DCM in Variable phase shift mode. Input frequency is 100 MHz.

However, the behavioural simulation shows that once the core asserts
LOCKED_OUT high, there is still a significant (approx. 3 ns) phase
shift between the input clock and clk0_out.

Is this clk_in to clk0_out phase relationship shown in the behavioural
simulation accurate?

(Apologies for tagging onto the end of this thread, I wanted to get an
answer efficiently and a few of the DCM gurus are likely to still be
looking at this thread.)
 
On 4 Apr 2006 21:02:31 -0700, "PeterC" <peter@geckoaudio.com> wrote:

A somewhat related question: I have simulated (behavioural) a Spartan 3
DCM with the PHASE_SHIFT parameter initialized to zero. I am using the
DCM in Variable phase shift mode. Input frequency is 100 MHz.

However, the behavioural simulation shows that once the core asserts
LOCKED_OUT high, there is still a significant (approx. 3 ns) phase
shift between the input clock and clk0_out.

Is this clk_in to clk0_out phase relationship shown in the behavioural
simulation accurate?

(Apologies for tagging onto the end of this thread, I wanted to get an
answer efficiently and a few of the DCM gurus are likely to still be
looking at this thread.)
Click to expand...
It's meant to make the phase of the feedback input (clkfb) the same as
the clock input (clkin). If you have an external (to the DCM) delay
between the clk0 output and the feedback input, you will see a phase
shift between clkin and clk0.

Does this match your configuration?

Regards,
Allan
 
Hi Sylvain,

"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in
message news:1144221898.783029.239120@i39g2000cwa.googlegroups.com...
Hello,
I'm using the Xilinx tools under linux 32 bits ( a gentoo ) and
I'm having a really big problem. Basically every Xilinx application
based on java (chipscope, planahead, coregen) can just 'freeze'
at anytime (usually pretty soon after I launch it). By freeze I mean
the GUI completly stops responding and doesn't even refresh
anymore.
Click to expand...
What version of the Xilinx tools? What kernel? What JVM?

Xilinx only officially supports RHEL but I know lots of people (including
me) run it on other Linux flavours without any problems. I'd see what
difference there are between your system and an out-of-the-box RedHat
install, and go from there. (Tech support can probably tell you what the
requirements are.)

Since the Xilinx tools are more and more based on java, that
means I'm really screwed.
Click to expand...
Actually, I'd disagree. Certainly Coregen as of ISE 8.1i is a native
application, with only small amounts of Java for legacy core GUIs. You're
right about the other two though. But there is certainly no policy at work
to increase the amount of Java used (if anything, the reverse is true).

Cheers,

-Ben-
 
Hi Ben,


I'm using the Xilinx tools under linux 32 bits ( a gentoo ) and
I'm having a really big problem. Basically every Xilinx application
based on java (chipscope, planahead, coregen) can just 'freeze'
at anytime (usually pretty soon after I launch it). By freeze I mean
the GUI completly stops responding and doesn't even refresh
anymore.

What version of the Xilinx tools? What kernel? What JVM?
Click to expand...
Sorry for the lack of Infos :

- ISE Foundation 8.1 sp 3
- Chipscope 8.1.03
- PlanAhead 8.1.2

The JVM is each time provided with theses tools. It's the sun jre 1.5.0
but i'm not sure of the revision.
I've tried with the latest sun jre as well with the same effects and
blackdown jre is only 1.4.2 and doesn't work at all (normal, its not a
1.5)

tnt@ritsuko ~ $ uname -a
Linux ritsuko 2.6.14-gentoo-r5-ritsuko #3 SMP PREEMPT Sun Jan 1
22:48:38 CET 2006 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel
GNU/Linux


Xilinx only officially supports RHEL but I know lots of people (including
me) run it on other Linux flavours without any problems. I'd see what
difference there are between your system and an out-of-the-box RedHat
install, and go from there. (Tech support can probably tell you what the
requirements are.)
Click to expand...
I don't know why but each time I try to open a webcase, I get a "Server
Error"
page at url :

https://xapps2.xilinx.com/websupport/clearexp_cgi/?login=Login

with a small sun favicon.


Since the Xilinx tools are more and more based on java, that
means I'm really screwed.

Actually, I'd disagree. Certainly Coregen as of ISE 8.1i is a native
application, with only small amounts of Java for legacy core GUIs. You're
right about the other two though. But there is certainly no policy at work
to increase the amount of Java used (if anything, the reverse is true).
Click to expand...
Well, ok it may not be a policy. But it's still a fact ;)
Indeed coregen has only some "ip customizer" but one of it is the v4 fx
emac wrapper ;) And besides that, it works well. I can work with
chipscope running on a remote machine using windows remote desktop and
launching the cs_server.sh on my local machine. But for plan ahead it's
a whole lot
more annoying.
And the weird thing is I never noticed that behavior in 7.1 ...


Regards,

Sylvain
 
PeterC wrote:
Is this clk_in to clk0_out phase relationship shown in the behavioural
simulation accurate?
Click to expand...
Allan Herriman replied:
It's meant to make the phase of the feedback input (clkfb) the same as
the clock input (clkin)
Click to expand...
One caution: the default DCM configuration inserts an intentional
delay in the DCM feedback path, making the clkfb LEAD the input
clock by about 1.5 ns in the V2 family (not sure about S3 numbers).

This is done to insure zero hold at IOB inputs in the default
SYSTEM_SYNCHRONOUS mode.

This also used to cause 'clock creep' in cascaded DCM's, but the
latest S/W might set the DCM to SOURCE_SYNCHRONOUS if it
sees a cascade.

The V2 delay element is described nicely in XAPP259 v1.0 (pp 4-5);
however, the equivalent documention for S3, XAPP462 v1.1 (pp 32-34),
is horribly confused by the notion that delaying feedback makes the
output clock happen earlier.

See also Answer Records 15350 and 13024

Simulation modeling of DCM delays over the years has been, er, quirky.

For past threads, google comp.arch.fpga for "DCM SOURCE_SYNCHRONOUS"

Brian
 
Maki wrote:
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 :eek:)

Thanks,
Maki
Click to expand...
It works here in the U.S. Did you read and agree to the license terms
and
export control?
 
Hi Gabor,

When I click on link to download I get following message:
"The file you have attempted to retrieve is not available at this time.
We apologize for the inconvenience."
The same thing for every module and for licensing option.
I never reach to agree "to license terms and export control".
I have tried to investigate this recently, and Latttice tech. support
concluded that the problem is in my ISP. But ISP people says that they
get the same behavior when they try to download from their central.
They claim that there is something wrong with website !
Anybody tried to download it for Europe?

Thanks,
Best regards,
Maki.
 
Jim Granville wrote:
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
Click to expand...
[ ... snip ...]

Spartan-3E FPGAs behave differently.

Whilst we are on this subject, to this detail,
can you give some info on how does Spartan 3E differ, and why ?

-jg
Click to expand...
The only difference is in the DLL phase shifter feature included with
the DCM. Most everything else is identical between Spartan-3 and
Spartan-3E DCMs.

There's a summary of the differences in the following Answer Record,
but I'll follow up here with the abbreviated version.
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004

In FIXED phase shift mode, the difference depends on which version ISE
that you are using, as described in the data sheet and the Answer
Record. Physically, the Spartan-3 DLL performs a fixed phase shift by
as much as a full clock cycle forward or backward. The Spartan-3E DLL
performs a fixed phase shift by as much as _half_ a clock cycle forward
or backward. For nearly all applications, the Spartan-3E half-clock
shift provides the same flexibility as the full clock shift, but with
significantly less silicon.

In VARIABLE phase shift mode, the difference is that the Spartan-3 DLL
performs a variable phase shift in fractions of a clock period, 1/256th
of a full circle. Think degrees, angles, radians, using your favorite
angular unit. Extra logic within the Spartan-3 DLL calculates the
delay line change. The Spartan-3E DLL also performs a variable phase
shift using a delay line. However, in Spartan-3E, you have raw control
over the delay. The shift is always in time, not in some angular unit.
---------------------------------
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.
 
John,
Thank you for your input. It has helped tremendously.

Hopefully, just one more question. When I do this:

BUS_INTERFACE SFSL0 = my_fsl_incoming
BUS_INTERFACE MFSL0 = my_fsl_outgoing

I get these two errors, which I think is at the root of the confusion.


ERROR:MDT - fsl_v20 (my_fsl_incoming) -
C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 197 - must
have
atleast 1 master assigned!

ERROR:MDT - fsl_v20 (my_fsl_outgoing) -
C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 210 - must
have
atleast 1 slave assigned!

For now, to fix it, I've done this:

BUS_INTERFACE MFSL0 = my_fsl_incoming
BUS_INTERFACE SFSL0 = my_fsl_incoming
BUS_INTERFACE SFSL1 = my_fsl_outgoing
BUS_INTERFACE MFSL1 = my_fsl_outgoing

Any comments on the errors or my solution?

Thanks,
Dale
 
What's more time efficient then going to your EDK and just adding an OPB_USB
peripheral? I was just asking why such a thing doesn't appear to exist. But,
yes, I agree I strayed off topic.
Click to expand...
hmm, I have created an OPB_USB peripheral a few years ago. This should
answer the question if this is possible or not. In case you have special
applications that utilize a lot of bandwidth, this might still be a good
idea. Unfortunately, my solution was based on USB 1.1, i.e. 12Mbps. And
in order to avoid any speculation on size, please refer to this site:
http://homepage.mac.com/f.bertram/usb_core.html

Regarding USB 2.0, i.e. 480Mbps, the structure looks a little different.
The PHY will already include the clock recovery (which is one of the
more critical parts of a USB core), and provide parallel data to the
attached devices. In case you are wondering if the higher layers of a
USB 1.1 controller could be reused: USB 2.0 defines a few more tokens,
so the state machines would need to be extended to support these.

Regarding firmware: To get a simple HID device recognized by Windows,
you would need about 1kB of 8051 assembly code. This is not too
critical, and there is plenty of good samples out there.


Best regards, Felix

--
Dipl.-Ing. Felix Bertram
http://homepage.mac.com/f.bertram
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top