Honored ContributorI'm seeing lot of hold violations between several DSP_MULT and DSP_OUT blocks. I have enabled the options such as Optimize hold timing for all paths and Optimize multi-corner timing but that is not helping in fixing the hold violations. I have attached the timing report on the path. Any suggestions to fix this issue would be really helpful.
Honored ContributorYou have two clock names. Are they taken care of.
I also notice all the 22 paths have same name and same slack?Honored ContributorYes I have constrained it. Yeah that (same name and same slack) was also very weird. Moreover there are also similar other paths with exactly same slack.
Honored ContributorHonored ContributorThe two clocks are synchronized. REGCLK is at 40MHz and SCLK is at 80MHz. Both the clocks are derived from same source. I have attached the report generated from GUI for the top failing paths.
Honored ContributorPositive hold requirements are normally met by the router adding delays to a path. Inside the DSP block, the paths are fixed and there's no general routing that can be used. That's normally not a problem though because the hold requirements are 0 and there's no clock skew, so no delay needs to be added.
In your timing report, the launch clock is REGCLK and the latch clock is SCLK and there's 0.999ns of skew. Looking at the timing report, you're taking your PLL generated clock and going through two different ripple clocks to create separate clocks. These clocks are skewed and causing the problem. You can't drive the DSP block with two skewed clocks like that and need to put them on the same domain. Ideally, I would get rid of the ripple clocks altogether. Can you create more outputs from the PLL? Can you create a clock enabled domain?Honored ContributorHonored ContributorThe delay is the same because it's modeled that way, i.e. they all have to make the transfer, and so just the worst case path is used for all of them. Since there are no options to route differently inside the block, it doesn't really matter. When it fails it's not the data path but the clock skew, which is what's occurring here.
Honored ContributorIt is not clear how a dsp block(mult/add) is wired to 2 clocks because it has one clk port.
Honored ContributorIf you pull up the altmult_add, you can specify different clocks for the A input, B input and output registers. Of course, it depends what device you're targeting, but I believe there is some flexibility. Another way is if it's inferred, in which case the timing could be fixed if the output registers were pushed into the fabric(that would fix it if it weren't inferred too). Of course, the best way is to get rid of the clock skew...
Honored Contributor
