Clock multiplexing and SDC

[Altera_Forum]

Hello, 

 Could someone please give me an example of how to use the set_output_delay command when the output clock is multiplexed?  I have a design where multiple 8 bit input busses are multiplexed to a single 8 bit output bus. Each of the input busses has its own input clock which should also be multiplexed to the output clock on the output bus. The output should be source synchronous.  I would like to use the set_output_delay command to ensure that the set-up and hold requirements are met, but I am not sure how this is done for multiple input clocks.  Thanks, Richard.

[Altera_Forum]

1) I hope you're not expecting clean behavior when switching between clocks(glitch free), or at least have put a lot of analysis to these cases. 

2) I hope you're not trying to run at extreme rates. Source synch interfaces rely on clock and data paths mimicking each other, and they just won't do a great job going through 8:1 muxes. (You may ask what's extreme, which is device/design dependent, but you'll see if you have problems when doing timing analysis) 3) Do you invert/phase shift the clock 180 going off chip, or are you sending the clock and data edge aligned?  You'll want to put 8 generated clocks on the port sending the muxed clock off chip, one generated from each input. You'll then have 8 set_output_delay assignments, where the -clock is this new generated clock for each case. Why is this important? Because you literally have 8 different interfaces going through these ports, so we're constraining them all. You'll also want to do a set_clock_groups command to relate them. For example, let's say you have 8 input clocks called inclk[7:0]. On the clock output port you'll have 8 generated clocks created based on these incoming clocks, call ssync_clk_out[7:0]. Then you'll have 8 set_output_delay constraints. You'll also have: set_clock_groups -exclusive -group {inclk[7] ssyn_clk_out[7:0]}   -group {inclk[7] ssyn_clk_out[7:0]}  -group {inclk[6] ssyn_clk_out[6]}  -group {inclk[5] ssyn_clk_out[5]}  ... -group {inclk[0] ssyn_clk_out[0]}   This way the path won't get analyzed when ssync_clk_out[5] is sent off chip, but inclk[4] clocks the data out. (In your mind this will never happen because the muxes are controlled by the same select lines, but Static Timing tools don't understand the code behavior and will analyze all possible paths. This set_clock_groups command is basically telling TQ that this analysis will never happen.)

[Altera_Forum]

>1) I hope you're not expecting clean behavior when switching between >clocks(glitch free), or at least have put a lot of analysis to these cases. 

 Glitches are not a problem in this design.  >3) Do you invert/phase shift the clock 180 going off chip, or are you sending >the clock and data edge aligned?  The output clock is inverted using a DDR register and inverted clock + data are alligned using DDR registers.   Perhaps I was not clear enough in my previous posting. The data and clock should be synchronous (edge aligned) as seen from the output port of the FPGA and not as seen from the different input ports. It also does not matter if there is a delay inside the FPGA, as long as the output data and clock are alligned.  For the generated clocks do I need to specify the output of the clock multiplexer as the source, or do I need to specify the input clock port as the source?  Thanks, Richard.

[Altera_Forum]

Make sure you understand source synchronous assignments on a single data stream(i.e. take 5 minutes to do a simple test case with a clock and data going off chip, and constrain it and understand how it's being analyzed, unless you've already done this or feel comfortable with it already.) Then move onto the clock muxing. 

 Just for clarification, you have 8 clocks coming in on 8 different pins? Do they go through PLLs, or are they muxed together? The 8 create_generated_clock assignments on the output port show that 8 different clocks go out this port, and what they are related to. (If the 8 clocks go through a PLL or register, then you will have a generated clock there, and the clock out create_generated_clock assignments will be generated from those generated clocks, not the input pins.) Show the constraints you have and the problem you're encountering, which might be useful.

[Altera_Forum]

>Just for clarification, you have 8 clocks coming in on 8 different pins?  

>Do they go through PLLs, or are they muxed together?   The 8 clocks come in on 8 different pins and do not go through a PLL. The input clocks vary from 25MHz to 150MHz and have a 50/50 duty cycle. The data changes on the falling edge. The PCB traces have been equalized so that the skew between the incoming data and clock should be minimal.  The input data is first lateched and then multiplexed to an output port together with the incoming clock. Something like this:  // input register reg[7:0] in_r[0:7];  always @(posedge in0_clk)  in_r[0] <= in_d;  // selection case (sel)   3'b000 : {out_d, out_clk} <= {in_r[0] in0_clk};  3'b001 : {out_d, out_clk} <= {in_r[1], in1_clk};  .  .  3'bxxx : {out_d, out_clk} <= {in_r[x], inx_clk}; endcase  The out_d and out_clk are then passed through DDIO registers to invert the clock and to edge allign the data to the clock close as possible.  This seems to run fine, but I do not understand how to set-up the constaints in the SDC file.  Thanks for the help Richard

[Altera_Forum]

150MHz might be pretty high. The interface can tolerate +/- 3.333ns of clock/data skew. 

 Anyway: create_clock -period 40.0 [get_ports in0_clk] inclk_25mhz ... create_clock -period 6.666 [get_ports in7_clk] inclk_150mhz  create_generated_clock -name outclk_25mhz -source [get_ports in0_clk] out_clk ... create_generated_clock -name outclk_25mhz -source [get_ports in7_clk] out_clk  set_output_delay -max -clock outclk_25mhz# .### out_d set_output_delay -min -clock outclk_25mhz# .### out_d ... set_output_delay -max -clock outclk_150mhz# .### out_d set_output_delay -min -clock outclk_150mhz# .### out_d  set_clock_groups -exclusive   -group {inclk_25mhz outclk_25mhz}  ...  -group {inclk_150mhz outclk 150mhz}  The# .### are the values you need to enter. Also note that there is no clock inversion in these constraints, which is incorrect. We're basically saying that the same clock that launches the data latches it and they are aligned. If the launch and latch clocks are aligned, then the data delay will need to be a half period longer to balance your setup and hold requirements. (This falls into my earlier question of making sure you can do a single source synchronous interface without the clock muxes. That's the difficult part. There is an app note on the website that covers this...)