myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Characterstringhandling

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

Thomas Traber wrote:

> I would use:
> 
>   a.next = ord("y")
>   if a == ord("y"):
> 
> But that also does not work. The verilog code looks like this:
> 
>   if ((char == ord(y))) begin
> 
> It does not seem to be Verilog syntax, is it?
> Maybe the conversion result should be
> 
>   if  ((char == 121)) begin
> 
> Would you agree?

Yes. This is the compromise that I hoped you would suggest :-) It consists
in adding support for a built-in function, something which has already
been done for a few others.

> Maybe I can supply a patch for this - but it seems to be not that easy.

It's probably much easier than some other things you did already :-)

You know what - I'll specify the patch. Don't feel obliged, but if
you will do it let me know, otherwise this serves as reminder :-)
Ideally you would use mercurial, this would be a nice test of that
flow. (See http://myhdl.jandecaluwe.com/doku.php/dev:repo)

Support for 'ord'
-----------------
* in _toVerilog.py and _toVHDL.py, look in visitCallFunc how 'int'
is handled. 'ord' will be similar.
* check whether the argument is a one-char constant string -> otherwise error
* use 'ord' on the argument to calculate the integer node value

Bonus: be more strict on which built-ins are supported
------------------------------------------------------
* in _analyze.py, look in visitCallFunc
* the test 'f in builtinObjects' now passes for any builtin - it should
only pass for builtins actually supported: (int, long, bool, len, ord ...)

Ideally:
--------
* Run the tests in test/conversion to see if nothing breaks. (Note: for
test/conversion/toVerilog, cosimulation needs to be installed. In the
other dirs in test/conversion, cosimulation is not needed, but GHDL
and either icarus or cver need to be installed - see the Makefiles.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] augmented operators

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

Thomas Traber wrote:
> The MyHDL todo list had a topic 
> 
> * augmented operators
> http://myhdl.jandecaluwe.com/doku.php/dev:todo:0.6?do=show#to_do
> 
> This topic is crossed out.
> 
> But augmented operators still are causing an error.
> 
> I tried it to implement it in _Signal.py. I think it works correct in
> the simulation. I also see no reason why it should not work for the
> toVerilog conversion.
> 
> Jan, do you have any special reason not to implement it?
> Lack of time? No need?

No, I must at least have thought that it was implemented :-)

But perhaps your reference to _Signal.py gives a clue. Augmented
operators are only implemented for intbv instances, where the
meaning is obviously the same as for Python integers.

I don't see how it could be done for signals, because I want
signal assignments to be explicitly different from "variable"
assignments (that is, through the .next attribute.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Characterstringhandling

[Thomas T. <tho...@de...>]

Jan Decaluwe wrote:

> Mm. I want the intbv to be almost an int, not a string, and
> I want MyHDL to preserve strong typing. This is not perl :-)
> 
> Why can't you use enumerated types for your purpose?
> 
> command = enum("YES", "NO", "MAYBE")
> 
> a.next = command.YES
> if a == command.NO:

Besides it is a lot of typing ("strong typing" ;-) ) it does not help, 
when parsing real text strings.
But I don't want to start a philosophical discussion about any kind of 
typing.

I would use:

  a.next = ord("y")
  if a == ord("y"):

But that also does not work. The verilog code looks like this:

  if ((char == ord(y))) begin

It does not seem to be Verilog syntax, is it?
Maybe the conversion result should be

  if  ((char == 121)) begin

Would you agree?

Maybe I can supply a patch for this - but it seems to be not that easy.

[myhdl-list] augmented operators

[Thomas T. <tho...@de...>]

The MyHDL todo list had a topic 

* augmented operators
http://myhdl.jandecaluwe.com/doku.php/dev:todo:0.6?do=show#to_do

This topic is crossed out.

But augmented operators still are causing an error.

I tried it to implement it in _Signal.py. I think it works correct in
the simulation. I also see no reason why it should not work for the
toVerilog conversion.

Jan, do you have any special reason not to implement it?
Lack of time? No need?


Thomas

Re: [myhdl-list] Characterstringhandling

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

