myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

Jan and All,

Due to IRL work, I will need a lot more time to produce any serious scientific
results in response to some requests made here. I just do not have time right
now, whereas Jan's essay motivated me to respond, at least initially.

In the interim, I'll attempt additional elucidation toward my viewpoint,
responding more in depth to this post.

Before I do forget this: I've no intention whatsoever to trash anybody here.
It's more that I've become non-believer in virtually all high-level HDLs, and
have a really different philosophical outlook on what may comprise high-level
design. Please also understand that due to it's extremely clean design
compared with others, a lot due to it's Pythonic character, MyHDL is certainly
my favorite among high-level HDLs.

On Sat, 07 Mar 2009 09:00:01 +0100, Jan Decaluwe wrote
> Michael Baxter wrote:
> 
> > Not at all. I might have done well to explain this better. A HDL should
> > provide a clean isomorphism between it's text representation and the
> > underlying hardware representation, most particularly with clearly denoting
> > the efficiency aspects of the implementation. Verilog does this now.
> 
> What counts is the actually obtained efficiency, not the efficiency that
> one think one sees from the code. If you can design at a higher level
> (perhaps with less "isomorphism") without loss of efficiency, you
> gain.
> 
> It think the real issue is that you seem to deny that synthesis can
> provide this kind of efficiency. We should be able to resolve this
> through experiments.

I will argue that behavioral synthesis leaves performance on the table, and
can make for poorer technology mapping, because I've seen it. I can produce
some evidence, but that's not what the real issue was for me.

The real issue is I want to set the number of bits directly for number
representation, period, without question, and never have them inferred. 

So that usual and unusual things can be done with representation, encoding,
and for hardware or software interpretation of the meaning of the bits. I
explicitly do NOT want a compiler attempting to assert meaning upon a field of
bits, as having a range would do. 

Specifying a number of bits does not place an interpretation upon the use of a
bitfield. A number range does. 

The simple case I pointed out before was microprocessor hardware where the
bits are interpreted as both signed and unsigned, at the same or different
times. Take an 8-bit example. If the interval [0, 255] is used to specify some
byte-oriented function by implication, how will the byte be interpreted when
the exact same flip-flops are expected to mean an interval of [-128,127] at a
later time in the same hardware?

IMHO, it's a serious elision error to specify a 1 byte register by
implication, using a range, when in the course of use the bits comprising the
byte, the interpretation could necessarily vary from that range. 

A set range, as a specification syntax or an HDL, appears to imply only one
possible interpretation. But hardware is regularly used right now with dual
interpretations, and sometimes more. Another example of multivariate bit-level
interpretation is for a signum taken over a field of bits. One range does not
elucidate all possible outcomes of representation.

I will aver IMHO that this is literally an example of the problem inherent is
attempting to use strong data typing practices from software unto hardware
problems. Hardware is different.

Now, apparently, I did have a misapprehension reading the essay that inferring
bit-widths was the ONLY way arithmetic was to be supported in MyHDL ... if
this is not so, then my bad, and I am sorry for that mistake. If slice
notation is still available, and you don't need to do any casting to produce
operands or results, then one possible use of MyHDL includes just ignoring
number ranges that infer a specific finitude.

> > I don't have the LRM handy, but I'm pretty sure Verilog-2001 deals with this
> > by allowing signed reg variables, and these do what you would expect. This is
> > distinct from the behavior of Verilog-1995, and it's treatment of integer
> > versus reg. Will try to run some compiles to check this out...
> 
> No, the problem *is* with 2001 signed regs. See the example in the essay
> when signed and unsigned are mixed and for example, 7 + -2 = -11
> instead of 5.

I will check this in more detail. I never use signed regs, and this generally
avoids all kinds of problems. So, I need to look further into this, and will
take your example under advisement. Something does not sound right here, and
I'm wonder if there's an easy explanation for the phenomena you describe.


> > (With apologies to Alan Perlis...) MyHDL programmers know the value of
> > everything, but the cost of nothing.
> 
> I think it's unfair to make such a statement (no matter how good it
> sounds) unless you can prove it. So I challenge you to prove that
> MyHDL-based designs are systematically less efficient than pure
> Verilog designs.

Actually this is pretty easy. This can be shown with logic designs that cannot
be inferred from behavioral Verilog, but are still written in Verilog.

Yes, inspecting the Verilog code would reveal enormous gulfs.

> Note that "synthesising" MyHDL always requires conversion to Verilog 
> or VHDL first. So it may be sufficient to inspect the Verilog output 
> code :-) Ohterwise, the MyHDL Cookbook may be a good start. I 
> provides examples, including one from Xilinx ISE, complete with 
> Verilog code after conversion and Xilinx ISE synthesis results.
> 
> Here are my predictions:
> 
> * there will be no systematic efficiency difference between MyHDL 
> and pure Verilog * there may be significant efficiency differences 
> between different synthesis tools * for some examples, I will be 
> able to design them at a higher level (e.g using higher level data 
> types) than the Verilog couterpart, wihout loss of efficiency.

I'll really have disagree on the first part, sorry.

I would agree that MyHDL could offer more "engineering efficiency," in the
sense that using higher level abstractions can obtain a result that actually
does work more readily. Even more particularly, modern silicon technology
could be massive enabling in that a smaller amount of HDL text (that means
more) can produce a greater amount of logic, than the case for Verilog alone.
I could agree even that producing designs this way is powerful, and quite
flexible.

But! None of that "engineering efficiency," matters when you absolutely must
obtain very high performance to meet specific system requirements, or to
achieve compliance with variety of industrial protocol or interoperability
specifications.

The temporal aspects of representation matter very much; I will argue again
that hardware is different than software. There is an enormously wide
difference between easily obtaining hardware that just works at all, and
hardware that must meet specifications, or its useless.

> > So in this matter, I vigorously disagree. HDLs must be different than computer
> > programming languages, because hardware is concurrent.
> 
> Both HDLs and programming languages are simulated/executed on a sequential
> computer. Therefore, all HDLs need some cleverness to maintain the concurrency
> illusion. MyHDL builds this technique into a powerful programming
> language, that's all.

Some CAD tools actually use sequential computers in plural, so in that sense,
the running programs really are concurrent ...

> > Once the isomorphism between the HDL representation and the underlying
> > hardware representation is lost, how can efficiency even be quantified?
> 
> By synthesizing and analyzing the result.

OK.

