• 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. Does Spectre native syntax support arrayed instances (bus...

Stats

  • Replies 3
  • Subscribers 129
  • Views 75
  • Members are here 0

Does Spectre native syntax support arrayed instances (bus notation)?

GX202407164559
GX202407164559 1 hour ago

I'm running into an issue when trying to use arrayed/bused instances in Spectre native syntax (simulator lang=spectre).

What I tried

I have a subcircuit (let's call it MY_CELL) with several ports, and I need to instantiate 256 copies of it with bused connections. I tried the following in native Spectre syntax:


simulator lang=spectre

// Attempt 1: angle brackets (SPICE-style)
XI0<0:255> ( A<0:255> B C<0:255> D ) MY_CELL
// → ERROR (SFE-874): Unexpected operator "<"

// Attempt 2: square brackets
XI0[0:255] ( A[0:255] B C[0:255] D ) MY_CELL
// → ERROR (SFE-874): Unexpected open square bracket "["


Both attempts produce syntax errors under simulator lang=spectre.

Current workaround

I'm currently switching to SPICE mode inline for the arrayed instance, then switching back:

simulator lang=spice
XI0<0:255> A<0:255> B C<0:255> D MY_CELL
simulator lang=spectre

This compiles and runs, but it feels like a workaround rather than a proper solution.

My questions

  1. Is it confirmed that Spectre native syntax does not support arrayed/bused instances at all? I couldn't find a definitive statement in the documentation (SPECTRE User Guide or Reference). If it is supported, what is the correct syntax?

  2. Performance: expanded vs. bused instantiation. If native Spectre doesn't support bus notation, the alternative is to write out all 256 instances explicitly (unrolled, Virtuoso is using \< \>), e.g.:

XI0_0 ( A_0 B C_0 D ) MY_CELL
XI0_1 ( A_1 B C_1 D ) MY_CELL
...
XI0_255 ( A_255 B C_255 D ) MY_CELL
            Compared to the SPICE-mode <0:255> bus notation, is there any difference in simulation performance (parsing time, memory usage, or solve time)? Or does the simulator internally expand the bus notation into individual instances anyway, making them equivalent?
        3. Best practice recommendation. For large designs requiring hundreds of repeated instances, what is the recommended approach in Spectre — use the inline simulator lang=spice switch, write a script to generate the unrolled netlist, or something else?

Any insights would be greatly appreciated. Thanks in advance!

Environment:

  • Spectre version: @(#)$CDS: spectre  version 23.1.0 64bit 04/15/2024 22:19 (csvcm36c-3) $
  • OS: RHEL 9.6
  • Cancel
  • Sign in to reply
  • Andrew Beckett
    Andrew Beckett 1 hour ago

    Spectre does not support iterated instances or buses in its native language. 

    When you use that syntax in the SPICE mode, it's not an iterated instance or a bus - it's just an instance name or net name with unusual characters in. There's a single instance of MY_CELL only. So there's no performance benefit one way or another because it's not a bus or an iterated instance here...

    If you're not using ADE, then the solution is to build the expanded netlist somehow.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • GX202407164559
    GX202407164559 1 hour ago in reply to Andrew Beckett

    Do you mean there is only one MY_CELL whose name is "XI0<0:255>"?

    I see, so the only solution will unroll it via script/manually/ADE.

    E.g. 

    XI0_0 ( A_0 B C_0 D ) MY_CELL
    XI0_1 ( A_1 B C_1 D ) MY_CELL
    ...
    XI0_255 ( A_255 B C_255 D ) MY_CELL

    Thank you for your reply.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Andrew Beckett
    Andrew Beckett 23 minutes ago in reply to GX202407164559
    GX202407164559 said:
    Do you mean there is only one MY_CELL whose name is "XI0<0:255>"?

    Yes, that's right.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel

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.

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

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