Thomas Traber wrote:
> Here comes an explanation of my bug report about improper character 
> string handling.
> 
> The following does not work:
> 
>     a = Signal(intbv()[8:])
>     a.next = "y"
>     if a == "n":
>         ...
> 
> IMO should myhdl at least character strings with length of one like an 
> integer ( ord(character) ).
> 
> I use this charcter handling for a simple command parser.

Mm. I want the intbv to be almost an int, not a string, and
I want MyHDL to preserve strong typing. This is not perl :-)

Why can't you use enumerated types for your purpose?

command = enum("YES", "NO", "MAYBE")

a.next = command.YES
if a == command.NO:
    ...


Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium

[myhdl-list] Characterstringhandling

[Thomas T. <tho...@de...>]

Here comes an explanation of my bug report about improper character 
string handling.

The following does not work:

	a = Signal(intbv()[8:])
	a.next = "y"
	if a == "n":
		...

IMO should myhdl at least character strings with length of one like an 
integer ( ord(character) ).

I use this charcter handling for a simple command parser.

I have attached a demonstration code and the verilog output - as it 
should be, e.g. is on my installation. I also attached the diff of my 
installation - it is incomplete, but works for my current porposes, 
including conversion to Verilog.

For strings with more than one character things are more difficult...

BTW:
This "//pass" lines in stringbugfunc.v are caused by another simple 
patch to avoid the print-with-more-than-one-argument warning.

Re: [myhdl-list] always_comb from a change in Signal list does not get triggered

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

Günter Dannoritzer wrote:
> Hi,
> 
> I am trying to create a word wide shift register and the output register 
> is connected with an always_comb to the output signal of the function. 
> Now this always_comb gets only triggered one time, even so I see the 
> output register signal change during the shift operation.
> 
> This is my code:
> 
> def pipe(clk,en,din, dout, N,width):
> 
>   pipe = [Signal(intbvSigned(width)) for i in range(N)]
> 
>   print "N: ", N
> 
>   @always(clk.posedge)
>   def rtl1():
>     if en:
>       for i in downrange(N,1):
>         print "i: %d"% i
>         pipe[i].next = pipe[i-1]
>       pipe[0].next = din
>     print "pipe: %s"% pipe
> 
> 
>   @always_comb
>   def rtl2():
>     print "pipe[N-1]: %d"% pipe[N-1]
>     dout.next = pipe[N-1]
> 
> 
>   return instances()
> 
> 
> 
> I attached the test bench for it. Running the test bench will fill the 
> pipe with values and print the output dout.
> 
> I changed the code so that the pipe memory has only N-1 entries and dout 
> being the Nth register, which worked fine. I just would like to know 
> what I am doing wrong so that the always_comb gets not triggered anymore?

always_comb doesn't understand lists of signals, or any composite type
that would contain signals for that matter. It only can handle signals
with a plain name in the code.

Handling composite types such as lists of signals raises many question
e.g. about efficiency. Also, this is certainly a construct that people
will expect to be convertible - which raises many question on itself.

Obviously the current situation were you are not warned is not OK. But I
think the best thing to do is explicity check for the types that you can
use and give an error otherwise, and ask people to use an explicit
"always" to control exactly what they want.

BTW, in this case you wouldn't need an "always_comb" block at all, you
could just write:

     dout = pipe[N-1]

to make dout and "alias" of the last pipe signal.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Günter Dannoritzer wrote:

> Now that brings me back to think about the idea of an extra function 
> based on concat() that is convertible with toVerilog/VHDL. That would 
> not add extra code to intbv, but would allow to create an intbv instance 
> with bit slices and allow to manipulate the sign.

I would prefer to add a new method to intbv instead of a function in the
myhdl namespace. Adding a new function always feels a bit like a "defeat"
to me - when possible I prefer methods to keep namespaces clean and tie
operators to their type.

"concat" is a function because it has to work on several different types.

> So what about having a function like:
> 
>    concatSigned(sign, slice1, [slice2, ...[sliceN]..])
> 
> It will return an intbv by concatenating the slice(s) and setting the 
> sign based on the specified sign.

With the intbv.signed() method, this could be done as follows:

      concat(....).signed()

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Blubaugh, David A. wrote:
> Jan,
> 
> 
> It looks as though I will have to utilize MyHDL for my Master's thesis.

Sounds like you're not too happy with it, I hope it's not that bad :-)

