EDK : FSL macros defined by Xilinx are wrong

[Jens Hildebrandt]

Plenolo wrote:

Hi all i am new in the group, i am a italian student of computer science

and

i have hobbies for electronics, too... so i have using PIC, St6/7
microcontroller, etc.. now my dream is develop some circuit with fpga

(or

similar) and VHLD language. I have just a bit studing (only teorically)

VHDL

in my university, but now i would REALLY program some chip for develop

some

simple and medium project.
I have not money (and i don't want ) to buy some original developing
system, so i would home build some free "programmer" (in-circuit JTAG

???)

how i have do in pass for PIC / St6/7 programmers


You'd be better off on comp.arch.fpga, for the actual hardware
questions - I've crossposted to there and set the followups to go
there also.



Ok, now i am here )


Regarding programming hardware, Altera have the Byteblaster schematics
downloadable from their site, in the Byteblaster datasheet. I can;t
recall if Xilinx have similar.


Ok thank i have found ByteblasterMV's datasheet
(http://www.altera.com/literature/ds/dsbytemv.pdf), is it correctly ?
I have found also a PCB and more at http://c.combaret.free.fr/projects.html
and i that it can interest at somebody... and i have found a old article
"Build your own ByteBlaster" from old mirror of "FreeCore Library" at
http://opencollector.org/history/freecore/What%20Altera%20didn't%20tell%20you.htm

but i am also interessed to Xilix cpld and fpga so somebody know if exist
some free programmer like type for Altera chips ?

Thank you very much ALL


Thank you very much to all friends, and sorry for my very bad and poor
english language


It's better than my Italian!


ahahahah

ciao ciao

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt



Hi Plenolo,

the Xilinx download cable has been discussed in a lot of threads in this group.
The download cable is officially called "Parallel Cable III" by Xilinx. Search
for this term on the their web site and you will get a lot of results including
a link to the schematic. If you need only JTAG (sufficient for most cases) you
can even simplify the design and go along with one 74HC125, some caps and
resistors and a D-SUB connector.
Here at my university we've built lots of these cables and they all work fine.

Good luck,
Jens

------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----

 

[MM]

"DGW" <chippa11@hotmail.com> wrote in message
news:3f943a26$0$21654$afc38c87@news.optusnet.com.au...

Sorry - newbie here so not the most brain draining question. I want to
test
if a previous design works on a board that I have. The previous design was
done for a similar board.

How similar?

What I want to know - Can I just take the .bit
file and send it down via IMPACT? That way eliminating any Xilinx
different
version conflict between my software and the software it was designed on?
Basically to see if this design is working fine on my board - a previously
simulated and synthesized .bit file ONLY is all I need to demonstrate the
working project fully????

Generally, the bit file has to be originally generated for the same Xilinx
device in the same package and your board should be using the same pins. If
the device is different IMPACT will probably simply refuse to load the file,
which is not more than a frustration. If, however, your new board uses pins
differently you might end up having to deal with a much bigger problem.

/Mikhail

P.S. This question has nothing to do with comp.lang.vhdl, so I am not
replying there...

 

[MM]

"Zak" <chippa11@hotmail.com> wrote in message
news:3f9537c8$0$21651$afc38c87@news.optusnet.com.au...

Am I correct in thinking that a design lab that was simuated and
implemented
onto a demo board with Xilinx Foundation 3.1, can have its bitstream used
with another version such as Xilinx Foundation 4.2i?

The *.bit file can be used with any version of the tools that supports the
device it was originally generated for.

/Mikhail

 

[Jeff Cunningham]

Peter Alfke wrote:

If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
four outputs with practically zero skew (<100ps?)between them, and they
can be fractions or multiples of the incoming clock. When you distribute
these signals on global clocks, there will not be any hold-time caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[valentin tihomirov]

Pressing headers does not help. I know that i need sometimes to reset (clear all messages) and redownload headers in OE. That is why I've considered missing messages as another bug. Actually, the problem is bad newserver as mikhail mentioned.

 

[Peter Alfke]

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:

Peter Alfke wrote:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
four outputs with practically zero skew (<100ps?)between them, and they
can be fractions or multiples of the incoming clock. When you distribute
these signals on global clocks, there will not be any hold-time caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[Charles]

One option is to modify the "add wave" section of the
tb_<filename>.tcl script created by dspbuilder.

from : add wave -radix dec /tb_test/oSines
to : add wave -radix dec -format Analog-Step /tb_test/oSines

hope this helps,

Charles


Anshu <experteyes2002@yahoo.co.in> wrote in message news:<eec61de.-1@WebX.raydaftYaTP>...

Hello all,


Well DSPBuilder is the altera tool that works on the Simulink
platform.
Well it do have an automated flow to the simulation tool called as
ModelSim -Altera.


Well I take the tb_<filename>.tcl to ModelSim and do the
Execute macro . Now it automatically opens the waveform editor.


I can view the signals only in the digital domain . I want to
visualize in the analog domain .


How i gonna view the signals in the analog domain in the ModelSim -
Altera ?


Any Suggestions ...


Regards
Anshu

 

[Bob Perlman]

Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

Thanks,
Bob Perlman
Cambrian Design Works

On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com>
wrote:

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:

Peter Alfke wrote:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
four outputs with practically zero skew (<100ps?)between them, and they
can be fractions or multiples of the incoming clock. When you distribute
these signals on global clocks, there will not be any hold-time caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[Austin Lesea]

Bob,

The DCM ICDES expert will weigh in here.

See below,

Austin

Bob Perlman wrote:

Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

?? Yes there is added jitter, but it is added to all outputs at the same time.

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

Not at all. All outputs are generated by matched devices in the clock generator
output block state machine that has the delay line (taps) as its inputs.

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

The latter. You get the +/- 140 offset on top of the 1 ns noise.

One can think of the offset, or skew as DC, and the jitter as AC. On any signal,
you have the AC component which varies, and the DC component which is fixed and
does not vary for any given part.

That is why the timing budget has to treat offsets different from jitter. They
are both measures of time, but one is peak to peak white AC noise (jitter), and
the other is + or - DC offset (output skew). Adding offsets is linear (1+1=2)
while adding jitter is quadratic (1+1=1.414 or sqr(2)).

Adding RMS jitter would add arithmetically (1+1=2), but the peak to peak to RMS
ratio of designs is so hard to evaluate, that the RMS to P-P conversion factor
could be guessed to be from 3 to 14 (and still not be right). Easier to keep
everything in P-P, and do the calculations that way.

 

[John_H]

Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
6.1i will adjust for the input-jitter induced timing skew.

If the caution we've been designing against can be a non-issue with a proper
INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
was ecstatic to see these new constraints. If the caution we've been
designing against is a non-issue because it never was a problem (despite
apparent empirical evidence otherwise) I'm still happy though a little
confused.

I never did find out if the multiple clocks were guaranteed to use the same
delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...

Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

Thanks,
Bob Perlman
Cambrian Design Works

On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com
wrote:

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:

Peter Alfke wrote:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you
have
four outputs with practically zero skew (<100ps?)between them, and
they
can be fractions or multiples of the incoming clock. When you
distribute
these signals on global clocks, there will not be any hold-time
caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[Austin Lesea]

John_H,

A few comments...

Austin

John_H wrote:

Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
6.1i will adjust for the input-jitter induced timing skew.

Skew is a fixed phase offset, or error, from a nominal value. Think of it aas
DC.

Jitter is variations around the "significant instant" (ie where a perfect clock
would be). Think of it as AC. Don't mix AC and DC. They don't mix well. AC
adds RMS or peak to peak root mean square. DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate)
so that you do not have to make an Excel spreadsheet to keep track of
everything.

