myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] 0.6dev9

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

Christopher L. Felton wrote:
> I agree the repository works for development snapshots.
> 
> The only thought would be for new users.  Is it as easy to pull from  
> the repository (new users not familiar with hg etc) as downloading a  
> zip.

Once a tracking repo is setup, it's easier to stay current: "hg pull -u".

 > I think there are enough instructions etc on the wiki and hg is
> python based for easy to install.  The cost of entry is slightly more  
> than downloading zip files.

Yes, the initial setup is more difficult. However, for truly new users
there should be a stable release on sourceforge. I realize that there
should be stable releases more often - once the VHDL hurdle has
been taken ... (mainly a question of documentation)

Given all this, let's make development snapshots obsolete and use the
hg approach instead. I may still tag from time to time. This should
also make the development loop more efficient and productive.

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] debugging Cosimulation with Icarus Verilog

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

Jan Decaluwe wrote:
...
> 
> Maybe with the bug fix you can use the assignment that was commented out,
> and perhaps that fixes it?
> 
>    // icarus stops on the following line but shouldn't
>    // cb_data_s.value = &value_s;
>    cb_data_s.value = NULL;
> 

Yes, that part works now. But unfortunately does not fix the toVerilog
test errors.

Some of the toVerilog tests failures are caused by the callback at
simulation time 0. The problem is that the callback at time 0 returns a
value 'x' for the signal. The Cosimulation class does not like that and
due to the exception in the Cosimulation._get(self) function an
intbv(None) instance is returned.

So the solution specific to Icarus would be to register the first
cbValueChange call back at simulation time 1. That could actually be
used for all simulators, as the others do it anyway that way.

BTW, I noticed the change is already part of the latest Icarus Verilog
development snapshot 2008-08-30.

Guenter

Re: [myhdl-list] debugging Cosimulation with Icarus Verilog

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
>> Excellent, looks like we're getting somewhere here!
> 
> Some update on the Icarus Verilog bug report #2048463 concerning the
> cbValueChange issues. The bug is fixed in the git repository, however,
> the difference in the call back behavior at time 0 remains. In the bug
> tracker there is some explanation about this behavior:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997
> 
> I also posted a question about this on comp.lang.verilog and got a reply
> from someone at Cadence. The Icarus Verilog developer Steve Williams
> replied now to that subject as well. Will see what comes out of that
> discussion.
> 
> Here is a link to the comp.lang.Verilog discussion:
> 
> http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/58628e26e5294c58#
> 
> I will look into adjusting the current myhdl.c for Icarus to work with
> the t0 behavior.

Maybe with the bug fix you can use the assignment that was commented out,
and perhaps that fixes it?

   // icarus stops on the following line but shouldn't
   // cb_data_s.value = &value_s;
   cb_data_s.value = NULL;

-- 
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] debugging Cosimulation with Icarus Verilog

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

Jan Decaluwe wrote:
> Excellent, looks like we're getting somewhere here!

Some update on the Icarus Verilog bug report #2048463 concerning the
cbValueChange issues. The bug is fixed in the git repository, however,
the difference in the call back behavior at time 0 remains. In the bug
tracker there is some explanation about this behavior:

http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997

I also posted a question about this on comp.lang.verilog and got a reply
from someone at Cadence. The Icarus Verilog developer Steve Williams
replied now to that subject as well. Will see what comes out of that
discussion.

Here is a link to the comp.lang.Verilog discussion:

http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/58628e26e5294c58#

I will look into adjusting the current myhdl.c for Icarus to work with
the t0 behavior.

Guenter

Re: [myhdl-list] Wraparound addition?

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

>>>
>>
>> There had been a discussion about that feature back in June of last  
>> year
>>  on this mailing list. Here is a link to the achieve of that:
>>
>> http://sourceforge.net/mailarchive/forum.php?forum_name=myhdl-list&max_rows=25&style=ultimate&viewmonth=200706
>>
>> Jan had written some background information about the intention of  
>> intbv
>> there in connection with the wrap around functionality.
>>
>> This might be a good question to be answered on the FAQ page.
>
> Ok, what about this:
>
> http://myhdl.jandecaluwe.com/doku.php/faq#how_do_i_describe_wrap-around_behaviour
>



Ok more on the wrap functionality.  I know this has come up a couple  
times and may have been answered.  The page referenced above has an  
example for an unsigned counter.  In the case for signed values I  
don't think the mod works?

