• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. .SPF Pin Annotation Issue in Virtuoso

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 15429
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

.SPF Pin Annotation Issue in Virtuoso

anurans
anurans over 6 years ago

Hi,

I am trying to perform transistor level post layout simulation on a 'P&R'ed digital design. After P&R and timing optimizations, I import the post layout netlist (without physical only cells) to Virtuoso (Cadence IC 6.1.7) along with extracted .dspf file. I have the OA version of the reference standard cell library in Virtuoso in which all cell views have power and well contacts. However the .dspf from Innovus does not have these contacts in "instance" section, so that when the .dspf is annotated to the schematic netlist, spectre simulation stops throwing following error :

ERROR (SFE-45): `Xpipe_in_0__dxin': An instance of `DFQBRM1RA' needs at least 8 terminals (but has only 4). 

The schematic Netlist looks like below:

subckt DFQBRM1RA QB CK D RB VDD VSS VBN VBP
M0 (VSS CK N_2_M0_s VBN) n_12_llrvt l=1E-08 w=1E-07 sa=1.6E-07 \
sb=4E-07 nf=1 mis_flag=1 sd=200n as=2.4E-14 ad=3.315E-14 \
ps=6.2E-07 pd=7.6E-07 sca=45.7965 scb=0.032936 scc=0.00744915 m=1 \
mf=1
M1 (N_3_M1_d N_2_M0_s VSS VBN) n_12_llrvt l=1E-08 w=1E-07 sa=4E-07 \
sb=1.6E-07 nf=1 mis_flag=1 sd=200n as=3.315E-14 ad=2.4E-14 \
ps=7.6E-07 pd=6.2E-07 sca=45.7965 scb=0.032936 scc=0.00744915 m=1 \
mf=1

whereas .dspf : 

Xpipe_in_0__umc65_dxin pipe_in_0__umc65_dxin:CK pipe_in_0__umc65_dxin:D
+ pipe_in_0__umc65_dxin:QB pipe_in_0__umc65_dxin:RB DFQBRM1RA

Is there a workaround to bypass this in Virtuoso ? 

Thanks in advance

Anuradha

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 6 years ago

    Hi Anuradha,

    The flow isn't really designed to support cell-level DSPF files (unless they are pin-compatible with the subckts you're using for the leaf cells) - more for transistor DSPF which would go all the way down to transistor level.

    There is the extra_port=true option on dspf_include, but that's unlikely to work as it would convert the missing pins to be effectively local nets and hence the supplies/wells would be floating, which is unlikely to be what you want.

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • anurans
    anurans over 6 years ago in reply to Andrew Beckett

    Hi Andrew, I modified the .spf file in a way that the instantiation of standard cells now have the supply rails. Simulation now runs (I am measuring power) and however I cannot see any waveform, power numbers with the spf inclusion. Without its annotation, simulation just works fine. Can't we annotate interconnect parasitics with standard cells in this way without going through gds flow ?

    Thanks

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 6 years ago in reply to anurans

    Hi Anurans,

    The thing is you're talking about the DSPF include flow here - this is not "annotation" as it replaces the original design hierarchy. With that, it's important for the leaf cells and the DSPF to tie up, which they don't here. I suspect that the changes you have made here are not really connecting up the supplies or something odd is going on.

    I've no experience of trying this flow with cell-level DSPF from Innovus, so I can't really comment on how well it works or if there are any workarounds to make it work. In general we would recommend using transistor DSPF for this flow.

    Potentially the approach you describe might work with spectre's DSPF stitching flow which does annotate the parasitics onto the original schematic hierarchy - but that can be problematic for other reasons and is a flow that we don't tend to encourage nowadays (which is why it doesn't show up in the ADE UI).

    It might be best to contact customer support so that we can take a look at your set up and work through the feasibility of getting this flow working (with the DSPF from Innovus). Maybe there's some switches in Innovus which can ensure that the power pins are connected (I don't know enough about Innovus to know off the top of my head, and I don't have the bandwidth to investigate at the moment as I'm travelling).

    Regards,

    Andrew.

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 6 years ago in reply to anurans

    Hi Anurans,

    The thing is you're talking about the DSPF include flow here - this is not "annotation" as it replaces the original design hierarchy. With that, it's important for the leaf cells and the DSPF to tie up, which they don't here. I suspect that the changes you have made here are not really connecting up the supplies or something odd is going on.

    I've no experience of trying this flow with cell-level DSPF from Innovus, so I can't really comment on how well it works or if there are any workarounds to make it work. In general we would recommend using transistor DSPF for this flow.

    Potentially the approach you describe might work with spectre's DSPF stitching flow which does annotate the parasitics onto the original schematic hierarchy - but that can be problematic for other reasons and is a flow that we don't tend to encourage nowadays (which is why it doesn't show up in the ADE UI).

    It might be best to contact customer support so that we can take a look at your set up and work through the feasibility of getting this flow working (with the DSPF from Innovus). Maybe there's some switches in Innovus which can ensure that the power pins are connected (I don't know enough about Innovus to know off the top of my head, and I don't have the bandwidth to investigate at the moment as I'm travelling).

    Regards,

    Andrew.

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information