EDK : FSL macros defined by Xilinx are wrong

[Michael Chan]

Just wondering if anyone can point me to some articals or papers that analyse
the characteristics of xilinx DLLs vs altera PLLs.

Thanks.

 

[Austin Lesea]

http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf

Is a side by side bench test of the DLL vs the PLL in a "real" situation
where IOs and logic are switching, not just a quiet side by side
back-off of a do-nothing design.

As frequencies increase, delays decrease, jitter fast becomes the number
one problem in a design.

Realizing this, we have many tools, design notes, suggestions, and
techniques to minimize jitter, and maximize performance.

Also,

http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf

is an excellent newly written description of the DCM (includes DLL) for
Spartan 3 which also makes for good reading.

Austin

Michael Chan wrote:

Just wondering if anyone can point me to some articals or papers that analyse
the characteristics of xilinx DLLs vs altera PLLs.

Thanks.

 

[Josh Model]

Austin,

Thanks, that's a decent and concise treatment of jitter. Not particularly
easy to do.

Quick question that perhaps you (or anyone who's had experience w/ the
RocketIO receivers) could answer...

Is the Peak-Peak Jitter tolerance spec'd in the rocketIO user's guide (.65
UI) spec'd in the 14-sigma fashion described in the xapp462 or is some
measurement interval (such as loop lock time) assumed?

As it's given in the RocketIO User's guide, there's no BER, no sigma factor,
and no specific measurement interval. Table 3-3, p.103 of the guide only
says "peak-to-peak"

Any help/ experience would be greatly appreciated

Thanks,
--Josh Model
MIT Lincoln Laboratory





"Austin Lesea" <austin@xilinx.com> wrote in message
news:c27kfg$e211@cliff.xsj.xilinx.com...

http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf

Is a side by side bench test of the DLL vs the PLL in a "real" situation
where IOs and logic are switching, not just a quiet side by side
back-off of a do-nothing design.

As frequencies increase, delays decrease, jitter fast becomes the number
one problem in a design.

Realizing this, we have many tools, design notes, suggestions, and
techniques to minimize jitter, and maximize performance.

Also,

http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf

is an excellent newly written description of the DCM (includes DLL) for
Spartan 3 which also makes for good reading.

Austin

Michael Chan wrote:
Just wondering if anyone can point me to some articals or papers that
analyse
the characteristics of xilinx DLLs vs altera PLLs.

Thanks.

 

[Austin Lesea]

Josh,

The p-p jitter for the V2P Rocekt IO is specified by using the 14 sigma
case of broadband (DC to daylight, no filters) RMS jitter as measured by
the Agilent DCA.

This method defines the "eye" as that which has 1E-12 BER or less
extrapolated from the 14 sigma points (no actual BER measurements are
done with this method).

As most folks know, if you filter out the low frequency phase noise
(which is tracked out by the receiver) then the RMS jitter is even less.

Hence the claim that we are error free when used correctly is valid (as
the 1E-12 contour was grossly pessimistic).

Austin

Josh Model wrote:

Austin,

Thanks, that's a decent and concise treatment of jitter. Not particularly
easy to do.

Quick question that perhaps you (or anyone who's had experience w/ the
RocketIO receivers) could answer...

Is the Peak-Peak Jitter tolerance spec'd in the rocketIO user's guide (.65
UI) spec'd in the 14-sigma fashion described in the xapp462 or is some
measurement interval (such as loop lock time) assumed?

As it's given in the RocketIO User's guide, there's no BER, no sigma factor,
and no specific measurement interval. Table 3-3, p.103 of the guide only
says "peak-to-peak"

Any help/ experience would be greatly appreciated

Thanks,
--Josh Model
MIT Lincoln Laboratory





"Austin Lesea" <austin@xilinx.com> wrote in message
news:c27kfg$e211@cliff.xsj.xilinx.com...

http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf

Is a side by side bench test of the DLL vs the PLL in a "real" situation
where IOs and logic are switching, not just a quiet side by side
back-off of a do-nothing design.

As frequencies increase, delays decrease, jitter fast becomes the number
one problem in a design.

Realizing this, we have many tools, design notes, suggestions, and
techniques to minimize jitter, and maximize performance.

Also,

http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf

is an excellent newly written description of the DCM (includes DLL) for
Spartan 3 which also makes for good reading.