> > If you want to synthesize real hardware, and not merely be a modeling
language, then
> > what the hardware is represented as, it's efficiency, and mutability of
> > purpose has primacy, in order for the efficiency argument to be true.
> 
> Didn't get that, sorry.

I was saying in other words what I'd said before; that bitfields in real
hardware already now have mutable representations. Implying that this is
necessary in synthesis of real hardware, but not necessarily demanded in
a modeling language used for simulation-only. 

> > But, what I said is still true. Automatically inferring the number of bits
> > required to represent numbers (integers), instead of allowing the designer to
> > choose that implementation directly is a serious language design error.
> 
> Again: 	MyHDL doesn't impose this *error* on you. You can set the bit
> width directly, using slice notation. If that's all you need or want 
> to know, fine.

I apparently misunderstood from the essay that slice notation was going away,
that intervals were the only method, or that slices could not be used for
arithmetic operations; my apologies again for not understanding.

> Aren't we exaggerating a little here? You make it sound as though inferring
> a bit width from an interval requires a complicated optimization. In
> reality it's trivial of course.

Yes of course this is easy. The inference of bit width is not what I am
concerned about. 

My concern is the use of inference to provide values, a fact which means
interpreting the meaning of bits by a compiler according to a value set. This
implication allows only one interpretation, where two or several may truly be
needed. If hardware is specified in a manner where on interpretation is
pre-set, but others become necessary, then the literal HDL text describing
this hardware is not accurate.

> Since I started with HDL-based design in 1990, I always wished I'd 
> have a generalized concept of VHDL's integer subtypes. So I thought 
> and worked hard to implement it the way I want. So be sure the 
> "error* is intentional :-)

I did understand this intention. I can also foresee that integer subtypes are
quite useful for DSP hardware in particular. However, I have strenuously
argued that it's an ill-suited representation or specification system for
general-purpose hardware.

> Jan

Best,
M

Re: [myhdl-list] essay about integer arithmetic

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

Michael Baxter wrote:

> Not at all. I might have done well to explain this better. A HDL should
> provide a clean isomorphism between it's text representation and the
> underlying hardware representation, most particularly with clearly denoting
> the efficiency aspects of the implementation. Verilog does this now.

What counts is the actually obtained efficiency, not the efficiency that
one think one sees from the code. If you can design at a higher level
(perhaps with less "isomorphism") without loss of efficiency, you
gain.

It think the real issue is that you seem to deny that synthesis can
provide this kind of efficiency. We should be able to resolve this
through experiments.

> I don't have the LRM handy, but I'm pretty sure Verilog-2001 deals with this
> by allowing signed reg variables, and these do what you would expect. This is
> distinct from the behavior of Verilog-1995, and it's treatment of integer
> versus reg. Will try to run some compiles to check this out...

No, the problem *is* with 2001 signed regs. See the example in the essay
when signed and unsigned are mixed and for example, 7 + -2 = -11
instead of 5.

> (With apologies to Alan Perlis...) MyHDL programmers know the value of
> everything, but the cost of nothing.

I think it's unfair to make such a statement (no matter how good it
sounds) unless you can prove it. So I challenge you to prove that
MyHDL-based designs are systematically less efficient than pure
Verilog designs.

Note that "synthesising" MyHDL always requires conversion to Verilog or VHDL
first. So it may be sufficient to inspect the Verilog output code :-)
Ohterwise, the MyHDL Cookbook may be a good start. I provides examples,
including one from Xilinx ISE, complete with Verilog code after conversion
and Xilinx ISE synthesis results.

Here are my predictions:

* there will be no systematic efficiency difference between MyHDL and pure Verilog
* there may be significant efficiency differences between different synthesis tools
* for some examples, I will be able to design them at a higher level (e.g using
higher level data types) than the Verilog couterpart, wihout loss of efficiency.

> So in this matter, I vigorously disagree. HDLs must be different than computer
> programming languages, because hardware is concurrent.

Both HDLs and programming languages are simulated/executed on a sequential
computer. Therefore, all HDLs need some cleverness to maintain the concurrency
illusion. MyHDL builds this technique into a powerful programming
language, that's all.

> Once the isomorphism between the HDL representation and the underlying
> hardware representation is lost, how can efficiency even be quantified?

By synthesizing and analyzing the result.

> If you want to synthesize real hardware, and not merely be a modeling language, then
> what the hardware is represented as, it's efficiency, and mutability of
> purpose has primacy, in order for the efficiency argument to be true.

Didn't get that, sorry.

> But, what I said is still true. Automatically inferring the number of bits
> required to represent numbers (integers), instead of allowing the designer to
> choose that implementation directly is a serious language design error.

Again: 	MyHDL doesn't impose this *error* on you. You can set the bit
width directly, using slice notation. If that's all you need or want to know, fine.

Aren't we exaggerating a little here? You make it sound as though inferring
a bit width from an interval requires a complicated optimization. In
reality it's trivial of course.

Since I started with HDL-based design in 1990, I always wished I'd have a
generalized concept of VHDL's integer subtypes. So I thought and worked hard
to implement it the way I want. So be sure the "error* is intentional :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a hardware description language:
   http://www.myhdl.org

[myhdl-list] inheriting from intbv

[Neal B. <ndb...@gm...>]

I thought maybe I'd make intbv work a bit more like I want, but deriving 
from it.  As a test:

class intbv_s (intbv):
    def __init__ (self, val, nrbits):
        intbv.__init__ (self, val, min=min_signed (nrbits), max=max_signed 
(nrbits)+1)

But this didn't convert properly to verilog:

...
    y1 = intbv_s($signed(acc1__sum >>> (4 - 1)), 10);
    y2 = intbv_s((y1 + 1), 10);
    y3 = intbv_s($signed(y2 >>> 1), 10);

Looking at _toVerilog.py, I wonder if there is a problem?  For example:


        elif f is intbv:

There are at least some places where 'is' is used instead of isinstance.  Is 
this intentional? 

Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

On Fri, 06 Mar 2009 17:49:14 +0100, Jan Decaluwe wrote
> Michael Baxter wrote:
> 
> > There are no data types in hardware!

I should have said: "There are no software-like data types in hardware!"
Verilog does have data types, but they meant to indicate hardware, not
represent variable or structures in computer programs.

> No, but that doesn't this prove that there shoudn't be data types
> in hardware description languages. Even a simple bit-vector
> is an abstraction that "doesn't exist" as such in hardware.
> Isn't this just a matter of what you're used to and what
> you trust?

