From: Steve Meyer (sjmeyer@crl.com)
Date: Fri Sep 12 1997 - 09:12:05 PDT
This problem area was discussed during some SDF task force meetings and I
still think that pulse limits and transport delays should not be added to
Verilog because this feature (and much more general cases) can better
be implemented using PLI 2.0.
>> Hi Adam,
>>
>> By controlling pulse limits, the delays in specify blocks can provide
>> transport delays, inertial delays, and anything in between (transport
>> and inertial delays are just opposite ends of a spectrum of
>> possibilities).
I do not think pulse limits are a good idea and in fact are an unsafe
feature because trying to guess that for example a pulse earlier than 20%
after initial edge should switch but a pulse more than 20% should become
x is unreliable. What if a process change is made?
I think the new +show_cancel_e feature that changes value to x on any
pulse makes pulse limits redundant and is in fact a safer and better feature.
For libraries that need percentage pulse limits or even more complicated
pin timing relationships, the new PLI 2.0 feature that allows call backs
on wire changes to allow a general C program to be run on every input
change is better, i.e. ASIC models that need such accurate modeling should
use the PLI 2.0. At least, I hope this feature will not be added until
more users start using PLI 2.0.
>>
>> Providing this kind of capability in delays outside the specify block
>> is something I very much want to add. I've brought this up in our
>> sub-group discussions, but we haven't moved this to the front burner
>> as of yet. But if both sub-groups are interested in this feature then
>> maybe it makes sense to deal with it now.
>>
>> Our vision of this feature includes the ability to specify and use
>> specparams outside the specify block, and the ability to annotate
>> specparams through the PLI (and thereby from SDF using the new LABELS
>> feature, where a LABEL matches with a GENERIC in VHDL and with a
>> specparam in Verilog).
>>
>> I'd like to modify your proposal so that the "->" operator transforms
>> the delay into one that can take pulse limits. In this way
>> modification of the pulse limits can provide any timing behavior
>> desired, including normal pulse filtering and pulse filtering to the
>> error state.
>>
>> An example:
>>
>> Verilog description:
>>
>> specparam dly = 100;
>>
>> -> #dly event_a;
>> -> @(posedge clk) event_a;
>> -> repeat (2) @(posedge clk) event_a;
>>
>> SDF description:
>>
>> (CELL
>> (CELLTYPE "cache")
>> (INSTANCE test.top.asic2)
>> (LABEL
>> (ABSOLUTE
>> (dly 150)
>> )
>> )
>> )
I agree that (LABEL feature is very good, but there is no need to change
current Verilog language to support it. Cver implement annotation to
both defparams and specparams using the follow, I think, simple algorithm:
1) SDF (LABEL construct causes first the (LABEL name (dly parameter above)
to be looked up in the specify block symbol table. If it is not found
there, the parameter is looked up in the module symbol table. If found,
it must be a defparam.
This requires users who want to back annotate to paramters to use
different parameter names for specify and defparams, but this is normal
practice currently because otherwise it is too hard to understand
models.
2) In the PLI 2.0, the vpi_put_value routine can be used to assign to
(annotate to) specify parameters object vpiSpecParam and defparams
object vpiParameter. Cver only allows vpi_put_value to parameters
before simulation begins (during delay elaboration) so that expressions
can be compiled and so delays can be optimized because parameters
may be used in constant delay values, but a simulator could allow
assignment (using expression reevaluation) during simulation.
>>
>> This is the first time I've written something up on this proposal, and
>> feedback, comments and corrections are welcome.
>>
>> Ted Elkind
>> Cadence Design Systems
>> (508) 262-6354
/Steve
-- Steve Meyer Phone: (415) 296-7017 Pragmatic C Software Corp. Fax: (415) 296-0946 220 Montgomery St., Suite 925 email: sjmeyer@crl.com San Francisco, CA 94104
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:42 PDT
and
sponsored by Boyd Technology, Inc.