As previously discussed the 2's complement wrap is often exploited in  
DSP.  The solution thus far has been to design within limits (no  
wrapping).  There are some scenarios that the resources required tends  
to using the 2's comp wrap.  Below is an example that illustrates the  
mod function to support the wrap in MyHDL.  I am missing how this can  
be applied to a signed value and still be convertible.  I haven't been  
able to think of any elegant solutions other than handling a bunch of  
different cases to handle negatives.

Increment Wrap Start Zero
    0     1     2     3     4     5     6     7     0     1     2      
3     4     5     6
    7     0     1     2     3     4     5     6     7     0     1      
2     3     4     5
    6     7     0     1     2     3     4     5     6     7     0      
1     2     3     4
    5     6     7     0     1     2     3     4     5     6     7      
0     1     2     3
    4     5     6     7     0     1     2     3     4     5     6      
7     0     1     2
    3     4     5     6     7     0     1     2     3     4     5     6

Decrement Wrap Start Positive
    7     6     5     4     3     2     1     0     7     6     5      
4     3     2     1
    0     7     6     5     4     3     2     1     0     7     6      
5     4     3     2
    1     0     7     6     5     4     3     2     1     0     7      
6     5     4     3
    2     1     0     7     6     5     4     3     2     1     0      
7     6     5     4
    3     2     1     0     7     6     5     4     3     2     1      
0     7     6     5
    4     3     2     1     0     7     6     5     4     3     2     1

Increment Wrap Start Negative -8
   -8     1     2     3     4     5     6     7     0     1     2      
3     4     5     6
    7     0     1     2     3     4     5     6     7     0     1      
2     3     4     5
    6     7     0     1     2     3     4     5     6     7     0      
1     2     3     4
    5     6     7     0     1     2     3     4     5     6     7      
0     1     2     3
    4     5     6     7     0     1     2     3     4     5     6      
7     0     1     2
    3     4     5     6     7     0     1     2     3     4     5     6

Decrement Wrap Start Negative -1
   -1     6     5     4     3     2     1     0     7     6     5      
4     3     2     1
    0     7     6     5     4     3     2     1     0     7     6      
5     4     3     2
    1     0     7     6     5     4     3     2     1     0     7      
6     5     4     3
    2     1     0     7     6     5     4     3     2     1     0      
7     6     5     4
    3     2     1     0     7     6     5     4     3     2     1      
0     7     6     5
    4     3     2     1     0     7     6     5     4     3     2     1


from myhdl import *

Q = 3
L = 2**Q
x = intbv(0, min=-L, max=L)

print '\n\nIncrement Wrap Start Zero'
for i in range(1, 11*L):
     print '%4d ' % x,
     x[:] = (x + 1) % L

     if i%15 == 0:
         print ''

print '\n\nDecrement Wrap Start Positive'
for i in range(1, 11*L):
     print '%4d ' % x,
     x[:] = (x - 1) % L

     if i%15 == 0:
         print ''

print '\n\nIncrement Wrap Start Negative -%d' % L
x[:] = -L
for i in range(1, 11*L):
     print '%4d ' % x,
     x[:] = (x + 1) % L

     if i%15 == 0:
         print ''

print '\n\nDecrement Wrap Start Negative -1'
x[:] = -1
for i in range(1, 11*L):
     print '%4d ' % x,
     x[:] = (x - 1) % L

     if i%15 == 0:
         print ''

Re: [myhdl-list] 0.6dev9

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

I agree the repository works for development snapshots.

The only thought would be for new users.  Is it as easy to pull from  
the repository (new users not familiar with hg etc) as downloading a  
zip.  I think there are enough instructions etc on the wiki and hg is  
python based for easy to install.  The cost of entry is slightly more  
than downloading zip files.

On Aug 26, 2008, at 4:29 AM, Günter Dannoritzer wrote:

> Jan Decaluwe wrote:
> ...
>>
>> Is it still meaningful to release development snapshots, now that  
>> there
>> is a public mercurial repository?
>
> I think now that the repository is there, it is just fine to use it  
> for
> following the latest development.
>
> Guenter
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] 0.6dev9

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

Jan Decaluwe wrote:
...
> 
> Is it still meaningful to release development snapshots, now that there
> is a public mercurial repository?

I think now that the repository is there, it is just fine to use it for
following the latest development.

Guenter

Re: [myhdl-list] Activation list problem along with list of signals

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

