[sv-bc] Re: [sv-ec] Errata: Complex Data Types of Wires

Some of the issues you raise overlap with the issues of combining
Verilog-AMS with SystemVerilog. One of the things that needs to be added
is a way of differentiating physical wires from logical connection,
e.g. a real variable can be either a 64-wire bus or a it can represent
the voltage on a single wire (AMS has wreal to denote the latter). The
difference is important because resolution needs to be performed on a
per-physical-wire basis.

The mixing of analog and digital behavior on a single (physical) wire
is a special case of resolution, the general case extension of the
algorithm used in AMS is:

    Convert all drivers to the type/domain of highest accuracy, resolve
    converted values, convert result back to receivers.

To make that work for SystemVerilog you need to have some idea of which
types are more accurate and how to convert between them.

Other functionality in AMS can be extended to handle bidirectional
component modeling for user defined types.

Note: VHDL does this stuff badly since it doesn't differentiate between
physical and logical connection and resolution is not performed flat.

Kev.

Jonathan Bradford;Freiburg wrote:

>
> Complex Data Types of Wires
>
>
> Motivation
>
>
> This is a request based on usage of System Verilog for an extension to
> System Verilog for accessing wires with complex data structures
> implied by their driving registers or data destinations.
> The examples have been modified to the proposed syntax in the summary.
>
> In System Verilog the interface can have signals declared as wires or
> variables.
>
> The wires can be declared as vectors or vectors of vectors or arrays
> of vectors, reflecting whether they are packed or unpacked data types.
> The wire can also be of various resolved types,
> such as tri1 (pullup) or trireg (holding) etc. The wire can also be in
> signed or unsigned (default) arithmetic.
>
> The variables can also be declared as vectors and vectors of vectors
> and arrays of vectors. They can also be defined as many other data
> types, as packed types for implementation such as
> structures etc, or unpacked for verification such as dynamic arrays
> etc. Again these may have attributes for signed or unsigned arithmetic
> and packed or unpacked data storage.
>
> But there is no resolution capability. i.e. they may be written to
> discretely by assignments in procedural code or a single structural
> assignment (continuous or connectivity).
>
> When implementing an RTL design it is safe to model states in the
> design using variables in the interfaces, so long as there is a single
> direction of signal flow and no multiple drivers.
>
> There are a number of constructs in System Verilog language to ensure
> this, such as interface modports with output statements for the
> variable to be written and the use of always_ff to
> constrict the assignments to these interface variables. These
> constructs restrict structural and procedural assignment to the state
> variables and implicate registered outputs in the single
> driving blocks.
>
> This allows the use of variables with complex data definitions such as
> structs etc in RTL implementation.
>
> However there are scenarios in RTL implementation where it is
> necessary to allow bidirectionality or at least multiple drivers (and
> enables) onto a common bus.
>
> This implies that only wires can be used for these interface signals.
> The driving variables are then explicitly assigned to, from the
> modules interfaced to the bus.
>
> But wires cannot be defined with such complex data structures as
> variables. Hence once a value is on the wires in the bus in the
> interface, it is not possible to use those signal values as easily
> as in the original variables. This is especially the case for structs.
>
> There are two main problems
>
> o wires containing values driven by variables of complex type must be
> correctly sized, throughout the interface hierarchy.
>
> o components of values on wires implied by the 'shape' of the driving
> variable need to be made accessible wrt those `shapes' rather than
> the explicit 'shape' of the wire.
>
>
> i.e.
>
> // a register driving the bus might be :-
>
> typedef struct packed { logic ecc; logic [7:0] data; } MemLoc;
>
> MemLoc mem_r;
>
> // whereas the signal in the interface - driven by multiple modules
> (enabled) :-
>
> wire [8:0] memsig;
>
> modport driver (inout [8:0] memsig);
>
> // a user of the interface signal needs to know where ecc and data
> are !
>
> my_ecc = memsig[8];
> my_data = memsig[7:0];
>
> If the definition of the structure were changed, the design hierarchy
> must be worked through to change all these structural references to
> the wires that transport signal values.
>
> One way to do this particular example is to use casting:
>
> my_ecc = MemLoc'(memsig).ecc
> my_data = MemLoc'(memsig).data
>
> However a cast cannot be an lvalue or an output port, so a more
> general facility is needed. A language extension to allow a packed
> data type to be associated with a wire vector can provide
> this generality and reduce the typing:
>
> The structure must be packed. The structure can be either 4-state or
> 2-state, but 4-state is recommended to maintain compatibility between
> variables and wires of the same type. There is
> one wire for each bit or logic, and the wire can have the normal range
> of strength values. The wire can be of type tri1, tri0, trireg,
> supply0, supply1 etc.
>
> Example
>
> // wire and interface definition
>
> wire <MemLoc> memsig;
>
> modport driver (inout <MemLoc> memsig);
>
> // this is similar to
> // wire [$bits(MemLoc)-1:0] memsig;
>
> // wire element of `shape` access
>
> my_ecc = memsig.ecc;
>
> my_data = memsig.data;
>
> assign memsig = mem_r;
>
> assign memsig.ecc = ^mem_r.data;
>
> Hence if the structure MemLoc changes, the slice access routines for
> the wire signals remain unchanged.
>
> In reality there is nothing changed in the behaviour of variables and
> wires, only in how their content is perceived.
>
> This perception of the shape is also independent of the driver, as
> there can be multiple drivers of the aggregate wire. The same wire may
> therefore be perceived in multiple ways :-
>
> typedef struct packed {logic [1:0] ignore, logic [6:0] ascii} CharLoc;
>
> my_data [7:0] = memsig.data;
> my_data [7:0] = CharLoc'(memsig).ascii;
> // msb becomes 0
>
> typedef union packed {MemLoc ML; CharLoc CL;} AnyLoc;
> AnyLoc anysig;
>
> my_data [7:0] = {anysig.ML.ecc, anysig.CL.ascii};
>
> Furthermore if the structure definition contains attributes such as
> signed for the arithmetic of its members, this is maintained for a
> member access, but not for the corresponding slice.
>
> typedef struct packed { logic signed [7:0] a; logic [7:0] b; } Slog;
>
> wire <Slog> slog_sig;
>
> if (slog_sig.a >>1 == slog_sig[15:8] >>1)
> $display ("Not all the time, No");
>
>
> The problem with respect to overloaded operators can be exemplified by
> considering a user defined structure to represent a fixed point number
> with fields for mantissa and exponent.
> Currently when a wire is used as an argument to such an operator,
> there is no way to infer that the value within the wire should be the
> mantissa and exponent as opposed to the integral integer
> value of a wire. However this is resolved when a wire has a structure
> definition.
>
>
> Summary
>
> A proposal for a collection of wires to be treated as a structure, as
> explained above.
>
> This proposal is to allow a type identifier to be used instead of
> signing and packed dimensions in net declarations.
>
>
> net declaration ::= net_type_or_trireg
> [ drive_strength | charge_strength ]
> [ vectored | scalared ]
> [ signing ] { packed_dimension } [ delay3 ]
> list_of_net_decl_assignments
> | net_type_or_trireg
> [ drive_strength | charge_strength ]
> [ vectored | scalared ]
> < type_identifier > [ delay3 ]
> list_of_net_decl_assignments ;
>
>
> The type_identifier should be limited to packed types.
>
> The < > characters are used to remove ambiguity.
>
>
>
>--
>
>________________________________________________________________________________
>
> /\ Jonathan Bradford mailto:bradford@micronas.com
> \/
> /\/\ MICRONAS GmbH http://www.micronas.com
> /\/\/\
> \/\/\/ Hans-Bunte-Str.19 Tel: +49 (0)761 517 2884
> \/\/ D-79108 Freiburg Fax: +49 (0)761 517 2880
> \/ Germany
>
>

-- 
http://www.grfx.com
mailto:dkc@grfx.com