Subject: Re: Another attribute: test_port
From: VhdlCohen@aol.com
Date: Thu Mar 28 2002 - 10:38:43 PST
A few comments:
Change from:
"In the case where the reg infers a storage device, it is the output of the
storage device that shall be used to create the test port."
TO:
Only objects that represents bits or bit vectors shall be used to create the
test port.
Rationale: It might be difficult for a tool to determine the "output of a
storage device".
ADD:
If a test ported attributed object is optimized out, that object shall not be
mapped onto a port.
In a message dated 3/28/02 12:14:28 AM Pacific Standard Time, kal@dspia.com
writes:
> I really like this attribute as it completely removes the need for
> synthesizable hierarchical assignments. But I'd like to change it a little
> bit. I think we should put it only at the top level where the final port
> needs to be created. I think it would be nice to be able to annotate a
> hierarchical assign statement at the top with test_port attribute so that
> there is no need for an ifdef and one doesn't necessarily get multiple test
> ports for multiple instantiations of the same module. And when one does a
> uniquify only one of the instantiations get the port which reflects what
> the hieararchical assign requires. This attribute effectively forces the
> synthesizer to create all the necessary ports in the gatelevel which are
> required by the hieararchical assign.
>
> Muzaffer Kal 408.654.9573
> DSPIA Inc.
BEN: I don't believe that we allowed the synthesis of objects with
hierarchical path definitions, such as:
q <= instancex.a.b.c;
Muzaffer's suggestion does make sense, but I see several issues with it:
1. Attributes are attached to objects when they are declared. That causes a
problem.
2. Using hierarchical definitions is not allowed. It it were, then we could
attach attribute test_port to object q, and do something like:
assign q = instancex.a.b.c;
3. Users may want the access to the test ports for each instantiated
instances because each one behaves independently.
Bottom line, I like the way the test_port attribute is currently defined,
with the above clarifications.
> <A HREF="http://www.dspia.com/">http://www.dspia.com>
> ASIC/FPGA design/verification consulting specializing in DSP algorithm
> implementations
> -----Original Message-----
> From: owner-vlog-synth@server.eda.org
> [mailto:owner-vlog-synth@server.eda.org]On Behalf Of VhdlCohen@aol.com
> Sent: Wednesday, March 27, 2002 9:07 AM
> To: jbhasker@cadence.com; vlog-synth@server.eda.org
> Subject: Re: Another attribute: test_port
>
>
>
>
> >> Bhasker,
>> I like your write up and the notes!
>> FYI, can use the ifdef to use the path to read internal signals if RTL, or
>> test port if gate level.
>> Don't know if you want to add that note.
>> Ben
>> --
>> In a message dated 3/27/02 8:53:29 AM Pacific Standard Time,
>> jbhasker@cadence.com writes:
>>
>> >>> (* synthesis, test_port [ =<optional_value> ] *)
>>>
>>> This attribute shall apply to a net or a reg.
>>>
>>> The presence of this attribute preserves the net or the reg for probing
>>> and
>>> shall cause it to appear as an output port (a test port) in
>>> the module it appears. If a module with a test port
>>> is instantiated in another module, a new test port
>>> shall also be created (one for each instance) in the parent module.
>>>
>>> In the case where the reg infers a storage device, it is the output of
>>> the
>>> storage device that shall be used to create the test port.
>>>
>>> Note: This attribute is needed for the verification of gate-level model
>>> designs at the "grey-box" level where internal signals may be needed for
>>> triggering of events in verifier (example, the occurrence of a
>>> simulatation push/pop of a fifo). It may also needed for hardware
>>> debugging when a difficult bug occurs.
>>>
>>> Note: Since this attribute creates additional ports in the synthesized
>>> logic,
>>> testbench reuse may be an issue.
>>>
>>
>
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
<A HREF="http://www.vhdlcohen.com/">http://www.vhdlcohen.com/> vhdlcohen@aol.com
Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Thu Mar 28 2002 - 10:42:55 PST