Andrew Lentvorski wrote:
> Jan Decaluwe wrote:
> 
>> For conversion, I can see an issue because during source code
>> manipulation the decorator needs to be stripped off, and from the
>> code this seems to assume a single-line decorator. It's a MyHDL
>> conversion issue.
> 
> Yep, that's exactly what it is.  Again, a better error is probably
> warranted.  A "Python Syntax Error" shouldn't look the same as a "MyHDL
> Python Syntax Error".

What I meant with "issue" is that it's a bug.

I don't have time now to look at it, but the culprit is probably
the following regexp substitution in conversion/_analyze.py:

s = re.sub(r"@.*", "", s)

The intention it that this strips off decorators from a function's
source code. This should be changed to work for any multiline
decorator, but this doesn't look immediately trivial.

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] Activation list problem along with list of signals

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

Jan Decaluwe wrote:

> For conversion, I can see an issue because during source code
> manipulation the decorator needs to be stripped off, and from the
> code this seems to assume a single-line decorator. It's a MyHDL
> conversion issue.

Yep, that's exactly what it is.  Again, a better error is probably
warranted.  A "Python Syntax Error" shouldn't look the same as a "MyHDL
Python Syntax Error".  Here was the error I got and the code.

Thanks,
-a


$ python test.py
Traceback (most recent call last):
  File "test.py", line 45, in <module>
    test()
  File "test.py", line 42, in test
    ve = convert_RegisterFile()
  File "test.py", line 37, in convert_RegisterFile
    writeData0, writeAddress0, writeEnable0)
  File "/home/andrewl/local/lib/python/myhdl/_toVerilog/_convert.py", line 113, in __call__
    genlist = _analyzeGens(arglist, h.absnames)
  File "/home/andrewl/local/lib/python/myhdl/_toVerilog/_analyze.py", line 130, in _analyzeGens
    ast = compiler.parse(s)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/compiler/transformer.py", line 52, in parse
    return Transformer().parsesuite(buf)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/compiler/transformer.py", line 129, in parsesuite
    return self.transform(parser.suite(text))
  File "<string>", line 1
    registerData[0x00], registerData[0x01])
                                          ^
SyntaxError: invalid syntax



#!/usr/bin/env python

from myhdl import Signal, delay, always, instance, StopSimulation, now, traceSignals, \
    Simulation, intbv, concat, enum, now, always_comb, toVerilog, instances

def RegisterFile(gclk, grst,
                 readPort0, readPort1, readPort2,
                 readAddress0, readAddress1, readAddress2,
                 writeData0, writeAddress0, writeEnable0):

    registerData = [Signal(intbv(0)[32:]) for ii in range(2)]

    @always(readAddress0, readAddress1, readAddress2,
            registerData[0x00], registerData[0x01])
    def read():
        readPort0.next = registerData[int(readAddress0)]
        readPort1.next = registerData[int(readAddress1)]
        readPort2.next = registerData[int(readAddress2)]

    @always(gclk.posedge)
    def write():
        if writeEnable0:
            if writeAddress0 != 0:
                registerData[int(writeAddress0)].next = writeData0

    return instances()

def convert_RegisterFile():
    (gclk, grst) = [Signal(bool(0)) for ii in range(2)]
    (readPort0, readPort1, readPort2, writeData0) = [Signal(intbv(0)[32:]) for ii in range(4)]
    (readAddress0, readAddress1, readAddress2, writeAddress0) = [Signal(intbv(0)[5:]) for ii in range(4)]
    writeEnable0 = Signal(bool(0))

    rf = toVerilog(RegisterFile, gclk, grst, 
                   readPort0, readPort1, readPort2,
                   readAddress0, readAddress1, readAddress2,
                   writeData0, writeAddress0, writeEnable0)

    return instances()

def test():
    ve = convert_RegisterFile()

if __name__ == '__main__':
    test()

[myhdl-list] 0.6dev9

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

Development version 0.6dev9 is available from here:

     http://myhdl.jandecaluwe.com/doku.php/dev:snapshots#snapshots

This is the first one after the change to mercurial. (I noticed I forgot
to tag the 2 previous development versions.)

Is it still meaningful to release development snapshots, now that there
is a public mercurial repository?

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] Activation list problem along with list of signals

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

Andrew Lentvorski wrote:
> I think it's been reported before, but placing a list of signals in an
> activation list doesn't seem to work.

No, but you can always construct a new sensitivity list from other
lists and elements and use that.

