Spartan® Family FPGAs

[vgobbi]

The output of an instance of PLL_ADV is clocked at 24 MHz plotted in the figure (in attachment)

with infinite persistence

measured by a 200 MHz and 500 MHz oscilloscopes.

It's a great clock and the system works properly,

but the waveform (like shark teeth) is not what I expected.

I expected a square waveform (closer to a digital signal).

Why this signal has this shape?

V-italiano

[gszakacs]

If you are measuring this signal near the output of the FPGA, then my guess is that you

are seeing reflections that cause some overshoot on the signal.  How long is the trace

that this signal drives?  Is it driving a single load?  If you measure the signal at the load

end does it look more square?  It doesn't look like there is enough overshoot to cause

problems in a typical system, but you might be able to get less overshoot by changing the

output drive strength to 6mA or 8 mA.  You should measure the waveform at the load

and use the drive strength that gives the "cleanest" signal.  Measuring at the FPGA or

in the middle of the trace you should probably see some "staircase" waveform.

-- Gabor

[vgobbi]

Meanwhile, thanks for the answer.-

This clock (24 MHz) is generated by a pll_adv and has as a load some of the blocks within the FPGA logic fabric.

I've then diverted to a path (order of a few cm) that arrives at a test point (parallel to the logic) for the measurement.

I wonder: how can i constrain the strength or the power of signal to drive out for measurement?

With that command?

You have to know that in addition to the clock in the other test point I measured other signals

processed by the logic fabric (of the order of tens of kHz) and in path of the same lenght

and these are perfectly square.

V-italiano

[gszakacs]

This clock (24 MHz) is generated by a pll_adv and has as a load some of the blocks within the FPGA logic fabric.

I've then diverted to a path (order of a few cm) that arrives at a test point (parallel to the logic) for the measurement.

Where the clock routes inside the FPGA is not important to the 'scope measurement.  When you say "diverted to

a path" do you mean that this clock drives another chip somewhere else on the board and also goes to the

test point?  That is not a good practice for clocks unless the test point can be placed without adding a "stub" to

the route.

I wonder: how can i constrain the strength or the power of signal to drive out for measurement?

You do this in the .ucf file.  For example if your output clock is called CLOCK_OUT and is on pin B15 then

change the line like:

NET "CLOCK_OUT" LOC = "B15" | IOSTANDARD = LVCMOS33 | DRIVE = 8;

In the example above I have added the part in red, and assume that the rest of the line is what

your .ucf file had before.

You have to know that in addition to the clock in the other test point I measured other signals

processed by the logic fabric (of the order of tens of kHz) and in path of the same lenght

and these are perfectly square.

"perfectly square" doesn't happen in the real world.  All signals are analog when viewed with

enough detail.  When you saw these slower signals, did you have the 'scope at the same

time scale?  Didn't the edges of these "perfectly square" signals have a slope similar to

the clock if you have the time scale at 25 ns per division?  And even so, the shape of the signal

will depend on the length of the board traces including the part that goes to the other chips,

not just the stub to the test point.

-- Gabor

[vgobbi]

>Where the clock routes inside the FPGA is not important to the 'scope measurement.  When you say "diverted to

>a path" do you mean that this clock drives another chip somewhere else on the board and also goes to the

>test point?  That is not a good practice for clocks unless the test point can be placed without adding a "stub" to

>the route.

No, i only drive out the signal (clock) that goes only to a test point (it drive nothing).

>You do this in the .ucf file.  For example if your output clock is called CLOCK_OUT and is on pin B15 then

>change the line like:

 >NET "CLOCK_OUT" LOC = "B15" | IOSTANDARD = LVCMOS33 | DRIVE = 8;

I understand. Many thanks.

>"perfectly square" doesn't happen in the real world.  All signals are analog when viewed with

>enough detail.  When you saw these slower signals, did you have the 'scope at the same

>time scale?  Didn't the edges of these "perfectly square" signals have a slope similar to

>the clock if you have the time scale at 25 ns per division?  And even so, the shape of the signal

>will depend on the length of the board traces including the part that goes to the other chips,

>not just the stub to the test point.

I'm sorry Gabor. It's true. An exemple of plotted signal is in attachment. It's only closer to a square shape

but  you're right of course.

