Implication of not specifying input delay constraint

Status
Not open for further replies.

mwb

Junior Member level 1
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.

Code:
set_wire_load_model -name "TSMC8K_Lowk_Aggresive"
set_drive 0.5 [all_inputs]
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
= 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
= 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

Super Moderator
Staff member
Well my take on this is with an FPGA you better have input delay constraints if you want consistent behavior of the part wrt it's input pins from build to build.

But I suppose in an ASIC you can accept whatever skewed input delays you've got after place, route, and fabrication over PVT and force the external device to just "deal with it".

Seems like a bad idea to me.

mwb

Junior Member level 1
Ok, maybe I didn't explain it right.

FPGA -> ASIC (with shift register inside)

The FPGA will output the serial data aligned to the rising clock edge. The ASIC, which I gave the timing constraints for in the original post, will shift in the data and then latch out a parallel stream. The ASIC has no input delay constraint so it looks to me like this tells the synthesis tools to assume the data and clock are aligned. In the timing report it has a line that says "delay: 0".

Super Moderator
Staff member
Might be assumed, but I haven't used DC for a long long time. Hopefully someone with recent experience can tell you.

FWIW, I kind of don't like the idea of not adding the constraint in because even if it is assumed, I don't like relying on an assumption to guarantee the ASIC will end up correct (or even an FPGA design).

mwb

Junior Member level 1
Yea, thanks. Got it. I rechecked all my timing reports and it looks like delay=0 is the default, but reassurance would be good.

ThisIsNotSam

the default is to assume data changes at the clock edge. that might be ok, or might make your entire test setup useless. really depends on your design. it might make hold timing impossible to meet.

also, let me get this out there, leaving all the optimization work for physical synthesis is a REALLY BAD idea. you want to address timing as soon as possible and that has to be done within DC.

mwb

Junior Member level 1
the default is to assume data changes at the clock edge. that might be ok, or might make your entire test setup useless. really depends on your design. it might make hold timing impossible to meet.

also, let me get this out there, leaving all the optimization work for physical synthesis is a REALLY BAD idea. you want to address timing as soon as possible and that has to be done within DC.

The test setup consists of an FPGA that is sending the data to the ASIC's internal shift register. I can constrain the FPGA to output the data on the rising clock edge. The in2reg setup and hold time slacks are 1ns and 750ps respectively so I really doubt there will be a problem doing this. Its also been verified using spectre.

#2. For smaller designs, doing the optimization work in encounter actually gives me better slack. From what I am told and from what I've read, this is because more accurate wiring and delay models are used. For bigger designs, fixing timing in DC definitely helps, but not by much. By bigger, I'm only talking 1000's of transistors, so its not really big at all and this is only anecdotal evidence.

ThisIsNotSam

#2. For smaller designs, doing the optimization work in encounter actually gives me better slack. From what I am told and from what I've read, this is because more accurate wiring and delay models are used. For bigger designs, fixing timing in DC definitely helps, but not by much. By bigger, I'm only talking 1000's of transistors, so its not really big at all and this is only anecdotal evidence.

your second point makes absolute no sense, sorry. if encounter gives you better slack, that means your wireload model is bad and doesn't capture reality. that is why there is such a big push to do physical aware logic synthesis these days. how much of a slack difference are we talking about? a few ps here and there is ok, but not much.

even for medium sized designs, you want to address timing early. you wouldn't even think of physical synthesis before knowing for sure the timing is 'good' at logic synthesis step.

mwb

Junior Member level 1
your second point makes absolute no sense, sorry. if encounter gives you better slack, that means your wireload model is bad and doesn't capture reality. that is why there is such a big push to do physical aware logic synthesis these days. how much of a slack difference are we talking about? a few ps here and there is ok, but not much.

even for medium sized designs, you want to address timing early. you wouldn't even think of physical synthesis before knowing for sure the timing is 'good' at logic synthesis step.

Its not by much, ~20ps, I guess Im splitting hairs but yes, its better for the smaller designs.

The wireload model is the standard model that comes with the PDK, in this case, TSMC65. What I meant by "more accurate" is that the P+R tool takes into account wire length.

Im not too worried about how I fixed timing in P+R instead of DC_shell. Ultimately, it passes timing with plenty of slack and there is only 20ps difference between the methods. Im more concerned with the set_input_delay -max/min set to 0. Even still, that is in effect telling the tool that the input data is coming in at the worst case time, aligned with the edge of the clock and it's still passing timing because encounter adds a few delays to the input data path. You did mention in a previous post that having a max and min input delay of 0 could mean it's impossible to meet hold timing? How? As long as the input data changes within or outside of the hold-time slack I'll be meeting hold time. The challenge is making sure the board delay and the fpga outputs are as close as possible to the clock edge, but I can do that.

I could have wrote a better constraint file but it seems like there isn't much to worry about since Im driving the ASIC with an FPGA and can adjust the output timing accordingly.

Last edited:

Status
Not open for further replies.