Austin

Michael Chan wrote:

Just wondering if anyone can point me to some articals or papers that

analyse

the characteristics of xilinx DLLs vs altera PLLs.

Thanks.

 

[Greg Steinke]

"Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>...

Just wondering if anyone can point me to some articals or papers that analyse
the characteristics of xilinx DLLs vs altera PLLs.

Thanks.

Michael,
Altera has published a document comparing PLLs to DLLs, specifically
looking at jitter.
http://www.altera.com/literature/tb/tb70.pdf

We also publish specs for PLL jitter in the appropriate device
datasheet, so you can take a look at those as well.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

 

[Austin Lesea]

Greg,

Two things: first, the spec is not peak to peak, but cycle to cycle, so
we do not "exceed" our spec as you erroneously state, and second, the
jitter from the DLL is decidely non-gaussian so any statistical
estimates are wrong. Can't "multiply by 6" or any other shortcut.

The peak to peak jitter is entirely random, but not a normal
distribution as the taps are discrete, and the selection of the taps is
from a digital control system.

The intrinsic jitter is not very interesting, as the "when busy" jitter
of our part is 1/3 of yours under the same conditions.

Choosing the 2X output is also not entirely honest, as the 1X outputs
have half the jitter (something you fail to mention, but we freely
advise our customers of).

Other than that, we also have LeCroy equipment, and use it often. The
+/- 6 ps intrinsic measurement capability for jitter is selling you
short, however, as the Wavecrest with its +/- 3 ps peak to peak worst
case intrinsic jitter would make the PLL look better.

Austin

Greg Steinke wrote:

"Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>...

Just wondering if anyone can point me to some articals or papers that analyse
the characteristics of xilinx DLLs vs altera PLLs.

Thanks.


Michael,
Altera has published a document comparing PLLs to DLLs, specifically
looking at jitter.
http://www.altera.com/literature/tb/tb70.pdf

We also publish specs for PLL jitter in the appropriate device
datasheet, so you can take a look at those as well.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

 

[Steve Casselman]

If you are doing jtag can't you use the xilinx cable design.


Steve

"Rene Tschaggelar" <none@none.net> wrote in message
news:408c21a8$0$708$5402220f@news.sunrise.ch...

Mike Treseler wrote:

Florian Student wrote

www.altera.com/literature/ds/dsbyte.pdf only gives a file not found
error.


see page 4 of
http://www.altera.com/literature/ds/dsbytemv.pdf


The only change to the MV is the replaacement of the LS244 with a HC244
to make it work also at 3.3V.

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

 

[Rene Tschaggelar]

I doubt, since the driver is specific to the part.
This ByteblasterMV is done in an evening with selfetching.

Rene

Steve Casselman wrote:

If you are doing jtag can't you use the xilinx cable design.


Steve

"Rene Tschaggelar" <none@none.net> wrote in message
news:408c21a8$0$708$5402220f@news.sunrise.ch...

Mike Treseler wrote:


Florian Student wrote


www.altera.com/literature/ds/dsbyte.pdf only gives a file not found

error.


see page 4 of
http://www.altera.com/literature/ds/dsbytemv.pdf


The only change to the MV is the replaacement of the LS244 with a HC244
to make it work also at 3.3V.

 

[Florian Student]

Thank you Mike, thank you Rene

Kind regards,
Florian Student

 

[Jonathan Bromley]

On Wed, 28 Apr 2004 11:37:22 -0700, Chris
Carlen <crcarle@BOGUS.sandia.gov> wrote:

[...]

But there is still the question about how to direct conditional
compilation of statements in an instantiated module from the
instantiating module. Ie., I'd like to have an `ifdef to conditionally
compile for instance the initial statement which is supoerfluous to
implementation, but not for simulation. Or I'd like to not have to edit
the module to change the defines, but simply adjust them from the top
level. I don't quite know how this works yet. I'll have to do some
experimenting.