If the caution we've been designing against can be a non-issue with a proper
INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
was ecstatic to see these new constraints. If the caution we've been
designing against is a non-issue because it never was a problem (despite
apparent empirical evidence otherwise) I'm still happy though a little
confused.

If you can state your confusion to me, I will attempt to clarify (can post, or
send to me directly).

I never did find out if the multiple clocks were guaranteed to use the same
delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

Clocks fromt he same DCM are spec'd to arrive at their destinations when using
the global clock buffers +/- 140 ps (for example) when the destinations are all
on the same H clock tree within a few CLBs or IOBs of one another (ie removing
clock skew on the global).

"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...
Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

Thanks,
Bob Perlman
Cambrian Design Works

On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com
wrote:

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:

Peter Alfke wrote:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you
have
four outputs with practically zero skew (<100ps?)between them, and
they
can be fractions or multiples of the incoming clock. When you
distribute
these signals on global clocks, there will not be any hold-time
caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[Peter Alfke]

Here is something from the other stereo channel (Austin and I often
complement each other):

Each DLL or DCM takes the rising input edge and feeds it into a very
long chain of cascaded buffers. In the background, we have a complex
calculating engine that figures out which tap should feed which output,
and it gracefully adjusts the tap setting when temperature or voltage
change. (One tap is about 50 picoseconds or less).
That's the basic mechanism, quite simple, although the implementation
takes tens of thousands of transistors.