> In any case, I was wondering if there is a way to utilize fixed-point
> within MyHDL as a way to successfully emulate floating-point?

MyHDL is a pure python package, and designed in such a way that you
should be able to use anything that Python offers for modeling.
In particular, you should be able to use any number representation
from the standard library or third parties in your models.

I anticipate that you're going to ask about conversion and so I want
to stress once again: MyHDL modeling is unconstrained, but conversion
is very constrained. Conversion is limited to the few datatypes as
described in the manual. in particular, in terms of number representation,
you're limited to integers.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Does anyone have a reasonable design with Myhdl

[Thomas T. <tho...@de...>]

Hi Asif,

> Can anybody point me to a reasonable modelling of a design with MyHDL and
> also the verilog equivalent of it? I have some commercial simulator and
> wanted to see how this one scales with that.

On the myhdl website are some nice examples,
i.e. I recently uploaded the myhdl code for sine wave generator using a 
sigma delta dac.

http://myhdl.jandecaluwe.com/doku.php/projects:sinewave_generator

It is based on a modified version of the cordic calculations in the 
cookbook example and of a modified SD-DAC design originally made by 
George Pantazopoulos (BTW: his website and email don't work anymore).

I did just myhdl python simulation with it - no cosimultion neither with 
   cver nor with quartus 
(http://myhdl.jandecaluwe.com/doku.php/projects:cosimulation_with_quartus).
But I successfully ran it on a Cyclone II.

Thomas

[myhdl-list] Does anyone have a reasonable design with Myhdl

[etv q. <etv...@gm...>]

Hi

Can anybody point me to a reasonable modelling of a design with MyHDL and
also the verilog equivalent of it? I have some commercial simulator and
wanted to see how this one scales with that.

Regards
Asif

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Blubaugh, D. A. <dbl...@be...>]

Jan,


It looks as though I will have to utilize MyHDL for my Master's thesis.
In any case, I was wondering if there is a way to utilize fixed-point
within MyHDL as a way to successfully emulate floating-point?  


Thanks,


David Blubaugh 

-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of Jan
Decaluwe
Sent: Thursday, June 19, 2008 4:34 AM
To: myh...@li...
Subject: Re: [myhdl-list] Slicing an unsigned intbv to a signed one

Christopher L. Felton wrote:

> 
> I agree about the targeted use case, that most should design with the 
> intended functionality.  But it was also indicated that backward 
> support (if you can do it in Verilog/VHDL you can do it in MyHDL) 
> should be included.

That is still the goal.

>>>> The goal is that MyHDL should make certain things easier, while 
>>>> keeping other things at least as easy as in Verilog/VHDL.
>>>>
>>>> I believe that using intbv's can avoid unsigned/signed confusion 
>>>> often found in VHDL/Verilog for numeric operations.
>>>> But of course, hardware designers also have a need to access and 
>>>> manipulate bit representations. I believe it's possible to make 
>>>> this as easy as in VHDL/Verilog. But we may not be there yet 
>>>> completely, as this case shows.
> 
>> The proposals I'm seeing do something else: they change the value of 
>> the operand based on the nature of the assignment target. That is 
>> much more tricky and implicit. For example, consider:
>>
>>     a = intbv(0, min=-8, max=8)
>>
>> Suppose we do sign extension based on the "sign" bit, then after
>>
>>     a[:] = 15    # '1111'
>>
>> a's value would be -1. And after:
>>
>>     a[:] = 31    # '11111'
>>
>> it would also be -1. Yet with:
>>
>>     a[:] = 23    # '10111'
>>
>> you would get a bound check error. Mm, I don't like it.
> 
> Good point, trying to add this "feature"  (Verilog/VHDL hardware type
> support) looks like it would be too kludgy.  At this juncture do you 
> suggest the implementation be left as is?  This would be one of the 
> cases where it is not pratical to make things as easy as Verilog/ 
> VHDL?

No, I think the OP has a point that should be solved. I just want a more
"explicit" solution (Explicit is better than implicit!)

Let's go back to the OP's use case:

a = intbv(0)[8:]
b = intbv(0, min=-8, max=8)

and he wants to assign a 4-bit slice of a to b, preserving the bit
pattern.

I propose to add a method that does sign extension in the "obvious"
way. The proper name might be extendSign() but I don't object signed():

b[:] = a[4:].signed()

Remarks:
- we don't "loose" anything against Verilog or VHDL: in those languages
you need similar casting (well, I'm not entirely sure about Verilog :-))
- you could use this in expressions, e.g. b[:] = a[4:].signed() + 1, not
just assignments
- conversion to Verilog/VHDL may be easy
- note that methods are also the way to implement operators in Python.
E.g. "not a" is just syntactic sugar for a.__invert__()

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you receive 
this e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:

> 
> I agree about the targeted use case, that most should design with the  
> intended functionality.  But it was also indicated that backward  
> support (if you can do it in Verilog/VHDL you can do it in MyHDL)  
> should be included.

That is still the goal.

>>>> The goal is that MyHDL should make certain things easier, while
>>>> keeping other things at least as easy as in Verilog/VHDL.
>>>>
>>>> I believe that using intbv's can avoid unsigned/signed
>>>> confusion often found in VHDL/Verilog for numeric operations.
>>>> But of course, hardware designers also have a need to access and
>>>> manipulate bit representations. I believe it's possible to make
>>>> this as easy as in VHDL/Verilog. But we may not be there yet
>>>> completely, as this case shows.
> 
>> The proposals I'm seeing do something else: they change the value of
>> the operand based on the nature of the assignment target. That is much
>> more tricky and implicit. For example, consider:
>>
>>     a = intbv(0, min=-8, max=8)
>>
>> Suppose we do sign extension based on the "sign" bit, then after
>>
>>     a[:] = 15    # '1111'
>>
>> a's value would be -1. And after:
>>
>>     a[:] = 31    # '11111'
>>
>> it would also be -1. Yet with:
>>
>>     a[:] = 23    # '10111'
>>
>> you would get a bound check error. Mm, I don't like it.
> 
> Good point, trying to add this "feature"  (Verilog/VHDL hardware type  
> support) looks like it would be too kludgy.  At this juncture do you  
> suggest the implementation be left as is?  This would be one of the  
> cases where it is not pratical to make things as easy as Verilog/ 
> VHDL? 

No, I think the OP has a point that should be solved. I just want
a more "explicit" solution (Explicit is better than implicit!)

Let's go back to the OP's use case:

a = intbv(0)[8:]
b = intbv(0, min=-8, max=8)

and he wants to assign a 4-bit slice of a to b, preserving the bit
pattern.

I propose to add a method that does sign extension in the "obvious"
way. The proper name might be extendSign() but I don't object signed():

b[:] = a[4:].signed()

Remarks:
- we don't "loose" anything against Verilog or VHDL: in those languages
you need similar casting (well, I'm not entirely sure about Verilog :-))
- you could use this in expressions, e.g. b[:] = a[4:].signed() + 1,
not just assignments
- conversion to Verilog/VHDL may be easy
- note that methods are also the way to implement operators in Python.
E.g. "not a" is just syntactic sugar for a.__invert__()

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

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

Christopher L. Felton wrote:

> Why do you believe there has been a persistence not to adopt a higher  
> level synthesis approach?  Why do so many still want to only "think  
> hardware"?  A general tendency to avoid change?  Momentum, course  
> work, etc is wrapped around, "thinking hardware"?  Obviously there are  
> scenarios where "thinking hardware" can get you into trouble.  Are  
> there scenarios when not "thinking hardware" can be detrimental?

Certainly: thinking hardware is often suboptimal and inefficient,
but not thinking hardware may get you into trouble. This shows
that "thinking hardware" is useless as a paradigm for HDL design.

I think that HDL design is a special kind of software development,
and that a synthesis tool is a compiler. So for a better paradigm,
I look to the software world. You want to be as productive as possible,
and therefore raise the abstraction level, without being inefficient.
The paradigm to achieve that is: "Understand your compiler".
I think that's what the best software designers do. You have to
understand what you can leave to your compiler to solve, and what
you should worry about yourself.

For example, take the case of "mixing blocking and non-blocking
assignments". Of course I want to use variable semantics to
describe complex behavior if that's possible.  So the remaining
question is: can a synthesis tool handle this efficiently? It may
take you some thinking time and experiments to understand it fully,
but the answer is yes. So I want to use it. And I certainly
don't accept any constraints from people who did less thinking
and less experiments on the matter than I did myself.

To me, the above is obvious and even trivial, but as you point
out, it's not "mainstream" in the hardware design community, and
you ask why. Here are some hypotheses that I use to understand
why my own projections have been so wrong :-) :

* perhaps hardware design (and its efficiency) are not *that*
important in the overall process of building systems;

* perhaps the software-oriented talent that might make a difference
is attracted by "more exciting" industries;

* perhaps most of us remain schematic-entry designers, that only use
HDL synthesis because its benefits are enormous even when used
inefficiently. The code we write is a reflection of the schematic
that we are drawing in our head.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> 
> The use case that I really want to push with the intbv is that of
> the VHDL constrained integer type. My goal is that designers forget
> about signed/unsigned for numeric operations.
> 
> For example, when you need a counter that has to count from -1 to 5,
> I hope that people will construct it as
>      intbv(0, min=-1, max=6)
> and not as
>      intbv(0, min=-8, max=8)
> 
> Why? Because I believe such constraints give you the best assertions that
> you'll ever have. My counters usually don't count between powers of 2, but
> in my code I systematically make bound errors. The first construction gives
> you instant run-time feedback about the error, the second may not.
> 
...
> 
> The proposals I'm seeing do something else: they change the value of
> the operand based on the nature of the assignment target. That is much
> more tricky and implicit. 

...
> 
> Of course, you could make things more sophisticated by only doing
> sign-extension if the bit width of rhs and lhs are equal. But this
> is getting a little too tricky for my taste.

I see you point and agree that adding this feature to intbv looks like 
to specific.

Now that brings me back to think about the idea of an extra function 
based on concat() that is convertible with toVerilog/VHDL. That would 
not add extra code to intbv, but would allow to create an intbv instance 
with bit slices and allow to manipulate the sign.

So what about having a function like:

   concatSigned(sign, slice1, [slice2, ...[sliceN]..])

It will return an intbv by concatenating the slice(s) and setting the 
sign based on the specified sign.

The toVerilog/VHDL converter would then be able to map that direct to a 
concatenation of bits with the result being of type signed().

Guenter

Re: [myhdl-list] intbv with min -1, max 1 has 2 bits?

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:

>>
>>2) why not a 1 bit signed intbv
>>That seems to be a bug. The one bit can function as a sign bit in
>>this (corner) case. I guess the test should really be:
>>
>>                 ...
>>                 elif max <= 1: # not 0
>>                     _nrbits = len(bin(min))
>>                 ...

I have implemented this fix and pushed it to the public repository.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

[Christopher L. F. <cf...@uc...>]

On Jun 16, 2008, at 12:20 PM, Jan Decaluwe wrote:

> Günter Dannoritzer wrote:
>> Jan Decaluwe wrote:
>
>>> This is in fact also one of my career-long battles :-) Basically,  
>>> I insist that
>>> HDL designers need both "variable" and "signal" semantics, also in  
>>> clocked
>>> processes. I agree that with languages like VHDL and MyHDL, this  
>>> is easier
>>> to understand, because those HDLs make a difference between  
>>> "variable" and
>>> "signal" objects.
>>
>> Have you considered writing a book about that? I feel like there is a
>> lot that could be taught, not available through books yet and it  
>> would
>> be a good publicity for MyHDL.
>
> Yes, I have, about this and related issues. Almost 15 years ago.
> I'm serious!
> Title: 'Efficient HDL synthesis'
> Subtitle: 'Avoiding the pitfalls of "thinking hardware"'
>
> I never started writing because I always thought that such a book
> would be obsolete by the time it would be published. I have never
> been more wrong.
>
> However (before you start to pity me) I have done something with
> those ideas which is probably more satisfactory: I co-founded
> a company, Easics, in which I'm still a director. I'm quite proud
> on Easics, because we have a history of design successes, even when
> our methodology is not exactly mainstream.
>
> Also, over the years I have posted about these matters on
> comp.lang.verilog/vhdl, trying everything from arguments,
> over irony and sarcasm, to gross insults :-)
> Without much success though.
>

