( ESNUG 351 Item 5 ) ---------------------------------------------- [5/4/00]

Subject: (  ESNUG 348 #8  )   Run Synopsys DesignPower w/ Cadence NC-Verilog

> We are using Synopsys DesignPower and Cadence NC-Verilog, in order to
> perform power estimation of our ASIC's - but we are having problems -
> perhaps some of your readers might be able to help us out.
>
> The problem relates to the backward SAIF file, written by NC-Verilog
> through the $toggle_report PLI supplied by Synopsys (the file contains
> switching activity for all ports).  It seems like some input ports are
> dropped, but not all.  When read into dc_shell, and running report_power,
> these "dropped input" are having default 50% switching activity (no
> annotation), which was the way I initially discovered the problem.
>
> The ports, which are in the rtl2saif output file, are all monitored
> except for one data_valid and in[0].  Why does this happen with
> NC-Verilog 3.0 PLI version 3.3 but this does not happen with either VCS
> or Verilog-XL 3.0 simulators?
>
>     - Hans M. Pedersen
>       Oticon A/S                                 Hellerup, Denmark


From: [ A Synopsys DesignPower CAE ]

John,

Monitoring behavior is simulator dependent.

Although my answer to this question is based on Pedersen's design that he
e-mailed to me, this answer applies to many in his situation.

In his particular case, Pedersen's data_valid (a single bit) in HDL is
connected to port 'in' of Pedersen's "XYZ" instance.  His port 'in' is
defined inside the "XYZ module" as a bus width of 3.  Pedersen's data_valid
is connected to in[0].  Since the other 'in' bits are not used, NC-Verilog
internally represents the port 'in' as a single bit object, which is
interpreted by our PLI as 'in'.  But inside Verilog-XL or VCS, Pedersen's
port 'in' is represented as a 4-bit bus object, which is interpreted by our
PLI as 'in[0], 'in[1]', etc.

Our PLI monitors the in[0] and checks whether the in[0] exists.  Our PLI
checks the rtl2saif (forward SAIF) output file and NC-Verilog for in[0].  A
mismatch occurs since in the rtl2saif output file the port is represented
as in[0] and in NC-Verilog the port is represented as ?in?.  Our PLI then
writes out the backward SAIF file.  Since port is interpreted by PLI as 'in'
under the NC-Verilog environment, our PLI fails to find the name 'in' in
rtl2saif output file and therefore the port name is not written out to the
backward SAIF file.  In Verilog-XL or in VCS, the in[0] port is represented
with a matching name so our PLI is able to monitor and, check in rtl2saif
and write out in the backward SAIF file information about that port.

Pedersen's Workaround:

 1) Remove 'in\[0\]' line in the rtl2saif file; then data_valid is captured.
 2) Change 'in\[0\]' to 'in' inside the rtl2saif output file; then
    data_valid and in are both captured.

Hope this helps.

    - [ A Synopsys DesignPower CAE ]