Driving of reset line - order of magnitude difference between RC & PrimeTime > Forums

Unanswered

Active Topics

Forums

Forums > Digital IC > Synthesis and test

Subject: Driving of reset line - order of magnitude difference between RC & PrimeTime

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

denil
Posts: 7
Online: User is Offline

10/18/2007 10:07 AM
Dear all, I am running into a weird problem with rtlcompiler on which I need some expert advice :-) In my design I have a reset line (asynchronous) which is connected to different blocks. In every block the signal is inverted and then passed to a bunch of RN-pins. The problem that I am encountering is that rc selects the smallest available inverter to drive these pins. A timing report through the inverter does not show any problem. In the example below the inverter g1529 only adds a delay 163ps while it is loading 159 reset pins. When performing a timing analysis with primetime the delay is found to be 6.25ns. I assume this value is correct? When I export the net loads with write_set_load I see that the net loaded by the inverter has a load of 0. Almost all other nets (even the ones with only a couple of loads attached) have a load > 0. Probably this is something very simple, I am quite new to rtlcompiler ;-) Thanks, Michael RTL Compiler: Pin Type Fanout Load Slew Delay Arrival (fF) (ps) (ps) (ps) ------------------------------------------------------------------------------ (clock virtual_clock) launch 0 R latency +1200 1200 R (in_del_1) ext delay +1000 2200 F mem_selectΎ] in port 3 6.3 0 +0 2200 F g519/A +0 2200 g519/Y INVX1MTH 2 8.3 207 +125 2325 R g517/A0 +0 2325 g517/Y AO22X4MTH 100 119.2 1222 +878 3203 R g516/B +0 3203 g516/Y NAND2BXLMTH 22 28.6 1340 +1163 4366 F cell/reset inst_decoder/reset g1529/A <<< +0 4366 g1529/Y (i) INVX1MTH 159 0.0 0 +163 4529 R reg_IR_ID_regΗ]/RN DFFRHQX4M +0 4529 ------------------------------------------------------------------------------ Timing slack : UNCONSTRAINED Start-point : mem_selectΎ] End-point : cell/inst_decoder/reg_IR_ID_regΗ]/RN rc:/> get_attribute net /designs/base/instances_hier/cell/instances_hier/inst_decoder/instances_comb/g1529/pins_out/Y /designs/base/instances_hier/cell/instances_hier/inst_decoder/nets/n_1617 rc:/> get_attribute num_loads /designs/base/instances_hier/cell/instances_hier/inst_decoder/nets/n_1617 159 PrimePower: Point Incr Path ------------------------------------------------------------------------------ clock virtual_clock (rise edge) 0.00 0.00 clock network delay (ideal) 1.20 1.20 input external delay 1.00 2.20 f mem_selectΎ] (in) 0.00 2.20 f g519/Y (INVX1MTH) 0.12 2.32 r g517/Y (AO22X4MTH) 0.89 3.21 r g516/Y (NAND2BXLMTH) 1.17 4.38 f cell/reset (opn_base) 0.00 4.38 f cell/inst_decoder/reset (decoder) 0.00 4.38 f cell/inst_decoder/g1529/Y (INVX1MTH) 6.25 10.63 r cell/inst_decoder/reg_IR_ID_reg⎟]/RN (DFFRHQX8MTH) 0.00 10.63 r data arrival time 10.63

lisiang
Moderator
Posts: 48
Online: User is Offline

10/18/2007 12:21 PM
since RTL_compiler is a synthesis tool, it makes certain assumption and high fanout net (ideal net with no wire delay) is one of them. In this case, it treated the RESET net as a high fanout ideal net and it assumed the net will be re-buffer in the p&r tool so no buffer tree was built for the net and also it assumed a wire delay of zero. I think you can change this behaivour by some variable (control min fanout #). li siang

denil
Posts: 7
Online: User is Offline

10/22/2007 12:57 AM
Hi Li Siang, thanks for you advance! Apparently I am doing something wrong in my p&r scripts, since the cell is not replaced by a bigger one. I will look into it. In meanwhile I tried to set the max_fanout for the whole design to 10 by: set_attribute max_fanout 10 /designs/base After synthesizing the design again the same not cell is used and still has as many reset pins connected to it. When I execute the fanout command on the output pin of the not, I get a list of over 100 pins connected to it. What is also weird is that when I check the design rules that it does not show any violation of max_fanout: rc:/> get_attribute max_fanout /designs/base 10.000 rc:/> report design_rules /designs/base Tracing clock networks. Levelizing the circuit. Computing net loads. Computing delays. Computing arrivals and requireds. Initializing DRC engine. ============================================================ Generated by: Encounter(r) RTL Compiler v06.20-s027_1 Generated on: Oct 22 2007 09:54:47 AM Module: base Technology libraries: ... Operating conditions: ... Interconnect mode: ple ============================================================ Max_transition design rule: no violations. Max_capacitance design rule: no violations. Max_fanout design rule: no violations. Any idea why this would be? Thanks for your help! Michael

grasshopper
Posts: 48
Online: User is Offline

10/22/2007 5:10 AM
Hi Michael, I believe RC idealizes clock nets and async reset pins since this are usually large fanout and much better handled in P&R. If you want to change this behavior I think there is an attribute to control that but cannot remember the name off the top of my head. The max_fanout attribute will not have any effect on these nets because they were idealized. gh-

Posting to forums is available to community members only.
Login or Register

Forums > Digital IC > Synthesis and test > Driving of reset line - order of magnitude difference between RC & PrimeTime

ActiveForums 3.6