Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Christopher F. <chr...@gm...>]

On 1/29/2013 8:06 AM, Per Karlsson wrote:
> Hm, that would enforce a coding style where every combinatorial cloud must
> be written monolithically. You could never break down a combinatorial
> problem into parts.
>
> I think this is a bad coding style. It makes for unreadable code, and it
> limits the amount of complexity that can be tackled successfully.
> /Per
>

While reviewing the Signal code for the mixed /bool/ and
/intbv[1:]/, I was thinking maybe the Signal object should
be refactored to *not* include the /_setNext/ and /_update/
cases for each type.  But rather have the types provide a
hook.  Currently, this is mainly the /intbv/ type.  But it
will provide a mechanism for user defined modeling types that
can include checks (like the bound check/handle) without
modifying the /Signal/ class.

Instead of the /Signal/ object having a case for each type
it is updating it will check the update for certain attributes

    _sig_set_next(next_val) return next
    _sig_update(next) return val
    _sig_end_sim_cycle()

I am thinking out load here.  Something like this would simplify
the /Signal/ class some but add Signal and Simulation responsibility
to the modeling type.  It would give the user some power to define
checks for custom types she might use in modeling (not conversion,
yet).

This would also give a mechanism to do the deferred check to
the end of the cycle.  But at the cost of extra work to the
simulator, the simulator would have to keep a list of all active
signals in a cycle and then do a final check/walk at the end of
the cycle.  As mentioned this would provide a nice hook for user
defined types and would give a mechanism for the deferred check.

But I have this haunting feeling I am missing something basic and
the error we think is an error might not be?  If we could propose
something like the above as a possible solution.

Regards,
Chris