Subject: Re: attribute: test_port // more comments
From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Thu Apr 04 2002 - 03:44:49 PST
I agree with your comment that this is a tool issue. As such even the notes
may be superfluous and I'm happy with your answer.
I think I was wondering if there was some uniform way of making connections to
test ports more explicit. If each test port could somehow be associated with
its hierarchical name in the netlist, for example, then connections could be
made to specific ports more easily (across all tools).
Maybe it's possible to require a reg/net attributed "test_port" (or just
"keep") to be available as an escaped identifier generated from the
hierarchical name?
eg
(* synthesis, test_port *) reg foo;
inside module bar would result in an escaped identifer
\bar.foo
representing the reg object.
Or is escaped identifier not permissible in a netlist?
Or does this step on tools' toes by over-specifying naming conventions?
Users could then have
`ifdef SYNTHESIS
`define BARFOO \bar.foo
`else
`define BARFOO bar.foo
`endif
followed by accesses to `BARFOO in testbenches
or
`ifndef SYNTHESIS
wire \bar.foo = bar.foo;
`endif
followed by accesses to \bar.foo
Maybe this would be useful for keep instead, as it needs no ports?
cheers
Daryl
Compile Verilog to C at www.tenisontech.com
> In a message dated 4/3/02 4:38:32 AM Pacific Standard Time,
> Daryl.Stewart@cl.cam.ac.uk writes:
> > The description of test_port does not explain the order in which the new
> > ports
> > are added, or whether they are given .-names for connection, and if so what
> >
> > the .-names are.
>
> Good question, but isn't that a tool issue rather than a spec issue?
> I think we could add a note that says something like:
> " The name of the test port shall be determined by the synthesis tool, and is
> not specificed in this document".
>
>
> > ADD: >
> > > If a test ported attributed object is optimized out, that object shall
> > not be
> > > mapped onto a port, unless there is a "keep" attribute (see section 6.1.4
> > d).
> >
> > Assuming the optimization-out of an object may change between
> > synthesis-runs, is there a way to tell when your test port disappears?
> Good question, but isn't that a tool issue rather than a spec issue?
> I think we could add a note that says something like:
> " The appearance or omission of a test port as a result of optimization may
> be reported by the synthesis tool, and is not specificed in this document".
>
> > A pathological case is where there are two submodules:
> > In my first synthesis, the first module produces a test-port, while the
> > other does not, due to an optimisation.
> > After changing my code, the next synthesis run optimises the first module's
> > port away, but this time the second module's is not.
> > Now the parent module still has a test-port added to it, but how do I know
> > where it came from??
> >
> Again, this is a tool issue, and above note takes care of that.
>
This archive was generated by hypermail 2b28 : Thu Apr 04 2002 - 03:48:13 PST