Now with your suggestions i start to think that the metal routes and test point stubs on the board are not

very good to drive clocks of tens of MHz.

[eteam00]

Now with your suggestions i start to think that the metal routes and test point stubs on the board are not very good to drive clocks of tens of MHz.

The frequency of the clock has nothing to do with it.  If your board is failing due to poor clock signals (ringing and reflections which cause double-clocking, for example) at 100MHz, the board will also fail at 1KHz.  The problem -- if there is indeed a problem -- will be caused by ugly clock edges.  Reducing clock frequency will space the clock edges further apart (in time), but will not make the clock edges any prettier or cleaner.

If clock signal integrity is indeed a problem with your board, you might gain some relief by slowing the clock edges (increased rise and fall time), which can be accomplished by reducing the output drive current (or drive strength) or by inserting a series resistor between the driver and the load pins.  Either of these possible remedies has limited benefits, and would merely reduce (if at all) the severity of the problem rather than eliminate or correct the problem.

Your scope waveform is completely useless for examining signal integrity.  At 10uS per division, any useful information in the signal edges is completely hidden.  With LVCMOS25 or LVCMOS33 signals, your scope timescale should be no more than 5nS (preferably 2nS) per division, and you should capture separate traces for rising and falling edges.

-- Bob Elkind

[ccon67]

When you go to high frequency such shark teeth :-))) is what you expect to see on scope, or better form of sinusoidal

But it's possible that you have a cheap probe, a poor ground return, poor layout, impedances mis-matched, et.c... the RF guys can tell you ton of reasons in this matter 

[eteam00]

When you go to high frequency such shark teeth :-))) is what you expect to see on scope, or better form of sinusoidal

I respectfully disagree...

• 24MHz is not considered "high frequency" in the context of Spartan-3 or Spartan-6 family FPGAs.

• A 350MHz (or better) digital storage oscilloscope should be considered a minimum requirement for development work involving simple LVCMOS signals on a digital logic board.  Such a basic scope should have no trouble with accurately displaying a 24MHz square wave with LVCMOS slew rates and levels.

But it's possible that you have a cheap probe, a poor ground return, poor layout, impedances mis-matched, etc...

Agreed.  There are many possibilities for the troubled 'scope waveform display, including the scope itself, the circuit board design (including the FPGA), and the designer's measurement technique and skills.

... the RF guys can tell you ton of reasons in this matter.

Basics of digital logic circuit board design need to be understood by anyone designing with modern logic devices, not just the microwave folks.  You have no business designing FPGA-based boards if you do not understand basic transmission line principles and practical applications.

A long, long time ago you could design with lower power schottky (74LS) and old-line CMOS logic, and the 10-15nS risetimes seemed to always work without a second thought to layout toplogy or termination.  Those days are, for the most part, gone and forgotten.

It is an often-repeated and always mistaken notion that signal integrity is a concern only for 'high-speed' or 'high-frequency' circuits -- 100MHz or higher, for example.  This is completely, utterly mistaken.  A clock edge with poor waveshape (glitches, hooks, undershoot, ringing, etc. etc. etc) will compromise system reliability at any operating frequency.

Ccon67,

This response is not directed at you in a personal way, but as a manner of technical disagreement with you on a topic with which I have very very strong and clear views.  There are many inexperienced (and under-experienced) designers reading these forum threads, and they need to know that proper circuit board design requires learning the subjects of transmission lines and signal integrity.  You do not need to be communicating with a cell phone or satellite to 'get in trouble' through ignorance of such basics.

-- Bob Elkind

[vgobbi]

 > The problem -- if there is indeed a problem -- will be caused by ugly clock edges. 

System seems to work well (especially the FPGA); i was only in doubt concerning the mismatch between the waveforms drawn in user guides and measurements with professional oscilloscopes.

V-italiano

[eteam00]

i was only in doubt concerning the mismatch between the waveforms drawn in user guides and measurements with professional oscilloscopes.

You are right to be concerned about the 'scope waveforms.  Either your board has a design weakness, or your skills in using your 'scope need to be improved, or possibly both.  You should be interested in both of these areas, improving your skills for the many design projects to follow.

Even if your design seems to be working reliably, it will be helpful to understand why the "shark's teeth" waveform appeared.

-- Bob Elkind