myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MyHDL logic synthesis

[Newell J. <pil...@gm...>]

On Sat, Mar 21, 2009 at 6:37 PM, Newell Jensen <pil...@gm...> wrote:

> Jan,
>
> Have you ever thought of giving MyHDL synthesis capabilities?  Icarus
> Verilog can synthesis designs and personally, I would find it a huge
> advantage to not have to go the MyHDL --> Verilog route as there are many
> things that are not convertable such as delays etc.


After re-reading this I realize that using a delays wasn't a good example.


>
>
> I haven't looked into what would need to happen to make this happen but I
> wanted to ask you to see what you thought about this.
>
> Personaly, writing everything in Python would be a dream come true.
>
> --
> Newell
>



-- 
Newell

[myhdl-list] MyHDL logic synthesis

[Newell J. <pil...@gm...>]

Jan,

Have you ever thought of giving MyHDL synthesis capabilities?  Icarus
Verilog can synthesis designs and personally, I would find it a huge
advantage to not have to go the MyHDL --> Verilog route as there are many
things that are not convertable such as delays etc.

I haven't looked into what would need to happen to make this happen but I
wanted to ask you to see what you thought about this.

Personaly, writing everything in Python would be a dream come true.

-- 
Newell

Re: [myhdl-list] Good news: real silicon!

[Christopher F. <chr...@gm...>]

> Early 2008 I designed the digital controller in a mixed-signal
> ASIC design with MyHDL.
>
> Overall, the project has been a big success and soon the chip
> will go into high-volume production (millions).
>
> I have now received permission to write a paper about the
> role that MyHDL played in the project. Needless to say, I'm
> very proud on this accomplishment. In a project like this,
> reliability and cost are crucial. Therefore, this will also
> be my answer to those who question the reliability and
> efficiency of MyHDL-based design - an answer in silicon!
>
> I'm aware of several FPGA projects that have been completed
> successfully with MyHDL, but no ASIC projects so far. So
> I'm going to claim this is the first ASIC tape-out, unless
> someone tells me otherwise! (This can be in private email.)
>
> Best regards,
>
> Jan
>


Congratulations!!!!  That is a very big milestone for MyHDL and very
exciting.  Good job with all the hard work!

Kudos again.
Chris

[myhdl-list] Good news: real silicon!

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

Early 2008 I designed the digital controller in a mixed-signal
ASIC design with MyHDL. 

Overall, the project has been a big success and soon the chip
will go into high-volume production (millions).

I have now received permission to write a paper about the
role that MyHDL played in the project. Needless to say, I'm
very proud on this accomplishment. In a project like this,
reliability and cost are crucial. Therefore, this will also
be my answer to those who question the reliability and
efficiency of MyHDL-based design - an answer in silicon!

I'm aware of several FPGA projects that have been completed
successfully with MyHDL, but no ASIC projects so far. So
I'm going to claim this is the first ASIC tape-out, unless
someone tells me otherwise! (This can be in private email.)

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] StopIteration caught?

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

Neal Becker wrote:
> My stimulus will read from the input vectors using .next().  Eventually 
> raising StopIteration.  It appears this is being caught?  And, does not stop 
> the simulation.  Is this the expected behavior?

Yes.

A MyHDL simulation consists of a number of "simultaneously" running
generators. If StopIteration weren't caught, the simulation would stop
as soon as one of them runs out of steam. Instead, a simulation has
to run as long as some generator remains active.

Of course, the problem then is that you can easily create simulations
that run forever. Not unlike VHDL and Verilog, you have to make sure
that the simulation stops when you know you're done. For this reason,
StopSimulation is explicitly exported by myhdl and it is the intention
that users raise it.

> I guess I need to catch StopIteration myself, and raise StopSimulation if I 
> want to stop?

Yes. Note that you would probably have to raise StopSimulation also in other
cases, for example when using a for-loop instead of a generator.
Otherwise the simulation runs as long as there are events e.g.
from a clock generator.

Alternatively you can give a time duration to Simulation.run().

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com

[myhdl-list] polytopes within MYHDL

