RE: EXTERNAL: [vhdl-200x] A compromise about modular type, boolean operations, integers...

There is still another alternative:

For signals, we can create modular integers today, using a resolution function.

We can expand the language in the following two ways for an easy to use, comprehensive modular integer data type.

1) Apply resolution functions to variables (single-driver by definition). 

2) Simplify invocation of an anonymous generic package with generic map as a prefix:

variable my_mod4 : ieee.modulo(modulus=>4).modular;

Where modulo is a package that defines a resolved subtype modular, with modulus defined by the package generic.

User-defined resolution functions could handle non-zero-based modular types.

Resolution functions can also be defined to automatically resize slv/signed/unsigned. 

Unfortunately, automatically resizing ufixed/sfixed would require specification of how the array of driven values is constructed for passing to the resolution function.

Why should we have to define such things in the language, when with a few simple changes, we can do so much more in code?

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX


-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of whygee@f-cpu.org
Sent: Wednesday, October 22, 2014 2:11 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: [vhdl-200x] A compromise about modular type, boolean operations, integers...

Hello again.

While discussing off-list, I listed the pros and cons of the 2 approaches discussed so far :

  * direct support by the integer type :
      - fast and easy to develop, maybe a few hundreds of lines
          of source code added to a simulator like GHDL (I don't
         know for the big professionnal software but it is a small
         incremental addition). A few days of coding, not much more
         to test, fast to deliver.
      - the range can create problems, we don't even know how many bits
         are handled ("at least 31, most likely 32, maybe 64" ?)

  * the new "modular" type
      - solves all the range problems, clean user code thanks to
          the masks and wrap-around performed under the hood.
      - introducing a new type means an order of magnitude more work,
          which is even slower because of all the legacy code and decades-old
          coding habits... So it's much less likely to appear and be used
          in a decent timeframe.

Then it struck me.
I don't know if this was mentioned before but the modular system works almost like the 'range system. In fact, it is very similar, and it differs only by wrapping around instead of trapping. So my compromise proposal requires two simultaneous, low-to-medium complexity modifications :

  A) Let the integer type support
not/and/or/xor/nand/nor/xnor/sll/sla/srl/sra/rol/ror
      just as it supports +, - etc. Eventually issue a warning that the user
      is shooting itself in the foot because the data size is not portable.

  B) Create a new behaviour (not type) by reusing all the code of "range".
      call it "modulo" or "modular" instead of "range", and when there is overflow,
      instead of issuing an error, wrap around. This is just a fork of an
      existing core feature of the language.

These two things, combined, should bring all the required safety and features while keeping the total overhead (size, work, time, acceptance) low.
It's also "future proof" since it would not require a rewrite when "universal integers" are implemented.


I suppose that inheritance of the range system means that modulo
must support lower bounds that are not zero, but we can decide 
otherwise.


Did I miss another caveat ?


YG

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.