Obviously, incoming jitter is passed through to the outputs ( delayed by
more than one period), but exactly equally to all outputs. So, there is
no added skew caused by the input jitter. If you trust the global clock
lines to distribute a clock with simultaneous arrival times at all
flip-flops, you should also trust two global lines to distribute two
different (e.g. 2:1) clocks in a similar way. No race condition...

This describes the physical action. What the timing analyzer does, and
why it does it, is not my area of expertise.

Peter Alfke
==========================
Austin Lesea wrote:

John_H,

A few comments...

Austin

John_H wrote:

Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
6.1i will adjust for the input-jitter induced timing skew.

Skew is a fixed phase offset, or error, from a nominal value. Think of it aas
DC.

Jitter is variations around the "significant instant" (ie where a perfect clock
would be). Think of it as AC. Don't mix AC and DC. They don't mix well. AC
adds RMS or peak to peak root mean square. DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate)
so that you do not have to make an Excel spreadsheet to keep track of
everything.



If the caution we've been designing against can be a non-issue with a proper
INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
was ecstatic to see these new constraints. If the caution we've been
designing against is a non-issue because it never was a problem (despite
apparent empirical evidence otherwise) I'm still happy though a little
confused.

If you can state your confusion to me, I will attempt to clarify (can post, or
send to me directly).



I never did find out if the multiple clocks were guaranteed to use the same
delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

Clocks fromt he same DCM are spec'd to arrive at their destinations when using
the global clock buffers +/- 140 ps (for example) when the destinations are all
on the same H clock tree within a few CLBs or IOBs of one another (ie removing
clock skew on the global).



"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...
Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

Thanks,
Bob Perlman
Cambrian Design Works

On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com
wrote:

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:

Peter Alfke wrote:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you
have
four outputs with practically zero skew (<100ps?)between them, and
they
can be fractions or multiples of the incoming clock. When you
distribute
these signals on global clocks, there will not be any hold-time
caused
problems. The skew is definitely less than any clock-to-Q.

Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

 

[Jim Granville]

Peter Alfke wrote:

Here is something from the other stereo channel (Austin and I often
complement each other):

Each DLL or DCM takes the rising input edge and feeds it into a very
long chain of cascaded buffers. In the background, we have a complex
calculating engine that figures out which tap should feed which output,
and it gracefully adjusts the tap setting when temperature or voltage
change. (One tap is about 50 picoseconds or less).
That's the basic mechanism, quite simple, although the implementation
takes tens of thousands of transistors.
snip