> However, I've got a more interesting issue.  Since I can't put the list
> into an activation list, I have to explicitly name every signal.
> Annoying, but doable.  Unfortunately, I can't seem to find a way to
> split the line that Python likes.  Since everything was inside a ()
> pair, I assumed that would work, but it doesn't seem to.  Then I tried a
> \ line extension operator, but that didn't work.
> 
> How do I split an activation list across multiple lines?

Are you talking about modeling or conversion?

For conversion, I can see an issue because during source code manipulation
the decorator needs to be stripped off, and from the code this seems to
assume a single-line decorator. It's a MyHDL conversion issue.

But for modelling, the methods you describe should work (as in pure Python).

Jan

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

[myhdl-list] ncsim cosimulation

[Steven D. <mo...@ya...>]

Hi,

I saw in the archives that someone had successfully performed myHDL/ncsim co-simulation.

To avoind re-inventing the wheel, an anyone provide further information on this ? (i.e. any changes to c files, makefile, etc

Thanks,

Steven


Send instant messages to your online friends http://uk.messenger.yahoo.com 

[myhdl-list] Activation list problem along with list of signals

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

I think it's been reported before, but placing a list of signals in an
activation list doesn't seem to work.

However, I've got a more interesting issue.  Since I can't put the list
into an activation list, I have to explicitly name every signal.
Annoying, but doable.  Unfortunately, I can't seem to find a way to
split the line that Python likes.  Since everything was inside a ()
pair, I assumed that would work, but it doesn't seem to.  Then I tried a
\ line extension operator, but that didn't work.

How do I split an activation list across multiple lines?

Thanks,
-a

Here's the code:

def RegisterFile(gclk, grst,
                 readPort0, readPort1, readPort2,
                 readAddress0, readAddress1, readAddress2,
                 writeData0, writeAddress0, writeEnable0):

    registerData = [Signal(intbv(0)[32:]) for ii in range(32)]

    # How do I split the following line?
    @always(readAddress0, readAddress1, readAddress2, registerData[0x00], registerData[0x01], registerData[0x02], registerData[0x03])
    def read():
        readPort0.next = registerData[int(readAddress0)]
        readPort1.next = registerData[int(readAddress1)]
        readPort2.next = registerData[int(readAddress2)]

    @always(gclk.posedge)
    def write():
        if writeEnable0:
            if writeAddress0 != 0:
                registerData[int(writeAddress0)].next = writeData0

    return instances()

[myhdl-list] gtkwave and strings issue

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

Hi,

I am using gtkwave 3.1.10 and noticed that it does not display the
enum() states of MyHDL properly. Anthony Bybell, the developer of
gtkwave confirmed that there is an issue with the current version and
that he will fix that.

Meanwhile it is possible to load vcd files containing strings with the
-L option.

Guenter

Re: [myhdl-list] Unable to get a counter working

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

Andrew Lentvorski wrote:
> Jan Decaluwe wrote:
>> I agree, and such a document isn't there yet. I believe all elements
>> are available, but it's all implicit and scattered over the documentation
>> and web site.
> 
> Would you have a recommendation for a VHDL book that matches your 
> thinking (or even qualifies as good)?

No, I'm not aware of any truly inspiring book about HDL design,
either with Verilog or VHDL.

-- 
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] create intbv from list of bits

[Vanheesbeke S. <Ste...@va...>]

Jan, 

>why can't you do the bit processing in a single
>generator on the bits of an input intbv?

I do some serial adders and multipliers for pipelined calculations. I
started some bottom up approach (defining an carry save adder) and then
started connecting them together: that's where the list of signals comes
in. 
I used the "from intbv to list of signals" and tried also to implement
the other way, but I don't really need it at the moment. 


>Yes, but I'd like to avoid that if possible, and I still think it is.
>A "real memory" is again an implementation concept. But the
implementation
>details may vary between target technologies, and I prefer synthesis
>tools to infer that from a generic description.

I don't mean a 'real memory' as an instance of a RAM block. I think the
generic instance is a good idea, but only use it when the python source
code uses a class that describes a memory. A list of signals can be
split in separate signals (for example reg test[3] becomes test_0,
test_1 and test[2]). 

On the other hand, it should be interesting if the converter can detect
this automatically, if not, the language drops down towards a simpler
HDL like Verilog or VHDL. 


-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of Jan
Decaluwe
Sent: woensdag 20 augustus 2008 10:23
To: myh...@li...
Subject: Re: [myhdl-list] create intbv from list of bits