Why do you believe there has been a persistence not to adopt a higher  
level synthesis approach?  Why do so many still want to only "think  
hardware"?  A general tendency to avoid change?  Momentum, course  
work, etc is wrapped around, "thinking hardware"?  Obviously there are  
scenarios where "thinking hardware" can get you into trouble.  Are  
there scenarios when not "thinking hardware" can be detrimental?

Good stuff, thanks for all the information!

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Christopher L. F. <cf...@uc...>]

On Jun 16, 2008, at 1:35 PM, Jan Decaluwe wrote:

> Christopher L. Felton wrote:
>> We had a similar issue/discussion with the invert (not) function of  
>> the
>> intbv class.  There seems to be a couple different specific use  
>> cases of
>> the intbv.
>>
>> 1. Generic bit container, this is then MyHDL intbv when there is no  
>> min,
>> no max value.  This is similar to the Verilog bit vector (reg [],  
>> wire
>> []) or VHDLs std_logic_vector.
>>
>> 2. Unsigned number, this is the MyHDL min=0, similar to the Verilog  
>> bit
>> vector, and VHDL unsigned()
>>
>> 3. Signed numbers, this is the MyHDL min is < 0,  similar to the  
>> Verilog
>> signed (reg or wire, Verilog 2001 and later) and VHDL signed()
>
> The use case that I really want to push with the intbv is that of
> the VHDL constrained integer type. My goal is that designers forget
> about signed/unsigned for numeric operations.