[David B. <dav...@ya...>]

Has anyone ever developed a polytopes arithmetic operation in MYHDL, which was also successfully synthesize such a design to VHDL or Verilog?  Polytopes are a sort of enumerated integer type operation.   Thanks, David Blubaugh


      

Re: [myhdl-list] StopIteration caught?

[Christopher F. <chr...@gm...>]

On Tue, Mar 17, 2009 at 12:57 PM, Neal Becker <ndb...@gm...> wrote:

> My stimulus will read from the input vectors using .next().  Eventually
> raising StopIteration.  It appears this is being caught?  And, does not
> stop
> the simulation.  Is this the expected behavior?
>
> I guess I need to catch StopIteration myself, and raise StopSimulation if I
> want to stop?
>
>
That would be my guess as well since I have only ever used raise
StopSimulation.

[myhdl-list] StopIteration caught?

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

My stimulus will read from the input vectors using .next().  Eventually 
raising StopIteration.  It appears this is being caught?  And, does not stop 
the simulation.  Is this the expected behavior?

I guess I need to catch StopIteration myself, and raise StopSimulation if I 
want to stop?

Re: [myhdl-list] strange problem

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

Neal Becker wrote:
> I'm still trying to wrap my head around myhdl.  This one is weird.

It is purely a Python scope issue. Consider:

def f():
    n = 0
    def g():
            n += 1
            print n
    g()

f()

Running this gives:

> python tmp.py
Traceback (most recent call last):
  File "tmp.py", line 8, in <module>
    f()
  File "tmp.py", line 6, in f
    g()
  File "tmp.py", line 4, in g
    n += 1
UnboundLocalError: local variable 'n' referenced before assignment


To understand what happens, consider that 'n += 1' is equivalent to:
  n = n + 1

When you *assign* to n somewhere locally, Python considers it a
local variable. As the n in the rhs as not been locally assigned yet,
you get the error.
Note that as long you don't assign to n, you would have read
access to the n in the enclosing scope.

For your case, put the initialization in the generator before
the while loop.

Jan

> 
> In my testbench/monitor, which was working, I just added a variable 
> 'input_sample_cnt':
> 
>     input_sample_cnt = 0
>     
>     @instance
>     def stimulus():
>         while (1):
>             yield clock.negedge
>             if (en):
>                 in_i.next = in_i_iter.next()
>                 in_q.next = in_q_iter.next()
>                 input_sample_cnt += 1
>                 
>             reset.next = 0
> 
> I get:
>     input_sample_cnt += 1
> UnboundLocalError: local variable 'input_sample_cnt' referenced before 
> assignment
> 
> But I've had this all along:
>     result_fd = file ('result', 'w')
>     count_fd = file ('count', 'w')
>     reset_fd = file ('reset', 'w')
>     x_fd = file ('x', 'w')
>     en_fd = file ('en', 'w')
>     oe_fd = file ('oe', 'w')
>     
>     @instance
>     def monitor():
>         while 1:
>             yield clock.posedge
>             ##print 'reset:', reset, 'en:', en, 'x:', x, 'count:', 
> to_hex(count), 'result:', to_hex(result)
>             if (oe):
>                 print >> result_fd, to_hex (result_i), to_hex (result_q)
>             print >> count_fd, to_hex (count)
>             print >> x_fd, to_hex (in_i), to_hex (in_q)
>             print >> reset_fd, to_hex (reset)
>             print >> en_fd, to_hex (en)
>             print >> oe_fd, to_hex (oe)
> 
> This seems functionally the same thing (other than using +=).  Why does this 
> latter work, but the former not?  What should I be doing instead?
> 
> 
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 


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

Re: [myhdl-list] strange problem

[Christopher F. <chr...@gm...>]

On Tue, Mar 17, 2009 at 9:59 AM, Neal Becker <ndb...@gm...> wrote:

> I'm still trying to wrap my head around myhdl.  This one is weird.
>
> In my testbench/monitor, which was working, I just added a variable
> 'input_sample_cnt':
>
>    input_sample_cnt = 0
>
>    @instance
>    def stimulus():
>        while (1):
>            yield clock.negedge
>            if (en):
>                in_i.next = in_i_iter.next()
>                in_q.next = in_q_iter.next()
>                input_sample_cnt += 1
>
>            reset.next = 0
>
> I get:
>    input_sample_cnt += 1
> UnboundLocalError: local variable 'input_sample_cnt' referenced before
> assignment
>
> But I've had this all along:
>    result_fd = file ('result', 'w')
>    count_fd = file ('count', 'w')
>    reset_fd = file ('reset', 'w')
>    x_fd = file ('x', 'w')
>    en_fd = file ('en', 'w')
>    oe_fd = file ('oe', 'w')
>
>    @instance
>    def monitor():
>        while 1:
>            yield clock.posedge
>            ##print 'reset:', reset, 'en:', en, 'x:', x, 'count:',
> to_hex(count), 'result:', to_hex(result)
>            if (oe):
>                print >> result_fd, to_hex (result_i), to_hex (result_q)
>            print >> count_fd, to_hex (count)
>            print >> x_fd, to_hex (in_i), to_hex (in_q)
>            print >> reset_fd, to_hex (reset)
>            print >> en_fd, to_hex (en)
>            print >> oe_fd, to_hex (oe)
>
> This seems functionally the same thing (other than using +=).  Why does
> this
> latter work, but the former not?  What should I be doing instead?
>
>
I am not the most knowledgeable with this issue.  But I think it is an issue
of scope.  In your example the "input_sample_cnt" is part of the testbench
and not part of the stimulus generator.  I forgot the relationship that the
"Signal" introduces.  There should be a way to use simple variables as you
outline (need to check the cookbooks and examples to refresh my memory).
If you make your variable a "Signal+, and use input_sample_cnt.next = ... it
will work.  As mentioned above  I believe there is a method to use variable
but I don't know off the top of my head.

[myhdl-list] strange problem

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

I'm still trying to wrap my head around myhdl.  This one is weird.

In my testbench/monitor, which was working, I just added a variable 
'input_sample_cnt':

    input_sample_cnt = 0
    
    @instance
    def stimulus():
        while (1):
            yield clock.negedge
            if (en):
                in_i.next = in_i_iter.next()
                in_q.next = in_q_iter.next()
                input_sample_cnt += 1
                
            reset.next = 0

I get:
    input_sample_cnt += 1
UnboundLocalError: local variable 'input_sample_cnt' referenced before 
assignment

But I've had this all along:
    result_fd = file ('result', 'w')
    count_fd = file ('count', 'w')
    reset_fd = file ('reset', 'w')
    x_fd = file ('x', 'w')
    en_fd = file ('en', 'w')
    oe_fd = file ('oe', 'w')
    
    @instance
    def monitor():
        while 1:
            yield clock.posedge
            ##print 'reset:', reset, 'en:', en, 'x:', x, 'count:', 
to_hex(count), 'result:', to_hex(result)
            if (oe):
                print >> result_fd, to_hex (result_i), to_hex (result_q)
            print >> count_fd, to_hex (count)
            print >> x_fd, to_hex (in_i), to_hex (in_q)
            print >> reset_fd, to_hex (reset)
            print >> en_fd, to_hex (en)
            print >> oe_fd, to_hex (oe)

This seems functionally the same thing (other than using +=).  Why does this 
latter work, but the former not?  What should I be doing instead?

Re: [myhdl-list] generate verilog with parameter statement

[Christopher F. <chr...@gm...>]

>
> How do I convert to verilog so that it will contain a 'parameter'
> statement?
>
> I want to specify a value via a verilog 'parameter'.  For example, I have a
> 'frame length' that will be passed to all modules via a verilog parameter.
> What would the corresponding myhdl source look like?
>
>
This isn't part of the standard conversion.  The philosophy is that your
complete design (for the most part) is implemented in MyHDL and that the
Verilog/VHDL is the output, similar to how netlists are generated by
synthesis tools but not, necessarily, directly used in the design.  There is
no conversion of the parameters since the generated code isn't intended to
be modular.  Other words the generated code is a direct representation of
the MyHDL after elaboration (after the parameters have been applied in
python etc).  See the conversion page for a better explanation than mine.