Not at all. I might have done well to explain this better. A HDL should
provide a clean isomorphism between it's text representation and the
underlying hardware representation, most particularly with clearly denoting
the efficiency aspects of the implementation. Verilog does this now.

> > Bits do what their hardware says to do,
> > and it may be completely unrelated to signedness, or even to values. The rules
> > of Verilog for arithmetic DO make sense: they do what hardware does, and that
> > is good.
> 
> I insist that Verilog's implicit casting of signed's to unsigned's
> in an expression does *not* make sense. The rules could have been
> different, and then they would makes sense in terms of their
> integer interpretation. But they would *still* do "what the hardware
> does": the difference would be sign-bit extension (= routing)
>  instead of zero padding.

I don't have the LRM handy, but I'm pretty sure Verilog-2001 deals with this
by allowing signed reg variables, and these do what you would expect. This is
distinct from the behavior of Verilog-1995, and it's treatment of integer
versus reg. Will try to run some compiles to check this out...

> > That is why software is different than hardware, and it's why HDLs
> > are completely different than computer programming languages.
> 
> Needless to say, one of my goals with MyHDL is to prove that this is 
> false. Seems I'm not succeeding :-)

(With apologies to Alan Perlis...) MyHDL programmers know the value of
everything, but the cost of nothing.

So in this matter, I vigorously disagree. HDLs must be different than computer
programming languages, because hardware is concurrent.

Virtually all computer programming languages lack concurrency; more acutely,
they lack explicit concurrency that is crucial to hardware. MyHDL exploits
some novel features in Python very cleverly, and it's very impressive in that
regard. I would not however describe Python as explicitly concurrent.

This does not mean that high-level approaches are inapplicable to HDLs, IMHO.
The issue is over how, the policies to be employed for representation, etc.

> > Applying computer programming language models (such as data types) to hardware
> > is a very dangerous idea for efficient, high-performance hardware engineering
> > of logic. Programming models don't work the way hardware works.
> 
> Many models don't. But with data types such as integers, booleans, 
> and enums there is no loss of efficiency, only a gain in clarity and 
> productivity.

Once the isomorphism between the HDL representation and the underlying
hardware representation is lost, how can efficiency even be quantified? If you
want to synthesize real hardware, and not merely be a modeling language, then
what the hardware is represented as, it's efficiency, and mutability of
purpose has primacy, in order for the efficiency argument to be true.

> > As a designer, I want complete and total control over the number of bits
> > represented in the (simulated or synthesized) hardware. A program should NOT
> > do that for me, because a computer program is too stupid to understand what I
> > want those bits to do, or to mean.
> 
> In case of integer arithmetic, which is really the sole topic of the 
> essay, that statement is evidently incorrect. The support of VHDL 
> integer subtypes in synthesis tools proves it.

Chuckle. I'll evade that argument by describing VHDL as a computer programming
language, which also happens to have a use for hardware design. Verilog is a
lot closer to real hardware, and as a HDL there the isomorphism between
representation as text and as hardware is much stronger.

But, what I said is still true. Automatically inferring the number of bits
required to represent numbers (integers), instead of allowing the designer to
choose that implementation directly is a serious language design error.

Best,
M

> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a hardware description language:
>     http://www.myhdl.org
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San 
> Francisco, CA -OSBC tackles the biggest issue in open source: Open 
> Sourcing the Enterprise -Strategies to boost innovation and cut 
> costs with open source participation -Receive a $600 discount off 
> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] essay about integer arithmetic

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

Michael Baxter wrote:

> There are no data types in hardware!

No, but that doesn't this prove that there shoudn't be data types
in hardware description languages. Even a simple bit-vector
is an abstraction that "doesn't exist" as such in hardware.
Isn't this just a matter of what you're used to and what
you trust?

> Bits do what their hardware says to do,
> and it may be completely unrelated to signedness, or even to values. The rules
> of Verilog for arithmetic DO make sense: they do what hardware does, and that
> is good.

I insist that Verilog's implicit casting of signed's to unsigned's
in an expression does *not* make sense. The rules could have been
different, and then they would makes sense in terms of their
integer interpretation. But they would *still* do "what the hardware
does": the difference would be sign-bit extension (= routing) instead of
zero padding.

> That is why software is different than hardware, and it's why HDLs
> are completely different than computer programming languages.

Needless to say, one of my goals with MyHDL is to prove that this is false.
Seems I'm not succeeding :-)

> Applying computer programming language models (such as data types) to hardware
> is a very dangerous idea for efficient, high-performance hardware engineering
> of logic. Programming models don't work the way hardware works.

Many models don't. But with data types such as integers, booleans, and enums there
is no loss of efficiency, only a gain in clarity and productivity.

> As a designer, I want complete and total control over the number of bits
> represented in the (simulated or synthesized) hardware. A program should NOT
> do that for me, because a computer program is too stupid to understand what I
> want those bits to do, or to mean.

In case of integer arithmetic, which is really the sole topic of the essay,
that statement is evidently incorrect. The support of VHDL integer subtypes
in synthesis tools proves it.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

Re: [myhdl-list] essay about integer arithmetic

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

Michael Baxter wrote:
> Yes, but I intend for integers to represent fields of bits, and to do numerous
> other things that are not constrained by intervals. In fact, some of those
> things (involving plural, concurrent bitfields) can be done purely with
> conventional arithmetic operations. Normal integers, but not being used normally.
> 
> A 32-bit microprocessor (comprised of hardware) can have 32-bit registers that
> represent integers that are not signed, or that are signed, both at the same
> time. It all depends on what software does to interpret the meaning of those
> 32-bit register bits. What's the correct interval representation for the
> design of the registers in that hardware?

There is none. You use a bit vector in this case, design at the bit
level, and let the integer interpretation to software:

   a = intbv(0)[32:]

I hope it's clear from the essay that intbv is dual-mode type,
where you have the *option* to use it as a true integer if you want.
I realize that you suggest that such use cases don't exist. That
sounds absurd to me, but of course I've not only used Verilog
but also VHDL :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

Re: [myhdl-list] essay about integer arithmetic

[Felton C. <chr...@gm...>]

On Mar 6, 2009, at 8:26 AM, Michael Baxter wrote:

> Yes, but I intend for integers to represent fields of bits, and to  
> do numerous
> other things that are not constrained by intervals. In fact, some of  
> those
> things (involving plural, concurrent bitfields) can be done purely  
> with
> conventional arithmetic operations. Normal integers, but not being  
> used normally.