I agree about the targeted use case, that most should design with the  
intended functionality.  But it was also indicated that backward  
support (if you can do it in Verilog/VHDL you can do it in MyHDL)  
should be included.

>>> The goal is that MyHDL should make certain things easier, while
>>> keeping other things at least as easy as in Verilog/VHDL.
>>>
>>> I believe that using intbv's can avoid unsigned/signed
>>> confusion often found in VHDL/Verilog for numeric operations.
>>> But of course, hardware designers also have a need to access and
>>> manipulate bit representations. I believe it's possible to make
>>> this as easy as in VHDL/Verilog. But we may not be there yet
>>> completely, as this case shows.

>
> The proposals I'm seeing do something else: they change the value of
> the operand based on the nature of the assignment target. That is much
> more tricky and implicit. For example, consider:
>
>     a = intbv(0, min=-8, max=8)
>
> Suppose we do sign extension based on the "sign" bit, then after
>
>     a[:] = 15    # '1111'
>
> a's value would be -1. And after:
>
>     a[:] = 31    # '11111'
>
> it would also be -1. Yet with:
>
>     a[:] = 23    # '10111'
>
> you would get a bound check error. Mm, I don't like it.

Good point, trying to add this "feature"  (Verilog/VHDL hardware type  
support) looks like it would be too kludgy.  At this juncture do you  
suggest the implementation be left as is?  This would be one of the  
cases where it is not pratical to make things as easy as Verilog/ 
VHDL?  Or try to find a more elegant implementation that will first  
not break the constraint integer model and second support bit  
manipulation while maintaining sign?

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:
> We had a similar issue/discussion with the invert (not) function of the 
> intbv class.  There seems to be a couple different specific use cases of 
> the intbv.
> 
> 1. Generic bit container, this is then MyHDL intbv when there is no min, 
> no max value.  This is similar to the Verilog bit vector (reg [], wire 
> []) or VHDLs std_logic_vector.
> 
> 2. Unsigned number, this is the MyHDL min=0, similar to the Verilog bit 
> vector, and VHDL unsigned()
> 
> 3. Signed numbers, this is the MyHDL min is < 0,  similar to the Verilog 
> signed (reg or wire, Verilog 2001 and later) and VHDL signed()