`define is global to a Verilog compilation, and therefore cannot be
controlled instance-by-instance. There's no way to conditionalise
compilation instance-by-instance in standard Verilog, but if your
tools support Verilog-2001 (not a done deal by any means) then
you can use "generate...if" to conditionalise some code based
on the value of a parameter, which of course can be pushed down
into an instance from its parent.

[...]

I *think* I understand that it's OK to
remove the reset (!Out) on Q_c asynchronously, although it
could easily be subverted by a sufficiently fast Clk_in.

I hadn't thought about what could go wrong here with the clock being
close to the reset. I got the basic circuit from Art of Electronics,
2nd. ed., page 523.

If it's in AoE it *must* be good

Are you thinking it is possible for some of the
flops in the counter to interpret a clock edge close to the release of
reset as happening before the reset removal, but some of the other flops
interpreting it as not happening before the reset removal?

Exactly so. In general, it is unsafe for an asynchronous signal
to influence more than one FF. The jargon is "input hazard".

One can
envision this happening due to propagation delays over physical wires.
But perhaps in the case of starting from zero, this isn't an issue.

This is indeed the case. If the counter is held at zero, then
only the very first flip-flop can be affected by the first clock
after reset is removed; so the timing of reset w.r.t. clock
doesn't matter (except that you might get metastability on the
LSB counter bit, but that's another story). However, if you are
trying to clock the counter very fast, it's just conceivable that
the skew on Reset between bit 0 and bit 1 of the counter is
greater than one clock period; in this case, it's just possible
that the counter could successfully increment from 0 to 1, but
the next bit is still held in reset by the time the NEXT clock
arrives - so the counter goes back to zero again. However,
this is very unlikely because the synth tools will surely lay
out the counter so that its FFs are rather close together (so
that it can use the ripple carry chain) and therefore the reset
distribution skew is likely to be quite small. So don't worry,
it's just me being paranoid as usual.

I also am nervous of the clearing of Out by a pulse
which is immediately terminated by Out clearing...

Yeah, I addressed this above, but what do you think of my analysis?

I think it's OK. Out is held in a FF. I think the design is
a reliable asynchronous state machine, but when I said "nervous"
I meant it - these things are hard to analyze, and it's very
easy to screw up by extrapolating from a working design to
a slightly different one that fails horribly, usually just
after shipment.

Well that's probably safer. I am becomming very interested in digital
delay generation and the question of how to reduce jitter. Of course,
my design has no leading edge jitter, and has up to one clock period of
trailing edge jitter. A fully synchronous design would do what? I
suppose there would be synchronization jitter on the leading edge (the
trigger edge), but then the time would be without jitter. There has to
be jitter somewhere.

Sure. A fully synch design has -0/+1 "jitter" both at the start and
at the end, I think. No escape. (It's not "jitter" in the usual
sense, rather "quantization error", but I guess that depends on what
you're trying to do with the resulting signal).

OTOH you should trawl through the last few months' comp.arch.fpga
archives and take a look at what Peter Alfke and others have had
to say about using polyphase clocks for very high resolution
time measurements. The Xilinx DLLs make all sorts of interesting
things possible. I haven't followed that discussion in detail,
but it sounds like a lot of fun.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Chris Carlen]

Jonathan Bromley wrote:

Are you thinking it is possible for some of the
flops in the counter to interpret a clock edge close to the release of
reset as happening before the reset removal, but some of the other flops
interpreting it as not happening before the reset removal?


Exactly so. In general, it is unsafe for an asynchronous signal
to influence more than one FF. The jargon is "input hazard".

I see. I will have to keep this in mind for future stuff.

One can
envision this happening due to propagation delays over physical wires.
But perhaps in the case of starting from zero, this isn't an issue.


This is indeed the case. If the counter is held at zero, then
only the very first flip-flop can be affected by the first clock
after reset is removed; so the timing of reset w.r.t. clock
doesn't matter (except that you might get metastability on the
LSB counter bit, but that's another story). However, if you are
trying to clock the counter very fast, it's just conceivable that
the skew on Reset between bit 0 and bit 1 of the counter is
greater than one clock period; in this case, it's just possible
that the counter could successfully increment from 0 to 1, but
the next bit is still held in reset by the time the NEXT clock
arrives - so the counter goes back to zero again. However,
this is very unlikely because the synth tools will surely lay
out the counter so that its FFs are rather close together (so
that it can use the ripple carry chain) and therefore the reset
distribution skew is likely to be quite small. So don't worry,
it's just me being paranoid as usual.

Things should be Ok at my 10kHz clock rate ;-D

Sure. A fully synch design has -0/+1 "jitter" both at the start and
at the end, I think. No escape. (It's not "jitter" in the usual
sense, rather "quantization error", but I guess that depends on what
you're trying to do with the resulting signal).

OTOH you should trawl through the last few months' comp.arch.fpga
archives and take a look at what Peter Alfke and others have had
to say about using polyphase clocks for very high resolution
time measurements. The Xilinx DLLs make all sorts of interesting
things possible. I haven't followed that discussion in detail,
but it sounds like a lot of fun.

I noticed that discussion, and my reaction was "what in the heck are
they talking about?" I think after getting some experience with logic
at the CPLD level I will head towards FPGAs. I'd like to first complete
a formal text or course on the matter.

Thanks for the input.


Good day!


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Jim Carlock]

Hit the escape key?

--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.


"Adlene" <Adlene3352@hotmail.com> wrote in message
news:c7hbeh$bqt$1@reader01.singnet.com.sg...
Hi, there:

When I right click on a text file, the Convert to Palm e-Book and
Convert to Palm PDB comes out...I have removed the application
for Palm e-Book Builder and restarted PC but these two menus won't
go away...

How may I remove these two menus manually?

Best Regards,
Kelvin

 

[Kelly]

Hi Kelvin,

It depends on where in the right click menu. They can be removed from here,
for starters:

Go to Start/Run/Regedit and navigate to:

HKEY_CLASSES_ROOT\*\OpenWithList
HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Directory\Background
HKEY_CLASSES_ROOT\Directory\shell
HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Drive\shell
HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Folder\shell
HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers

--
All the Best,
Kelly

Microsoft-MVP WindowsŽ XP
2004 Windows MVP "Winny" Award

Troubleshooting Windows XP
http://www.kellys-korner-xp.com

Taskbar Repair Tool Plus!
http://www.kellys-korner-xp.com/taskbarplus!.htm


"Adlene" <Adlene3352@hotmail.com> wrote in message
news:c7hbeh$bqt$1@reader01.singnet.com.sg...
Hi, there:

When I right click on a text file, the Convert to Palm e-Book and
Convert to Palm PDB comes out...I have removed the application
for Palm e-Book Builder and restarted PC but these two menus won't
go away...

How may I remove these two menus manually?

Best Regards,
Kelvin

 

[sabine]

David,

The DUC is a free IP which can be downloaded from our website.
As opposed to other IP, it has been implemented with our System Generator
tool and can be downloaded as a source code for System Generator, or
a netlist.
Please take a look at the following page and let me know if you have any
questions.

http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=DUC

Sabine

------------------------------------------------------------------------

Subject: Where is my Digital Up Convertor in Logicore ??!!
Date: 6 Jun 2004 19:58:28 -0700
From: djb@global.net.mt (David Joseph Bonnici)
Organization: http://groups.google.com
Newsgroups: comp.arch.fpga

I have been on the xilinx website and they say that they have included
the Digital Up Convertor in ISE package. I have opened Coregen but I
CANNOT FIND IT. Perhaps I am getting cross eyed. I tried a file search
on the installation path C:\xilinx and there is not even the duc.pdf
I know that I can build one myself from the other blocks, but I would
like to use it. (to be less error prone, designs use less slices, less
code, less time)
Is there someone that has the same problems that I have?

Apart from that: Can someone explain me what is "Bit convergent
rounding" with a practical example of numbers?

David

 

[qianeasy]

Hi,David
Did you use the EMAC core in EDK, I heard that it will be unstable
unless you buy a core from Xilinx.

 

[Matthew Ouellette]

The EMAC core is delivered by Xilinx in the EDK is identical to the
pay-for core, except it has an eval license that enables reset circuitry
so that the device times out after 8-10 hours of use. Besides the reset
logic, the functionality should be equivalent.

Matt

qianeasy wrote:

Hi,David
Did you use the EMAC core in EDK, I heard that it will be unstable
unless you buy a core from Xilinx.

 

[tns1]

license_rant_master wrote:

I am an ASIC engineer who frequently 'takes work home' with me.
snip

With a standard cable or DSL connection, VNC works pretty well. I don't
think it could violate any license since it only virtualizes the
interface, and that part at least, should be fully owned by the user.
Overzealous license agreements that try to impose what you do with your
hardware should be slapped down by the courts, but the increasing
virtualization /globalization blurs the 'site' definition. Interesting
stuff.

If VNC really does not work for you, there must be a way that your
vendor can extend/change the license to one or more node locked seats
(tied to a removable NIC, say). Node locked seats should never be
restricted by distance from the license server. Rant on dude. We should
all have the right to use every legitimate seat 24/7, no matter where we
are.

 

[rickman]

tns1 wrote:

license_rant_master wrote:
I am an ASIC engineer who frequently 'takes work home' with me.
snip

With a standard cable or DSL connection, VNC works pretty well. I don't
think it could violate any license since it only virtualizes the
interface, and that part at least, should be fully owned by the user.
Overzealous license agreements that try to impose what you do with your
hardware should be slapped down by the courts, but the increasing
virtualization /globalization blurs the 'site' definition. Interesting
stuff.

If VNC really does not work for you, there must be a way that your
vendor can extend/change the license to one or more node locked seats
(tied to a removable NIC, say). Node locked seats should never be
restricted by distance from the license server. Rant on dude. We should
all have the right to use every legitimate seat 24/7, no matter where we
are.

I can tell that this is going to be one of those long threads that have
a loooong life.

Software companies charge with two principles in mind. One is the cost
of doing busisness. If you buy three licenses for a given location the
vendor can expect an average level of support that they will need to
provide to that site and others like it. If they allow you to use the
same license at other locations, their revenue will not go up, but the
level of support required will likely increase. Many vendors allow for
this by selling more expensive licenses which are authorized company
wide. So you will just need to pay a bit more.

The other issue that software vendors consider is the one that users
consider, value. Let's face it, like other products, the price is not a
function of what it costs to make it unless that cost sets the minumum
price. Non-commodity products are sold at a price that reflects the
value to the customer. A node locked license has less value than a site
license which has less value than a company wide license. Support costs
not withstanding, the value here sets the price paid.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[tns1]

In my experience the 'after hours' time I spend on these tools is either
because the SW is buggy/poorly documented and I couldn't get the job
done during office hours, or I am trying to extend my skills, ultimately
reducing my need for support. Heck, the only support available after
hours (sometimes during hours too) are these public forums anyway, so
what is the vendors cost? Unless of course, the users are finding lots
of bugs and pressing for fixes. But hey, this is just one of those
unpaid services we users provide.

rickman wrote:

tns1 wrote:

license_rant_master wrote:

I am an ASIC engineer who frequently 'takes work home' with me.

snip

With a standard cable or DSL connection, VNC works pretty well. I don't
think it could violate any license since it only virtualizes the
interface, and that part at least, should be fully owned by the user.
Overzealous license agreements that try to impose what you do with your
hardware should be slapped down by the courts, but the increasing
virtualization /globalization blurs the 'site' definition. Interesting
stuff.

If VNC really does not work for you, there must be a way that your
vendor can extend/change the license to one or more node locked seats
(tied to a removable NIC, say). Node locked seats should never be
restricted by distance from the license server. Rant on dude. We should
all have the right to use every legitimate seat 24/7, no matter where we
are.


I can tell that this is going to be one of those long threads that have
a loooong life.

Software companies charge with two principles in mind. One is the cost
of doing busisness. If you buy three licenses for a given location the
vendor can expect an average level of support that they will need to
provide to that site and others like it. If they allow you to use the
same license at other locations, their revenue will not go up, but the
level of support required will likely increase. Many vendors allow for
this by selling more expensive licenses which are authorized company
wide. So you will just need to pay a bit more.

The other issue that software vendors consider is the one that users
consider, value. Let's face it, like other products, the price is not a
function of what it costs to make it unless that cost sets the minumum
price. Non-commodity products are sold at a price that reflects the
value to the customer. A node locked license has less value than a site
license which has less value than a company wide license. Support costs
not withstanding, the value here sets the price paid.

 

[Mark Ng]

Hi Richard,

Try the attached...

Thanks,
Mark

Richard Sloan wrote:

Why does code that someone wrote and used on a Lattice part, not compile
right with Xilinx webpack tools, various parts of the code it does not like.

Is ABEL a standard? Seems the answer is already no.

Can anyone help make the code Xilinx ready? Its not a lot of code 40 lines
and most of its look fairly simple.

I will attach it for you to see.

Thanks!