• 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. Mixed-Signal Design
  3. Using internal nodes for liberate_ams - characterization...

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 64
  • Views 2113
  • 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

Using internal nodes for liberate_ams - characterization of macro block

bitmaster
bitmaster over 4 years ago

Hi,

I'm a new user to liberate_ams, originally doing digital IC design, using Innovus for top-level implentation of mixed-signal chips.

I'm trying to characterize a large full-custom block with digital interface and internal clock distribution. We do not have a top-level testbench for the block, so I'm going for truth-table based characterization. For a start, I want to characterize one single flip-flop which has its CLK and D inputs directly connected to inputs of the block. The output of the flip-flop is an internal node, with subsequent connectivity inside the block.

My problem now is that I can't find a way to correctly point liberate_ams to this internal node. The extracted layout node/net name is X2310/60 (netlist without parasitics, as a start).
My define_cell command looks as follows:
define_cell \
  -clock { clk } \
  -input { en  <and a few more> } \
  -output { d_out<0:1023>  <and a few more> } \
  -delay delay_template_7x6 \
  -power power_template_7x6 \
  -constraint constraint_template_3x3 \
  -internal X2310/60 \
  block_top

And the according truth-table:
table chip_en_clk_in
pins         clk    en      X2310/60
INIT         R      L       X        
en_RISE      R      1       C        
en_FALL      R      0       C        
endtable

When I run char_ams (with the -user_arcs_only option) I get the following output:

...
(AMS-info) - Start Macro Characterization ...
(AMS-warning) - no wire exists for bus' pin: X2310/60
(AMS-warning) - no wire exists for bus' pin: X2310/60
             Skipping table chip_en_clk_in
(AMS-error) - at least 1 transition for 1 wire must be specified - please check table: constraint.tbl
             If this is a power table, set 'mx_power_leakage_table_vector_ratio' to 20 or more - max 100
             If using define_deck command, make sure the -dut_inst instance name exists and is correct
...

I also tried specifying pin names of hierarchical instances to no avail - so I couldn't find a way to put that constraint on this internal node.

I'd be glad if somebody could tell me how to setup such internal nodes correctly - or whether this is the correct way of setting this up at all... sorry for that potentially silly question...

Andreas

  • Cancel
Parents
  • Guangjun Cao
    Guangjun Cao over 4 years ago

    Hi Andreas,

    If X2310/60 is hierarchy/name, please try X2310.60 -- use "." instead of "/" in the define_cell command and vector table.

    If you are looking at the timing model now, I also suggest you start with the static mode first, which does not need a vector table.

    Regards,

    Guangjun

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Guangjun Cao
    Guangjun Cao over 4 years ago

    Hi Andreas,

    If X2310/60 is hierarchy/name, please try X2310.60 -- use "." instead of "/" in the define_cell command and vector table.

    If you are looking at the timing model now, I also suggest you start with the static mode first, which does not need a vector table.

    Regards,

    Guangjun

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
  • bitmaster
    bitmaster over 4 years ago in reply to Guangjun Cao

    Hi Guangjun,

    thanks a lot for your quick reply - I didn't suspect hierarchy delimiters at all, it was indeed as easy as that... ;-)

    And thank you for pointing to static mode. I'll go with that first.

    Cheers,
    Andreas

    • Cancel
    • Vote Up 0 Vote Down
    • 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