( ESNUG 355 Item 15 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 348 #8 351 #5 ) Synopsys DesignPower & Cadence NC-Verilog
> Monitoring behavior is simulator dependent.
>
> 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.
>
> - [ A Synopsys DesignPower CAE ]
From: Steven Sharp <sharp@cadence.com>
NC-Verilog cannot be internally representing the port 'in' as a single bit
object if it is declared as a four bit object. That isn't how Verilog works.
This may be an issue with "vectored" versus "scalared" nets. Perhaps this
PLI application is not handling one of them correctly.
- Steven Sharp
Cadence
> Our PLI monitors the in[0] and checks whether the in[0] exists. Our PLI
> checks the rtl2saif (forward SAIF) output file & 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 and therefore the port name is not written out to the
> backward SAIF file. In Verilog-XL or 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.
>
> - [ A Synopsys DesignPower CAE ]
From: Parvathy Uma <puma@cadence.com>
While this may do as a workaround (not a good one if you are actually
looking at bits) the correct solution would be to get the latest version of
the Design Power PLI. The problem was in the PLI code; problem description
follows:
The user PLI looks at all the nets in a module and once it finds a
vector net, checks whether it is a expanded vector net.
If it is a expanded vector net, it uses acc_next_bit to get
each bit of the expanded vector net.
Then it does a acc_fetch_type on the net bit and decides to put a vcl
trigger based on the return type.
Verilog-XL returns type accNet whereas NC-Verilog returns accNetBit
(Since it is actually a net bit, NC is correct in returning type
accNetBit.)
For a number of reasons, XL cannot always figure out whether bit of a
expanded vector net is a net or a net bit. The solution to this particular
problem is for the user PLI to anticipate a return type of accNetBit.
The STAR # for this problem is star #98945
- Parvathy Uma
Cadence
|
|
