[sv-ec] Re: [sv-dc] Collapsing semantics for user-defined composite nets

My view is that resolution should always be done flat across all drivers (in agreement with Jim) since that's the only thing that works for hardware modeling. Marking a module's usage as input or output is really an orthogonal issue, and is probably specific to the driver/receiver type - i.e. if you have a "logic" driver you would expect it to be marked "output", but some parasitic capacitance (Thevenin) in (say) a submodule on the same net would be marked "inout".

So I would say enforcement of direction is an attribute of the type, and should be left up to the user (for user-defined types).

In my opinion language constructs that changes behavior depending on where they are placed or dissociated attributes should be avoided at all costs, i.e. using "input" or "output" on a port should have no effect on how resolution is performed, and attaching a module above or below another module in the hierarchy should behave the same (e.g. a parasitic capacitance).

Kev.

On 04/07/2011 09:09 PM, Lear, Jim wrote:
> Hi Gordon,
> I've exchanged some email with Scott regarding this, and I'm not sure if you or anyone else got a copy.
>
> The best option, in my opinion, is to collapse everything, including inputs and outputs. Having non-collapsed nets can introduce unintended consequences. If input and output directions are strictly enforced, collapsing all nets should be possible.
>
> Below is an example of when not collapsing on an output can cause a problem for an averaging RF. Starting from the bottom of the hierarchy, baaa drives an output, 'a', whose type is resolved with an averaging function. Baaa drives a value of 1. Sub-block baa instantiates baaa and also drives 'a' with 0. Partitioning at this level will result in the output of baa being 0.5. baa then is instantiated in ba which drives 'a' with a 1. With baa driving a 0.5 and ba driving a 1.0, we get 0.75. However, a resolution over a collapsed net will result in a value of 2/3.
>
> 1 block ba(output a)
> 2 a<=1;
> 3 sub-block baa(output a);
> 4 a<=0.0;
> 5 sub-block baaa(output a);
> 6 a<=1.0;
>
> When an input is driven from within a module, one is violating or attempting to violate the direction of the port. Allowing this to be done will split the net or violate the direction. One can always explicitly create a local net and assign it to the value of the input port, if one wishes to split nets.
>
> Similarly, when one reads an output port, one is either reading a value that differs from the outside value, or one is attempting to violate the direction of the port. Again, allowing this will split the net or violate the direction. A local net can be explicitly created and the output port can be assigned the value of the local net, if one wants split nets and to read the value that is driven out of the block.
>
> If input writing and output reading is strictly forbidden, then we can and should collapse inputs, outputs, and inouts. Partitioning of nets can be done explicitly by the programmer, if desired. Strictly enforcing direction is key.
>
> I believe this strict enforcement is done in VHDL, so I'm surprised that nets weren't universally collapsed. I always went through the schematics and converted any ports that were Thevenin types to bi-directional because the directional enforcement could trip me up down the hierarchy. Some little sub-block deep in the hierarchy would have an input port attached to a net that was generally an output. Furthermore, Thevenin devices such as resistors have to "see" what external values are driven on nets so inouts were generally the only option. Analog designers like using port directions even though electrical nets really have no direction, so it ends up impacting and their schematics.
>
> In fact, the strictness was a bit of a nuisance. On several occasions I wished to read the value I was driving on an output net, requiring an explicitly created internal net holding the driven value that could be read. The output net was then assigned the value of the internal net.
>
> Ironically, completely eliminating the directionality of ports creates a condition in which all nets can be collapsed. Everything is implicitly an inout. It's only when directionality is haphazardly enforced will partitioning be required. Partitioning becomes necessary when, for example, one can write to an input port but the driven input port does not modify the external net.
>
> Kindest Regards,
> Jim Lear
> Cirrus Logic
> (512) 851-4612
> (512) 293-7248 (mobile)
>
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Thursday, April 07, 2011 5:49 PM
> To: sv-bc; SV_EC List; sv-dc@eda.org
> Cc: Little Scott-B11206; Vreugdenhil, Gordon
> Subject: [sv-dc] Collapsing semantics for user-defined composite nets
>
>
> I'm sending this out broadly to gather input regarding some decisions that the SV-DC committee needs to make regarding collapsing semantics and implications of that for user-defined composite nets.
>
> If you have input and due to participation rules cannot respond to the reflector, you can respond directly with feedback to either Scott or myself (both cc'd here).
>
> Background
>
> The basic mandate of SV-DC is to propose enhancements to SV to allow for more flexible pure digital models which can more reasonably approximate analog subsystems. As part of that work, SV-DC is first proposing extensions to allow "atomic" composite nets and user defined resolution functions for such nets. This is conceptually similar to VHDL's composite signal support with user defined resolution.
>
> Current status
>
> There is a reasonable level of consensus on the basics of the proposal including how atomic composite nets and resolution functions are to be defined. There is also consensus that such nets should collapse across inout port connections. This is important to make a requirement since user-define resolution functions might often be non-associative and require all drivers to be presented in order to correctly compute a resolved value on the net.
>
> The main question within the committee is whether collapsing should be required across input and output ports as well. Doing so would be at least philosophically more consistent with collapsing expectations in existing verilog. However, requiring input and output ports to not collapse would provide a second form of resolution under (indirect) user control -- full collapsed driver presentation for inout connected nets and a more hierarchical segmented approach (similar to VHDL) when input or output port boundaries are encountered.
>
> While there are certainly resolution function definitions which could demonstrate the difference with a hierarchical resolution (such as a simple "average" taking the sum of driven values divided by the number of drivers), it is not clear whether there are any situations in which hierarchical resolution would in fact be semantically preferable to the fully collapsed view. If there is not, it would likely be preferable to not bother supporting a "hierarchical"
> resolution flow via port modes and simply require full collapsing in all cases.
>
> This is not a trivial decision as it impacts future compatibility no matter what we do and also potentially impacts discussions regarding alignment of Verilog-AMS and SV. We are talking directly to the Verilog-AMS committee as well, but wanted to attempt to have as broad an audience as possible.
>
> The current proposal can be review via mantis at:
> http://www.eda.org/svdb/view.php?id=3398
>
> If you do have feedback or would like clarifications, please feel free to contact me (or Scott) and we can coordinate discussion.
>
> For longer discussion responses, it is likely better to just respond to sv-dc in order to reduce noise in sv-ec/sv-bc. Those who would like to monitor any discussion should probably watch the sv-dc archive.
>
> Thanks all.
>
> Gord.
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.