Subject: Re: Verilog++ 6th committee meeting
From: Peter Flake (flake@co-design.com)
Date: Mon Sep 10 2001 - 02:31:07 PDT
All,
I am still on vacation so I have not been able to do all the
actions. However here are the replies to a couple of points.
At 11:13 AM 8/27/01 -0700, Simon J. Davidmann wrote:
>PF p53 - need modport discussed more - to explain what it really is. and
>why the two examples do have different. ie "master and slave are declared
>as modports because..." needs more discussion on the rationale of modports
>(more than just what they are - why they are needed).
The purpose of a modport declaration is to provide the information that
would normally be in a module header. This consists of which variables or
wires of the interface are used by this module, and in what
direction. Such information allows the module which uses such a modport to
be synthesized without having to do a global connectivity analysis of the
design.
>Question on implicit types
>--------------------------------------
>does there need there to be the ability to have implicit nets extended to
>other data types
>do we need implicit variables? - but they need to be hierarchically
>defined, eg some blocks undefined things could need to be wires, some times
>reals, etc
>Peter Flake - did think about it - but problem is that he feels that it
>breaks existing verilog (in some cases)
>Mike McNamara - suggests leave implicit nets alone, and if needed add
>something new? - best to leave it into the schematic tool...
>Cliff Cummings will send out his paper on this
>Peter Flake - we could have "infer type" to be added to the
>`default_nettype directive or something better - talk with David Smith and
>then come up with some proposal.
The biggest problem with implicit types is the situation where types are
passed both down the hierarchy and up it.
Types can be passed down with parameters and with interfaces. If types can
be passed upwards by connectivity, it becomes very difficult to determine
an elaboration order. In fact it is possible to construct cyclic type
definitions across the hierarchy using constant functions such as $bits.
So the real problem is having untyped port declarations combined with
untyped connections.
A style of using dynamic types could be adopted for port declarations and
implicit connections, but this would be restrictive, inefficient, and only
apply to variables.
>Other Issues
>-------------------
>Cliff Cummings - to look at what the issue is with generate statement to do
>with passing in parameter - will send us all a note on this
>SS: - need to be able to generate the ports of a module?? is a requirement
>- will try and find out what the real requirement is
> could generate loop create port lists. it is anomalous that port
> lists
>cannot be in the generate loop.
>PF - to think on these
Syntactically I would suggest using a triple dot like C varargs in the port
list, and then putting the port declarations as module items in the
generate loop. However this would probably be quite an effort to implement.
Peter.
This archive was generated by hypermail 2b28 : Mon Sep 10 2001 - 02:31:40 PDT