a strange setup timing violation:
the path is from the 'write enable' of a FIFO, to another register in the design.
it seems like a problem in the Quartus 2 (64 bit V14.1.0 B186 12/3/14 SJ Full Version) since we cant find this actual path in the design.
using the locate path command in the time quest, show me the path provided in the files below - its doesn't look like the path in violation list. also tried to understand the path with the nodes in the Data Path window but it seems a little bit confusing.
for example - locating the node `Equal0~datac` in the RTL viewer led me to a comparator, which its inputs are not the 'write enable', but 'lb_hc_rx_din' and another irrelevant input.
by the way, 'lb_hc_rx_din' is coming from the FIFO, which the 'write enable' in the violation path is its 'write enable', however I wasn't expecting it to be a problematic path since the FIFO RAM output is isolating the path (like a register).
is it possible there is a problem in the quartus, and this path should be a false path?
I am adding relevant files and screenshot. please can you help me find out what is the path and how to handle it?
just to be clear - even if is it possible that the path is actually starting from the RAM data output, and not the ram write enable input,
I do not find such path in my design .
Please upgrade your Quartus version to the latest version as v14.0 is quite old and the software is not downloadable anymore thus it is hard to support.
If the issue still persists, then please help to share your design so I could investigate further.
Hi Richard, unfortunately, upgrading the version is not possible, due to some reasons. one of them is the fact that device we use ("Cyclone V" DEVICE 5CGXFC9E6F31I7) is not supported in the newer versions.
I can add the relevant src files in personal path if it help...
You've got a very long interconnect delay going to this clock control block:
; 5.883 ; 4.766 ; RR ; IC ; 1 ; CLKCTRL_R6
for both the data arrival and data required paths. Did you manually add a clock control block to your design (as an IP) or with so many clocks, was the design forced to use this clock control block to distribute the clock for the failing path? Locate the failing path to the Chip Planner to see the physical placement and to determine if there are physical resource constraints on the path which is leading to this.
I will check this, thank you.
but let say there are too many clock in the design. is this falling path really problematic? please note that it start from the FIFO WE, and continue towards another block trough the FIFO data out port. it seems that this path should be constrained as false path.
what do you think?
For fifo, there are some constrain mention in the user guide: https://www.intel.com/programmable/technical-pdfs/683522.pdf, You may take a look if it suite your case
When you set a false path, this means that you do not care whether that path meet any timing wrt to clock. My suggestion is to send us your whole design.qar to take a look first. My suggestion is to use set_multicycle path is the path is too long, or add register in btw the path.
Could you help to share the .qar project files by generate it through, Project > Achieve Project ?
I am not able to replicate the timing violation with the individual design files provided. Maybe something is missing.
I have yet to receive any response from you in regards to my last reply.
With that, I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.