I disagree, here we are specifically talking about integers  
constrained by intervals.  Integer being used as integers.  Particular  
to myhdl you can still simply define bit vector based on the number of  
bits.  Using the constrained integer bit vectors, I would think of as  
a subset.  And that it would be useful to design with integers, when  
intended to use integers, instead of dealing with a more basic type.   
I don't believe this is intended to force min, max for any and all bit  
vectors.  I think the essay makes a good argument to use constrained  
integer bit vectors when the design is using integers.

>
>
> A 32-bit microprocessor (comprised of hardware) can have 32-bit  
> registers that
> represent integers that are not signed, or that are signed, both at  
> the same
> time. It all depends on what software does to interpret the meaning  
> of those
> 32-bit register bits. What's the correct interval representation for  
> the
> design of the registers in that hardware?

This is a great example, you have a generic container.  Presumably you  
may not want to use an integer to represent it in its basic form.  But  
from the perspective of different computation elements it could be  
desirable that the register is presented as a constrained integer.  In  
the Verilog case it would be the same type, in VHDL example the  
register maybe a std_logic but the adder may deal with it as a signed  
type.  Similar scenario in myhdl could occur.

>
>
> Another case I neglected is also salient. In some very useful encoding
> systems, collections of bits can also mean [-1,1] values, which has a
> wonderful representation in bit-form, but not as integers, nor as  
> intervals.

This is another good example, question constrained integer useful or  
not.

Chris

Re: [myhdl-list] essay about integer arithmetic

[Pieter <pie...@gm...>]

> Ranges of values due not define a bitwidth explicitly, they define it implicitly.

You're right, I didn't look at that as an implicit bit width, but in
fact it is. It is undesirable in the cases you name, but I can see it
has its use if you only mean to create some integer number.

2009/3/6 Michael Baxter <ma...@cr...>:
> Hi Pieter,
>
> Verilog functioned successfully for many years without a representation for
> signedness. Adding signed bitfields to the language is really I think only a
> form of syntatic sugar. It's not strictly necessary for hardware design.
>
> There are no data types in hardware! Bits do what their hardware says to do,
> and it may be completely unrelated to signedness, or even to values. The rules
> of Verilog for arithmetic DO make sense: they do what hardware does, and that
> is good. That is why software is different than hardware, and it's why HDLs
> are completely different than computer programming languages.
>
> Applying computer programming language models (such as data types) to hardware
> is a very dangerous idea for efficient, high-performance hardware engineering
> of logic. Programming models don't work the way hardware works.
>
> Ranges of values due not define a bitwidth explicitly, they define it implicitly.
>
> As a designer, I want complete and total control over the number of bits
> represented in the (simulated or synthesized) hardware. A program should NOT
> do that for me, because a computer program is too stupid to understand what I
> want those bits to do, or to mean.
>
> A collection of bits can well more than a single range in representation. A
> 32-bit register can represent 32 bit flags, each having a range [0,1]. Or it
> could represent (4) 8-bit values, each having a range [0,255], [-128,127] or a
> mix. Or it could represent two fields, (6) 1-bit flag values concatenated to a
> 26-bit ordinal. Or, or, or... any number of alternative representations
> involving bit-level concurrency that cannot be represented with a single
> interval specification. This kind of thing is done all the time in hardware.
>
> I don't want to use several intervals to imply what I mean, I want to use a
> single ordinal to say how many bits I want, their interpretation being
> possibly completely unrelated to the number of bits as a total.
>
> Use of intervals is being proposed as a means to imply bitwidth, and this is
> an anathma to explicit, specific, user-defined design representation.
>
> As a designer, I already know what I want the underlying hardware bit
> representation to do, or to mean. A high-level HDL should get out of my way to
> let me do that.
>
> Hope this answers your queries with some additional amplification.
>
> Best,
> Michael
>
> On Fri, 6 Mar 2009 14:22:59 +0100, Pieter wrote
>> That's funny, only yesterday I saw someone write this:
>>
>> some_signal <= '0'
>> if ((a-b) = 1 or (b-a) = 1) then
>>   some_signal <= '1';
>> end if;
>>
>> The arithmetic rules in Verilog are confusing and just wrong. The
>> rules in VHDL are hard to grasp for students, but there's some logic
>> behind it. If only the result of an operation would be as wide as the
>> target, that would solve many issues. It doesn't feel right to change
>> the size of the operand, to get the right size for the result. (and
>> of course you should be able to add a signed and an unsigned operand
>> without having to cast the unsigned to signed + adding a zero to the
>> front)
>>
>> @ Michael Baxter
>> I don't have a lot experience in hardware design. For me this doesn't
>> feel like automating bit-widths. You still define max and min values
>> for the intbev, so you declare the bit width explicitly. Isn't it
>> about the arithmetic rules that are counter-intuitive? I can't see
>> there's anything wrong with those of MyHDL, they are intuitive and
>> create the hardware you want. Can you explain why you believe this
>> automates bit widths and this should never be done?
>>
>> kind regards,
>>
>> pieter
>>
>> 2009/3/6 Michael Baxter <ma...@cr...>:
>> > IMHO, though informed with years of hardware implementation experience,
>> > automating bit-widths should be 100% a non-goal. It should never be done under
>> > any circumstances whatsoever.
>> >
>> > IMHO, this is a serious failing of MyHDL.
>> >
>> > Best,
>> > Michael
>> > California
>> >
>> > On Fri, 06 Mar 2009 07:21:50 -0500, Neal Becker wrote
>> >> 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
>> >> >
>> >> >
>> >> >
>> >>
>> >> If you really want to automate the bit widths, perhaps some kind of
>> >> interval arithmetic is wanted?
>> >>
>> >> python mpmath and pyinterval both supply some interval arithmetic,
>> >> but these are over reals, not integers.
>> >>
>> >>
> ------------------------------------------------------------------------------
>> >> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> >> Francisco, CA -OSBC tackles the biggest issue in open source: Open
>> >> Sourcing the Enterprise -Strategies to boost innovation and cut
>> >> costs with open source participation -Receive a $600 discount off
>> >> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
>> >> _______________________________________________
>> >> myhdl-list mailing list
>> >> myh...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> > -Strategies to boost innovation and cut costs with open source participation
>> > -Receive a $600 discount off the registration fee with the source code: SFAD
>> > http://p.sf.net/sfu/XcvMzF8H
>> > _______________________________________________
>> > myhdl-list mailing list
>> > myh...@li...
>> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
>> >
>>
>> --
>> Pieter Cogghe
>> Iepenstraat 43
>> 9000 Gent
>> 0487 10 14 21
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA -OSBC tackles the biggest issue in open source: Open
>> Sourcing the Enterprise -Strategies to boost innovation and cut
>> costs with open source participation -Receive a $600 discount off
>> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Pieter Cogghe
Iepenstraat 43
9000 Gent
0487 10 14 21

Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

