Clocking critical warning

[omikron]

Hello

I am using AXI_dynclk and rgb2dvi from Digilentic git. The ref clock od dynclk core comes to AXI_clk pin.

When placing the design, I will always get this critical warning for each generated clock. And the design says Completed but timing constraints not met. How can I fix this?

[D@n]

Please see Xilinx's comment about the "no logical paths" warning.  They recommend safely ignoring it.

Now, as for your design not meeting timing requirements ... sigh.  That's been the story of a lot of what I've been working with these days.  (I've been trying to take a 100MHz design that works on an Artix-7 and get it to run at 200MHz.)  The good news is there are solutions.  The bad news is ... they take work.  Here are some things I've been using as parts of my solutions:

1. Try to use Moore machines where possible.  These will often delay your changes by a clock, but they tend to go easier through place and route. 

2. Make sure your state machines, or your if statements, depend upon as few variables as possible.  I struggled with this as I often had state machines and if's that said things like if (counter == 32'h00) then ...  I've managed to change most of these to if (zero_counter) then ... where zero_counter is a one bit register, and where it is high any time my counter would be zero.

3. If possible, define every output of your state machines on every state. 

4. I had lots of state machines with logic such as if (reset) else case (state) ... endcase.  I've gone back and redesigned many of these so that only those variables that need to be reset get the if(reset) treatment.  In general, there are often values that are don't cares except in certain circumstances.  Engineer the logic for these values so that the value is correct when you do care, but so that you adjust the don't care logic to use the minimum amount of overall logic.  (Did that just make sense?)

5. On-chip memories are tricky things.  If you can get the tools to use block RAMs, do so.  This often means, however, that your memory logic must be as simple as possible.  For example, a memory read should ideally read on every clock from the address given it--whether you need to read from the address, the address is even valid, or not.  If you need to, you can add a gate to the clock, but not much more.  In other words--don't place memory reads inside case structures or big long if then else if then else if ... structures.

6. Writing memory is similar.  Keep your logic simple.  In one case, when building a SDSPI routine, I found that the logic to write block RAM was way too complex  (Look at fifo_a_mem and fifo_b_mem).  So, instead, I wrote to a strobe register, an address register, and a data register.  These registers were determined within my state machine.  On the next clock then, if the strobe was high, I would write to the memory.  (The links show how the file looked before these modifications.)  With modifications, the routine now successfully places and routes at 200+MHz.

7. The best source I've found for getting a design to meet timing has been Xilinx's White Paper, "HDL Coding Practices to Accelerate Design Performance."  This is actually a very valuable document, and I would recommend anyone designing with FPGA's read and consider what it says.

Hope this helps.  If not, let me know what I've missed,

Dan