From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Wed Jan 06 1999 - 09:05:35 PST
BAD MSG:
Hi Mac,
-Lines: 198
Content-Type: text/plain; charset="us-ascii"
Content-Length: 6103
X-Status: $$$$
X-UID: 0000000767
Status: RO
We are not proposing any of the class/inheritance/hierarchy stuff that was
proposed in '95. We are simply proposing attributes as a placeholder for
information about something in the Verilog. By the way, the value assigned
to an attribute may be a parameter (the BNF stops at "constant_expression"
but that includes parameters), which may be made instance-specific using
defparams if desired.
One may think of these as similar to synthesis pragmas (like one_hot or
whatever), but a bit cleaner in that you don't have to go parsing comments
to find this information. I'm told that for the majority of synthesis
pragmas in VHDL, design compiler actually uses VHDL attributes. Please
correct me if I'm wrong on that.
We expect that much of the use of attributes will be vendor-specific, but
we do want to standardize on the mechanism for including such information
in the Verilog. We may want to standardize on a few attributes (view,
library, maybe even cycle), but we view it as a higher priority to
standardize on the mechanism.
Thanks,
-Tom
At 08:33 AM 1/6/99 -0800, Michael McNamara wrote:
>
>Tom Fitzpatrick writes:
> > Hi All,
> >
> > Attributes are a very useful feature that we are currently using in
> > Verilog-XL, and NC-Verilog. We mostly use them to identify things like
VHDL
> > modules for mixed-language simulation, and identifying modules that may be
> > cycle simulated. These could also be extended to include library and view
> > information with the new config proposal which will be coming out soon.
> > I've included the proposed BNF below.
>
> Attributes were considered for 1364-1995, and then at
>Cadence's suggestion, were removed from the draft. At the time, the
>reasons given were that they suffered from being module specific, not
>instance specific. The base example is that while one might be
>tempted to say:
>
> module foo;
> part (* xloc = 3, yloc = 4 *) p1 (a,b,c);
> part (* xloc = 5, yloc = 2 *) p2 (a,b,c);
> endmodule
>
> to specify instance location (or timing or other instance
>specific information), once the parent module foo is instantiated
>multiple times, this feature no longer works well.
>
> Are you proposing anything over and above the attribute syntax
>of 1995, or is it instead the case that you have found new usefulness
>in the original syntax, given mixed language simulation (be the 'other
>language' VHDL or cycle based Verilog)?
>
> -mac
>
> >
> > module top(b,c);
> > output b;
> > reg clk,a;
> > wire b,c;
> >
> > // instantiate a vhdl module here:
> > vhdlmod vhdlmod(clk,a,b);
> >
> > // instantiate a cycle-sim module here:
> > cyclemod (* const integer cycle = 1; *) cyclemod(clk,a,c);
> > endmodule
> >
> > module vhdlmod(clk,a,b) (* const integer foreign = "VHDL WORKLIB.E:a"; *);
> > input clk,a;
> > output b;
> > ...
> > endmodule
> >
> > We currently only allow for attribute types to be integer, time or real.
> > Since there is no real string type in Verilog, this leads to the 'integer
> > foreign = "string"' syntax above, which some people may think looks
kind of
> > strange. We could extend the type list to include "string".
> >
> > Your questions and comments are welcome.
> > Thanks,
> > -Tom
> >
> >
> > Here's the BNF:
> >
> > This is what an attribute is:
> > <instance_attr> ::= (* <attr_list> *)
> >
> > <attr_list>::
> > ::= <attr><,attr>*
> >
> > <attr>
> > ::= [CONST] <type><attr_spec_list>;
> >
> > <attr_spec_list>
> > ::= <attr_spec><,attr_spec>*
> >
> > <attr_spec>
> > ::= <attr_name> = <value>
> > ||= <attr_name>
> >
> > <value>
> > ::= <constant>
> > ||= <constant_expression>
> >
> > <type>
> > ::=integer
> > ||=time
> > ||=real
> >
> > This is how an attribute is used:
> > variable instances:
> >
> > <type><range>?<instance_attr><instances>+
> > <type>
> > ::= REG
> > ||= TIME
> > ||= INTEGER
> > ||= INPUT
> > ||= OUTPUT
> > ||= INOUT
> >
> > REAL <instance_attr>?<instances>+
> > REALTIME <instance_attr>?<instances>+
> > EVENT <instance_attr>?<events>+
> >
> >
<net_type><strength>?<expandrange>?<delay>?<instance_attr>?<net_expression>;
> > <net_expression>
> > ::= <net_name>
> > ||= <net_name> = <expression>
> >
> > gate and switch instances:
> >
> > <gate_type> [<drive_strength>] [<delay>] [<instance_attr>]
> > <gate_instance>+;
> >
> > module and udp declarations and instantiations:
> >
> > MODULE <module_name> [<port_list>] [<instance_attr>];
> > [<module_item>]
> >
> > ENDMODULE
> >
> > PRIMITIVE <prim_name> ((port_list) [<instance_attr>];
> > <prim_declaration>+
> > [<prim_initialization>]
> > <table_definition>
> > ENDPRIMITIVE
> >
> > Module or udp ports:
> >
> > <port_type> [<range>] [<instance_attr>] <list_of_variables>;
> > <port_type> ::= INPUT
> > ||= OUTPUT
> > ||= INOUT
> >
> > Function and Task declarations and invocations:
> >
> > FUNCTION [<range>] <function_name> [<instance_attr>];
> > <tf_declarations>+
> > [<statement>]
> > ENDFUNCTION
> >
> > TASK <task_name> [<instance_attr>] ;
> > <tf_declarations>+
> > [<statement>]
> > ENDTASK
> >
> > built-in operators:
> >
> > <unary_op> [<instance_attr>] <expression>
> >
> > <expression> <binary_op> [<instance_attr>] <expression>
> >
> > ? [<instance_attr>] <expression> : <expression>
> >
> > ---------------
> > Tom Fitzpatrick
> >
> > Senior Technical Marketing Manager Cadence Design
Systems, Inc.
> > Cycle Simulation Products 270 Billerica Rd.
> > Logic Design and Verification Business Unit Chelmsford, MA 01824
> > x6438 (978)446-6438
>
>
---------------
Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc.
Cycle Simulation Products 270 Billerica Rd.
Logic Design and Verification Business Unit Chelmsford, MA 01824
x6438 (978)446-6438
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:24 PDT
and
sponsored by Boyd Technology, Inc.