So when this 'smart tracking' has to adjust a delay step
( due to Temp, or Vcc changes ) you will get a quantized jump
in the delay ? (50ps)
Some may call that jitter, and it depends on the HW design
how often it occurs.
With Hyst in the decision, the spectrum of the jitter can
be reduced, but note that poor Vcc behaviour can cancell the
Hyst.
It does not sound like the adjust steps are an issue from
Tsu/Th viewpoint, but they _may_ affect a system with a critical
jitter budget - such as those where jitter == signal to noise
floor.

-jg

 

[Jeff Cunningham]

Google dug up the following quote from Ray back on 2003-04-21.

/quote

I got nailed on an early Virtex design where the 1x and 2x clocks were
sourced by the same DLL. Several factors contributed:
- the 1x clock was very lightly loaded while the 2x clock was heavily
loaded,
- There was fair amount of jitter on the clock input (>300ps IIRC),
- There was heavy output switching on pins adjacent to the clock input
pin (adds
to jitter at DLL clock input)
- the failing nets were on direct flip-flop to flip-flop connections (no
LUT) on
FF's that were floorplanned to be adjacent.
- static timing indicated no setup or hold violations.

The combination of the jitter (which with input jitter barely in spec
plus jitter introduced by output current modulation of input thresholds
was likely out of spec), highly skewed loading (not convinced this is a
real factor), and the absolute minimum flip-flop to flip-flop delay
conspired to bite us where it counted. Since then, we have as a policy
treated the 1x and 2x clock domains with utmost care to make sure the
receiver is not sensitive around the transmitter's active edge. I
suspect that if you have no direct connects between adjacent slices at
the clock domain boundary, you won't have a problem.

/unquote

Peter & Austin, I really want to believe you. Do you think Ray's being
overly careful? Could it be a problem in the "extreme" topology Ray
describes?

Jeff

 

[Tim]

Jeff Cunningham wrote:

Google dug up the following quote from Ray back on 2003-04-21.

<big snip>

The combination of the jitter (which with input jitter barely in spec
plus jitter introduced by output current modulation of input
thresholds was likely out of spec), highly skewed loading (not
convinced this is a real factor), and the absolute minimum flip-flop
to flip-flop delay conspired to bite us where it counted.

As I recall this discussion and various previous analyses,
the final concensus was that hugely different loads on the
two clocks is suspect #1.

If so, is this still (!) the view at Xilinx, and if it is the
view has the clock buffering changed enough on recent products
to alter matters?

 

[Austin Lesea]

Jeff,

Read my techXclusive on the web "Does Your Design Have Enough Slack" which
describes how jitter takes directly away from the slack in your timing
budget.

ISE6.1 has new ways that keep track of jitter in the new products, so that
this effect can be carefully kept track of (between clocks from different
DCMs, 1X vs 2X, etc.).

I would say that if you ignore jitter totally, and expect to operate without
any problems, and are pushing any limit (frequency, time, part utilization,
SSO limits) you will be disappointed.

This is not unique to FPGAs or even to any one vendor: it is a fact of life
that with clock periods approaching 2.5 ns in some designs, 500 ps P-P of
jitter becomes 20% of the entire timing budget!

If the system clock was 10 MHz, and the design was not too exciting, then no
one would care about 500 ps of jitter.

Austin

Jeff Cunningham wrote:

Google dug up the following quote from Ray back on 2003-04-21.

/quote

I got nailed on an early Virtex design where the 1x and 2x clocks were
sourced by the same DLL. Several factors contributed:
- the 1x clock was very lightly loaded while the 2x clock was heavily
loaded,
- There was fair amount of jitter on the clock input (>300ps IIRC),
- There was heavy output switching on pins adjacent to the clock input
pin (adds
to jitter at DLL clock input)
- the failing nets were on direct flip-flop to flip-flop connections (no
LUT) on
FF's that were floorplanned to be adjacent.
- static timing indicated no setup or hold violations.

