Re: attribute: test_port // new text proposal


Subject: Re: attribute: test_port // new text proposal
From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Fri Apr 05 2002 - 05:45:38 PST


>
> Daryl,
> Question: How do you know where in hierachy module will be instantiated?
> Lets say module A has internal wire S used as a test port.
> A is instantiated in B, B in C, C in D.
> A is also instantiated in E, E in F.
> Now what's the name of test port for S?

Let's assume the instance of B is called b, etc.

Well with the current proposal for test_port, there's no way of knowing which
of the exposed output ports is connected to d.c.b.a.S and which to f.e.a.S -
you suggested this would be tool dependent. On reflection I think that this
makes writing even vaguely portable verilog difficult.

With my previous suggestion they would be always be available as
escaped-identifier nets \d.c.b.a.S and \f.e.a.S.

Can someone say whether or not the standard can specify the use of escaped
identifiers in an output netlist?? If the netlist is verilog it's ok, but I
guess it may not be practical for all output formats??

Perhaps the standard should specify the port connection names to be created in
the same way as my suggested escaped identifiers.

> My other concern though is:
> Lets say module A has internal wire S used as a test port.
> S has a keep and test_port attribute.
> S is connect to regA, which is optimized out by synthesis tool.

Sorry - you mean the equivalent of assign S = regA; I assume

> S gets connect to test port, but is really internally connected to
> nothing!
> I guess vendors should report this as a warning.

If it's a test-port-as-exposed-output then it should probably be treated
exactly the same as if a user had a normal output port wire which they'd
connected to regA.
Once a net/reg is attributed test_port it is implicitly added to the port list
and treated as any other port.

A simple (!) fix is to say that:

----- begin suggested text for standard -----
Objects attributed test_port are implicitly added to the end of the port list
in the order in which they are so attributed, and are treated as though they
had been explicitly declared as output ports.
The test_ports of child modules are added after a module's own test_port
objects, in the order in which the child modules are instantiated.
Each test port is given a port_identifier which is an escaped identifier
formed by prefixing the hierarchical name of the test_port object within the
module with a backslash.
----- end suggested text for standard -----

This would make the number and position of test port outputs constant.
I'd like to propose this test for inclusion in the standard. Sorry I can't
make the conference call!

e.g with

module foo(.one(bar), .two(ban));
input bar;
output ban;

(* synthesis, test_port *) reg zoo;
wire bar;
(* synthesis, test_port *) reg ban;

...
endmodule;

the instantiations

foo Fbyorder(a1,b1,c1,d1);
foo Fbyname(.one (a2), .two (b2), .\ban (d2), .\zoo (c2));

connect
c1 to Fbyorder.zoo
d1 to Fbyorder.ban
c2 to Fbyname.zoo
d2 to Fbyname.ban

If they occur in a module "top" (which has a single input port .clk(clk)) then

top Tbyname(.clk(clk), .\Fbyname.zoo (n1), .\Fbyorder.zoo(m1));
top Tbyorder(clk, m2, , n2, );

would connect
m1 to Tbyname.Fbyorder.zoo
n1 to Tbyname.Fbyname.zoo
m2 to Tbyorder.Fbyorder.zoo
n2 to Tbyorder.Fbyname.zoo

Hope I got my syntax right. It's a bit eye-boggling, but it's predictable ;)

cheers
Daryl

Compile Verilog to C at www.tenisontech.com

> BEN
>
> > 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?
>



This archive was generated by hypermail 2b28 : Fri Apr 05 2002 - 05:49:47 PST