Vanheesbeke Stefaan wrote:
> Thanks for the effort. Indeed the proposed functionality can be done
in
> pure modeling, I needed something to explain the question. 
> 
> Maybe I'm thinking too much in hardware when writing something in
> python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS
> ([Signal(bool(0)) for i in range(8)]) from a hardware point of view.

Too much hardware thinking is a general issue, also in VHDL and
certainly
in Verilog :-)

The issue you raised is valid, and I need to solve it. However, now that
you mention it, why can't you do the bit processing in a single
generator on the bits of an input intbv?

> Most of the time defining a list of signals is only a way of
describing
> connections that are held together in a single variable instead of
> defining a real memory (address, data, ...). So maybe a real memory
can
> be described in a separate class to separate it from the 'list of
> signals' behavior.

Yes, but I'd like to avoid that if possible, and I still think it is.
A "real memory" is again an implementation concept. But the
implementation
details may vary between target technologies, and I prefer synthesis
tools to infer that from a generic description.

Jan

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


------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

______________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________

Re: [myhdl-list] Unable to get a counter working

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

Jan Decaluwe wrote:
> I agree, and such a document isn't there yet. I believe all elements
> are available, but it's all implicit and scattered over the documentation
> and web site.

Would you have a recommendation for a VHDL book that matches your 
thinking (or even qualifies as good)?  I can go pull that from one of 
the local university libraries.

I've seen quite a few VHDL books, but most of them kinda suck (to be 
fair, Verilog has the same issue).

Thanks,
-a

[myhdl-list] MyHDL code clean-up - please review

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

I think the introduction of decorators in MyHDL 0.5 has been
a success, and by now everybody uses them.

For pure modelling, you can construct generators in any way,
including directly without decorators, and that will always
remain so.

However, some more implementation-oriented features, such
as hierarchy extraction, signal tracing and conversion also
contain support for non-decorator generators. This complicates
the code considerably, and in my opinion, unnecessarily.
Before adding new features, I would like to remove this
support to simplify the code.

Again, if you use decorators, everything should continue to
work as before. Below I will describe the proposed changes
in detail. Please review and give feedback about any objection.

* remove 'processes' function
This (undocumented) function is obsolete if you use decorators. It
was deprecated in 0.5.

* change 'instances' function to only return generators from decorators
Currently 'instances' returns any kind of generator. Sometimes people
may want to use a generator for other purposes than hardware description:
currently you can't use 'instances' in that case. By only returning
generators from decorators, this would become possible.

* remove support for "top-level" generators

Consider the degenerated case where the top-level is a generator:

def top():
    <generator_body>

Hierarchy extraction, signal tracing and conversion have some special
support for this, which I would like to remove. Note that the
above is equivalent to:

def top():
     @instance
     def logic():
         <generator_body>
     return logic

* in general, assume that for hierarchy extraction, signal tracing
and conversion, only generators from decorators need to be considered.
There may be some more places in the code where this assumption can help
to simplify things.


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] Unable to get a counter working

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

Andrew Lentvorski wrote:
> Jan Decaluwe wrote:
> 
>> I don't think they do anything related to the issue that you
>> had. Try something similar with plain Python, and you'll have the
>> same issue.
> 
> Actually, I understand the Python scoping rules pretty well.  I've been 
> doing Python for a while.

Then you must agree that the unbound local error you had is
to be expected, with or without a MyHDL decorator.

> The decorator actually causes certain things to be pulled into scope, 
> somehow (presumably when it works out the activation list).  I need to 
> look at that.

I don't think so, but let us know what you find.

>> Any resemblance of MyHDL with Verilog is superficial. It's much
>> closer to VHDL. This simply reflects my opinion that Verilog
>> has some serious design flaws, such as the fact that there
>> is no separation between signals and variables. So you are
>> correct that you'll have to understand the MyHDL model
>> for effective usage.
> 
> Actually getting your thoughts about this would probably be helpful to 
> those of us coming from a Python/Verilog background.  Sort of a "design 
> philosophy" thing to help make the mental transition smoother.

I agree, and such a document isn't there yet. I believe all elements
are available, but it's all implicit and scattered over the documentation
and web site.

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] create intbv from list of bits

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

Vanheesbeke Stefaan wrote:
> Thanks for the effort. Indeed the proposed functionality can be done in
> pure modeling, I needed something to explain the question. 
> 
> Maybe I'm thinking too much in hardware when writing something in
> python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS
> ([Signal(bool(0)) for i in range(8)]) from a hardware point of view.