The use case that I really want to push with the intbv is that of
the VHDL constrained integer type. My goal is that designers forget
about signed/unsigned for numeric operations.

For example, when you need a counter that has to count from -1 to 5,
I hope that people will construct it as
     intbv(0, min=-1, max=6)
and not as
     intbv(0, min=-8, max=8)

Why? Because I believe such constraints give you the best assertions that
you'll ever have. My counters usually don't count between powers of 2, but
in my code I systematically make bound errors. The first construction gives
you instant run-time feedback about the error, the second may not.

> The current implementation seems have all the properties that Jan 
> discussed, high level approach while maintaining the low-level hardware 
> access for cases 1 and 2.  For case 3 there are the issues that Günter 
> pointed out, you can't modify the msb and maintain the state of the 
> signed number (or pass the bound checks). 
> 
> Could we do something similar as the invert solution (not) and use the 
> knowledge of the type of number being represented and modify the bits 
> accordingly?

Certainly, but I think the question really is how. The invert problem
was solved by defining what the operator should return depending on
the nature of the operand. We could do a similar thing here using
a method that would do sign-extension. Given the "same" bit pattern,
the result would be different for an "unsigned" versus a "signed".

The proposals I'm seeing do something else: they change the value of
the operand based on the nature of the assignment target. That is much
more tricky and implicit. For example, consider:

     a = intbv(0, min=-8, max=8)

