Forum Discussion
Altera_Forum
Honored Contributor
8 years agoFirst, short remark concerning forum policy ... quite frequently a posted message doesn't appear immediately, but is retained for approval.
And this approval can be as long as ... 24h. I asked for this issue to forum administration, but still didn't receive any answer. It occurred once more time yesterday: I answered to Tricky, but my message is still "in approval". Well let's return to subject ... --- Quote Start --- 1. Check if there are any ignored constrains. --- Quote End --- Yes, there are 2 ignored constraints (as I've already exposed yesterday in my non-posted message). Trying to resolve the violations issues on sdram data bus (blue cadre on the screenshot in 1st message), I was thinking (probably wrongly) that the best solution here is to introduce multicycles, i.e. "open the window", using terminology of the ryan scoville's timequest user guide (at least as I understood it). Looking at the Waveform diagram in "Timing Report" for SDRAM data [6] (left part of bottom screenshot in the 1st message), one can believe that problem can be fixed by shifting forward the "latch edge". That is what I tried to do with the following commands: set_multicycle_path -setup -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 2 set_multicycle_path -hold -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 1 And these commands were ignored by TimeQuest parser. --- Quote Start --- 2. Check if there are any unconstrained paths. --- Quote End --- No, after applying your suggestions (in another thread), there is no more unconstrained paths --- Quote Start --- 3. Check clock transfers and make sure that there are no invalid clock transfers analysed. --- Quote End --- At 1st glance NO ... at least there is nothing "in red" --- Quote Start --- Violations between unrelated clocks or paths - usually can be solved by setting clock groups or setting false path between unrelated paths. Violations in register-to-register level - usually caused by bad coding style, go back to your VHDL/Verilog code and fix it. Violations in I/O - can be solved by using PLL and clock phase shift, clock inversion ect. --- Quote End --- In my simple case there are only a few clocks: external clock, 2 PLL generated clocks and JTAG clock - altera_reserved_tck. Concerning coding style - actually there is no code, only Qsys module instantiation. So, perhaps, my case correspond to "Violations in I/O" ? Here I have 2 questions:- The PLL module in Qsys has 2 ouput and one of them is phase-shifted. This phase shift isn't reflected in .SDC file ... I beleived that TimeQuest can handle this shift without .SDC modification (again probably I'm wrong)
- So even in this case multicycles can't be considered as "reliable remedy"