• 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. Digital Implementation
  3. "Undefined scan chain" error during Innovus `place`

Stats

  • Replies 4
  • Subscribers 93
  • Views 414
  • Members are here 0

"Undefined scan chain" error during Innovus `place`

GS202507021424
GS202507021424 27 days ago

I'm trying to run a RocketChip (rv64gc) design through the Genus/Innovus synth+place&route flow (with gpdk045 as the underlying technology), and running into a "scan chain" related issue during Innovus place (and subsequently cts). During place, I get this error:

    [check_scan_connected]: number of scan connected with
        missing definition = 5267, number of scan = 18274,
        number of sequential = 27937, percentage of missing
        scan cell = 18.85% (5267 / 27937)
    **ERROR: (IMPSP-9099): Scan chains exist in this design
        but are not defined for 18.85% flops. Placement and
        timing QoR can be severely impacted in this case!
    It is highly recommend to define scan chains either through
        input scan def (preferred) or specifyScanChain.

If I ignore this and continue by running cts, I then get this error:

    **ERROR: (IMPCCOPT-1349): Clock tree clock connects to 5 module(s)
        without definitions in the netlist.
    ...
    **ERROR: (IMPCCOPT-2196): Cannot run ccopt_design because
        the command prerequisites were not met. Review the previous
        error messages for more details about the failure.

Synthesis (with Genus) completes error-free, for whatever that's worth...

I suspect that this is somehow related to the RocketChip's debug interface, which has its own independent debug_clock and a few additional *reset signals:

    module ExampleRocketSystem(
      input         clock,
      input         reset,
      input         resetctrl_hartIsInReset_0,

      // debug interface:
      input         debug_clock,
      input         debug_reset,
      output        debug_clockeddmi_dmi_req_ready,
      input         debug_clockeddmi_dmi_req_valid,
      input  [6:0]  debug_clockeddmi_dmi_req_bits_addr,
      input  [31:0] debug_clockeddmi_dmi_req_bits_data,
      input  [1:0]  debug_clockeddmi_dmi_req_bits_op,
      input         debug_clockeddmi_dmi_resp_ready,
      output        debug_clockeddmi_dmi_resp_valid,
      output [31:0] debug_clockeddmi_dmi_resp_bits_data,
      output [1:0]  debug_clockeddmi_dmi_resp_bits_resp,
      input         debug_clockeddmi_dmiClock,
      input         debug_clockeddmi_dmiReset,
      output        debug_ndreset,
      output        debug_dmactive,
      input         debug_dmactiveAck,

      // mem_axi4_0 64-bit data width AXI (master) port;

      // mmio_axi4_0 64-bit data width AXI (master) port;

      // l2_frontend_bus_axi4_0_axi4_0 64-bit data width AXI (slave) port;

      input  [7:0]  interrupts
    );
      ...
    endmodule

In the .sdc file for Genus (synthesis), I have designated clock as the clock signal (using create clock -name "clock" -period ...), but I'm unsure of whether (and how) to deal with the debug_clock signal, or if that's even the way to address the subsequent "scan chain" errors I get during place...

Any clues, tips, or pointers much appreciated!

  • Cancel
  • Sign in to reply
Parents
  • Pascal
    Pascal 2 days ago

    Try putting thic command  "set_db / .use_scan_seqs_for_non_dft" false in genus after elaboration and befor syn_gen

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • GS202507021424
    GS202507021424 1 day ago in reply to Pascal

    Hi Pascal,

    Many thanks, that did it!!! 

    I guess I need to remember GENUS*/doc/genus_attref/genus_attref.pdf for future reference, as a place to look for in cases where I feel "there ought to be a flag that does this" :)

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • GS202507021424
    GS202507021424 1 day ago in reply to Pascal

    Hi Pascal,

    Many thanks, that did it!!! 

    I guess I need to remember GENUS*/doc/genus_attref/genus_attref.pdf for future reference, as a place to look for in cases where I feel "there ought to be a flag that does this" :)

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
  • Pascal
    Pascal 22 hours ago in reply to GS202507021424

    i am happy to help! 

    • 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.

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

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