Synchronous resets during ASIC synthesis

[harshpar1]

Clock nets and asynchronous resets are generally specified as being ideal during synthesis. It is the responsibilty of the layour engineers to lay the clock tree and the reset tree so that the skew is within limits and that the circuit meets timing.

However my question is:

How are synchronous reset nets dealt with during synthesis? These nets are high fanout nets as well (similar to clock and asynchronous reset nets). How do I specify a synchronous net as being ideal. The synopsys design compiler does not let me specify an internal pin as being ideal. Can anyone let me know what is the correct procedur of specifying an internal pin as source of an ideal network?

 

[ebuddy]

You don't have to set synchronous reset as ideal net. Let synthesis tool buffer it.

 

[harshpar1]

The synthesis tool isn't great at buffering high fanout nets (I miss timing by a few pico seconds which could very well be met). So I would rather have that taken care of in the backend layout process. Do backend layout houses have an option of buffering the synchronous reset nets? Or is it almost always advised to let the synthesis tool take care of synchronous resets?

How would I specify such a net as ideal? set_ideal_network [get_pins reset_gen/sync_rst] doesn't do the needful.

 

[lostinxlation]

How would I specify such a net as ideal? set_ideal_network [get_pins reset_gen/sync_rst] doesn't do the needful.

option1; set_ideal_net
option2: set_false_path
option3: let the synthesis tool buffer it.

 

[harshpar1]

Thanks. I guess I will do a set_dont_touch on the net and then specify it as a false path.

 

[harshpar1]

[/COLOR]Just to close the loop on the thread:

You can set an ideal net by: set_ideal_net [get_nets -of_objects [get_pins your_pin_path]]. The problem is this ideal net wont be propagated. So if this net's path has combinatorial logic then the ideal net wont propagate unless all the inputs to the combinatorial logic are atrributed as ideal.

So for synchronous reset nets which are high fanout nets we have the following options: (Apart from letting the synthesis tool buffer it up)

1. Declare the net as ideal (command shown above) and then let the backend layout engineers buffer it up to meet timing. Dont set a dont_touch on the net just set it as ideal.
2. Think of some RTL changes to ease critical timing paths.

 

[sunjianhuigou]

Hi:
at synthesis step,u can do as follow:
My design is a synchronous reset system;
SYNTHESIS I had done work about this step)
set_idel_network [get_ports [list reset_in1 reset_in2 xxx]
set_false_path [get_ports [list reset_in1 reset_in2 xxx]
set_dont_touch_network [get_ports [list reset_in1 reset_in2 xxx]
just setting to the reset port, it's enough!
Then you need to analysis the timing with the PrimeTime best ,maybe exist some paths that the cell delay is very very large, then you should analysis it, eg a AND gate (AND_reset_in1 & AND_data_net = AND_out (eg, delay incr 30.0) ), that the reset_in1 net passed a and logic, inducing this problem, of course maybe other operations inducing the problem, you should analysis the path, then need to set_ideal_network to the output the gate that casued the problem(eg,AND_out in this example,set_ideal_network [get_pins xxx/xxxx/AND_out]) ;
2 P&R step(this step i just have heared some ideas)
add buffer to the input port, and the added numbers should be appropriate, maybe after this opration some problems is solved.
Of course you can dispose the reset_in1/2 trees like treating the clock tree ,it's a good method.
But, to balance the reset tree can't solve the RECOVERY/REMOVAL problem. having very good idea?
How to solve the timine vilovation caused by them is important too. And the front-end engineer should add the reset manage logic (eg,another DFF(whose input is '0' if '0' is reset enable) befor the reset_in1 ) to solve the problem;
And if the design have 2 clocks clk1 and clk2(asynchoronous) ,should have reset_in1 and reset_in2 to reset clock1 and clock2 part separatly?if using the same reset_in signal ,maybe inducing the reset operation asynchoronous problem during diffrent clocks , have a better way to deal with it?