Electronic – Using both clock edges in an FPGA design

clockfpgatiming-analysisxilinx

So, after getting some advice from some good people here, I managed to put together my first (very modest) FPGA design. It is basically just a few registers and counters, and only runs at a few MHz, but I could synthesise and implement it with no warnings, and the real signals coming out seem to do what simulation made me think they would. I learned a few things along the way.

Now I want to learn how to set timing constraints and run timing analysis. So I am reading through the Xilinx doc UG612 and I see at the top of page 205:

"Use only one edge of the clock"

Hmm. Seems I broke the law. Part of my design is a parallel load shift register – I used the negedge of the last cycle of the clock to load it (from a counter which was clocked on the previous posedge). A quick sketch:

Of course, I am not directly using the negedge here, but the load signal is derived from it. I thought that this was good – but Xilinx tells me – don't do that.

Am I wrong? If so, why? What should I do instead?

Best Answer

"Use only one edge of the clock"

I don't know why they would say that. You can use both rising and falling clock edges in the design and the timing analyser will take that into account.

Thus a 200MHz clock will give you 5 ns from rising edge to rising edge but only 2.5 ns from rising edge to falling edge. I made a small example using 16 bit values:

always @(posedge clk)
   result1 <= counter + hold;
always @(negedge clk)
   result2 <= counter + hold;

Below is a screenshot of the ISE timing analysis. It is for a 5ns 50% duty cycle clock.

The text is about a failing path from bit 3 of counter to bit 15 of result2. As you can see it uses the rising edge as source and the falling edge for the destination.

Related Solutions

Electronic – Pipelining and clock frequency issue

Your design will not function correctly if it runs at 100 MHz but is only spec'd (by the tools) to run at 50 MHz. If it does, then it's a one-off miracle that wouldn't work when you make a change and rerun the tools. Don't do it. Don't even do it if your clock is 100 MHz and the tools tell you the design can run at 99.5 MHz.

To solve your problem you can either write a simple 'divide by power of 2' clock divider to reduce the clock frequency (something like this in Verilog):

reg [n:0] count; 

always @(posedge CLK_100) begin
  count <= count + 1;
end

BUFG bg_0 (.I(count[m]), .O(CLK_DIV));

(where 'm' <= 'n' and 'bufg' is a global clock buffer, and must be used for synchronous designs) or use a Digital Clock Manager (DCM).

Hopefully that solves your pipelining issues as well unless you absolutely have to run the entire design at 100 MHz. Other than pipelining you can consider using FIFOs if you have part of the design running at 50 MHz and the other at 100 MHz, but you'll have to say a bit more about what you're doing to get more meaningful help here.

Electronic – Working with Spartan-6 LX9 clock

Is there any documentation for that is generic or covers Spartan-6 LX9 board?

The DCM is fully contained within the FPGA chip. So it doesn't matter what board you have. The documentation will be based on what chip you have.

For the Spartan-6 family, see the Spartan 6 Clocking Resources User Guide
Is using this module is absolutely necessary in this example? Is that possible to do the same thing easily w/o using that module?

If you're just blinking LEDs, you probably don't need to use the DCM. Probably they used it because its a very complicated block and they specifically wanted to provide an example of using the DCM without much else in the way of complex logic to confuse things.
How people usually go about vendor specific things like clock? For example, if one wants to target both Altera FPGAs and Xilinx ones. What is the process to achieve that? Is it similar to ordinary C pre-processor typedefs etc?

Unfortunately, complex hard cores like clock management is one of the areas where there's not much compatibility between vendors. You'll likely have to make significant code changes if you want a design using these features that is portable between two device families, whether they're from the same or different vendors.

If you can simplify your interface so that you just have one input clock coming from off-chip, and a number of derived clocks that are distributed to the rest of your logic, the cleanest solution is probably to push all of the vendor-specific code into a single module that you can instantiate in your top-level code. Then you can just use a different "clock management" module depending which device you're targeting.

If you want to do something like dynamically changing the phase relationship between various clocks, or switch between several choices of reference clock frequency, you probably have no choice but to re-code substantial chunks of logic for different target devices.

Remember that in addition to the Verilog code, there will probably also be numerous constraints that need to be defined, and these will also need to be different for different devices.

Best Answer

Related Solutions

Electronic – Pipelining and clock frequency issue

Electronic – Working with Spartan-6 LX9 clock

Related Topic