Subject: Re: Ballot feedback: test_port
From: Steve Golson (sgolson@trilobyte.com)
Date: Tue Jul 16 2002 - 10:28:46 PDT
> One of the comments recd during ballot was to rename the "test_port"
> attribute
> as "probe_point". Here is the exact comment:
>
> "test_port seems to be a misleading name for this functionality.
> probe_point seems to better get to the intent of the attribute, and does not
> lead to user expectation that this affects post production test."
>
> I would like feedback from the WG on whether "probe_point" is a better name
> for
> the attribute or not.
>
> - bhasker
I agree with the comment. I think "test_port" is somewhat misleading.
There is some ambiguity with the word "test" -- does it refer to specific
types of production testing (e.g. scan, JTAG) or is it more general?
VhdlCohen@aol.com wrote:
>
> The other issue with "test_point" is that you lose the notion that the signal
> in question is brought out to a "port".
That's a valid point. However the attribute applies to something which is
*not* a port (not yet, anyway) -- so calling it a "probe_point" actually
makes sense.
> "test_port" seems to better indicate that notion of "bring that signal to a
> 'port' for 'test'.
But it's not necessarily for test, is it? "probe" seems like a better name.
You are "probing" down into the depths of the code, to get at a signal.
> I don't get this concept of "expectation that this affects post production
> tests'".
The commenter thinks that the name "test_port" implies that it has something
to do with the actual manufacturing test.
> Perhaps some can explain that to me. In fact, if I were to activate and keep
> this attribute, no matter what its name is, I'll ave a port for test in the
> final production.
But it's not for test -- not necessarily. It could be for debug, or profiling,
or whatever. It's an ugly hack so you don't have to rewrite your code to bring
out this signal.
> My recomendation: NO CHANGE.
> Ben
I reccommend changing it to "probe_point".
BTW, have any synthesis/simulation vendors commented on this? I think it may
be very difficult to implement. If you are deep down in your hierarchy when
you first encounter the "test_port" attribute, now you have to change the
behavior of all the upper modules which may have already been parsed! Yuck.
defparams do the same thing, and they are deprecated now.
-seg
Steve Golson / Trilobyte Systems / +1.978.369.9669 / sgolson@trilobyte.com
Consulting in: Verilog, Synopsys, patent analysis, reverse engineering
This archive was generated by hypermail 2b28 : Tue Jul 16 2002 - 10:39:49 PDT