Too much hardware thinking is a general issue, also in VHDL and certainly
in Verilog :-)

The issue you raised is valid, and I need to solve it. However, now that
you mention it, why can't you do the bit processing in a single
generator on the bits of an input intbv?

> Most of the time defining a list of signals is only a way of describing
> connections that are held together in a single variable instead of
> defining a real memory (address, data, ...). So maybe a real memory can
> be described in a separate class to separate it from the 'list of
> signals' behavior.

Yes, but I'd like to avoid that if possible, and I still think it is.
A "real memory" is again an implementation concept. But the implementation
details may vary between target technologies, and I prefer synthesis
tools to infer that from a generic description.

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] create intbv from list of bits

[Vanheesbeke S. <Ste...@va...>]

Thanks for the effort. Indeed the proposed functionality can be done in
pure modeling, I needed something to explain the question. 

Maybe I'm thinking too much in hardware when writing something in
python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS
([Signal(bool(0)) for i in range(8)]) from a hardware point of view.

Most of the time defining a list of signals is only a way of describing
connections that are held together in a single variable instead of
defining a real memory (address, data, ...). So maybe a real memory can
be described in a separate class to separate it from the 'list of
signals' behavior. 

Stefaan


-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of Jan
Decaluwe
Sent: dinsdag 19 augustus 2008 17:28
To: myh...@li...
Subject: Re: [myhdl-list] create intbv from list of bits

Ok, list of signal issues again :-)

First of all, to be clear: what you want is easy enough to do
in pure modeling. The issue, like often, is conversion with all
its restrictions.

After thinking about it, I don't see a way to do what you want
without some kind of better support for lists of signals used
inside generators. At some point, you'll need a for loop over
all the members of the list in a single generator, to avoid
multiple drivers to a signal. (I check on multiple drivers
because synthesis wouldn't allow that anyway.)

This issue is coming up regularly so I'll try to do something
about it. I can't assess feasibility or timing just yet, but
I think I have an idea to lift the current restrictions.

The background issue is that Verilog memories have all kinds
of restrictions, so you don't want to use them unless
absolutely necessary. Currently this is enforced by a
severe restriction: you can't use list syntax in a generator
for a signal which is accessed as a plain signal in some other
generator.

It may be possible to detect whether a list is actually
referenced inside a generator, and only declare it as a Verilog
memory in that case. The result would be that everything
that works now would continue to work unchanged, but now
you would be able to use lists of signals inside
generators in general.

Jan


Vanheesbeke Stefaan wrote:
> Hi,
> 
>  
> 
> For a bit manipulation functionality, I need to split an intbv into 
> induvidual bits (a list of signals).
> 
>  
> 
> On the bits some configurable operations are done, and after this, I 
> need to create an intbv again. How can this be done in myhdl?
> 
>  
> 
> I have a testcase with a simple inverter for each bit, so you get the 
> idea :
> 
>  
> 
> First I get the induvidual bits with the GetBit() function.
> 
> The bits are processed in Function()
> 
> Then I need to stick the bits toghether again...
> 
>  
> 
> Stefaan
> 
>  
> 
>  
> 
>  
> 
> from myhdl import *
> 
>  
> 
> def Function(input_, output_):
> 
>             @always_comb
> 
>             def f():
> 
>                         output_.next = not input_
> 
>             return f
> 
>  
> 
> def Connect(In, Out):
> 
>     @always_comb
> 
>     def connect():
> 
>         Out.next = In
> 
>     return connect
> 
>  
> 
> def GetBit(input_, bit, out):
> 
>             @always_comb
> 
>             def getbit():
> 
>                         out.next = input_[bit]
> 
>             return getbit
> 
>  
> 
> def SetBit(input_, bit, out):
> 
>             @always_comb
> 
>             def setbit():
> 
>                         out.next[bit] = input_
> 
>             return setbit
> 
>            
> 
>  
> 
> def test(a, out):
> 
>  
> 
>             bits        = len(a)
> 
>             a_list      = [Signal(bool(0)) for i in range(bits)]
> 
>             result_list = [Signal(bool(0)) for i in range(bits)]
> 
>            
> 
>             retval = []
> 
>             retval.extend([GetBit(a, i, a_list[i])             for i
in 
> range(bits)])
> 
>             retval.extend([Function(a_list[i], result_list[i]) for i
in 
> range(bits)])
> 
>            
> 
>             #need something here to create an intbv out that is a 
> concatination of the bits in result_list
> 
>            
> 
>             #setting a bit at a time :
> 
>             #retval.extend([SetBit(result_list[i], i, out) for i in 
> range(bits)])
> 
>                         #does not work :"Signal has multiple drivers :
out"
> 
>            
> 
>             #passing a single bit af an intbv :
> 
>             #retval.extend([Connect(result_list[i], out[i]) for i in 
> range(bits)])
> 
>                         #does not work : "Port is not used : out"
> 
>                         #and in the verilog description : "assign 0 = 
> retval_8_In;"
> 
>            
> 
>             return retval
> 
>            
> 
> if __name__ == "__main__":
> 
>             a   = Signal(intbv(0)[4:])
> 
>             out = Signal(intbv(0)[4:])
> 
>             toVerilog(test, a, out)
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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


