Re: [Iverilog-devel] Generate scope change in vvp and the VPI API for development

[<by...@nc...>]

Thanks for the examples.

I experimented more with SV on VCS and added the following scope types:

    FST_ST_VCD_STRUCT          = 6,
    FST_ST_VCD_UNION           = 7,
    FST_ST_VCD_CLASS           = 8,
    FST_ST_VCD_INTERFACE       = 9,
    FST_ST_VCD_PACKAGE         = 10,
    FST_ST_VCD_PROGRAM         = 11,

...interesting, I can see SV interfaces dumped by VCS into FSDB now.  (FST looks exactly the same after I convert, so the types store OK in FST.)

I also added the following datatypes:

    FST_VT_SV_BIT              = 22,
    FST_VT_SV_LOGIC            = 23,
    FST_VT_SV_INT              = 24,    /* declare as 31:0 */
    FST_VT_SV_SHORTINT         = 25,    /* declare as 15:0 */
    FST_VT_SV_LONGINT          = 26,    /* declare as 63:0 */
    FST_VT_SV_BYTE             = 27,    /* declare as 7:0  */
    FST_VT_SV_ENUM             = 28,    /* declare as appropriate type range */
    FST_VT_SV_SHORTREAL        = 29,    /* declare and emit same as FST_VT_VCD_REAL */

...all these adds are in SVN and I'm experimenting with them.  Note that for "enum", I need to think about the symbolic/named encodings as the same enum can be redefined in different scopes.  For now I'm going to punt on the string encodings as I don't want to have a simulator emit the strings for every declaration of a SV enum variable, or have to emit the enum dictionary inside a scope, etc.  This is going to require some thought.

The shortreal type is currently treated internally as real (this might change) as I don't believe there are any float values that can't be respresented exactly as doubles.  (I don't know if there are any exotic NaN conditions that break that.)

All of the above said, gtkwave is moving along as being able to correlate against what an existing implementation does helps a lot.

-Tony