Subject: [sv-ac] SVAC 0.79 commentary - 11.8 .. 11.12
From: Adam Krolnik (krolnik@lsil.com)
Date: Wed Jan 29 2003 - 11:46:17 PST
Good morning;
Here are my comments on the last sections of the proposal.
11.8 "Manipulating data in a Sequence"
LRM - example sequence e
Suggest using 'x' instead of x+1 to make it a simple fifo example.
Safety - example sequence e_two_pipes
See comments on 11.6.8 for why this is bad.
Correctness - example sequence e_with_id
See, this is not as simple as 'adding an id to each input data'.
As written, if (id_out == id && valid_out) is not ever true, then
you won't get an error about pipe_out1 being wrong. It should be
written with only 1 implication operator. Also, the range
for finding the valid_out should be less than 'inf'. This would allow
someone to get an error reported early in simulation rather than after
a global timeout.
11.9 "System Functions"
Are we going to include the $asserton(), $assertkill(), $assertoff()
system tasks (from SV 3.0) for controlling assertions?
Is there any way to associate a clock for assertions within a hierarchy?
E.g. Say you have a multiplexer module that does not include a clock as
part of it's interface (since combinatorial is not clocked.) Does this
mean I can not write an assertion to ensure that the inputs to the
multiplexer are correct?
11.10 "Property definition"
Suggest 'never' ahead of 'accept'? Places keyword closer to
beginning of property. Then you read property a = never ... or
" assert never ..."
LRM - what does it mean if there is no event_control clause?
LRM - "A property can be referred in directives" Replace "in" with "to by" ?!
LRM - Add text here about assert <prop_expr> being more like
assert first_match(prop_expr)
This is important and should not be a note in the BNF.
LRM - add language that omitted else action block results in the default
else clause being added:
else $error()
LRM - 2nd last sentence, :"A directive can be referred by referencing"
Suggest, "A directive can be referenced by using its optional name."
LRM - last sentence "When a name is not provided, a tool must assign a name
to the directive."
Is this a requirement of tools for all anonymous directives? The wording
needs to then be "shall assign..." Is there any specific algorithm for
generating said names?
11.10.1 "Declaring Properties ..."
The LRM should show the BNF fragments of properties, directives, etc. where
they can be written, etc.
11.10.2 What is the value of declaring a property within a procedural block
(unlike all other declaration?) Recommend declarations follow SystemVerilog rules.
Only in named blocks, outside otherwise.
11.11 Need to explain how templates are different from modules. Interfaces
are getting a beating for not being modules... Explain how templates
can be called (like a task) from procedural code - and what that does
for the properties (if anything) in a template.
No explanation of how non-blocking assignments work within templates.
Estimation suggests that they evaluate based on their usage in a propert/sequence
with a clock derived from the context. Need proper explanation for:
1. Initial value
2. When clocked/updated
3. One value (not per sequence/property starting cycle)
4. Justification why always block with std SystemVerilog syntax is not sufficient.
LRM - add BNF for instantiating/calling assertion templates.
LRM - second paragraph, remove "and direction", typo "dtat_type".
LRM - example with named connection. Explain how one obtains the default
value with named connections - leave it out, don't send anything in?
LRM - explain what can be passed into a template: variable, hierarchical reference,
expression, sequence? property? template variable?
Questions:
1. can I call a template from a function? Can I write an assertion within a
function? Note, there may be multiple calls to a function (from different
or the same places) that would need to be considered.
11.12 "Binding properties to scopes or instances"
I recommend an alternative approach:
extend <module>;
Allow templates to be created, instantiated, included, etc.
Of course, this would allow anything to be added to a module, thereby providing some
amount of aspect based design.
I would be open to allowing "extend <instance>" if one can explain why you would
have a property that can't be checked on all instances (and you can't embed a
disable into the property.)
Advantages:
1. Provides the same concept as 'bind' but is more general.
One could utilize this feature to conditionally include assertions,
debug code, verification code, additional functionality, etc.
2. Co-locates the information about binding a program/template to a
module with the program block or template block. E.g.
extend mp_alu; // Add these assertions to define correct operations.
template alu_opcode_valid();
...
endtemplate
alu_opcode_valid();
endmodule
3. See AOP resources...
Questions about current proposal:
1. Why can one only bind a program block? I can instantiate a template
into a module, but for binding, this is not allowed?
2. Why do bound things run differently than templates/properties/sequences?
There is no language about sequences/properties running in the verification
phase whereas the program blocks are written that way.
3. Where can these statements be placed? In a module?; in $root?
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 11:48:43 PST