Re: [myhdl-list] intbv.saturate, intbv.wrap

[Jan D. <ja...@ja...>]

Thomas Traber wrote:

> Jan suggested this feature request 
<https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group_id=91207> here on the list.

It would be useful if anyone that is both doing DSP development and
using MyHDL takes a look at that feature request, and the discussions.

> I suppose "wrapping around" is the default behaviour of any logic.

I see it differently. Wrap around is the behavior of a typical hardware
implementation. Therefore, most hardware designers think that this
is somehow "normal" or even useful. Which is why Verilog regs and
VHDL signed/unsigned behave the way I do.

One of the goals of the intbv type is to show that there is a better way.
It wants to be an int in the first place. If you need wrap-around, it
insists to do this explicitly with a test or a modulo operation.

>  So to implement it checkBounds just need to be inhibited.

As a consequence of the above, no. If you inhibit that test, the intbv
acts as a Python int.

>
> BTW, I tried the follwing:
>
> ---------------------------
> class analogbv(intbv):
>
>     def _checkBounds():
>         return
>
> ---------------------------
>
> It does not work, because in _Signal.py _checkBounds from _intbv.py is used and not my own 
_ceckBounds. It is not easy to add new types to myhdl.


The culprit is the intbv class, not Signal.

The intbv operations return new intbv instances, not instances of the subclass.
It won't work well with subclassing currently. I know I suggested this to you
before. It's not a good idea. Sorry.

Let's try to clarify this. What is your goal - modeling, or also
conversion, synthesis and implementation?

If it's only modeling, there's little need to have this discussion. Just
use your own types. MyHDL - the modelling language for event-driven
hardware systems - is intended to be fully generic. In particular, the Signal
class is intended to work with any data type, not just MyHDL-defined types.

If it's also conversion and implementation, I think you'll have to lower
your expectations drastically. There are a lot of severe restrictions,
similar to restrictions on synthesizable HDL code.

The intbv class is in the middle between the high-level view and the
implementation-oriented view. It's the work-horse for implementation-oriented
code, but it attempts to be higher level than what other HDLs offer for
this purpose.

Now, suppose intbv subclassing would work and you define a subclass with
different behavior. What you cannot expect that this will somehow
magically make it to equivalent converted Verilog. All MyHDL behavior
that is supported by the conversion tools has to be mapped explicitly
(and painstakingly) in them.

Again, I don't know if DSP languages such as Simulink do this (conversion
and implementation), and if they do, it doesn't seem trivial (in general,
for the whole set of operations).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com