Yes, but I intend for integers to represent fields of bits, and to do numerous
other things that are not constrained by intervals. In fact, some of those
things (involving plural, concurrent bitfields) can be done purely with
conventional arithmetic operations. Normal integers, but not being used normally.

A 32-bit microprocessor (comprised of hardware) can have 32-bit registers that
represent integers that are not signed, or that are signed, both at the same
time. It all depends on what software does to interpret the meaning of those
32-bit register bits. What's the correct interval representation for the
design of the registers in that hardware?

Another case I neglected is also salient. In some very useful encoding
systems, collections of bits can also mean [-1,1] values, which has a
wonderful representation in bit-form, but not as integers, nor as intervals.

Best,
M

On Fri, 6 Mar 2009 08:14:39 -0600, Felton Christopher wrote
> >
> >
> > A collection of bits can well more than a single range in  
> > representation. A
> > 32-bit register can represent 32 bit flags, each having a range  
> > [0,1]. Or it
> > could represent (4) 8-bit values, each having a range [0,255],  
> > [-128,127] or a
> > mix. Or it could represent two fields, (6) 1-bit flag values  
> > concatenated to a
> > 26-bit ordinal. Or, or, or... any number of alternative  
> > representations
> > involving bit-level concurrency that cannot be represented with a  
> > single
> > interval specification. This kind of thing is done all the time in  
> > hardware.
> >
> 
> Think this topic is only discussing when a collection of bits is  
> acting as a number, integer, and not some other "data type" such as  
> flags, logic, etc.  You wouldn't use the min, max when defining a  
> collection of bits that are not used for integer arithmetic.
> 
> I think there will be some different opinions in the design approach 
>  but if you wanted an 8 bit register that was used as simple flags,
>  you  could do that the conventional way without min and max.
> 
> As the essay states in the beginning "essay about elementary  
> arithmetic with integers".  This topic is about representing 
> integers  
> (when the designer intends integers) and not removing basic bit  
> vectors for other uses.
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San 
> Francisco, CA -OSBC tackles the biggest issue in open source: Open 
> Sourcing the Enterprise -Strategies to boost innovation and cut 
> costs with open source participation -Receive a $600 discount off 
> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] essay about integer arithmetic

[Felton C. <chr...@gm...>]

>
>
> A collection of bits can well more than a single range in  
> representation. A
> 32-bit register can represent 32 bit flags, each having a range  
> [0,1]. Or it
> could represent (4) 8-bit values, each having a range [0,255],  
> [-128,127] or a
> mix. Or it could represent two fields, (6) 1-bit flag values  
> concatenated to a
> 26-bit ordinal. Or, or, or... any number of alternative  
> representations
> involving bit-level concurrency that cannot be represented with a  
> single
> interval specification. This kind of thing is done all the time in  
> hardware.
>

Think this topic is only discussing when a collection of bits is  
acting as a number, integer, and not some other "data type" such as  
flags, logic, etc.  You wouldn't use the min, max when defining a  
collection of bits that are not used for integer arithmetic.

I think there will be some different opinions in the design approach  
but if you wanted an 8 bit register that was used as simple flags, you  
could do that the conventional way without min and max.

As the essay states in the beginning "essay about elementary  
arithmetic with integers".  This topic is about representing integers  
(when the designer intends integers) and not removing basic bit  
vectors for other uses.

  
  

Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

Hi Pieter,

Verilog functioned successfully for many years without a representation for
signedness. Adding signed bitfields to the language is really I think only a
form of syntatic sugar. It's not strictly necessary for hardware design.

There are no data types in hardware! Bits do what their hardware says to do,
and it may be completely unrelated to signedness, or even to values. The rules
of Verilog for arithmetic DO make sense: they do what hardware does, and that
is good. That is why software is different than hardware, and it's why HDLs
are completely different than computer programming languages.

Applying computer programming language models (such as data types) to hardware
is a very dangerous idea for efficient, high-performance hardware engineering
of logic. Programming models don't work the way hardware works.

Ranges of values due not define a bitwidth explicitly, they define it implicitly.

As a designer, I want complete and total control over the number of bits
represented in the (simulated or synthesized) hardware. A program should NOT
do that for me, because a computer program is too stupid to understand what I
want those bits to do, or to mean.

A collection of bits can well more than a single range in representation. A
32-bit register can represent 32 bit flags, each having a range [0,1]. Or it
could represent (4) 8-bit values, each having a range [0,255], [-128,127] or a
mix. Or it could represent two fields, (6) 1-bit flag values concatenated to a
26-bit ordinal. Or, or, or... any number of alternative representations
involving bit-level concurrency that cannot be represented with a single
interval specification. This kind of thing is done all the time in hardware.

I don't want to use several intervals to imply what I mean, I want to use a
single ordinal to say how many bits I want, their interpretation being
possibly completely unrelated to the number of bits as a total.

Use of intervals is being proposed as a means to imply bitwidth, and this is
an anathma to explicit, specific, user-defined design representation.

As a designer, I already know what I want the underlying hardware bit
representation to do, or to mean. A high-level HDL should get out of my way to
let me do that.

Hope this answers your queries with some additional amplification.

Best,
Michael