But it may not be practical to re-implement your design in MyHDL.  You may
want to start implementing some of the modules in MyHDL and incorporate it
to your design.  In that case, BOMK, you will have to use the "User-defined
code" (http://www.myhdl.org/doc/0.6/manual/conversion.html)<http://www.myhdl.org/doc/0.6/manual/conversion.html>,
__verilog__, to add the parameters you want.

Hope that helps, Good luck

[myhdl-list] generate verilog with parameter statement

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

How do I convert to verilog so that it will contain a 'parameter' statement?

I want to specify a value via a verilog 'parameter'.  For example, I have a 
'frame length' that will be passed to all modules via a verilog parameter.  
What would the corresponding myhdl source look like?

Re: [myhdl-list] essay about integer arithmetic

[Christopher F. <chr...@gm...>]

>
> However, if we're talking about abstract behavior of numbers, how about
> some fixed-point support?  One of the nice things about VHDL is the
> ability to specify negative indicies that align with negative powers of
> 2.  Verilog doesn't (or at least didn't) provide even this level of support.
>
>
>  +1
>
> I would love to have a fixed-point type with arthimetic support.  It is a
> lot of book keeping and quite messy syntactically to add /subtract/multiply
> two fixed point numbers, especially when they have different fractional
> widths.  When adding/subtracting, for example, you have to zero pad the LSBs
> until the decimal points line up prior to adding.  Something like (in
> verilog):
>
> wire [DATA_WIDTH-1:0] result = data1 + { data2, {FRAC_WIDTH1 - FRAC_WIDTH2
> {1'b0}};
>
> Furthermore, you have to know up front which one is going to have more
> fractional bits so that you can pad the appropriate one.
>
>
I think this is one of the strong benefits of MyHDL / Python.  MyHDL
provides the basics building blocks for simulation and conversion.  You can
add your packages / modules that do all the book keeping for things like
fixed-point.  This probably isn't something that should be built into the
language but additional modules and packages that can be created.

Re: [myhdl-list] essay about integer arithmetic

[Lane B. <la...@ub...>]

Andrew Lentvorski 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
>>     
>
> The essay sums up some of my gripes about the mishmash that is the whole 
> abstract behavior of numbers problem.  Nicely done.  I know that I'll 
> point more than a few newbies at it.
>
>
> I do have a bit of a gripe about statements like:
> "This situation would not persist without the widespread support of the 
> designer community."
>
> Ummmmm, no.  Most of the designers I know of hate the way a *lot* of 
> things are done in Verilog and VHDL.  Would we be using MyHDL if that 
> were not the case?  ;)  However, an individual designer has very limited 
> options to push back into these standards.  See SystemVerilog, for 
> example.  EDA vendors have a high incentive and large resources to 
> push/implement what is *profitable* to them--usefulness to the the user 
> is an orthogonal consideration.
>
>
> However, if we're talking about abstract behavior of numbers, how about 
> some fixed-point support?  One of the nice things about VHDL is the 
> ability to specify negative indicies that align with negative powers of 
> 2.  Verilog doesn't (or at least didn't) provide even this level of support.
>   
+1

I would love to have a fixed-point type with arthimetic support.  It is 
a lot of book keeping and quite messy syntactically to add 
/subtract/multiply two fixed point numbers, especially when they have 
different fractional widths.  When adding/subtracting, for example, you 
have to zero pad the LSBs until the decimal points line up prior to 
adding.  Something like (in verilog):

wire [DATA_WIDTH-1:0] result = data1 + { data2, {FRAC_WIDTH1 - 
FRAC_WIDTH2 {1'b0}};

Furthermore, you have to know up front which one is going to have more 
fractional bits so that you can pad the appropriate one.


Lane

Re: [myhdl-list] essay about integer arithmetic

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

Jan Decaluwe wrote:

> Andrew Lentvorski wrote:
> 
>> However, if we're talking about abstract behavior of numbers, how about
>> some fixed-point support?  One of the nice things about VHDL is the
>> ability to specify negative indicies that align with negative powers of
>> 2.  Verilog doesn't (or at least didn't) provide even this level of
>> support.
>> 
>> Writing, say, a delta-sigma modulator in any HDL language is kind of a
>> pain because we don't have an abstract "fixed point number" that you can
>> assert against.  Adding extra bits at either end to cover different
>> issues (Did it overflow?  I need more integer bits.  Is the error too
>> large?  I need more fractional bits.) is a pain when it interacts with
>> sign bits.
> 

I have written fixed-pt code using c++ boost::python, if anyone's interested.

Re: [myhdl-list] essay about integer arithmetic

[David B. <da...@we...>]

Jan Decaluwe wrote:
> Andrew Lentvorski wrote:
> 
>> However, if we're talking about abstract behavior of numbers, how about 
>> some fixed-point support?  One of the nice things about VHDL is the 
>> ability to specify negative indicies that align with negative powers of 
>> 2.  Verilog doesn't (or at least didn't) provide even this level of support.
>>
>> Writing, say, a delta-sigma modulator in any HDL language is kind of a 
>> pain because we don't have an abstract "fixed point number" that you can 
>> assert against.  Adding extra bits at either end to cover different 
>> issues (Did it overflow?  I need more integer bits.  Is the error too 
>> large?  I need more fractional bits.) is a pain when it interacts with 
>> sign bits.
> 
> I have no experience with this. Is there synthesis support for it?
> 

I haven't used that feature myself, but I believe it is synthesisable in 
VHDL.  It just allows indexes that don't start at 0.  However, I expect 
it would be a little awkward to use the same idea with intbv since 
negative indexes have a different meaning for slicing in Python.

>> Unrelated note: I *STILL* hate c.next = <some expression>
>>
>> The fact that c = <some expression> often silently does the wrong thing 
>> when you really meant c.next = <some expression> is very un-Pythonic.
>>
>> Did Python 3K enable some form of introspection that could do something 
>> about this?
> 
> Some MyHDL decorators (always_comb) use introspection already.
> So we could use them to do checks like the one you propose.
> Of course, this would only work when decorators are used to
> create generators.
> 
> Jan
> 
> 

Re: [myhdl-list] essay about integer arithmetic

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

Andrew Lentvorski wrote:

> However, if we're talking about abstract behavior of numbers, how about 
> some fixed-point support?  One of the nice things about VHDL is the 
> ability to specify negative indicies that align with negative powers of 
> 2.  Verilog doesn't (or at least didn't) provide even this level of support.
> 
> Writing, say, a delta-sigma modulator in any HDL language is kind of a 
> pain because we don't have an abstract "fixed point number" that you can 
> assert against.  Adding extra bits at either end to cover different 
> issues (Did it overflow?  I need more integer bits.  Is the error too 
> large?  I need more fractional bits.) is a pain when it interacts with 
> sign bits.

I have no experience with this. Is there synthesis support for it?

> Unrelated note: I *STILL* hate c.next = <some expression>
> 
> The fact that c = <some expression> often silently does the wrong thing 
> when you really meant c.next = <some expression> is very un-Pythonic.
> 
> Did Python 3K enable some form of introspection that could do something 
> about this?

Some MyHDL decorators (always_comb) use introspection already.
So we could use them to do checks like the one you propose.
Of course, this would only work when decorators are used to
create generators.

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

Andrew Lentvorski 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
> 
> The essay sums up some of my gripes about the mishmash that is the whole 
> abstract behavior of numbers problem.  Nicely done.  I know that I'll 
> point more than a few newbies at it.
> 
> 
> I do have a bit of a gripe about statements like:
> "This situation would not persist without the widespread support of the 
> designer community."
> 
> Ummmmm, no.  Most of the designers I know of hate the way a *lot* of 
> things are done in Verilog and VHDL.  Would we be using MyHDL if that 
> were not the case?  ;)  However, an individual designer has very limited 
> options to push back into these standards.  See SystemVerilog, for 
> example.

