Re: [myhdl-list] essay about integer arithmetic

[Andrew L. <bs...@al...>]

Jan Decaluwe wrote:
> This is an essay that I wanted to write for a long time.
> It describes what I think is wrong with integer arithmetic
> in VHDL and Verilog, and why MyHDL provides a solution.
> 
> Before releasing it to the general public, I'm interested
> to hear what you think about it.
> 
>     http://www.jandecaluwe.com/hdldesign/counting.html

The essay sums up some of my gripes about the mishmash that is the whole 
abstract behavior of numbers problem.  Nicely done.  I know that I'll 
point more than a few newbies at it.


I do have a bit of a gripe about statements like:
"This situation would not persist without the widespread support of the 
designer community."

Ummmmm, no.  Most of the designers I know of hate the way a *lot* of 
things are done in Verilog and VHDL.  Would we be using MyHDL if that 
were not the case?  ;)  However, an individual designer has very limited 
options to push back into these standards.  See SystemVerilog, for 
example.  EDA vendors have a high incentive and large resources to 
push/implement what is *profitable* to them--usefulness to the the user 
is an orthogonal consideration.


However, if we're talking about abstract behavior of numbers, how about 
some fixed-point support?  One of the nice things about VHDL is the 
ability to specify negative indicies that align with negative powers of 
2.  Verilog doesn't (or at least didn't) provide even this level of support.

Writing, say, a delta-sigma modulator in any HDL language is kind of a 
pain because we don't have an abstract "fixed point number" that you can 
assert against.  Adding extra bits at either end to cover different 
issues (Did it overflow?  I need more integer bits.  Is the error too 
large?  I need more fractional bits.) is a pain when it interacts with 
sign bits.


Unrelated note: I *STILL* hate c.next = <some expression>

The fact that c = <some expression> often silently does the wrong thing 
when you really meant c.next = <some expression> is very un-Pythonic.

Did Python 3K enable some form of introspection that could do something 
about this?

-a