Suppose we do sign extension based on the "sign" bit, then after

     a[:] = 15    # '1111'

a's value would be -1. And after:

     a[:] = 31    # '11111'

it would also be -1. Yet with:

     a[:] = 23    # '10111'

you would get a bound check error. Mm, I don't like it.

Of course, you could make things more sophisticated by only doing
sign-extension if the bit width of rhs and lhs are equal. But this
is getting a little too tricky for my taste.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:

>>This is in fact also one of my career-long battles :-) Basically, I insist that
>>HDL designers need both "variable" and "signal" semantics, also in clocked
>>processes. I agree that with languages like VHDL and MyHDL, this is easier
>>to understand, because those HDLs make a difference between "variable" and
>>"signal" objects.
> 
> Have you considered writing a book about that? I feel like there is a 
> lot that could be taught, not available through books yet and it would 
> be a good publicity for MyHDL.

Yes, I have, about this and related issues. Almost 15 years ago.
I'm serious!
Title: 'Efficient HDL synthesis'
Subtitle: 'Avoiding the pitfalls of "thinking hardware"'

I never started writing because I always thought that such a book
would be obsolete by the time it would be published. I have never
been more wrong.

However (before you start to pity me) I have done something with
those ideas which is probably more satisfactory: I co-founded
a company, Easics, in which I'm still a director. I'm quite proud
on Easics, because we have a history of design successes, even when
our methodology is not exactly mainstream.

Also, over the years I have posted about these matters on
comp.lang.verilog/vhdl, trying everything from arguments,
over irony and sarcasm, to gross insults :-)
Without much success though.

> I have to say you have put a lot of ingenuity in MyHDL and every time I 
> come back to it I learn something new.

MyHDL can be interpreted as another opportunity for me to stop whining
and do something positive with my ideas about how things ought to be.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Christopher L. F. <cf...@uc...>]

Yes, that is a much better solution.  Implementing something similar  
appears to achieve the goals.  As before I did not implement anything  
for the slicing to test.  The slicing approach would be similar (and  
testing probably pretty weak, need to test other bit widths, unsigned,  
etc.).

------ Example Output ------
 >>> x = intbv(7, min=-8, max=8)
 >>> x
intbv(7)
 >>> str(x)
'0111'
 >>> x[3] = 1
 >>> x
intbv(-1L)
 >>> str(x)
'1111'
 >>> x[0] = 0
 >>> x
intbv(-2L)
 >>> str(x)
'1110'
 >>> x[1] = 0
 >>> x
intbv(-4L)
 >>> str(x)
'1100'
 >>> x[2] = 0
 >>> x
intbv(-8L)
 >>> str(x)
'1000'
 >>> x[3] = 0
 >>> x
intbv(0L)
 >>> str(x)
'0000'
 >>> x[3] = 1
 >>> x
intbv(-8L)
 >>> str(x)
'1000'
 >>> x[:] = 3
 >>> x
intbv(3L)
 >>> str(x)
'0011'
 >>> x[3] = 1
 >>> x
intbv(-5L)
 >>> str(x)
'1011'
 >>>

----- Diff ------

154,163d153
<
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<             # CFELTON EDIT
<             # Create a sign bit mask
<             if self._min < 0 and key == self._nrbits-1:
<                 smask = (-1 << self._nrbits-1)
<             else:
<                 smask = 0
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<
165c155
<                 self._val |= ((1L << i) | smask)
---
 >                 self._val |= (1L << i)
167,169c157
<                 self._val &= (~(1L << i) & ~smask)
<
<
---
 >                 self._val &= ~(1L << i)