I agree that "widespread support" sounds a bit harsh and perhaps too
"active". Perhaps "compliancy" is a better description?

On the other hand, most designers I know *personally* also favor
a more abstract approach, but overall I have every indication
that this is a currently a minority view. Otherwise, wouldn't
VHDL integer subtypes be used more than they are? Wouldn't
people complain more about Verilog's bizarre integer
interpretation, instead of silently obeying the rules?

And even in the MyHDL community, I don't expect everyone to
agree. Look at some responses in this thread.

There's a reason I put this essay on my personal website
instead of myhdl.org. I expect controversy (and I'm just
starting :-)). It's not necessary to agree with my
viewpoints to be able use MyHDL successfully, so I shouldn't
alienate people unnecessarily.

Regards,

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

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

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

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


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

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


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

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


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

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

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

-a

Re: [myhdl-list] essay about integer arithmetic

[Thomas H. <th...@ct...>]

Jan Decaluwe schrieb:
> 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,

let me say that I enjoyed your essay very much. I have done some designs
in VHDL but did not have to use arithmetic in the past, other than the
usual '+1' for counters.

MyHDL to the rescue when I had to implement a serial pipelined divider:
your article explains very well the issues that I could avoid with it.

-- 
Thanks,
Thomas

Re: [myhdl-list] essay about integer arithmetic

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

