Subject: [sv-cc] resolution of remaining sv-cc LRM issues
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Apr 10 2003 - 14:24:49 PDT
(all page and section references are with respect to draft 4, page numbers
are LRM page numbers, not PDF page numbers)
LRM 40:
(page 279, section 28.3.1)
no, pragmas have to be used as attributes not sufficiently capable in the current
revision of SV. Specifically, attributes can only be attached to a single declaration,
whereas for FSM descriptions information needs to be attached to declarations of multiple
variables/parameters, or to variable concatenations and part selects (for which no declarative
item even exists to which an attribute could be attached).
It is proposed that these limitations be raised as an issue to be resolved in SV 3.2
LRM 41:
(page 280, section 28.3.6)
Yes, enumerated types could also be used, but this use of parameters for
FSM modelling is common. In either case the pragma would be the same.
LRM 43:
(page , section 28.4.1)
Remove this section (VPI entity/relation diagrams related to coverage)
With the re-write below for LRM 44 and 45 these are no longer required
LRM 44:
(page 282, section 28.4.3)
Replace the body of section 28.4.3 with the following text:
To obtain coverage information, the vpi_get() function is extended with additional vpi properties
that can be obtained from existing handles:
vpi_get(<coverageType>, instance_handle)
Returns the number of covered items of the given coverage type in the given instance.
Coverage type is one of the coverage type properties described in section 28.4.2
For example, given coverage type vpiStatementCoverage, this call would return the number
of covered statements in the instance pointed by instance_handle.
vpi_get(vpiCovered, assertion_handle)
vpi_get(vpiCovered, statement_handle)
vpi_get(vpiCovered, signal_handle)
vpi_get(vpiCovered, fsm_handle)
vpi_get(vpiCovered, fsm_state_handle)
Returns whether the item referenced by the handle has been covered. For handles that
may contain multiple coverable entities, such as statement, fsm and signal handles, the return value
indicates how many of the entities have been covered.
For assertion handle, the coverable entities are assertions
For statement handle, the entities are statements
For signal handle, the entities are individual signal bits
For fsm handle, the entities are fsm states
vpi_get(vpiCoveredCount, assertion_handle)
vpi_get(vpiCoveredCount, statement_handle)
vpi_get(vpiCoveredCount, signal_handle)
vpi_get(vpiCoveredCount, fsm_handle)
vpi_get(vpiCoveredCount, fsm_state_handle)
Returns the number of times each coverable entity refered by the handle has been covered. Note
that this is only easily interpretable when the handle points to a unique coverable item
(such as an individual statement); when handle points to an item containing multiple coverable
entities (such as a handle to a block statement containing a number of statements), the result
is the sum of coverage counts for each of the constituent entities.
vpi_get(vpiCoveredMax, assertion_handle)
vpi_get(vpiCoveredMax, statement_handle)
vpi_get(vpiCoveredMax, signal_handle)
vpi_get(vpiCoveredMax, fsm_handle)
vpi_get(vpiCoveredMax, fsm_state_handle)
Returns the number of coverable entities pointed by the handle. Note that this will always
return 1 (one) when applied to an assertion or fsm state handle.
vpi_iterate(vpiFsm, instance-handle)
Returns an iterator to all FSMs in an instance.
vpi_handle(vpiFsmStateExpression, fsm-handle)
Returns the handle to the signal or expression encoding the FSM state.
vpi_iterate(vpiFsmStates, fsm-handle)
Returns an iterator to all states of an FSM.
vpi_get_value(fsm_state_handle, state-handle)
Returns the value of an FSM state.
LRM 45:
(page 283, section 28.4.4)
Replace the body of section 28.4.4 with the following text:
vpi_control(<coverageControl>, <coverageType>, instance_handle)
vpi_control(<coverageControl>, <coverageType>, assertion_handle)
Controls the collection of coverage on the given instance or assertion. Note that statement,
toggle and FSM coverage are not individually controllable (ie they are controllable only at the
instance level and not on a per statement/signal/FSM basis). The semantics and behavior are as
per the $coverage_control system function (see section 28.2.2.1)
coverageControl is one vpiCoverageStart, vpiCoverageStop, vpiCoverageReset or vpiCoverageCheck, as defined in section 28.4.2
coverageType is any one of the vpi coverage type properties (section 28.4.2)
vpi_control(<coverageControl>, <coverageType>, name)
This saves or merges coverage into the current simulation. The semantics and behavior are specified as per the
equivalent system functions $coverage_merge (see Section 28.2.2.4) and $coverage_save (see Section 28.2.2.5).
coverageControl is one of vpiCoverageMerge or vpiCoverageSave, defined in section 28.4.2
LRM 70:
(page , section D.7.7)
remove note, change preceeding list item from:
-- bit (i.e., 2-state) packed arrays up to 64 (previously 32) bit (canonical representation shall be used, like
for a function result)
to:
-- bit (i.e., 2-state) packed arrays up to 32 bit (canonical representation shall be used, like
for a function result)
LRM 71:
(page , section D.8)
correct cross-reference: D.8.3
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Thu Apr 10 2003 - 14:26:26 PDT