Oscillating output signal Nexys3

[renti]

Hi, I have written some VHDL code that when simulated looks like in the first picture. However, if I route the signal to a PMOD connector, the signal behaves in a very weird way, as can be seen on the scope screenshot. I made extra sure the scope probe was grounded properly. The problem persists if I route the signal to different connectors. Has anybody experienced anything similar?

[D@n]

Is your output the result of combinatorial logic, or a registered value?

Dan

[renti]

The sclk signal is the one I'm feeding out. I also put sclk_en and nsclk_en to two different PMOD pins and they look fine. 

nclk<=not(clk);
nsclk_en<=not(sclk_en);
clock_out_ff : ODDR2 
Port map(
d0 => '1',
d1 => '0',
CE => sclk_en,
c0 => clk,
c1 => nclk,
q => sclk,
r => '0',
s => nsclk_en
);

 

[D@n]

Ok, I just reread your question again.  What you want is an oscillating output that is gated by a clock enable, right?  You want a gated clock, and ... that's what you've measured.

You posted two pictures.  The first is the one you expect things to look like, and the second is what you actually measure, right?  So ... ahm ... what's the problem?  What are you expecting that you aren't getting?  Are you expecting a perfectly square wave in the second picture?  If that's the case, we should discuss signal transition speed (it's not instantaneous) and measurement bandwidth (that's not perfect either).  If the problem is something else, such as not seeing the low flat value before the high flat value, having the wrong number of transitions, or ... whatever else, let me know (I assumed you might be off-cut, and I didn't count the transitions).

So ... let's discuss bandwidth for a moment, since while clocks may avoid logic delays (gated clocks can't), they can't avoid a bandwidth limitation.  If you look at the Fourier transform of a square wave (wikipedia works this out), you'll find that it has an infinite frequency extent.  However, the moment you add capacitance (or inductance) into a circuit (a.k.a. wires), the bandwidth ceases to be infinite.  (Everything has capacitance ... the width of the wire on a circuit board effects this, the distance between layers within the circuit board, etc.)  That means that the square wave is going to look smoother, with rounder edges.  The more bandwidth you have available, the less the capacitance affects you, etc., the sharper the edges will be.  In general, however, a chip or a board will only be designed for a particular speed.  Wires cannot transition faster--they don't have the bandwidth.  Hence the clocks will look smoother.  The closer you get to that maximum frequency, the smoother the clocks will look and the closer they will match a sine wave.  One of the difficult parts of designing a really high speed board, such as the NetFPGA for example, is that you must engineer these effects to an absolute minimum--it can be a rough challenge.

Both wikipedia and WolframMathworld try to discuss the effects of bandwidth on a square wave in their respective articles. 

In your case, you've also got some measurement limiting taking place.  If you only sample (or display) a signal at four times per clock tick, you'll get an effect where the clock (even if square) starts to look more like a sine wave again.  It's actually worse than that, because if your clock rate on your board starts to get close to (or past) the maximum rate your instrument can measure, you can see all kinds of fascinating effects.  These effects are called aliasing, another topic you can find in wikipedia.  Because of this, I remember one old hand teaching me that the test instrumentation must always be 10x better than the instrument under test.  So, if you are running a clock at 25 MHz, you must have a test instrument capable of sampling at 500MHz.  (50MHz would be the minimum to avoid aliasing, 500MHz is 10x better than that ...)  Anything less and you start to have to worry about how the test instrument is interfering with your ability to interpret your results--such as I imagine you might be noticing above..

Still, though, I feel like I'm guessing at your problem.  Have I addressed it, or did I miss it?

Dan

 

[renti]

Hi Dan,

thanks for the long answer. This is embarrassing, you are right, it was indeed a bandwidth problem and the signal is correct the way it is. Thanks again for the help!

[D@n]

Renti,

1. Glad I could help. 

2. Don't be embarrassed.  This mistake isn't as uncommon as it sounds--it's just been years since I've made it.  I figure you've got to make this mistake at least once in your journey.  Hopefully by placing this on a public forum, we'll even keep others from the same mistake.

Still, I'm glad I could help.

Dan