------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

______________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________

Re: [myhdl-list] Unable to get a counter working

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

Jan Decaluwe wrote:

> I don't think they do anything related to the issue that you
> had. Try something similar with plain Python, and you'll have the
> same issue.

Actually, I understand the Python scoping rules pretty well.  I've been 
doing Python for a while.

The decorator actually causes certain things to be pulled into scope, 
somehow (presumably when it works out the activation list).  I need to 
look at that.

> Any resemblance of MyHDL with Verilog is superficial. It's much
> closer to VHDL. This simply reflects my opinion that Verilog
> has some serious design flaws, such as the fact that there
> is no separation between signals and variables. So you are
> correct that you'll have to understand the MyHDL model
> for effective usage.

Actually getting your thoughts about this would probably be helpful to 
those of us coming from a Python/Verilog background.  Sort of a "design 
philosophy" thing to help make the mental transition smoother.

-a

Re: [myhdl-list] create intbv from list of bits

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

Ok, list of signal issues again :-)

First of all, to be clear: what you want is easy enough to do
in pure modeling. The issue, like often, is conversion with all
its restrictions.

After thinking about it, I don't see a way to do what you want
without some kind of better support for lists of signals used
inside generators. At some point, you'll need a for loop over
all the members of the list in a single generator, to avoid
multiple drivers to a signal. (I check on multiple drivers
because synthesis wouldn't allow that anyway.)

This issue is coming up regularly so I'll try to do something
about it. I can't assess feasibility or timing just yet, but
I think I have an idea to lift the current restrictions.

The background issue is that Verilog memories have all kinds
of restrictions, so you don't want to use them unless
absolutely necessary. Currently this is enforced by a
severe restriction: you can't use list syntax in a generator
for a signal which is accessed as a plain signal in some other
generator.

It may be possible to detect whether a list is actually
referenced inside a generator, and only declare it as a Verilog
memory in that case. The result would be that everything
that works now would continue to work unchanged, but now
you would be able to use lists of signals inside
generators in general.

Jan


Vanheesbeke Stefaan wrote:
> Hi,
> 
>  
> 
> For a bit manipulation functionality, I need to split an intbv into 
> induvidual bits (a list of signals).
> 
>  
> 
> On the bits some configurable operations are done, and after this, I 
> need to create an intbv again. How can this be done in myhdl?
> 
>  
> 
> I have a testcase with a simple inverter for each bit, so you get the 
> idea :
> 
>  
> 
> First I get the induvidual bits with the GetBit() function.
> 
> The bits are processed in Function()
> 
> Then I need to stick the bits toghether again...
> 
>  
> 
> Stefaan
> 
>  
> 
>  
> 
>  
> 
> from myhdl import *
> 
>  
> 
> def Function(input_, output_):
> 
>             @always_comb
> 
>             def f():
> 
>                         output_.next = not input_
> 
>             return f
> 
>  
> 
> def Connect(In, Out):
> 
>     @always_comb
> 
>     def connect():
> 
>         Out.next = In
> 
>     return connect
> 
>  
> 
> def GetBit(input_, bit, out):
> 
>             @always_comb
> 
>             def getbit():
> 
>                         out.next = input_[bit]
> 
>             return getbit
> 
>  
> 
> def SetBit(input_, bit, out):
> 
>             @always_comb
> 
>             def setbit():
> 
>                         out.next[bit] = input_
> 
>             return setbit
> 
>            
> 
>  
> 
> def test(a, out):
> 
>  
> 
>             bits        = len(a)
> 
>             a_list      = [Signal(bool(0)) for i in range(bits)]
> 
>             result_list = [Signal(bool(0)) for i in range(bits)]
> 
>            
> 
>             retval = []
> 
>             retval.extend([GetBit(a, i, a_list[i])             for i in 
> range(bits)])
> 
>             retval.extend([Function(a_list[i], result_list[i]) for i in 
> range(bits)])
> 
>            
> 
>             #need something here to create an intbv out that is a 
> concatination of the bits in result_list
> 
>            
> 
>             #setting a bit at a time :
> 
>             #retval.extend([SetBit(result_list[i], i, out) for i in 
> range(bits)])
> 
>                         #does not work :"Signal has multiple drivers : out"
> 
>            
> 
>             #passing a single bit af an intbv :
> 
>             #retval.extend([Connect(result_list[i], out[i]) for i in 
> range(bits)])
> 
>                         #does not work : "Port is not used : out"
> 
>                         #and in the verilog description : "assign 0 = 
> retval_8_In;"
> 
>            
> 
>             return retval
> 
>            
> 
> if __name__ == "__main__":
> 
>             a   = Signal(intbv(0)[4:])
> 
>             out = Signal(intbv(0)[4:])
> 
>             toVerilog(test, a, out)
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
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] Wraparound addition?

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

