Source-Synch I/O Constraints

[Altera_Forum]

I've read just about every post by Rysc and Kaz on constraints. Many thanks for their contributions to this forum. 

 I'm having trouble getting the constraints right for a source synchronous interface that's driven by mux from 3 separate sources. Two of the sources are Input to Output paths, while the third source is internally generated.  Here's what I have for constraints WRT this interface so far:  create_clock -name clkA -period 37.037 create_clock -name clkB -period 37.037 # # Create generated clocks at output of mux create_generated_clock -name clk_pll -source }] -add create_generated_clock -name clkA_muxout -source -add create_generated_clock -name clkB_muxout -source -add # # Create generated clocks at clock out pin create_generated_clock -name clk_pll_ext -source }] -add create_generated_clock -name clkA_ext -source -add create_generated_clock -name clkB_ext -source -add # # Tsu of ext. device = 1.4ns # # Th of ext. device = 1.4ns set_output_delay -clock clk_pll_ext -min -1.4 }] -add_delay set_output_delay -clock clk_pll_ext -max 1.4 }] -add_delay set_output_delay -clock clkA_ext -min -1.4 }] -add_delay set_output_delay -clock clkA_ext -max 1.4 }] -add_delay set_output_delay -clock clkB_ext -min -1.4 }] -add_delay set_output_delay -clock clkB_ext -max 1.4 }] -add_delay    I'm receiving the following warning from TQ:  Warning (332088): No paths exist between clock target "mclk_p" of clock "clk_pll_ext" and its clock source. Assuming zero source clock latency. Warning (332088): No paths exist between clock target "mclk_p" of clock "clkA_ext" and its clock source. Assuming zero source clock latency. Warning (332088): No paths exist between clock target "mclk_p" of clock "clkB_ext" and its clock source. Assuming zero source clock latency.  It appears that TQ is correctly analyzing the Input to Output paths from ClkA/B to mclk. However, clk_pll to output is not being analyzed...  Here's what I have for clock groups:  set_clock_groups -asynchronous .... other clocks -group set_clock_groups -exclusive -group -group -group    I feel like I'm missing something simple here. Any ideas?   EDIT: Just to clarify the system architecture.  The design has two synchronous input interfaces including clock and data. Those two interefaces are muxed with an internally generated set of clock and data and driven on the output. Both clock and data are muxed on the output.

[Altera_Forum]

- Which is the PLL input clock? You're missing a derive_pll_clocks command, btw. 

 - Are you muxing the PLL clock, clkA and clkB into mclk_p? Or are you just using one of them?

[Altera_Forum]

Sorry, that's just s snippet from my sdc file. I do have the derive_* statements in there. 

 derive_pll_clocks derive_clock_uncertainty  The input clock to the PLL is the GXB reference clock at 148.5MHz.  create_clock -name {gxb_refclk} -period 6.734 -waveform {0.000 3.367}    Yes, I'm muxing the three clocks out on mclk_p.

[Altera_Forum]

I don't see anything wrong then. Don't you get any more errors/warnings? 

TQ is complaining that there's no recombination logic driving mclk_p from neither clkA_p, clkB_p and the PLL. Is it possible that Quartus optimized away the logic that should be driving mclk_p?  PS1: Are clkA, clkB and the gxb_refclk related clocks? PS2: What are the generated clocks at the mux output for

[Altera_Forum]

Yea, I get a bunch of warning related to the VIP cores and DDR3 but I tend to ignore those. 

 I don't think it's optimizing the logic away. I can see the mux in post-map technology viewer.  ClkA, ClkB and gxb_refclk are from 3 separate, unrelated ICs.  The generated clocks on the mux output are so I can cut the analysis using clock groups, otherwise I get failing paths between separate launch and latch clocks that won't actually occur because of the mux.   I tried to give just a snippet of the sdc with generic names because this design has a large number of unrelated clock domains with a lot of similar muxing.

[Altera_Forum]

One thing that doesn't look right to me is that you are using set_output delay three times for same node of m_data_p with reference to three clocks. 

 The nodes m_data_p must only be set relative to clock driving it directly.  Moreover mclk_p is not clear what it is referring to.

[Altera_Forum]

kaz,  

mclk_p is a muxed clock: it can be clkA, clkB or the PLL output clock. So, the way he is constraining it looks correct to me.  kkoorndyk, If clkA, clkB and gxb_refclk are unrelated, then you probably should cut all paths between them from analysis (ie, set them in separate clock groups) and use clock domain crossing techniques, if needed.

[Altera_Forum]

Updated snippet from the sdc: 

 set_clock_groups -asynchronous .... other clocks -group -group set_clock_groups -exclusive -group -group -group   Doesn't that cut gxb_refclk, ClkA and ClkB?

[Altera_Forum]

From the wording of the warning: 

 "no path exists between clock target mclk_p of clkA_ext and its clock source"  It looks like TQ is treating the muxed output mclk_p as if a register clocked by clkA_ext. Clearly it is not. Try set false path and see if it helps get rid of warning. I wouldn't worry otherwise.

[Altera_Forum]

You're mclk_p should have the node of the mux clock as it's source, since that's what drives it. So something like: 

 create_generated_clock -name clkA_ext -source [get_pins {clock_mux|Equal3|combout}] -master_clock clkA_muxout [get_ports {mclk_p}] -add

[Altera_Forum]

Thanks Rysc. That seems to clear up the warning, but when I run the Report All I/O Timings macro, I'm not seeing those I/O constrained in the Registers to Outputs reports. I only see those I/O under the Inputs to Outputs reports. That makes me concerned whether that path through the mux is constrained.

[Altera_Forum]

I generally don't use the pre-canned I/O analysis, but create my own TQ_analysis.tcl file and put stuff in like so: 

 report_timing -setup -npaths 50 -detail full_path -to [get_ports {m_data_p[*]}] -panel_name "m_data_p||setup" report_timing -hold -npaths 50 -detail full_path -to [get_ports {m_data_p[*]}] -panel_name "m_data_p||hold"  I do it for most interfaces and so the reports are tailored to those interfaces. (Anything you miss still shows up in the summary/hold/recovery/removal reports, so if something failed you'd know about it). Now if the above says no paths exist, it needs to be analyzed why. (I'm not sure on first glance, but fixing the create_generated_clock shouldn't have broken anything. Did the paths show up before?

[Altera_Forum]

There we go! Running it manually gives me what I'm looking for. I would have expected the macro to do that for me since it's called Report _ALL_ I/O Timing. :-) 

 Thanks for the help!   EDIT: To answer your question - No, it did not show up before the change to the SDC.

[Altera_Forum]

I assume it means all types of I/O timing(inputs, outputs, port to port, and setup/hold of each), as it still has a parameter for number of paths to report in each case, which is defaulting to 1000. This where I think TimeQuest's scripting capabilities come through, as searching through more than a thousand paths is a pain.