On Fri, 6 Mar 2009 14:22:59 +0100, Pieter wrote
> That's funny, only yesterday I saw someone write this:
> 
> some_signal <= '0'
> if ((a-b) = 1 or (b-a) = 1) then
>   some_signal <= '1';
> end if;
> 
> The arithmetic rules in Verilog are confusing and just wrong. The
> rules in VHDL are hard to grasp for students, but there's some logic
> behind it. If only the result of an operation would be as wide as the
> target, that would solve many issues. It doesn't feel right to change
> the size of the operand, to get the right size for the result. (and 
> of course you should be able to add a signed and an unsigned operand 
> without having to cast the unsigned to signed + adding a zero to the 
> front)
> 
> @ Michael Baxter
> I don't have a lot experience in hardware design. For me this doesn't
> feel like automating bit-widths. You still define max and min values
> for the intbev, so you declare the bit width explicitly. Isn't it
> about the arithmetic rules that are counter-intuitive? I can't see
> there's anything wrong with those of MyHDL, they are intuitive and
> create the hardware you want. Can you explain why you believe this
> automates bit widths and this should never be done?
> 
> kind regards,
> 
> pieter
> 
> 2009/3/6 Michael Baxter <ma...@cr...>:
> > IMHO, though informed with years of hardware implementation experience,
> > automating bit-widths should be 100% a non-goal. It should never be done under
> > any circumstances whatsoever.
> >
> > IMHO, this is a serious failing of MyHDL.
> >
> > Best,
> > Michael
> > California
> >
> > On Fri, 06 Mar 2009 07:21:50 -0500, Neal Becker wrote
> >> 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
> >> >
> >> >
> >> >
> >>
> >> If you really want to automate the bit widths, perhaps some kind of
> >> interval arithmetic is wanted?
> >>
> >> python mpmath and pyinterval both supply some interval arithmetic,
> >> but these are over reals, not integers.
> >>
> >>
------------------------------------------------------------------------------
> >> Open Source Business Conference (OSBC), March 24-25, 2009, San
> >> Francisco, CA -OSBC tackles the biggest issue in open source: Open
> >> Sourcing the Enterprise -Strategies to boost innovation and cut
> >> costs with open source participation -Receive a $600 discount off
> >> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> >> _______________________________________________
> >> myhdl-list mailing list
> >> myh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> > ------------------------------------------------------------------------------
> > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> > -Strategies to boost innovation and cut costs with open source participation
> > -Receive a $600 discount off the registration fee with the source code: SFAD
> > http://p.sf.net/sfu/XcvMzF8H
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> 
> -- 
> Pieter Cogghe
> Iepenstraat 43
> 9000 Gent
> 0487 10 14 21
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San 
> Francisco, CA -OSBC tackles the biggest issue in open source: Open 
> Sourcing the Enterprise -Strategies to boost innovation and cut 
> costs with open source participation -Receive a $600 discount off 
> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] essay about integer arithmetic

[Neal B. <ndb...@gm...>]

In case anyone is interested, here is my run_time_fixed_pt class.
(run_time because bit widths are set at run time, so I can use it from 
python.  I have another version that sets widths at compile time as template 
parameters).

Re: [myhdl-list] essay about integer arithmetic

[Pieter <pie...@gm...>]

> If you want to multiply 8bit x 8bit and result in 16bit, what you do in
> convert both operands to 16bit first.

Hmm, for me it seems more logical that you should have 16 bits at the
left hand side of the assignment, to get a 16 bit result?

result_16 = op_a_8 * op_b_8;

2009/3/6 Neal Becker <ndb...@gm...>:
> Michael Baxter wrote:
>
>> IMHO, though informed with years of hardware implementation experience,
>> automating bit-widths should be 100% a non-goal. It should never be done
>> under any circumstances whatsoever.
>>
>> IMHO, this is a serious failing of MyHDL.
>>
> Actually, I agree.  That's why I wrote about my c++ approach to fixed-pt
> integers.  There, the approach is:
>
> For unary op, the output size is same as input
> For binary op, the 2nd operand is converted to the first, then the output
> size is same as input
>
> (Actually, fixed-pt has 2 attributes: a number of integer bits and a number
> of frac bits, or equivalently a size and a binary point)
>
> If you want to multiply 8bit x 8bit and result in 16bit, what you do in
> convert both operands to 16bit first.
>
> The reason is, I really don't think it's possible to have a machine
> correctly deal with these issues in all cases.
>
> Perhaps more important, though, is the question of even if it is possible
> for some kind of algorithm to decide the bit widths, is this really
> desirable?  I'm not sure about that.  Maybe the designer really should be
> aware of these details.
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Pieter Cogghe
Iepenstraat 43
9000 Gent
0487 10 14 21

Re: [myhdl-list] essay about integer arithmetic

[Pieter <pie...@gm...>]

That's funny, only yesterday I saw someone write this:

some_signal <= '0'
if ((a-b) = 1 or (b-a) = 1) then
  some_signal <= '1';
end if;

The arithmetic rules in Verilog are confusing and just wrong. The
rules in VHDL are hard to grasp for students, but there's some logic
behind it. If only the result of an operation would be as wide as the
target, that would solve many issues. It doesn't feel right to change
the size of the operand, to get the right size for the result. (and of
course you should be able to add a signed and an unsigned operand
without having to cast the unsigned to signed + adding a zero to the
front)

@ Michael Baxter
I don't have a lot experience in hardware design. For me this doesn't
feel like automating bit-widths. You still define max and min values
for the intbev, so you declare the bit width explicitly. Isn't it
about the arithmetic rules that are counter-intuitive? I can't see
there's anything wrong with those of MyHDL, they are intuitive and
create the hardware you want. Can you explain why you believe this
automates bit widths and this should never be done?

kind regards,

pieter

2009/3/6 Michael Baxter <ma...@cr...>:
> IMHO, though informed with years of hardware implementation experience,
> automating bit-widths should be 100% a non-goal. It should never be done under
> any circumstances whatsoever.
>
> IMHO, this is a serious failing of MyHDL.
>
> Best,
> Michael
> California
>
> On Fri, 06 Mar 2009 07:21:50 -0500, Neal Becker wrote
>> 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
>> >
>> >
>> >
>>
>> If you really want to automate the bit widths, perhaps some kind of
>> interval arithmetic is wanted?
>>
>> python mpmath and pyinterval both supply some interval arithmetic,
>> but these are over reals, not integers.
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA -OSBC tackles the biggest issue in open source: Open
>> Sourcing the Enterprise -Strategies to boost innovation and cut
>> costs with open source participation -Receive a $600 discount off
>> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Pieter Cogghe
Iepenstraat 43
9000 Gent
0487 10 14 21

Re: [myhdl-list] essay about integer arithmetic

[Neal B. <ndb...@gm...>]

Michael Baxter wrote:

> IMHO, though informed with years of hardware implementation experience,
> automating bit-widths should be 100% a non-goal. It should never be done
> under any circumstances whatsoever.
> 
> IMHO, this is a serious failing of MyHDL.
> 
Actually, I agree.  That's why I wrote about my c++ approach to fixed-pt 
integers.  There, the approach is:

For unary op, the output size is same as input
For binary op, the 2nd operand is converted to the first, then the output 
size is same as input

(Actually, fixed-pt has 2 attributes: a number of integer bits and a number 
of frac bits, or equivalently a size and a binary point)

If you want to multiply 8bit x 8bit and result in 16bit, what you do in 
convert both operands to 16bit first.

The reason is, I really don't think it's possible to have a machine 
correctly deal with these issues in all cases.

Perhaps more important, though, is the question of even if it is possible 
for some kind of algorithm to decide the bit widths, is this really 
desirable?  I'm not sure about that.  Maybe the designer really should be 
aware of these details.

Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

IMHO, though informed with years of hardware implementation experience,
automating bit-widths should be 100% a non-goal. It should never be done under
any circumstances whatsoever.

IMHO, this is a serious failing of MyHDL.

Best,
Michael
California

On Fri, 06 Mar 2009 07:21:50 -0500, Neal Becker wrote
> 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
> > 
> > 
> >
> 
> If you really want to automate the bit widths, perhaps some kind of 
> interval arithmetic is wanted?
> 
> python mpmath and pyinterval both supply some interval arithmetic, 
> but these are over reals, not integers.
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San 
> Francisco, CA -OSBC tackles the biggest issue in open source: Open 
> Sourcing the Enterprise -Strategies to boost innovation and cut 
> costs with open source participation -Receive a $600 discount off 
> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] essay about integer arithmetic

[Neal B. <ndb...@gm...>]

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
> 
> 
> 

If you really want to automate the bit widths, perhaps some kind of interval 
arithmetic is wanted?

python mpmath and pyinterval both supply some interval arithmetic, but these 
are over reals, not integers.

[myhdl-list] essay about integer arithmetic

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

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



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

Re: [myhdl-list] another intbv question

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

Neal Becker wrote:
> I noticed that
> 
> x = intbv (5, -16, 15)
> 
> print x._min
>> -16
> 
> print (x >> 1)._min
> None
> 
> This is surprising.  I would have expected that arithmetic operations on 
> intbv would result in an intbv with the same #bits.
> 
> I have implemented a fixed pt arithmetic class in c++ (based on 
> boost::constrained_value).  What I did there is all operations result in the 
> same # bits.  If you want something different, first convert operands to the 
> desired result size.  For example, multiplying 2 8-bit values will give an 
> 8-bit result.  If you wanted a 16-bit result, first convert the inputs to the 
> wider field.
> 
> Others have argued that these conversions should be automatic (e.g., 8 x 8 -
>> 16), but I prefer explicit.
> 
> In any case, I think the intbv behavior is surprising.  Is this really 
> desirable?

In my opinion it is. I don't see the benefit of having to deal
with bit widths myself if a tool can do so (better).

intbv *is* explicit, but not at the bit width level, but at the
level of value constraints. This is inspired by VHDL's integer subtypes.

Arithmetic operations on intbv return integers, the idea is that the
range of a result is checked at the moment when it is assigned to
an existing intbv using slice assignment.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

[myhdl-list] another intbv question

[Neal B. <ndb...@gm...>]

I noticed that

x = intbv (5, -16, 15)

print x._min
> -16

print (x >> 1)._min
None

This is surprising.  I would have expected that arithmetic operations on 
intbv would result in an intbv with the same #bits.

I have implemented a fixed pt arithmetic class in c++ (based on 
boost::constrained_value).  What I did there is all operations result in the 
same # bits.  If you want something different, first convert operands to the 
desired result size.  For example, multiplying 2 8-bit values will give an 
8-bit result.  If you wanted a 16-bit result, first convert the inputs to the 
wider field.

Others have argued that these conversions should be automatic (e.g., 8 x 8 -
> 16), but I prefer explicit.

In any case, I think the intbv behavior is surprising.  Is this really 
desirable?

Re: [myhdl-list] not supported, extra positional arguments

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

Neal Becker wrote:
> BTW, all I'm trying to do here is declare a signed number the same size as 
> the one passed in.  Is there an easier way?


The convertor doesn't support the *args and *kwargs syntax for extra
arguments.

I would clarify the code by calculating constants once in advance:

def sat (....)

    min_x, max_x = min_signed(len(x)), max_signed(len(x))
    min_out, max_out = ...

    @always_comb
    ....



Jan