The combination of the jitter (which with input jitter barely in spec
plus jitter introduced by output current modulation of input thresholds
was likely out of spec), highly skewed loading (not convinced this is a
real factor), and the absolute minimum flip-flop to flip-flop delay
conspired to bite us where it counted. Since then, we have as a policy
treated the 1x and 2x clock domains with utmost care to make sure the
receiver is not sensitive around the transmitter's active edge. I
suspect that if you have no direct connects between adjacent slices at
the clock domain boundary, you won't have a problem.

/unquote

Peter & Austin, I really want to believe you. Do you think Ray's being
overly careful? Could it be a problem in the "extreme" topology Ray
describes?

Jeff

 

[Austin Lesea]

Tim,

Since Virtex everything is fully buffered, Loads can change the timing, but
only very slightly (10s of ps MAX), and not much at all on global clock
buffers.

What gets folks in trouble is what I answered in my other post on this
thread: they fail to see what their total system jitter is, and add that
to the amount of slack they need.

Austin

Tim wrote:

Jeff Cunningham wrote:
Google dug up the following quote from Ray back on 2003-04-21.

big snip

The combination of the jitter (which with input jitter barely in spec
plus jitter introduced by output current modulation of input
thresholds was likely out of spec), highly skewed loading (not
convinced this is a real factor), and the absolute minimum flip-flop
to flip-flop delay conspired to bite us where it counted.

As I recall this discussion and various previous analyses,
the final concensus was that hugely different loads on the
two clocks is suspect #1.

If so, is this still (!) the view at Xilinx, and if it is the
view has the clock buffering changed enough on recent products
to alter matters?

 

[Peter Alfke]

Jim Granville wrote:

It does not sound like the adjust steps are an issue from
Tsu/Th viewpoint, but they _may_ affect a system with a critical
jitter budget - such as those where jitter == signal to noise
floor.

Jim, if your design is sensitive to 50 ps jitter, it needs an external

clean-up PLL.
Inside a digital chip there will always be some jitter, and on-chip PLL
are not so good either. Jitter is noise in the time domain, and digital
circuits are inherently noisy...

Peter Alfke

 

[daica]

hi scott, <BR>
I assume your camera output is 125 fps, non interlace? At the output DVI requires 60 fps, that mean you are dropping 65 frames per second. <p>As other mentioned, you need to make sure to swap the buffers in sync with the camera vsync that makes image integrity. Since you are vertically down-scanning, 2 frame buffers is enough, otherwise you may need more than 2 buffers or the dualport rams. <p>One thing I doubt about 125 frames/s <BR>
camera non interlace?

 

[Bob Perlman]

Hi -

On 5 Nov 2003 03:32:50 -0800, ra1brzrufe001@sneakemail.com (vijay)
wrote:

theosib@hotmail.com (Timothy Miller) wrote in message news:&lt;80eae8c5.0311041140.7516de73@posting.google.com&gt;...
I am a user of Nedit (nedit.org) and I do a lot of Verilog coding.
When coding verilog modules, you have a module definition which takes
one form, and you have a module instantiation which takes another
form. Even with columnar copy/paste/search/replace, it can be a
tedious process to convert one to the other. Thus, I humbly offer a
Nedit macro I wrote that converts a module definition (header) to an
instantiation. Make a copy of the module definition header, paste it
where you want it, put the cursor anywhere within the copy, and then
run the macro.

Similar function is provided by other scripts available on the web.
You could try invoking these scripts from your editor.
for example I use the alias
\xemacs -l ~/.emacs.batch -l verilog-mode.el !* -f verilog-auto -f
save-buffer --batch
To take advantage of the features found in verilog-mode.el in my
editor(vim)
Regards
Vijay

I second that; I do the same thing from within my editor (Ultraedit).
The point is this: you can use a good deal of the power of Verilog
mode for emacs *without ever opening up Emacs*. Automatically
generating argument lists, either for modules or their instantiations,
is a snap.

Bob Perlman
Cambrian Design Works