Home > Community > Forums > Logic Design > Undesirable buffer insertion for constant pins attached to an instantiated hard macro

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 Undesirable buffer insertion for constant pins attached to an instantiated hard macro 

Last post Tue, Jul 5 2011 2:02 PM by grasshopper. 4 replies.
Started by Brannon 04 Jul 2011 12:49 PM. Topic has 4 replies and 3050 views
Page 1 of 1 (5 items)
Sort Posts:
  • Mon, Jul 4 2011 12:49 PM

    • Brannon
    • Not Ranked
    • Joined on Mon, Jul 4 2011
    • Posts 6
    • Points 75
    Undesirable buffer insertion for constant pins attached to an instantiated hard macro Reply

    My design 'foo' imports a hard macro for a subdesign 'bar', referenced via a bar.lef and bar.lib. One edge of foo abuts with an edge of bar with bar's pins on that edge passed directly to foo's ports. Some of the bar output pins are constants, and thus bar.lib lists a 'function' with a constant value for those pins. RC seems to want to buffer its version of those ports rather than just connect to the output pins of the bar (they are buffered internal to bar, so there is no ESD concern).

    The problem is that there is no room to drop a buffer which leads to hilarious results (the buffer is placed many mm away). I'd like to instruct RC (and subsequent velocity runs) to connect those ports directly without any buffering. I [perhaps foolishly] tried:

     set_attribute iopt_avoid_tiecell_replacement true [dc::get_ports o_*]

    It didn't work (or perhaps I applied this at the wrong point in the flow)--Any suggestions?

    • Post Points: 20
  • Mon, Jul 4 2011 7:40 PM

    • grasshopper
    • Top 25 Contributor
    • Joined on Fri, Jul 18 2008
    • Chelmsford, MA
    • Posts 241
    • Points 3,200
    Re: Undesirable buffer insertion for constant pins attached to an instantiated hard macro Reply

    Hi Brannon,

     did you try simply preserving (set_attr preserve true [find / -pin ...) such pins ? I believe that should suffice, If that works, I beleive you can even include the preserved/dont_touch'ed pins in your liberty model. Please report back if that works

     gh-

    • Post Points: 20
  • Tue, Jul 5 2011 12:29 PM

    • Brannon
    • Not Ranked
    • Joined on Mon, Jul 4 2011
    • Posts 6
    • Points 75
    Re: Undesirable buffer insertion for constant pins attached to an instantiated hard macro Reply

    That didn't seem to work--it still replaces the connection to the constant pin on the hard macro with an 'assign out = 1'b0', and then sometime later it replaces all the assigns with buffers.

     

    • Post Points: 5
  • Tue, Jul 5 2011 1:14 PM

    • Brannon
    • Not Ranked
    • Joined on Mon, Jul 4 2011
    • Posts 6
    • Points 75
    Re: Undesirable buffer insertion for constant pins attached to an instantiated hard macro Reply

    I'm having better luck with:

     set_attribute propagate_constant_from_timing_model false <instance>

     This prevents it from noticing that the pin is constant driven from the instance and thus avoids turning this into an assign which later gets turned into a buffer.

    • Post Points: 20
  • Tue, Jul 5 2011 2:02 PM

    • grasshopper
    • Top 25 Contributor
    • Joined on Fri, Jul 18 2008
    • Chelmsford, MA
    • Posts 241
    • Points 3,200
    Re: Undesirable buffer insertion for constant pins attached to an instantiated hard macro Reply

     Hi Brannon,

    that seems like the right attibute. Thanks for reporting back

     gh-

    • Post Points: 5
Page 1 of 1 (5 items)
Sort Posts:
Started by Brannon at 04 Jul 2011 12:49 PM. Topic has 4 replies.