12-03-2011 01:51 PM - edited 12-03-2011 01:54 PM
Hello, folks. I've got an interesting problem where the sensitivity list for a block isn't working correctly. I'm not sure why.
I wanted an LED to change states once every second as a way to test triggering on both edges of an input signal from a 40 MHz oscillator. I later plan to continue my project to do more important signalling which requires logic on both edges--this is just a test. I figured I'd tell it to invert the LED once every 80 million edges which should cause it to change once per second with the 40 MHz oscillator I'm using, yielding an ultimate flash frequency of 0.5 Hz.
I noticed first that the LED in the example below was flashing at an unexpectedly fast rate. After expanding the count condition to 800 million and timing how long it took with my watch, I was able to approximate the real triggering frequency to be right at about 1.8 GHz. Furthermore, I can take my oscillator input lead and tie it to ground and the counter still progresses at 1.8 GHz. It doesn't appear that the sensitivity list is working for some reason.
OSC is an XO ticking at 40 MHz.
module Core(input OSC, output LED); reg [31:0] Delay = 32'd0; reg obuf_LED = 0; always @(OSC) begin if (Delay == 80000000) begin Delay <= 0; obuf_LED <= ~obuf_LED; end else begin Delay <= Delay + 1; end end assign LED = obuf_LED; endmodule
Any idea of what is wrong? Am I mistaken in my thought that @(signal) is equivalent to @(posedge signal or negedge signal)? It's worth noting that I did try the second and found that it only triggered at the oscillator frequency, not double as it should have. It doesn't appear to work correctly either way I try it.
12-03-2011 02:12 PM
What physical hardware circuit on the FPGA is capable of clocking on both the rising and falling edge of an input clock signal?
Even if you can (theoretically) describe such a function, you are still limited to the set of devices and circuits and functions which are physically present on the FPGA (and understood by the synthesiser).
-- Bob Elkind
12-03-2011 02:38 PM
12-03-2011 03:07 PM - edited 12-03-2011 03:16 PM
I suppose I don't understand how to answer the question. I'm not well versed in the physical logic fabric of each given FPGA family I work with. I just come to this situation from the perspective of knowing that I can successfully trigger at either the posedge or negedge at my discretion so why not both? I know the logic settles faster than the overall rate I'm looking for (80 MHz).
Edit: mcgett's reply is newer than what I had on my screen at the time of posting.
When using @(OSC):
The warnings suggest that the synthesizer added every utilized signal into the sensitivity list because it thought my list was incomplete. Thus, it added Delay to the list which means it was incrementing as fast as the logic was capable of doing so (1.8ish GHz).
When using @(posedge OSC, negedge OSC):
No warnings specific to sensitivity lists or OSC. It just doesn't trigger on every edge regardless.
12-03-2011 04:27 PM
12-03-2011 04:37 PM
If that's the way it is, I'll deal with it. It just seems odd that there'd be a limitation preventing something so obviously desirable. I've been working with FPGAs for a few years now, but it wasn't until now that I had a real reason to try and do logic on both sides of a cycle. Historically, I've always just run a system clock that's twice whatever I need to work with and did all logic on the positive edge of that. I gather that's the usual approach.
I don't have any book to reference. I've never had any formal training or schooling on this subject. It's an activity I got into through trial and error, just like I did with software programming 15 years ago. If it appears that I'm missing "basic" pieces of information, that's probably why. It doesn't help that most resources on the subject that I have access to are more or less unusably awful. Some of the better Verilog resources on the web are geared toward code that works fine in simulators but is useless on real hardware. I imagine those sites are meant to cater mostly to an academic audience using simulators.
12-03-2011 08:26 PM
If that's the way it is, I'll deal with it.
Not many choices on the matter, eh?
It just seems odd that there'd be a limitation preventing something so obviously desirable.
To the contrary, it's not odd in the least bit. Clocking systems on a single clock edge (either rising or falling, but not both) relies on a well-controlled circuit attribute: clock frequency (or period). Clocking systems on both clock edges relies on a circuit attribute which is difficult to control in both clock generation and clock buffer/distribution: clock duty cycle or symmetry. And then there's the other annoying problem: flip-flops clock on a single edge, period. End of story.
In today's systems designs there are interconnects which depend on the timing relationship between the rising and falling edges of a single clock. They are called DDR (Dual Data Rate) interconnects, most commonly found in DRAM interfaces. But even in such DDR interconnects, two separate flip-flops are used for data capture -- one clocked on the rising edge and the other clocked on the falling edge. And the clock symmetry problem is still difficult to manage. In many DRAM controllers (including Xilinx controllers) a double-frequency clock is used to generate the "dual-edge" capture clock while controlling capture clock duty cycle (symmetry).
Historically, I've always just run a system clock that's twice whatever I need to work with and did all logic on the positive edge of that. I gather that's the usual approach.
You were on the right track there, and now you are beginning to realise why this was the right track.
I've never had any formal training or schooling on this subject. It's an activity I got into through trial and error, just like I did with software programming 15 years ago.
What's is so incredibly amazing to me is that you have gotten this far without so much as a fundamental understanding of the structure, operation, and proper application of a flip-flop, one of the very most fundamental building blocks if digital logic systems.
I hope you are beginning to now realise that understanding the principles and mechanics of logic hardware is an essential part of a design engineer's training and expertise. What you don't know might be quite disastrous (i.e. incredibly expensive for a private firm depending on the finished design). What you don't know can -- and will -- hurt you, your colleagues, your employer, and your customers.
-- Bob Elkind
12-04-2011 08:45 AM
I appreciate your having taken the time to explain it to me. It's through contributions of people like yourself that I improve my understanding of the subject (and future googlers benefit as well).
Don't worry about me though, I'm not doing anything related to HDL or programmable logic professionally. It's just something that interests me so I do it as a hobby. It will take a long time to master without formal training (which isn't available here even if I were to want it), but that's sort of the point. It's the process of learning that makes it fun in the first place.