Re: [Iverilog-devel] VVP Performance boots

[Cary R. <cy...@ya...>]

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> All the uses of the tables in tables.cc should be handled
> so that
> they are independent of the vvp_bit4_t encoding. I manually
> map
> vvp_bit4_t objects to bit pairs like are expected in the
> tables.
> Or at least I *think* I got it every where the hex and oct
> tables
> in tables.cc are used. Those are all the tables that are
> left
> in tables.cc.
> 
> Note that tables.cc is generated by draw_tt.c
> 
> As for all the bit pattern references in
> vpi_vthr_vector.cc, I
> thought I got them all, but I can see that I missed a few
> yet.
> I would really like to change those last bits so that they
> do
> not in any way depend on vvp_bit4_t encoding. I would
> rather
> keep all code that depends on vvp_bit4_t encoding in the
> vvp_net.h
> and vvp_net.cc files, if possible. If that means putting
> new map
> arrays in vvp_net.h, that's OK I think.
> 
> For example, I see a few remaining cases of expressions of
> the
> form ("01xz"[foo]) where foo is a vvp_bit4_t.
> Better to bury
> those as macros in vvp_net.h.

OK this is yours to fix. Once you fix the above string scanmem3 passes correctly. I saw some strange aval/bval stuff in vpi_memory.cc, vpi_signal.cc and vpi_vthr_vector.cc. All this is related to X vs Z values.

Adding a bin_digits to table.cc would also help encapsulate this. There are also a few places where the oct_digits array is incorrectly given size 256 instead of 64.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