Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Implication of not specifying input delay constraint

Status
Not open for further replies.
M

mwb

Junior Member level 2
Joined
Jul 20, 2015
Messages
21
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,469
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_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
 

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.
 

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".
 

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).
 

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

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.
 

ThisIsNotSam said:
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.
Click to expand...

OK, let me address #1:

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.
 

mwb said:
OK, let me address #1:


#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.
Click to expand...

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.
 

ThisIsNotSam said:
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.
Click to expand...


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.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top