Pieter wrote:
>> 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;

There we go :-)

See? If you start from the bit-widths, nobody agrees and
the result seems always wrong.

I think bit widths should be such that an integer
interpretation works as expected. However, calling this
"automating bit-widths" is really too much honour. It's
close to trivial. The trick is in the mindset.

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

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?

Note that the essay describes an existing implementation,
not something that would want for some future version.

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

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

Strong typing's answer to mutability of meaning is data type conversion.
Actually I consider this to be an appopriate usage of conversion functions,
in contrast to the ones caused by VHDL's low level approach to arithmetic,
as described in the essay.

I you need to transport bits, use a bit vector. If a part of it should be
interpreted as an interval in some module, convert it to an interval
and do the operation. An so on. Seems to me this makes the purpose
clearer than having to work with naked bits everywhere.

There's actually a user example of this on the MyHDL website,
where a complex number is tranported over a data bus:

http://www.myhdl.org/doku.php/projects:cplx_math


> 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 will modify a sentence in the essay to make it absolutely clear that
bit-width support is here to stay. In fact intbv's behavior is quite stable
for a number of years now, including both bit vector support and integer
subtype-like support. I am now just taking some time to describe certain
aspects which some may find useful. I have waited with this (as I expect
it will be controversial) until I could back it up with working silicon.

Thanks for the feedback.

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

It's easy enough: the result is what you get when you apply Verilog's
rules on this. I believe therefore that the rules are flawed. The basic
issue is that when you mix signed and unsigned operands, all operands
are implicitly cast to unsigned, instead of signed as it should be.

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

It seems to me that your are questioning logic synthesis itself. And indeed,
I can imagine that there are applications where it's not applicable or
efficient. One shouldn't use MyHDL in such cases, its paradigm relies on
efficient synthesis.

What I'm claiming is that *if* synthesis is applicable, there will be
no significant difference between a MyHDL and a Verilog-based design flow.
I'm quite confident that there remain sufficient applications for
which synthesis works very well. I'm also pretty sure that I'll be
able to show you examples for which it actually works better than
what can be expected from a human designer in a reasonable time.

Jan


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

Re: [myhdl-list] inheriting from intbv

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

Neal Becker wrote:
> 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? 

The goal is indeed to make subclassing possible as you suggest, and support
it by the convertor.

However, I have not yet tried it or tested this myself, so there will be
bugs. I intend to fix this in short order, because I agree that it could
be very useful.

The code that you point to should not use isinstance but issubclass.
With that change, it seems to me it should work.

Warning: using subclassing to set min/max ranges should work, but
not to change intbv functionality - that is built-in in the convertor.

Jan

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