196d183
<
449,455c436
<         s = ''
<         for i in range(self._nrbits):
<             if self._val & (1 << i):
<                 s = '1' + s
<             else:
<                 s = '0' + s
<         return s #str(self._val)
---
 >         return str(self._val)


On Jun 13, 2008, at 12:20 PM, Günter Dannoritzer wrote:

> Christopher L. Felton wrote:
>> Ok, below was my quick test to double check if it could be done.  A
>> real implementation probably need more thought (if feasible at all).
> ...
>
> I think what you need to do is not just multiply by -1, but create a
> mask that is ORed with the actual number. If the sign bit gets set,  
> the
> mask will be all 1 upwards from the sign bit and all 0 down to bit 0.
> Then OR that with the current intbv value.
>
> So instead of this:
>
>   self._val = -1 * self._val
>
> do this:
>
>   self._val = (-1 << self._nrbits-2) | self._val
>
> This is basically a merging between the existing bits below the sign  
> bit
> and the sign change to negative.
>
> For clearing the sign bit the simplest way would be to slice the bits
> below the sign bit out and return them as a new intbv value.
>
> Guenter
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Christopher L. Felton wrote:
> Ok, below was my quick test to double check if it could be done.  A  
> real implementation probably need more thought (if feasible at all).
...

I think what you need to do is not just multiply by -1, but create a 
mask that is ORed with the actual number. If the sign bit gets set, the 
mask will be all 1 upwards from the sign bit and all 0 down to bit 0. 
Then OR that with the current intbv value.

So instead of this:

   self._val = -1 * self._val

do this:

   self._val = (-1 << self._nrbits-2) | self._val

This is basically a merging between the existing bits below the sign bit 
and the sign change to negative.

For clearing the sign bit the simplest way would be to slice the bits 
below the sign bit out and return them as a new intbv value.

Guenter

[myhdl-list] Using the MyHDL mercurial repository

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

As mentioned earlier, there is now a public MyHDL mercurial
repository:

    http://myhdl.sourceforge.net/hg/myhdl

You can use this url to browse the repository and its history.

But you can also use it with mercurial, assuming you have
it installed. Here's an overview:

$ hg clone http://myhdl.sourceforge.net/hg/myhdl myhdl

This make clone of the repository in a local 'myhdl' directory.
In that directory you can now do the following:

$ hg in
to check if there are new changesets.

$ hg pull
to get new changesets

$ hg update
to update the workspace with new changesets

Furthermore, you can make changesets from your own patches.

$ hg commit
to create a new changeset based upon your local changes
(You may want to do this in another clone)

You can not directly push your changesets to the sourceforge
repository, but you can use 'hg bundle' to make a changeset
file that you can send me. I could use such a file to review
changesets, and commit and push them if I like them.

More info about mercurial can be found here:

     http://www.selenic.com/mercurial/wiki/

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:
> Ok, below was my quick test to double check if it could be done.  A  
> real implementation probably need more thought (if feasible at all).
> 
> With that said, I do think this approach will work.  Even if you have  
> a non power of 2 limit you still need N bits to represent the max and  
> min values.  If the msb of the "bit container" is modified it will  
> change the sign.   

I meant non-power of 2 values, not the limits, and I don't
think it works:

---
 >>> x = intbv(7, min=-8, max=8)
 >>> bin(x)
'111'
 >>> x[3] = 1
1 1 15 -8 8 4
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/home/jand/dev/myhdl/myhdl/_intbv.py", line 173, in __setitem__
     self._checkBounds()
   File "/home/jand/dev/myhdl/myhdl/_intbv.py", line 89, in _checkBounds
     (self._val, self._min))
ValueError: intbv value -15 < minimum -8
---

Should give -1, right?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] intbv with min -1, max 1 has 2 bits?

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

Günter Dannoritzer wrote:

> That feature is really great. What I haven't understood yet is, does 
> sourceforge now support hg repositories or does hg export the repository 
> as a bunch of html pages, so you can basically host that repository on 
> any basic html page without extra software?

No, it's the real mercurial web interface of a repository.

Sourceforge doesn't officially support mercurial, but I followed this recipe:
     http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge

> Is there a way to check the source out with hg?

Yes - I'll explain this shortly in a separate post.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com