> 
> This is OK:
> def sat_rnd (x, bits, outbits, output):
>     @always_comb
>     def sat_rnd_logic():
>         y1 = intbv (int (x >> (bits-1)), min_signed (len (x)), max_signed 
> (len (x)))
>         y2 = intbv (int (y1 + 1), min_signed (len (x)), max_signed (len 
> (x)))
>         y3 = intbv (int (y2 >> 1), min_signed (len (x)), max_signed (len 
> (x)))
>         if (y3 > max_signed (outbits)):
>             output.next = max_signed (outbits)
>         elif (y3 < min_signed (outbits)):
>             output.next = min_signed (outbits)
>         else:
>             output.next = y3
> 
>     return sat_rnd_logic
>     
> But this is not:
> 
> def sat_rnd (x, bits, outbits, output):
>     @always_comb
>     def sat_rnd_logic():
>         y1 = intbv (int (x >> (bits-1)), *extrema_signed (len (x)))
>         y2 = intbv (int (y1 + 1), *extrema_signed (len (x)))
>         y3 = intbv (int (y2 >> 1), *extrema_signed (len (x)))
>         if (y3 > max_signed (outbits)):
>             output.next = max_signed (outbits)
>         elif (y3 < min_signed (outbits)):
>             output.next = min_signed (outbits)
>         else:
>             output.next = y3
> 
>     return sat_rnd_logic
>     
>  python test3.py
> Traceback (most recent call last):
>   File "test3.py", line 174, in <module>
>     verilog()
>   File "test3.py", line 161, in verilog
>     toVerilog (Decimator, clock, en, x, log2_n, count, result, reset)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_toVerilog.py", 
> line 115, in __call__
>     genlist = _analyzeGens(arglist, h.absnames)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
> 155, in _analyzeGens
>     compiler.walk(ast, v)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 106, in walk
>     walker.preorder(tree, visitor)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 63, in preorder
>     self.dispatch(tree, *args) # XXX *args make sense?
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
>     self.dispatch(child, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
>     self.dispatch(child, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
> 261, in visitFunction
>     self.visitChildNodes(node, *args)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_misc.py", line 
> 137, in visitChildNodes
>     self.visit(n, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
>     self.dispatch(child, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
> 240, in visitAssign
>     self.visit(node.expr, *args)
>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>     return meth(node, *args)
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
> 244, in visitCallFunc
>     self.raiseError(node, _error.NotSupported, "extra positional arguments")
>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_misc.py", line 
> 128, in raiseError
>     raise ConversionError(kind, msg, info)
> 
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

Re: [myhdl-list] intbv improvement?

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

Neal Becker wrote:
> Jan Decaluwe wrote:
> 
>> Neal Becker wrote:
>>> I would find this addition to the intbv constructor helpful:
>>>
>>> class intbv(object):
>>>     __slots__ = ('_val', '_min', '_max', '_nrbits')
>>>     
>>>     def __init__(self, val=None, min=None, max=None, _nrbits=0,
>>> is_signed=False):
>>>         if _nrbits:
>>>             if (is_signed):
>>>                self._min = -1 << (_nrbits-1)
>>>                self._max = ~(-1 << (_nrbits-1))
>>>             else:
>>>               self._min = 0
>>>               self._max = 2**_nrbits
>> I infer that you want to use _nrbits as an end user also?
>> This is not how the type is set up. _nrbits is intended
>> to be a private parameter of the constructor for internal
>> use.
>>
>> One of the goals of intbv is to get rid of unsigned/signed
>> thinking as much as possible, and push the use of fine-grained
>> range control as high-level alternative.
>> (I'm actually writing a paper about this, almost finished.)
>>
>> Jan
>>
> 
> I want to make sure my value is converted to verilog signed.  AFAICT, the 
> only way I have now to do this is with intbv specifying min and max, rather 
> than nrbits?

Yes.

> That's OK, but a little inconvenient.

Here I disagree, I actually believe the opposite is true though
I understand it goes against current conventional wisdom.

Note that by using min and max, you never have to think
or worry about the difference between signed/unsigned.
The convertor should solve the issues for you.

My upcoming essay deals exactly with these issues
in detail, please stay tuned! (in one week or so)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

[myhdl-list] not supported, extra positional arguments

[Neal B. <ndb...@gm...>]

BTW, all I'm trying to do here is declare a signed number the same size as 
the one passed in.  Is there an easier way?

This is OK:
def sat_rnd (x, bits, outbits, output):
    @always_comb
    def sat_rnd_logic():
        y1 = intbv (int (x >> (bits-1)), min_signed (len (x)), max_signed 
(len (x)))
        y2 = intbv (int (y1 + 1), min_signed (len (x)), max_signed (len 
(x)))
        y3 = intbv (int (y2 >> 1), min_signed (len (x)), max_signed (len 
(x)))
        if (y3 > max_signed (outbits)):
            output.next = max_signed (outbits)
        elif (y3 < min_signed (outbits)):
            output.next = min_signed (outbits)
        else:
            output.next = y3

    return sat_rnd_logic
    
But this is not:

def sat_rnd (x, bits, outbits, output):
    @always_comb
    def sat_rnd_logic():
        y1 = intbv (int (x >> (bits-1)), *extrema_signed (len (x)))
        y2 = intbv (int (y1 + 1), *extrema_signed (len (x)))
        y3 = intbv (int (y2 >> 1), *extrema_signed (len (x)))
        if (y3 > max_signed (outbits)):
            output.next = max_signed (outbits)
        elif (y3 < min_signed (outbits)):
            output.next = min_signed (outbits)
        else:
            output.next = y3

    return sat_rnd_logic
    
 python test3.py
Traceback (most recent call last):
  File "test3.py", line 174, in <module>
    verilog()
  File "test3.py", line 161, in verilog
    toVerilog (Decimator, clock, en, x, log2_n, count, result, reset)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_toVerilog.py", 
line 115, in __call__
    genlist = _analyzeGens(arglist, h.absnames)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
155, in _analyzeGens
    compiler.walk(ast, v)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 106, in walk
    walker.preorder(tree, visitor)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 63, in preorder
    self.dispatch(tree, *args) # XXX *args make sense?
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
    self.dispatch(child, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
    self.dispatch(child, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
261, in visitFunction
    self.visitChildNodes(node, *args)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_misc.py", line 
137, in visitChildNodes
    self.visit(n, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
    self.dispatch(child, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
240, in visitAssign
    self.visit(node.expr, *args)
  File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line 
244, in visitCallFunc
    self.raiseError(node, _error.NotSupported, "extra positional arguments")
  File "/usr/lib/python2.5/site-packages/myhdl/conversion/_misc.py", line 
128, in raiseError
    raise ConversionError(kind, msg, info)

Re: [myhdl-list] AttributeError: '_ConvertFunctionVisitor' object has no attribute 'funcBuf'

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

Neal Becker wrote:
> I'm still getting my head around this verilog stuff.  I think it's working 
> now.
> 
> If I want to translate something to verilog, I need to remember to write 
> verilog-ish versions of all the functions it uses.

As said before, if you can keep things outside generators, e.g. for
computation of constants, the code can be arbitrarily complex.

Otherwise, you're correct that there are important limitations.

Also, it seems you found a bug in the convertor when an ordinary function
calls another one.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a hardware description language:
    http://www.myhdl.org

Re: [myhdl-list] intbv improvement?

[Neal B. <ndb...@gm...>]

Jan Decaluwe wrote:

> Neal Becker wrote:
>> I would find this addition to the intbv constructor helpful:
>> 
>> class intbv(object):
>>     __slots__ = ('_val', '_min', '_max', '_nrbits')
>>     
>>     def __init__(self, val=None, min=None, max=None, _nrbits=0,
>> is_signed=False):
>>         if _nrbits:
>>             if (is_signed):
>>                self._min = -1 << (_nrbits-1)
>>                self._max = ~(-1 << (_nrbits-1))
>>             else:
>>               self._min = 0
>>               self._max = 2**_nrbits
> 
> I infer that you want to use _nrbits as an end user also?
> This is not how the type is set up. _nrbits is intended
> to be a private parameter of the constructor for internal
> use.
> 
> One of the goals of intbv is to get rid of unsigned/signed
> thinking as much as possible, and push the use of fine-grained
> range control as high-level alternative.
> (I'm actually writing a paper about this, almost finished.)
> 
> Jan
> 

I want to make sure my value is converted to verilog signed.  AFAICT, the 
only way I have now to do this is with intbv specifying min and max, rather 
than nrbits?  That's OK, but a little inconvenient.