Timing constraints for DDR output multiplexer

Consider the following circuit, which multiplexes the d0 and d1 inputs to the y output in one clock cycle (i.e., double data rate, DDR).

simulate this circuit – Schematic created using CircuitLab

Which may be the result of synthesizing the following Verilog code:

module ddr_mux (
input wire clk,
input wire d0, d1,
output wire y
);

reg q0, q1;

always @(posedge clk) q0 <= d0;
always @(negedge clk) q1 <= d1;

assign y = clk ? q1 : q0;

endmodule


I have the following timing requirements:

• q0 must not change while the MUX select input is at 0
• q1 must not change while the MUX select input is at 1

In other words,

• y must have at most two transitions per clock period.

If the synthesis and timing analysis tools do not know these requirements on the y output, they have the freedom to implement the circuit with an arbitrary timing relationship between q0, q1, and sel. Here is an example of how this could go wrong:

And here is the desired behaviour:

How do I correctly express this in the form of SDC constraints to be read by Cadence synthesis and timing analysis tools?

• I'm not familiar with verilog, so I'm not posting this as an answer...However, I'm working on a frame-timing circuit where I solved the same problem using ans AND gate + SR flip-flop on each Q input line. Use d0 AND CLK for Set on q0 & d1 AND NOT CLK for Set on q1; then use NOT CLK Reset q0 & CLK Reset q1 – Robherc KV5ROB Mar 3 '16 at 15:31
• Thanks for your input. But isn't what you describe just accomplished by using D flip-flops as shown in my drawing? – mkrieger1 Mar 3 '16 at 17:20
• If your D-flipflops (sorry, didn't catch the DFF labels) are latching based on CLK state, then where is your problem/question? I assumed, based on your statement of needing to ensure no more than 2 Y transitions/clk that you were seeing a failure there. – Robherc KV5ROB Mar 3 '16 at 21:30
• @RobhercKV5ROB: I've updated the question to illustrate what the problem is. – mkrieger1 Mar 4 '16 at 10:31
• Ok, looking at your added information, I think you're trying to describe a problem due to mis-matched propagation delays between your DFFs and your MUX selector. In practice, so long as the mis-match is small enough, it is often negated by output/load parasitics. If you're 'seeing' a problem with it in your (actual) output, you may need to add (a) buffer gate(s) to the circuit to delay whichever component(s) is(are) 'getting ahead.' – Robherc KV5ROB Mar 4 '16 at 15:49