mwb
Junior Member level 2
I have a serial-to-parallel converter based on a shift register and a bank of flip-flops that latches the data out. My timing constraint file is below. Clk is the serial clock and p_clk controls the output dffs.
Is it safe to assume that not specifying input delay constraints tells the tool that the data and clock to each dff is aligned? I can't find any reference to this in the dc_shell manual or synopsys constraint manual.
I dont correct setup and hold violations in dc_shell, I do that in encounter. The final netlist that encounter outputs shows delay cells have been added to the data input ports and looking at the timing arcs for each input, the delays are also shown. The delays push the data edge back to the next clock edge to satisfy the setup time, this makes sense to me.
Lastly, I simulate the p+r'd netlist in virtuoso. The input serial data is changed at the rising clock edge and the circuit works fine.
So my question is, it appears that not having an input delay constraint tells dc_shell, encounter, etc that the input data is aligned to the positive clock edge. Is this correct?
Thanks
- - - Updated - - -
I should add, the input to the shift register is coming from an off-chip FPGA that I can also constrain. Therefore, I see no problem with using no input delay constraints because I can align the data with the clock edge at the FPGA.
Thanks
Code:
set_wire_load_model -name "TSMC8K_Lowk_Aggresive"
set_wire_load_mode top
set_drive 0.5 [all_inputs]
set_load 1 [all_outputs]
set_max_capacitance 0.1 [all_inputs]
set_max_fanout 8 [get_designs]
set_max_fanout 8 [all_inputs]
#set_max_delay 1 -from [all_inputs]
create_clock clk -period 5 -waveform {0 2.5}
create_clock p_clk -period 340 -waveform {0 170}
set_dont_touch_network [all_clocks]
set_false_path -from clk -to p_clk
set_clock_uncertainty 0.5 clk
set_clock_uncertainty 0.5 p_clk
Is it safe to assume that not specifying input delay constraints tells the tool that the data and clock to each dff is aligned? I can't find any reference to this in the dc_shell manual or synopsys constraint manual.
I dont correct setup and hold violations in dc_shell, I do that in encounter. The final netlist that encounter outputs shows delay cells have been added to the data input ports and looking at the timing arcs for each input, the delays are also shown. The delays push the data edge back to the next clock edge to satisfy the setup time, this makes sense to me.
Code:
Path 1: MET Setup Check with Pin sr_reg_0_/CP
Endpoint: sr_reg_0_/D (^) checked with leading edge of 'clk'
Beginpoint: serial_data_in (^) triggered by leading edge of '@'
Path Groups: {inclkSrc2reg}
Other End Arrival Time 0.131
- Setup 0.035
+ Phase Shift 5.000
- Uncertainty 0.500
= Required Time 4.596
- Arrival Time 3.592
= Slack Time 1.004
Clock Rise Edge 0.000
+ Input Delay 0.000
+ Drive Adjustment 0.024
= Beginpoint Arrival Time 0.024
Timing Path:
+--------------------------------------------------------------------------------------------+
| Instance | Arc | Cell | Slew | Delay | Arrival | Required |
| | | | | | Time | Time |
|--------------------------+------------------+---------+-------+-------+---------+----------|
| | serial_data_in ^ | | 0.024 | | 0.024 | 1.028 |
| FE_PHC68_serial_data_in | I ^ -> Z ^ | DEL015 | 0.046 | 0.286 | 0.310 | 1.314 |
| FE_PHC362_serial_data_in | I ^ -> Z ^ | DEL005 | 0.026 | 0.066 | 0.376 | 1.380 |
| FE_PHC910_serial_data_in | I ^ -> Z ^ | CKBD2 | 0.019 | 0.040 | 0.416 | 1.420 |
| FE_PHC589_serial_data_in | I ^ -> Z ^ | DEL0 | 0.068 | 0.746 | 1.162 | 2.166 |
| FE_PHC500_serial_data_in | I ^ -> Z ^ | DEL0 | 0.066 | 0.759 | 1.921 | 2.925 |
| FE_PHC139_serial_data_in | I ^ -> Z ^ | DEL1 | 0.095 | 1.671 | 3.592 | 4.596 |
| sr_reg_0_ | D ^ | DFCNQD1 | 0.095 | 0.000 | 3.592 | 4.596 |
+--------------------------------------------------------------------------------------------+
Clock Rise Edge 0.000
+ Drive Adjustment 0.012
= Beginpoint Arrival Time 0.012
Other End Path:
+-------------------------------------------------------------------------+
| Instance | Arc | Cell | Slew | Delay | Arrival | Required |
| | | | | | Time | Time |
|------------+-------------+---------+-------+-------+---------+----------|
| | clk ^ | | 0.012 | | 0.012 | -0.992 |
| clk__L1_I0 | I ^ -> ZN v | INVD24 | 0.014 | 0.013 | 0.025 | -0.979 |
| clk__L2_I0 | I v -> ZN ^ | CKND24 | 0.028 | 0.037 | 0.062 | -0.942 |
| clk__L3_I0 | I ^ -> ZN v | INVD24 | 0.020 | 0.033 | 0.095 | -0.909 |
| clk__L4_I1 | I v -> ZN ^ | CKND24 | 0.040 | 0.033 | 0.128 | -0.876 |
| sr_reg_0_ | CP ^ | DFCNQD1 | 0.040 | 0.003 | 0.131 | -0.873 |
+-------------------------------------------------------------------------+
Lastly, I simulate the p+r'd netlist in virtuoso. The input serial data is changed at the rising clock edge and the circuit works fine.
So my question is, it appears that not having an input delay constraint tells dc_shell, encounter, etc that the input data is aligned to the positive clock edge. Is this correct?
Thanks
- - - Updated - - -
I should add, the input to the shift register is coming from an off-chip FPGA that I can also constrain. Therefore, I see no problem with using no input delay constraints because I can align the data with the clock edge at the FPGA.
Thanks