Günter Dannoritzer wrote:
> Andrew Lentvorski wrote:
>> How do I add two unsigned intbv() objects such that the addition wraps 
>> around?
>>
>> Obviously, I can do the addition and then mask it and reassign like so:
>>
>> new = (old0 + old1) & 0xffff
>>
>> However, I doubt that is going to translate to verilog properly.
> 
> There had been a discussion about that feature back in June of last year 
>   on this mailing list. Here is a link to the achieve of that:
> 
> http://sourceforge.net/mailarchive/forum.php?forum_name=myhdl-list&max_rows=25&style=ultimate&viewmonth=200706
> 
> Jan had written some background information about the intention of intbv 
> there in connection with the wrap around functionality.
> 
> This might be a good question to be answered on the FAQ page.

Ok, what about this:

http://myhdl.jandecaluwe.com/doku.php/faq#how_do_i_describe_wrap-around_behaviour


-- 
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] Unable to get a counter working

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

Andrew Lentvorski wrote:
> Jan Decaluwe wrote:
>> Andrew Lentvorski wrote:
>>> Could someone please explain to me what I'm doing wrong?  I'm trying to
>>> implement what would be a basic PC counter in a microprocessor.  The
>>> stage has two def's: pc_logic which should basically just be a
>>> combinatorial adder and pc_flops which captures the state of the
>>> combinatorial logic on an edge.
>>>
>>> Why doesn't this work?  Worse, why does the one commented line throw a
>>> UboundLocalError error?
>> See Gunter's post for the answer in a MyHDL context.
>>
>> For clarity, I would like to add that the issue is conceptually not related
>> to something MyHDL-specific, but to the semantics of assignment and
>> local namespaces in Python. These work differently than in many other
>> languages and it is important to understand this clearly. See also:
>>
>>    http://www.network-theory.co.uk/docs/pytut/PythonScopesandNameSpaces.html
> 
> Thanks for the reference.  The decorator is clearly doing something 
> behind the scenes that I need to think about.

To understand what the decorators do, see here:

http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#creating_generators_with_decorators

I don't think they do anything related to the issue that you
had. Try something similar with plain Python, and you'll have the
same issue.

It is true however that MyHDL pushes a style in which you define
local (generator) functions inside another function (that defines
the module). So issues with Python namespaces and scopes may emerge
sooner than for other Python users.

> There's no question that a lot of my issues are stupid.  Both in terms 
> of being dumb mistakes (assigning to the variable rather than the 
> attribute) as well as due to having a faulty mental model of how MyHDL 
> works.

Nothing stupid about it, we have all gone through the same issues.
I'm convinced the Python learning curve is shorter than for many
other languages, but it's still there. Of course MyHDL adds some
additional complications, that may make things much harder.
(I'm too close to know :-))

Any resemblance of MyHDL with Verilog is superficial. It's much
closer to VHDL. This simply reflects my opinion that Verilog
has some serious design flaws, such as the fact that there
is no separation between signals and variables. So you are
correct that you'll have to understand the MyHDL model
for effective usage.

Jan

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