03-21-2017 04:39 AM
I have a question to the following design (Vivado 2016.4 also tested with an early version. The target is a Kintex-7). You can see in the first screenshot a placed LUT2 in front of an FF. The first LUT input pass-through one data signal, while the second input is connected to the CLK. The LUT output assigns the pass-through data only on CLK=Hi. The FF triggers on the negative edge of the CLK.
In the picture, the CLK path is highlighted. Here the clock to both elements (FF, LUT) shares the same path (global clock network) until they reach the switch matrix in front of the CLB. In the switch matrix, the CLK to the LUT is routed via a bounce pip to the LUT. The CLK to the FF is routed via the "normal" clocking network.
If I run a timing summary report, a hold time violation occurred. See the next two pictures; one for the slow processed corner and one for the fast processed corner.
I am a bit confused: why is there a difference in the timing (data path and destination clock path) as both signals share the same physical path? One can see the difference at the BUFHCE, as well.
Further, if I ignore this warning and run the design on the board no error occurred. Additionally, a similar design build in ISE 14.7 (Spartan-6) reported no hold time violation and runs smoothly.
I assume that the differences in the CLK signal generated by the different routing through leaving the global clock tree and the LUT's delay are high enough.
03-21-2017 07:33 AM
Not all paths are equal,
They have different actual distances, loading. Not to mention process variation. Because one instance works is no guarantee all future ones will as well. In fact, if the tools are unhappy, then you should be as well.
Not the accepted (recommended) way to design.
And (to me) what you are doing makes no sense (does not look like a proper synchronous design).
If you want (or need) a latch, instantiate it (the DFF is also a latch if configured to do that).
03-21-2017 08:13 AM
Thanks for your fast answer.
Ok, this small illustration makes no sense at all, as you said. This design is part of a research project. Therefore we need such a construction in a bigger (LUT3 or higher) design. We used the clock to ensure that the LUT evaluates after all data signals are valid and produces no glitches etc.
But why works such a construction on the Spartan-6 with ISE?
And why does the tool reports a different time at the BUFHCE? In the attached pictures you can see the marked rows. Why is the time in the data path 38.308 ns and in the destination clock path 37.761?
Maybe I interpret the report in a wrong manner, what is the meaning of the timing number in the paths column?
03-21-2017 08:28 AM
Take a look at this post (near the end) on the discussion of clock pessimism; the difference in delay you are seeing on the common components are being added back in in the "clock pessimism" line of the analysis.
But the bigger question is why are you using a clock in combinatorial logic? It is very highly encouraged to avoid doing this...
What are you doing with the clock that it needs to be routed to a LUT? There are probably "more legal" ways of accomplishing what you want to achieve without using a clock in the datapath.