04-07-2021 02:10 AM
I'm doing PnR of design (details of which i can't share here), i'm getting below error :
CRITICAL WARNING: [Timing 38-249] Generated clock ullclk_DUT1 has no logical paths from master clock clk_12_DUT1.
Resolution: Review the path between the master clock and the generated clock with the schematic viewer and correct the -source option. If it is correct and the master clock does not have a timing path to the generated clock, define the generated clock as a primary clock by using create_clock.
I've attached the image too. The case is a create clock is defined with same of clk_12_DUT1 on a FF output (design is like that only). This FF output passes through a BUFG and then goes to LUT (of which the image is attached) input I3. I was trying to define the generated clock constraint on this LUT output.
Also, i queried the clock at I3 input of LUT, and i'm getting ullclk_DUT1 as result which is expected but when i query the same on LUT (as per below warning 'y' is the LUT instance name) output, i don't get any result in TCL console and rather get the warning as :
WARNING: [Vivado 12-1008] No clocks found for command 'get_clocks -of_objects [get_pins wrapper_DUT1/a/b/c/d/e/f/y/O]'.
Resolution: Verify the create_clock command was called to create the clock object before it is referenced.
Note : I don't have any false paths or anything which could have disabled the clock progation to LUT output. I'm using Vivado 2019.1 and also tried 2020 version too but same result.
04-07-2021 03:09 AM
@rakesh_bansal just to clarify - you are creating a clock on the output of a FF and then it gets passed to a LUT6 and then onto a bufgce?
If so, then this really isn't a recommended clocking topology. You need to be using CMB (clock modifying blocks) if at all possible.
If you really need to create a clock on the output of a FF then you should be using create_generated_clock and not create_clock.
You have a further problem then of passing this clock through a LUT. The timing tools will not propagate clocks through this LUT hence the [Vivado 12-1008] warning.
04-07-2021 04:13 AM
I understand it totally.
Even on my previous design I was putting a CGC constraint on FF output and letting that clock pass through LUT. All that was working fine with same version of Vivado tool.
Suddenly when design got updated due to some issue fix, I've started seeing this problem and hence asking. I totally understand this may create timing closure issues on FPGA. But what I'm trying to understand is why tool not able to pass the clock through LUT.
04-07-2021 05:45 AM
The timing tool cannot analyze the logic configuration for the clock, so clock cannot pass through general logic resource，such as Lut，FF, BRAM, ....
The clock can pass BUFGCTRL, BUFGMUX, BUFG.
The generated clock can be derived automatically for MMCM, PLL and BUFG_GT.
04-07-2021 06:43 AM
Sorry but I beg to differ here. The clock should be able to pass any fabric. In the same non-working case, the same clock (clk_12) is passing through another LUT1 and there on query of clock (using get_clock on LUT1 output) I can see that clock is propagating and seen by tool too. Only through LUT6 it's not passing.
Just to keep you informed, with old design, the same scenario and structure is passing the clock through all LUTs correctly.
04-07-2021 07:29 AM
just to jump in here
there are two parts to this,
The tools code are tested / expect for people to use them in a given way ,
There are a million and one ways to break all tools,
You are looking to make what is called asynchronous clocks, these run on logic nets, not the clock nets,
To get onto a flip flop clock input, the clock yo make will have to jump from the generator FlipFlop onto the clock network for that FF,
The constraints you have to set could become very interesting real quick,
not saying its impossible, but unless you have some very good reason to code in this special manor, then its best not to ,
I would be interested to know what the reason is,
Second, you are saying quiet correctly that any logical signal should be able to be connected to a lut input,
and this is true,
but a lut is on the logical net, not the clock net,
and what can not happen is the timing analysis tool can not propagate a timing constraint through a LUT,
It was summed up by @dsheils
If you "need to create a clock on the output of a FF then you should be using create_generated_clock and not create_clock.
You have a further problem then of passing this clock through a LUT. The timing tools will not propagate clocks through this LUT hence the [Vivado 12-1008] warning."
04-09-2021 01:18 PM
Hi @drjohnsmith ,
I understand that Tool is designed to deal with clean clock tree (CT) with no logic/LUT on CT.
That is not the case in my design. And i had used/emulated the design on FPGA (considering the risk of Tool not able to handle logic on CT or going against what FPGA architecture experts recommends) with such LUT(s) on CT (not caring about performance but, keeping a note in mind that LUT on CT would cause hold violations and hence trying to keep such logic minimal) using Vivado Tool for VCU118.
I never faced such issue where clock was not able to propagate across a LUT. (With this i mean on input of LUT i can query the clock but on output of LUT the clock is not shown because i got warning in Tool log file that there is no logical path between source and generated clock. I had checked that simple wire from source clock to LUT input multiple times in schematic :)).
Above said, fine, having timing issues and tool not able to close the timing i will have to handle. But my main worry is about 'Why clock is not propagating across LUT6' (When at same time i can clearly see it traversing (by querying at input and output of LUT1) across LUT1).
So far i never faced above issue (even though handling such designs (LUT on CT) multiples in past) and hence my basic question!
Thanks for understanding and sorry for long response (not indented to disrespect anyone).
04-09-2021 02:36 PM
Just to keep you updated, I even tried with CGC on FF output and even then the issue was same where clock was not propagating across LUT6.
There is no warning when XDC is read first time but warning pops up at design_opt stage only. When i simply open *.edf file in vivado and read the xdc file through TCL console and query the clocks on input and output of LUT6 --> Clocks are realized by tool correctly at both input and output.
So, seems like issue is during optimization stage only.
04-10-2021 03:57 AM
If you want to switch clocks ,
why are you not using a BUFGMUX , are these not in the chip you have ?
04-10-2021 05:33 AM
Hi @drjohnsmith , we even tried BUFGMUX present on FPGA. But it also resulted in same warning and no clock at bufgmux output. FYI, i even cross checked that there are no false paths or ASYNC domains' constraints which can lead to this behaviour. Thanks.
04-10-2021 07:41 AM
If I can recap then,
You have some code, that does not compile as you expect it should ?
you have tried all the obvious ways. to no avail.
Can I suggest then, that the way forward is for you to either share your code or more likely, make a smaller test case that shows the problem your describing,
BUFGMUX have certainly worked well for me,
so its sounding like something in the code / constraints,
04-11-2021 06:44 AM
@drjohnsmith , The code got compiled correctly. I could confirm the same in schematic too.
This seems to be a peculiar problem which i tried to reproduce with a sample test, but to no avail.
Also, i can't share the problematic *.dcp because this is company owned.
I've also used BUFGMUX/BUFGCTRL in past which worked for me too but here these also couldn't help.
04-11-2021 09:13 AM - edited 04-11-2021 09:16 AM
Without more detailed information,
and explicitly an example to be looked at
I'm sorry, but my crystal ball has broken and I can not guess the answer
may be some one else can jump in,
I note above that Xil hainxve twice come in and told you the problem,
and we have tried to help you explore how to approach this
I wish you luck,
07-22-2021 02:49 PM
I would love to know why this happens. I work in ASIC emulation and constantly have similar looking LUTs in the clock network to mux between two different clocks. Often multiple layers of clock muxes which makes BUFGCTRL's run out and no be a great solution either. We also want to make sure we emulate the clock muxing logic as close as we can so ideally we want the logic to stay the same.
I just ran into a new build where nothing I can see directly related to the clock changed, but it went from allowing a generated clock on the output to generating a clock error. I've been checking on here for several years for a solution to this and haven't found anything yet. Working with Xilinx support hasn't really gotten me anywhere either for similar reasons. I know this post is a bit old, but I hope eventually this gets fixed or debuggable since generally clocks go through LUTs just fine.
07-23-2021 02:16 AM
ASICs and FPGA have a Key difference,
ASICs the clock network is designed for the logic design,.
In an FPGA there are a limited number of dedicated clock routes,
these have limited amount of clock gating on them,
Clock routes are fast , large area, special routes. well matched in speed.
The normal logic network is by comparison very slow, nano seconds,
Different routes have different delays,
which the tools all take care off.
Thus the general rule is do not use the logic nets as clock routes,
its possible, but your fighting the tools and the way most people use FPGA's
Whilst were talking ASICs,
they tend to use Latches, which the FPGA has, but again is not used much, and you fight the tools as most engineers do not use latches in FPGAs, the tools are not geared to latch optimisation.
07-23-2021 07:37 AM
In the case I usually have this logic is usually around glitch free mux logic that generally works for us in emulation. Yes using the FPGA primitives would be better, but we want to verify our clock switching logic functions as expected. I think where the tools get confused on LUT6's is usually if there is too much control logic going to the LUT and it can't easily see which clocks would flow through the LUT. In my most recent issue that drove me here it was related to a control port that needed a set_case_analysis to simplify the mux logic and let the tool assume both clock inputs should go through based on one unknown mux select signal.
The reason my recent design suddenly failed was due to synplify synthesis changing a control register name to add "_ret_#" to the end of the register name and my set_case_analysis was no longer being applied. This turned out not to be a Xilinx issue and would have been eventually caught in Vivado warning linting, but wasn't noticed initially. I've noticed the newer versions of Vivado have changed how to view a pins set_case_analysis value which made this a little harder to notice when just looking at the schematic/timing report though. I just wanted to add this experience in case @rakesh_bansal or other similar cases could benefit from it.