Subject: Re: DirectC: C layer
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Dec 16 2002 - 12:53:29 PST
Hi all,
here is just some grumbling from a silly SW guy about some details of the header. Not much and not very important.
Andrzej, see this as a honor that I can only critisize such minor details ...
-Michael
Andrzej Litwiniuk wrote:
> "sverilog.h"
> =================
>
> This file contains the following definitions:
>
> /* canonical API representation */
>
> #define sv_0 0
> #define sv_1 1
> #define sv_z 2 /* representation of 4-st scalar z */
> #define sv_x 3 /* representation of 4-st scalar x */
There are several members of our working group discussing about OO features, C++ and others, but nobody is asking why we are still using antique styles like
#define instead of enum's here. I understand that this is similar to PLI/VPI, and as such might be a more compatible solution, but from a software engineering
viewpoint I needed to say this.
So why is this not a typedef'd enum? This could also be used then for -- and compiler provable - definitions of the both types below.
> typedef unsigned char svBit; /* scalar */
> typedef unsigned char svLogic; /* scalar */
> /* 2-state and 4-state vectors, modelled upon PLI's avalue/bvalue */
> #define VEC32_NEEDED(WIDTH) (((WIDTH)+31)>>5)
> typedef unsigned int
> svBitVec32; /* (a chunk of) packed bit array */
>
> typedef struct { unsigned int c; unsigned int d;}
> svLogicVec32; /* (a chunk of) packed logic array */
to be consistent with PLI we should rename c and d to avalue/bvalue
> /* reference to a standalone packed array */
> typedef void* svBitPackedArr;
> typedef void* svLogicPackedArr;
> /* a handle to a generic object (actually, unsized array) */
> typedef void* svHandle;
>
> /* functions for translation between simulator's and canonical representations */
>
> /* s=source, d=destination, w=width */
>
> /* actual <-- canonical */
> void vcPutBitVec32 (svBitPackedArr d, svBitVec32* s, int w);
> void vcPutLogicVec32 (svLogicPackedArr d, svLogicVec32* s, int w);
can we just use the more descriptive names s=source, d=destination, w=width instead of providing them in a comment?
> /* canonical <-- actual */
> void vcGetBitVec32 (svBitVec32* d, svBitPackedArr s, int w);
> void vcGetLogicVec32 (svLogicVec32* d, svLogicPackedArr s, int w);
-as above
> The above functions copy the whole array in either direction. User is responsible for providing the correct width and for allocating an array in the canonical
> representation.
>
> More functions may be added, for accesing individual bits or small (<=32)
> part-selects.
>
> Similarly, functions for converting packed arrays into char* strings (for
> printing) or other way round (for reading) may be provided, like in VCS
> (cf. VCS DirectC.h).
>
> "directc.h"
> ===========
>
> This file provides implementation specific definitions.
> In particular, it defines the macros for specifying variables representing
> SV packed arrays:
>
> #define BIT_PACKED_ARRAY(WIDTH,NAME) ...
> #define LOGIC_PACKED_ARRAY(WIDTH,NAME) ...
>
> (For example, VCS might defined the later macro as follows:
> #define LOGIC_PACKED_ARRAY(WIDTH,NAME) vec32 NAME [ VEC32_NEEDED(WIDTH) ]
> )
Andrzej Litwiniuk wrote: (part2)
> ...
> Several new definitions are added to "sverilog.h" file; in the text below
> those definitions are interspersed with comments and remarks.
> Again, all names are provisional and subject to discussion and improvment.
>
> /* common type for 'bit' and 'logic' scalars.
> Shall we rather have two separate types, say, svScalarBit, svScalarLogic?
> */
> typedef unsigned char svScalar;
As already said, I prefer to have svScalarBit and svScalarLogic. But do we need this when we have svBit and svLogic???
What is the difference, I currently don't see it anymore ???
> /* functions for bit-select and limited width part-select */
>
> /* Packed arrays are assumed to be indexed n-1:0,
> where 0 is the index of least significant bit */
>
> /* functions for bit-select */
> /* s=source, d=destination, i=bit-index */
>
> svScalar svGetSelectBit(svBitPackedArr s, int i);
> svScalar svGetSelectLogic(svLogicPackedArr s, int i);
>
> void svPutSelectBit(svBitPackedArr d, int i, scalar s);
> void svPutSelectLogic(svLogicPackedArr d, int i, scalar s);
>
> /*
> * functions for part-select
> *
> * a narrow (<=32 bits) part select is copied between
> * the implementation representation and a single chunk of
> * canonical representation
> *
> * s=source, d=destination, i=starting bit index, w=width
> * like for variable part selects; limitations: w <= 32
> */
>
> Please note that for the sake of symmetry a canonical representation
> (i.e. an array) is used both for 'bit' and 'logic', though a simpler
> int could be used for 'bit' part selects <= 32-bit.
>
> void svGetPartSelectBit(svBitVec32* d, svBitPackedArr s, int i, int w);
> void svPartGetSelectLogic(svLogicVec32* d, svLogicPackedArr s, int i, int w);
>
> /*
> * for 'bit' type a part select <= 32-bit is really an int
> * so a function could be used:
> * int svGetPartSelectBit(svBitPackedArr s, int i, int w);
> */
>
> void svPutPartSelectBit(svBitPackedArr d, svBitPackedArr s, int i, int w);
> void svPutPartSelectLogic(svLogicPackedArr d, svLogicPackedArr s, int i, int w);
>
> /*
> * for 'bit' type a part select <= 32-bit is really an int
> * so simpler arg could be used:
> * svPutPartSelectBit(svBitPackedArr d, int up_to_32-bits, int i, int w);
> */
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 13:25:25 PST