myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Some thoughts on toVerilog, toVHDL, etc.

[<dan...@we...>]

Hi,

When browsing for netlists I ran across this page about a free netlist 
format:

	http://www.confluent.org/wiki/doku.php?id=fnf:index

This gave me an idea and I was wondering how feasible this really is? 
How difficult would it be in MyHDL instead of creating individual 
toVerilog, toVHDL, etc. modules, to go through a neutral netlist and 
from there create HDL code?

I think this netlist format steamed from the confluence language, which 
I am not really familiar with. However, I read that it is possible to 
convert confluence in all types of other languages, like Verilog, VHDL, 
but also programming language like C. This is also pictured in the web 
link I gave above. Now I was wondering when the netlist format is the 
key to that flexibility, whether MyHDL could take favor of developments 
already done in that area?


Cheers,

Guenter

[myhdl-list] Re: Hi, every one

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

Zhang Yong wrote:
> Dear all,
> 
> I am a newbie of myhdl. Thank you all for designing the very simple,
> smart and powerful tool.

Welcome.

> I download version 0.41 from web, which was released last year. I just
> want to know: is it still in active developing now? when release the new
> version? and is there a roadmap?

With release 0.4, I had more or less implemented the features that I
could define "stand-alone" (perhaps with the exception of vhdl support.)
Since then, development depends much more on user input. If you browse
this mailing list, you will find examples of active development of
features based on suggestions and discussions with users, including
snapshots that implement those features.

In the mean time, enough new features have been implemented or defined
to warrant a new release. Still a lot to do (documentation), so it's
not immediate, but still this year.

> BTW, if i want to do some help for the develop, how?

Pick your feature: something that should be possible and that you really
need, and you can't do now. Start a discussion in this mailing list
and we'll take it from there. (Clearly specifying a feature is often
more work than implementing it.)

You can also help by doing real projects and telling the world
about it, BTW.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Hi, every one

[Zhang Y. <yz...@ce...>]

Dear all,

I am a newbie of myhdl. Thank you all for designing the very simple,
smart and powerful tool.

I download version 0.41 from web, which was released last year. I just
want to know: is it still in active developing now? when release the new
version? and is there a roadmap?

BTW, if i want to do some help for the develop, how?

BR,
Zhang Yong

[myhdl-list] Re: Tristate logic (newbie question)

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

I appreciate detailed work on patches very much, but would it
be possible to add some explanation on the patch also? I understand
it deals with tristate support but would like to know in some
sentences what the patch does and how it was verified.

Regards, Jan


José Pedro Matos wrote:
> #################################################################
> # brouter.py EXAMPLE code
> #################################################################
> from __future__ import generators
> from myhdl import Signal, Simulation, delay, traceSignals, intbv,
> toVerilog
> 
> 
> def brouter( clk, clk2m, mclk, cs_z, liu_thz, rd_z, dados, teste,
> rs232_tx, rs232_rx, addr):
>         """ brouter
>             um exemplo simples em myhdl
> 
>             input clk; CLK_CPU
>             input clk2m; CLK_2048MHz
>             output mclk; CLK_LIU_MCLK
>             input cs_z; CS_FPGA_Z
>             output liu_thz; LIU_TH_Z
>             input rd_z; RD_Z
>             inout [7:0] dados; DADOS
>             output teste; pino de test
>             output rs232_rx; RX uC porta serie 2
>             input rs232_tx; TX uC porta serie 2
>             input [19:0] addr; ADDR
>             
>         """
> #       teste.next = clk.val
> #       mclk.next = clk2m.val
> #       liu_thz.next = intbv(0)[1:]
> #       rs232_rx.next = rs232_tx.val
> 
>         def brouterProcess():
>                 while 1:
>                         yield cs_z, rd_z
>                         if (cs_z == 0) and (rd_z == 0):
>                                 dados.next = intbv(0xA5)[8:]
>                         else:
>                                 dados.next = intbv(None)[8:] #high
> impedance assign
> 
>         return brouterProcess()
> 
> 
> clk= Signal(bool(0))
> clk2m= Signal(bool(1))
> mclk = Signal(bool(0))
> cs_z = Signal(bool(1))
> liu_thz = Signal(bool(1))
> rd_z = Signal(bool(1))
> dados = Signal(intbv(0)[8:])
> teste = Signal(bool(0))
> rs232_tx = Signal(bool(1))
> rs232_rx = Signal(bool(0))
> addr = Signal(intbv(0)[20:])
> 
> dados.next = intbv(val=None,_nrbits=8)
> dados.next = intbv(None)[8:]
> 
> if dados.val._nrbits == 0:
>         print "len: 0\n"
> else:   
>         print "len: %d \n" % (dados.val._nrbits)
> 
> br_inst= toVerilog(brouter, clk, clk2m, mclk, cs_z, liu_thz, rd_z,
> dados, teste, rs232_tx, rs232_rx, addr)
> 
> #################################################################
> # GENERATED CODE
> #################################################################
> 
> module br_inst (
>     clk,
>     clk2m,
>     mclk,
>     cs_z,
>     liu_thz,
>     rd_z,
>     dados,
>     teste,
>     rs232_tx,
>     rs232_rx,
>     addr
> );
> 
> input clk;
> input clk2m;
> input mclk;
> input cs_z;
> input liu_thz;
> input rd_z;
> output [7:0] dados;
> reg [7:0] dados;
> input teste;
> input rs232_tx;
> input rs232_rx;
> input [19:0] addr;
> 
> 
> 
> always @(cs_z or rd_z) begin: _MYHDL1_BLOCK
>     if (((cs_z == 0) && (rd_z == 0))) begin
>         dados <= 8'ha5;
>     end
>     else begin
>         dados <= 8'hZ;
>     end
> end
> 
> endmodule
> 
> 
> ############################ CUT ME #############################
> # _intbv.py.patch
> ############################ CUT ME #############################
> jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u --new-file
> _intbv.py /usr/lib/python2.3/site-packages/myhdl/_intbv.py
> --- _intbv.py   2004-12-29 13:37:59.000000000 +0000
> +++ /usr/lib/python2.3/site-packages/myhdl/_intbv.py    2005-08-31
> 13:54:36.000000000 +0000
> @@ -71,14 +71,13 @@
>      min = property(_get_min, None)
>  
>      def _checkBounds(self):
> -        if self._max is not None:
> -            if self._val >= self._max:
> -                raise ValueError("intbv value %s >= maximum %s" %
> -                                 (self._val, self._max))
> -        if self._min is not None:
> -            if self._val < self._min:
> -                raise ValueError("intbv value %s < minimum %s" %
> -                                 (self._val, self._min))
> +       if self._val is not None:
> +               if self._max is not None:
> +                       if self._val >= self._max:
> +                               raise ValueError("intbv value %s >=
> maximum %s" % (self._val, self._max))
> +                       if self._min is not None:
> +                       if self._val < self._min:
> +                               raise ValueError("intbv value %s <
> minimum %s" % (self._val, self._min))
>  
>  
>      # hash
> @@ -113,7 +112,10 @@
>      def __getitem__(self, key):
>          if isinstance(key, int):
>              i = key
> -            res = intbv((self._val >> i) & 0x1, _nrbits=1)
> +           if self._val is None:
> +               res= intbv(None,_nrbits=1)
> +           else:
> +               res = intbv((self._val >> i) & 0x1, _nrbits=1)
>              return res
>          elif isinstance(key, slice):
>              i, j = key.start, key.stop
> @@ -127,7 +129,10 @@
>              if i <= j:
>                  raise ValueError, "intbv[i:j] requires i > j\n" \
>                        "            i, j == %s, %s" % (i, j)
> -            res = intbv((self._val & (1L << i)-1) >> j, _nrbits=i-j)
> +           if self._val is None:
> +               res= intbv(None,_nrbits=i-j)
> +           else:
> +                res = intbv((self._val & (1L << i)-1) >> j,
> _nrbits=i-j)
>              return res
>          else:
>              raise TypeError("intbv item/slice indices should be
> integers")
> ############ CUT ME ###############################################
> 
> 
> ############ CUT ME ###############################################
> #  _convert.py.patch
> ############ CUT ME ###############################################
> jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u
> _toVerilog/_convert.py /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py
> --- _toVerilog/_convert.py      2004-12-24 13:35:02.000000000 +0000
> +++ /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py
> 2005-08-31 13:58:31.000000000 +0000
> @@ -654,7 +654,10 @@
>             node.expr.node.obj is intbv:
>              c = self.getVal(node)
>              self.write("%s'h" % c._nrbits)
> -            self.write("%x" % c._val)
> +            if c._val is not None:
> +               self.write("%x" % c._val)
> +           else:
> +               self.write("Z") 
>              return
>          self.visit(node.expr)
>          self.write("[")
> ############ CUT ME ###############################################
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf


-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:

> Jan Decaluwe wrote:
>>
>> Back to our original issue: if as user wants set
>> the instance name to another value than the default,
>> the usage model would be:
>>
>>    toVerilog.name = "myInstanceName"
>>    inst = toVerilog(func, *args, **kwargs)
>>
>> I'm inclined to implement it like that - so hurry
>> with feedback if you want to stop me :-)

> This would work, although it seems like logically a class is better for 
> that. I wouldn't think to set an attribute to a function, even though 
> python supports it. I am OK with it though, would get used to it, and 
> probably learn and use that feature of python in other circumstances.

Perhaps we have a misunderstanding?

In the code above, toVerilog actually is an instance of a
ToVerilogConvertor class. So you do get all the goodies
of classes, instances, and attributes. However, the class
would support the special __call__ attribute, which
means you can call toVerilog as if it were a function.

When I think of it further, I think this way to do it
provides the right balance between backward compatibility
and additional power required to customize toVerilog's
behavior.

> Let me throw in a couple more ideas:
> 
> a 2nd function,
> 
> inst = toVerilogNamed(func,name,*args,**kwargs)
> 
> or just changing toVerilog to that format, throwing backward 
> compatibility to the wind. You could allow "" or None to use the default 
> as it is now.

If find neither proposal attractive. It is very well possible
that we will want to support additonal options than "name"
in the future. The proposals above don't address that.
Moreover, I believe that default usage should really be
as simple as going from:

    inst = func(*args, **kwargs)

to:

    inst = toVerilog(func, *args, **kwargs)

without having to explain about additional capabilities. For
many users and in many cases, this usage will be enough.
It is appropriate that the more sophisticated user needs
to learn a little more (e.g. that toVerilog is actually
in instance).

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: toVerilog dynamic top level name

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

> Ok - so we need another way to parametrize toVerilog's behavior.
> Note that until now I have been able to avoid "options" to
> the convertor, but at some point that may become unavoidable.
> So we need a general way support options, and "name" would
> be the first supported option.
>
> One could think of using function attributes, e.g.
>     toVerilog.name = "topname"
> However, with normal functions, this has a similar problem,
> as they have non-hidden attributes that we don't want to
> touch, e.g. func_name.
>
> What we would do is to create a ToVerilogConvertor class,
> that defines the supported option names as attributes.
> It would have a __call__ interface and toVerilog would
> become an instance of that class, so that its behavior
> would remain as it is now (except for the difference in
> instance name inference, as discussed earlier.)
>
> An advantage would be that the supported attributes
> can be managed attributes (properties) so that we can
> do any type of checking on them. Another advantage
> (in the future) is that a user could create other
> convertor instances with the options set to other
> values, e.g. toVerilogForXilinx.
>
> Back to our original issue: if as user wants set
> the instance name to another value than the default,
> the usage model would be:
>
>    toVerilog.name = "myInstanceName"
>    inst = toVerilog(func, *args, **kwargs)
>
> I'm inclined to implement it like that - so hurry
> with feedback if you want to stop me :-)


This would work, although it seems like logically a class is better for 
that. I wouldn't think to set an attribute to a function, even though 
python supports it. I am OK with it though, would get used to it, and 
probably learn and use that feature of python in other circumstances.

Let me throw in a couple more ideas:

a 2nd function,

inst = toVerilogNamed(func,name,*args,**kwargs)

or just changing toVerilog to that format, throwing backward 
compatibility to the wind. You could allow "" or None to use the default 
as it is now.

Tom

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:
> Jan Decaluwe wrote:
> 
>>
>> I propose to drop the current instance name inference mechanism.
>> Instead, I would use func.func_name as the default name.
>> (This is the name that appears in the def statement).
>> Technically, this is more correct, as the Verilog file
>> doesn't contain an instance, but a module.
>>
>> Additionally, a named parameter "name" would be introduced
>> in toVerilog, that can be used to override the default name
>> in any desired way.
> 
> 
> That would work great, if you don't like the default name you can 
> substitute in what you want.
> 
> Can you do this in python?
> def toVerilog(func,name=None, *args,**kwargs)
> 
> It seems like
> 
> toVerilog(add,"addTopName",x,a,b,clk)
> 
> Could get name and *args confused? Maybe I'm confused...

No, you're right, it can't work like that. I thought of using
a keyword argument "name" but that would end up in **kwargs,
and we want to use that for named association with ports.

Ok - so we need another way to parametrize toVerilog's behavior.
Note that until now I have been able to avoid "options" to
the convertor, but at some point that may become unavoidable.
So we need a general way support options, and "name" would
be the first supported option.

One could think of using function attributes, e.g.
     toVerilog.name = "topname"
However, with normal functions, this has a similar problem,
as they have non-hidden attributes that we don't want to
touch, e.g. func_name.

What we would do is to create a ToVerilogConvertor class,
that defines the supported option names as attributes.
It would have a __call__ interface and toVerilog would
become an instance of that class, so that its behavior
would remain as it is now (except for the difference in
instance name inference, as discussed earlier.)

An advantage would be that the supported attributes
can be managed attributes (properties) so that we can
do any type of checking on them. Another advantage
(in the future) is that a user could create other
convertor instances with the options set to other
values, e.g. toVerilogForXilinx.

Back to our original issue: if as user wants set
the instance name to another value than the default,
the usage model would be:

    toVerilog.name = "myInstanceName"
    inst = toVerilog(func, *args, **kwargs)

I'm inclined to implement it like that - so hurry
with feedback if you want to stop me :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: toVerilog dynamic top level name

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

>
> I propose to drop the current instance name inference mechanism.
> Instead, I would use func.func_name as the default name.
> (This is the name that appears in the def statement).
> Technically, this is more correct, as the Verilog file
> doesn't contain an instance, but a module.
>
> Additionally, a named parameter "name" would be introduced
> in toVerilog, that can be used to override the default name
> in any desired way.

That would work great, if you don't like the default name you can 
substitute in what you want.

Can you do this in python? 

def toVerilog(func,name=None, *args,**kwargs)

It seems like

toVerilog(add,"addTopName",x,a,b,clk)

Could get name and *args confused? Maybe I'm confused...

>
> [For completeness: the current implementation also infers
> the name if it is subscripted, e.g. inst[0]. But this
> is probably an exotic feature that nobody uses and
> therefore would not be missed.]

You could still use name="inst[%s]"%i or something like that to take 
care of that.

BTW, I never did figure out in Python how to make a dynamic variable 
name. I gave up and hacked my local copy of MyHDL to pass a sting to 
toVerilog with the name.

Tom

Re: [myhdl-list] Re: Tristate logic (newbie question)

[Tom D. <td...@di...>]

I agree with you dislike for tri-states.

I like the fact that a None signal causes a problem that you have to fix=20
before your simulation works.

If we are talking about I/O tri-states, then it can easily be solved=20
with an HDL wrapper and bringing out of the MyHDL code the date_o,=20
data_i and data_oe signals.

Tom


Jan Decaluwe wrote:

> Jos=E9 Pedro Matos wrote:
>
>> hello to all.
>>
>> Is any solution for the tristate question been resolved?
>
>
> Bom dia, tudo bem? :-)
>
> Not much has been done - I still hate tristates as much as then :-)
> However, in the development version, I have started to support None as
> as a value for an intbv slice, by removing the bound checks if
> the value is None. This was done to support things like:
>
>    intbv()[8:]
>
> in list of signal definitions (for memory inference in toVerilog).
>
>>
>> The first example that i make in verilog and in vhdl is to put a value
>> in the data bus when READ_Z and ChipSelect_Z go down and then put the
>> bus in high impedance when the chip is not selected. I see it work fin=
e.
>> I'm happy.
>>
>> I tried to generate the same hdl in myhdl. Not happy.
>>
>> I would like to use myhdl, because python is on my self-learning path,
>> because for what i've read i believe in xp programming and i see lot o=
f
>> good things comming from python people.
>>
>> Can someone help me?
>> I could try hack the code. Has someone done that?
>
>
> Hacking the code is fine, a discussion on how things should work,
> in full detail, even better :-)
>
>> Why there is no CVS for this project?
>
>
> (Note: I do use CVS locally to manage the source code.)
>
> To main reasons why there is not yet a public CVS repository:
>
> 1. In my judgement, it was not the most urgent functionality
> for the project, considering the stage it is in.
> 2. I hoped that by the time a public repo would be useful, there
> would be a better alternative to CVS available, perhaps a
> distributed version control system.
>
> Best regards,
>
> Jan
>

[myhdl-list] Re: Tristate logic (newbie question)

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

José Pedro Matos wrote:
> hello to all.
> 
> Is any solution for the tristate question been resolved?

Bom dia, tudo bem? :-)

Not much has been done - I still hate tristates as much as then :-)
However, in the development version, I have started to support None as
as a value for an intbv slice, by removing the bound checks if
the value is None. This was done to support things like:

    intbv()[8:]

in list of signal definitions (for memory inference in toVerilog).

> 
> The first example that i make in verilog and in vhdl is to put a value
> in the data bus when READ_Z and ChipSelect_Z go down and then put the
> bus in high impedance when the chip is not selected. I see it work fine.
> I'm happy.
> 
> I tried to generate the same hdl in myhdl. Not happy.
> 
> I would like to use myhdl, because python is on my self-learning path,
> because for what i've read i believe in xp programming and i see lot of
> good things comming from python people.
> 
> Can someone help me?
> I could try hack the code. Has someone done that?

Hacking the code is fine, a discussion on how things should work,
in full detail, even better :-)

> Why there is no CVS for this project?

(Note: I do use CVS locally to manage the source code.)

To main reasons why there is not yet a public CVS repository:

1. In my judgement, it was not the most urgent functionality
for the project, considering the stage it is in.
2. I hoped that by the time a public repo would be useful, there
would be a better alternative to CVS available, perhaps a
distributed version control system.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:
> I was trying to develop a class to handle the details of synthesizing a 
> MyHDL function. This was all fine except for one thing that I am stuck on.
> 
> To use toVerilog, you do:
> 
> topName = toVerilog(func,*args,**kwargs)
> 
> I could not get this to work with a dynamic topName. I tried the 
> following and some other attempts as well.
> 
> exec('%s = toVerilog(func,*args,**kwargs)'%(name)
> 
> func, is the name of the MyHDL function to use, *args, **kwargs are the 
> signal and parameter connections  to that function. name is a string 
> representation of what the top level name should be.
> 
> I don't think this is a python limitation, either my error or  because 
> of how toVerilog figures out the top level name.
> 
> Any ideas?

Yes - it's ugly and it is caused by my exagerated attempts
to make things "easier" for a user :-)

My goal was to encourage the user to simulate the converted
design (because good simulation catches more errors
than the convertor does.) That's why toVerilog returns
an instance, and why I wanted to use the instance name
when naming the converted Verilog files.

So, in:

    topName = toVerilog(func,*args,**kwargs)

I need to find the string "topName". If you think about
it, you'll understand why this gets ugly. toVerilog
does crazy things: it gets its own frame info, finds
the source file, gets to the line of its own call,
and parses that to get the instance name ...
And of course, this all fails when the scheme above is not
followed (e.g. when not using the returned instance value,
or with dynamic naming).

So I apologize :-) and propose to change this to something
less "clever". Now, an issue to consider is that this would
introduce some backward incompability. So, to all those
interested: please review the following proposal carefully and
provide feedback.

I propose to drop the current instance name inference mechanism.
Instead, I would use func.func_name as the default name.
(This is the name that appears in the def statement).
Technically, this is more correct, as the Verilog file
doesn't contain an instance, but a module.

Additionally, a named parameter "name" would be introduced
in toVerilog, that can be used to override the default name
in any desired way.

For consistency, a similar thing should be done with
traceSignals.

This solution would be more general with much simpler
code. However, as I said, existing code would need to
be modified as the Verilog files will have different
names than before (by default).

[For completeness: the current implementation also infers
the name if it is subscripted, e.g. inst[0]. But this
is probably an exotic feature that nobody uses and
therefore would not be missed.]

Feedback welcome.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Tristate logic (newbie question)

[P. M. <jos...@pt...>]

#################################################################
# brouter.py EXAMPLE code
#################################################################
from __future__ import generators
from myhdl import Signal, Simulation, delay, traceSignals, intbv,
toVerilog


def brouter( clk, clk2m, mclk, cs_z, liu_thz, rd_z, dados, teste,
rs232_tx, rs232_rx, addr):
        """ brouter
            um exemplo simples em myhdl

            input clk; CLK_CPU
            input clk2m; CLK_2048MHz
            output mclk; CLK_LIU_MCLK
            input cs_z; CS_FPGA_Z
            output liu_thz; LIU_TH_Z
            input rd_z; RD_Z
            inout [7:0] dados; DADOS
            output teste; pino de test
            output rs232_rx; RX uC porta serie 2
            input rs232_tx; TX uC porta serie 2
            input [19:0] addr; ADDR
            
        """
#       teste.next = clk.val
#       mclk.next = clk2m.val
#       liu_thz.next = intbv(0)[1:]
#       rs232_rx.next = rs232_tx.val

        def brouterProcess():
                while 1:
                        yield cs_z, rd_z
                        if (cs_z == 0) and (rd_z == 0):
                                dados.next = intbv(0xA5)[8:]
                        else:
                                dados.next = intbv(None)[8:] #high
impedance assign

        return brouterProcess()


clk= Signal(bool(0))
clk2m= Signal(bool(1))
mclk = Signal(bool(0))
cs_z = Signal(bool(1))
liu_thz = Signal(bool(1))
rd_z = Signal(bool(1))
dados = Signal(intbv(0)[8:])
teste = Signal(bool(0))
rs232_tx = Signal(bool(1))
rs232_rx = Signal(bool(0))
addr = Signal(intbv(0)[20:])

dados.next = intbv(val=None,_nrbits=8)
dados.next = intbv(None)[8:]

if dados.val._nrbits == 0:
        print "len: 0\n"
else:   
        print "len: %d \n" % (dados.val._nrbits)

br_inst= toVerilog(brouter, clk, clk2m, mclk, cs_z, liu_thz, rd_z,
dados, teste, rs232_tx, rs232_rx, addr)

#################################################################
# GENERATED CODE
#################################################################

module br_inst (
    clk,
    clk2m,
    mclk,
    cs_z,
    liu_thz,
    rd_z,
    dados,
    teste,
    rs232_tx,
    rs232_rx,
    addr
);

input clk;
input clk2m;
input mclk;
input cs_z;
input liu_thz;
input rd_z;
output [7:0] dados;
reg [7:0] dados;
input teste;
input rs232_tx;
input rs232_rx;
input [19:0] addr;



always @(cs_z or rd_z) begin: _MYHDL1_BLOCK
    if (((cs_z == 0) && (rd_z == 0))) begin
        dados <= 8'ha5;
    end
    else begin
        dados <= 8'hZ;
    end
end

endmodule


############################ CUT ME #############################
# _intbv.py.patch
############################ CUT ME #############################
jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u --new-file
_intbv.py /usr/lib/python2.3/site-packages/myhdl/_intbv.py
--- _intbv.py   2004-12-29 13:37:59.000000000 +0000
+++ /usr/lib/python2.3/site-packages/myhdl/_intbv.py    2005-08-31
13:54:36.000000000 +0000
@@ -71,14 +71,13 @@
     min = property(_get_min, None)
 
     def _checkBounds(self):
-        if self._max is not None:
-            if self._val >= self._max:
-                raise ValueError("intbv value %s >= maximum %s" %
-                                 (self._val, self._max))
-        if self._min is not None:
-            if self._val < self._min:
-                raise ValueError("intbv value %s < minimum %s" %
-                                 (self._val, self._min))
+       if self._val is not None:
+               if self._max is not None:
+                       if self._val >= self._max:
+                               raise ValueError("intbv value %s >=
maximum %s" % (self._val, self._max))
+                       if self._min is not None:
+                       if self._val < self._min:
+                               raise ValueError("intbv value %s <
minimum %s" % (self._val, self._min))
 
 
     # hash
@@ -113,7 +112,10 @@
     def __getitem__(self, key):
         if isinstance(key, int):
             i = key
-            res = intbv((self._val >> i) & 0x1, _nrbits=1)
+           if self._val is None:
+               res= intbv(None,_nrbits=1)
+           else:
+               res = intbv((self._val >> i) & 0x1, _nrbits=1)
             return res
         elif isinstance(key, slice):
             i, j = key.start, key.stop
@@ -127,7 +129,10 @@
             if i <= j:
                 raise ValueError, "intbv[i:j] requires i > j\n" \
                       "            i, j == %s, %s" % (i, j)
-            res = intbv((self._val & (1L << i)-1) >> j, _nrbits=i-j)
+           if self._val is None:
+               res= intbv(None,_nrbits=i-j)
+           else:
+                res = intbv((self._val & (1L << i)-1) >> j,
_nrbits=i-j)
             return res
         else:
             raise TypeError("intbv item/slice indices should be
integers")
############ CUT ME ###############################################


############ CUT ME ###############################################
#  _convert.py.patch
############ CUT ME ###############################################
jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u
_toVerilog/_convert.py /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py
--- _toVerilog/_convert.py      2004-12-24 13:35:02.000000000 +0000
+++ /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py
2005-08-31 13:58:31.000000000 +0000
@@ -654,7 +654,10 @@
            node.expr.node.obj is intbv:
             c = self.getVal(node)
             self.write("%s'h" % c._nrbits)
-            self.write("%x" % c._val)
+            if c._val is not None:
+               self.write("%x" % c._val)
+           else:
+               self.write("Z") 
             return
         self.visit(node.expr)
         self.write("[")
############ CUT ME ###############################################

[myhdl-list] Tristate logic (newbie question)

[P. M. <jos...@pt...>]

hello to all.

Is any solution for the tristate question been resolved?

The first example that i make in verilog and in vhdl is to put a value
in the data bus when READ_Z and ChipSelect_Z go down and then put the
bus in high impedance when the chip is not selected. I see it work fine.
I'm happy.

I tried to generate the same hdl in myhdl. Not happy.

I would like to use myhdl, because python is on my self-learning path,
because for what i've read i believe in xp programming and i see lot of
good things comming from python people.

Can someone help me?
I could try hack the code. Has someone done that?=20

Why there is no CVS for this project?


--
Jos=E9 Pedro Matos

Re: [myhdl-list] toVerilog does not like the logging module

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

--- Günter Dannoritzer <dan...@we...> wrote:

> Hi,
> 
> I started using the logging module of python to
> print out debugging 
> information instead of just using print functions.
> The nice feature 
> about this is that the logging information can be
> left in the code and 
> just disabled by setting the level to what level
> should print out 
> accordingly.
> 
> However, it seems like toVerilog does not like
> logging entries, as it 
> canceled on them with an Assertion Error. This is
> maybe not only a 
> logging problem as there are many other python
> modules that could be 
> included in code. Off course there is the question
> how much sense it 
> makes to include modules in a part of code that is
> meant for being 
> translated by toVerilog anyway.

Currently, what you can do is include code to be
ignored in an if __debug__ statement.

This was included in 0.4.1 but the manual was not
updated with that release. Browse the RFE section on
SourceForge for (closed) issues.

Jan


> 
> I was just wondering whether it would be beneficial
> to have some type of 
> ignore function that allows to specify modules that
> should be ignored by 
> toVerilog? So for example if I do a:
> 
> 	import logging
> 
> 
> I can do
> 
> 	myhdl.ignore(logging)
> 
> 
> and toVerilog will ignore any statements of the
> type:
> 
> 	logging.debug(...)
> 
> 
> Regards,
> 
> Guenter
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is Sponsored by the Better Software
> Conference & EXPO
> September 19-22, 2005 * San Francisco, CA *
> Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects
> & Teams * Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

Re: [myhdl-list] ROM inference from toVerilog output

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

--- Tom Dillon <td...@di...> wrote:

> Jan,
> 
> This version works very well. All list of signals
> troubles are fixed.
> 
> The only trouble I'm having is with dual port ROMs.
> I am checking to see 
> how to fix that. I don't think the dual case
> statement is the answer.

What is the Verilog coding style to infer this, if
any?

I see the issue: expansion into a case removes info
and makes it hard to infer that this can be "shared"
resource. The Verilog code would have to keep the info
about the original list in some way.  Using a function
perhaps?`

Jan
> 
> Thanks for the new features, they are very useful.
> 
> Tom
> 
> 
> 
> 
> Jan Decaluwe wrote:
> 
> > Hi all:
> >
> > Attached you find a snapshot of the myhdl
> development tree. The
> > goal is to implement ROM inference from toVerilog
> output. This
> > snapshot is for testing purposes.
> >
> > Release notes
> > =============
> >
> > The requirements to infer ROMs from toVerilog
> output were discussed
> > recently. See the discussions elsewhere in the
> mailing list for
> > more background.
> >
> > A tuple of ints is conceptually viewed as a ROM,
> and indexing it
> > is viewed as accessing the ROM. If such indexing
> is the RHS of
> > an assignment, that assignment is mapped to a case
> statement
> > in Verilog, with a case item per address. This is
> done because
> > certain synthesis tools know how to map such code
> into a ROM.
> >
> > The tuple of ints can be defined at the same
> places where signals
> > can be defined, that is, outside generators.
> (Note:
> > everything outside a generator is "elaborated" by
> the Python
> > intepreter.)
> >
> > This snapshot also changes the rules for mapping
> lists of signals
> > to memories in the Verilog output. Only lists of
> "anonymous" signals
> > (signals that don't have a name at any
> hierarchical level) are
> > mapped to memories. This preserves both the older
> functionality
> > and the new functionality for RAM inference.
> >
> > Note: in the near future, I won't use the mailing
> list for snapshots,
> > but the MyHDL web site once it has been
> "wikified".
> >
> > Installation
> > ============
> >
> > This snapshot should be installed as a replacement
> of the myhdl
> > subdirectory in the installation directory.
> >
> > Regards,
> >
> > Jan
> >
> 
> 
>
-------------------------------------------------------
> SF.Net email is Sponsored by the Better Software
> Conference & EXPO
> September 19-22, 2005 * San Francisco, CA *
> Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects
> & Teams * Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] toVerilog does not like the logging module

[<dan...@we...>]

Hi,

I started using the logging module of python to print out debugging 
information instead of just using print functions. The nice feature 
about this is that the logging information can be left in the code and 
just disabled by setting the level to what level should print out 
accordingly.

However, it seems like toVerilog does not like logging entries, as it 
canceled on them with an Assertion Error. This is maybe not only a 
logging problem as there are many other python modules that could be 
included in code. Off course there is the question how much sense it 
makes to include modules in a part of code that is meant for being 
translated by toVerilog anyway.

I was just wondering whether it would be beneficial to have some type of 
ignore function that allows to specify modules that should be ignored by 
toVerilog? So for example if I do a:

	import logging


I can do

	myhdl.ignore(logging)


and toVerilog will ignore any statements of the type:

	logging.debug(...)


Regards,

Guenter

[myhdl-list] toVerilog dynamic top level name

[Tom D. <td...@di...>]

I was trying to develop a class to handle the details of synthesizing a 
MyHDL function. This was all fine except for one thing that I am stuck on.

To use toVerilog, you do:

topName = toVerilog(func,*args,**kwargs)

I could not get this to work with a dynamic topName. I tried the 
following and some other attempts as well.

exec('%s = toVerilog(func,*args,**kwargs)'%(name)

func, is the name of the MyHDL function to use, *args, **kwargs are the 
signal and parameter connections  to that function. name is a string 
representation of what the top level name should be.

I don't think this is a python limitation, either my error or  because 
of how toVerilog figures out the top level name.

Any ideas?

Thanks, Tom

Re: [myhdl-list] ROM inference from toVerilog output

[Tom D. <td...@di...>]

Jan,

This version works very well. All list of signals troubles are fixed.

The only trouble I'm having is with dual port ROMs. I am checking to see 
how to fix that. I don't think the dual case statement is the answer.

Thanks for the new features, they are very useful.

Tom




Jan Decaluwe wrote:

> Hi all:
>
> Attached you find a snapshot of the myhdl development tree. The
> goal is to implement ROM inference from toVerilog output. This
> snapshot is for testing purposes.
>
> Release notes
> =============
>
> The requirements to infer ROMs from toVerilog output were discussed
> recently. See the discussions elsewhere in the mailing list for
> more background.
>
> A tuple of ints is conceptually viewed as a ROM, and indexing it
> is viewed as accessing the ROM. If such indexing is the RHS of
> an assignment, that assignment is mapped to a case statement
> in Verilog, with a case item per address. This is done because
> certain synthesis tools know how to map such code into a ROM.
>
> The tuple of ints can be defined at the same places where signals
> can be defined, that is, outside generators. (Note:
> everything outside a generator is "elaborated" by the Python
> intepreter.)
>
> This snapshot also changes the rules for mapping lists of signals
> to memories in the Verilog output. Only lists of "anonymous" signals
> (signals that don't have a name at any hierarchical level) are
> mapped to memories. This preserves both the older functionality
> and the new functionality for RAM inference.
>
> Note: in the near future, I won't use the mailing list for snapshots,
> but the MyHDL web site once it has been "wikified".
>
> Installation
> ============
>
> This snapshot should be installed as a replacement of the myhdl
> subdirectory in the installation directory.
>
> Regards,
>
> Jan
>

[myhdl-list] ROM inference from toVerilog output

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

Hi all:

Attached you find a snapshot of the myhdl development tree. The
goal is to implement ROM inference from toVerilog output. This
snapshot is for testing purposes.

Release notes
=============

The requirements to infer ROMs from toVerilog output were discussed
recently. See the discussions elsewhere in the mailing list for
more background.

A tuple of ints is conceptually viewed as a ROM, and indexing it
is viewed as accessing the ROM. If such indexing is the RHS of
an assignment, that assignment is mapped to a case statement
in Verilog, with a case item per address. This is done because
certain synthesis tools know how to map such code into a ROM.

The tuple of ints can be defined at the same places where signals
can be defined, that is, outside generators. (Note:
everything outside a generator is "elaborated" by the Python
intepreter.)

This snapshot also changes the rules for mapping lists of signals
to memories in the Verilog output. Only lists of "anonymous" signals
(signals that don't have a name at any hierarchical level) are
mapped to memories. This preserves both the older functionality
and the new functionality for RAM inference.

Note: in the near future, I won't use the mailing list for snapshots,
but the MyHDL web site once it has been "wikified".

Installation
============

This snapshot should be installed as a replacement of the myhdl
subdirectory in the installation directory.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: toVerilog and memories

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>
> No, I mean that the tuple will not be mapped to something in Verilog.
> All constants from the tuple will be directly put at the appropriate
> place in the Verilog case statement, like so:
>
> # in MyHDL: theTuple = (72, 35, 9, 109 ...)
>
> // Verilog output
> ....
> always @(posedge clk) begin: RL
>     //  ROM
>     case (addr)
>         0: dout <= 72;
>         1: dout <= 35;
>         2: dout <= 9;
>         3: dout <= 194;
>         ...
>
> Is that OK?


Yes.

>
> Ok, I'll make the last one the default. I'll include the synthesis
> pragma's for now - I don't see how they can hurt and perhaps other
> tools need them.

Sounds, good. I will run it through all the tools we have to test it.

>
>> I would love to give it a try. Also if it includes the list of 
>> signals fix from the previous posting that would be very useful.
>
>
> Yes, I'll prepare a snapshot with that fix and the ROM support.


Great.


Tom

[myhdl-list] Re: toVerilog and memories

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

Tom Dillon wrote:

>>
>> Now for the details:
>>
>> It's not necessary to use an additional memL object - the code could
>> just simply refer to the defining list dataL instead. That list would
>> not be present in Verilog - all constants would be directly present
>> in the code. I assume that's Ok for the synthesis tools?
> 
> 
> This sounds like a great idea.
> 
> When you say directly present in the code, you mean in the MyHDL source, 
> correct?

No, I mean that the tuple will not be mapped to something in Verilog.
All constants from the tuple will be directly put at the appropriate
place in the Verilog case statement, like so:

# in MyHDL: theTuple = (72, 35, 9, 109 ...)

// Verilog output
....
always @(posedge clk) begin: RL
     //  ROM
     case (addr)
         0: dout <= 72;
         1: dout <= 35;
         2: dout <= 9;
         3: dout <= 194;
         ...

Is that OK?

>> About the case statement: should it have synthesis attributes like
>> parallel_case, full_case? Should there be a default fallback or
>> not? 
> 
> 
> The cases are mutually exclusive since a unique address selects each 
> one. I have have never put attribute on them and they get inferred fine.
> 
> You should only have enough cases as the length of the tuple, since if 
> your address is bigger synthesis will figure out you don't use them all 
> optimize the rom. This is important since not all roms end up in built 
> in memories, sometimes in combinatorial logic or registers.
> 
> So I would either use the default for the last one, or leave it out. 
> Leaving it out will probably produce a synthesis warning.

Ok, I'll make the last one the default. I'll include the synthesis
pragma's for now - I don't see how they can hurt and perhaps other
tools need them.

> I would love to give it a try. Also if it includes the list of signals fix from the previous posting that would be very useful.

Yes, I'll prepare a snapshot with that fix and the ROM support.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: toVerilog and memories

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

>
> I like this. It is a feature where conversion can have an additional
> productivity advantage, as as lists/tuples of constants are easier
> to create and maintain in Python than in Verilog.

Yes, we now build roms from a python script for just that reason.

>
> Now for the details:
>
> It's not necessary to use an additional memL object - the code could
> just simply refer to the defining list dataL instead. That list would
> not be present in Verilog - all constants would be directly present
> in the code. I assume that's Ok for the synthesis tools?

This sounds like a great idea.

When you say directly present in the code, you mean in the MyHDL source, 
correct?

In Verilog you would need the case statement addressed by the index and 
outputting the value from the rom on a wire that would connect to where 
it was needed.

>
> There's no need for these constants to be intbv's - plain int's
> are just fine and easier.

I think ints would be OK for the right side of the assignment in Verilog 
since it can figure out the width from the left.

>
> So in short: a tuple of ints used in an assignment in the way you
> described, would be expanded into an equivalent case statement.
>
> About the case statement: should it have synthesis attributes like
> parallel_case, full_case? Should there be a default fallback or
> not? 

The cases are mutually exclusive since a unique address selects each 
one. I have have never put attribute on them and they get inferred fine.

You should only have enough cases as the length of the tuple, since if 
your address is bigger synthesis will figure out you don't use them all 
optimize the rom. This is important since not all roms end up in built 
in memories, sometimes in combinatorial logic or registers.

So I would either use the default for the last one, or leave it out. 
Leaving it out will probably produce a synthesis warning.

>
> All the above will come without additional effort. The high-level
> assignment will be mapped to a case statement, and all context
> that surrounds it will be there as usual.


Dual port roms as well? That is great.

>
> I have an initial implementation ready along the lines above and
> I could generate a new snapshot. If there is feedback, send it
> quickly because next week I have another assignment.


I would love to give it a try. Also if it includes the list of signals 
fix from the previous posting that would be very useful.

Tom

[myhdl-list] Re: toVerilog and memories

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

Tom Dillon wrote:

> ROMs are also needed and easy to infer in synthesis. It would be very 
> good if the following would produce a case statement in Verilog:
> 
> def rom(dout,addr,clk=None,dataL=None) :
>  """
>    rom : rom module
> 
>    Inputs:
>      addr        : input address
>      clk         : clock for synchronous roms, == None for async
>    Outputs:
>      dout        : output port, width determines width of rom
>    Params:
>      dataL       : list of values for rom, length is depth of rom
>  """
> 
>  memL = [intbv(data,min=dout._min,max=dout._max) for data in dataL]
>    while 1:
>        yield posedge(clk)
>        dout.next = memL[int(addr)]
> 
> 
> You would need to be able to figure out that the values in memL never 
> get modified after it is defined.
> 
> The important thing here, is the memL define and the dout.next 
> assignment need to get mapped to a case statement:
> 
> always @(posedge clk)
>  case(addr) :
>    0 : dout <= dataL[0] ;
>    1 : dout <= dataL[1] ;
>    .
>    .

I like this. It is a feature where conversion can have an additional
productivity advantage, as as lists/tuples of constants are easier
to create and maintain in Python than in Verilog.

Now for the details:

It's not necessary to use an additional memL object - the code could
just simply refer to the defining list dataL instead. That list would
not be present in Verilog - all constants would be directly present
in the code. I assume that's Ok for the synthesis tools?

There's no need for these constants to be intbv's - plain int's
are just fine and easier.

To make sure that a list of constants cannot be modified outside
the scope of toVerilog, I propose to use a tuple instead. Note
that a tuple cannot be modified after creation, which maps nicely
to the concept of a Rom. No doubt this may cause some initial
confusion with users who use lists for everything, but I think
it's worthwhile to document and explain this. Note that a
tuple can easily be created from a list:

    t = tuple(AnyList)

So in short: a tuple of ints used in an assignment in the way you
described, would be expanded into an equivalent case statement.

About the case statement: should it have synthesis attributes like
parallel_case, full_case? Should there be a default fallback or
not?

> Now you may also want some control around this, or possibly asynchronous 
> so only the list needs to become the case statement, that case statement 
> may end up inside come control statements. Possibly a clock enable.
> 
> This is very helpful. There are also dual port ROMs, so you would need 
> two case statements on the same list, with a separate address into the 
> list.

All the above will come without additional effort. The high-level
assignment will be mapped to a case statement, and all context
that surrounds it will be there as usual.

I have an initial implementation ready along the lines above and
I could generate a new snapshot. If there is feedback, send it
quickly because next week I have another assignment.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: RAM inference from toVerilog output

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

Tom Dillon wrote:
> Jan,
> 
> Thanks for the update. So far it is making memories properly including 
> true dual port rams with separate always blocks. I will run some more 
> cases over the next few days.
> 
> One problem, it looks like all lists of signals are being mapped to 
> memory structures in Verilog, even true lists of signals as described in 
> 3.1.2 of the manual.

Yes. I figured this would be a feature :-)

 > This won't synthesize properly and causes some
> cosimulation problem, specifically slicing of one of the signals.

Well spotted. I agree that this will cause problems.

> Is it possible for you to distinguish between a list for memory and a 
> true list of signals?

Yes. The difference is that a list intended for a memory will only
contain "anonymous" signals. They can only be accessed through list
indexing. In the other type of usage (as described in the manual) the
signals in the list will have a regular signal name at other levels of
the hierarchy. In this case, as the output Verilog code is flat,
the convertor has to choose which name to keep and declare: the "memory" 
name, or the signal names.

In the code snapshot, the "memory" name is kept when it is higher in the 
hierarchy. But this has problems as you point out. So instead, the
signal names should always be used when available. For conversion
purposes, such a list name cannot be referenced inside a generator -
this will result in an error.

I have already modified the code an checked it in. My test suite
continues to run unchanged, but now again signals are used in
the output of test_RandomScrambler.py. The code will be included
in a future snapshot with additional features - but you can thus
assume that it will work as desired.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: RAM inference from toVerilog output

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

Tom Dillon wrote:
> Jan,
> 
> Thanks for the update. So far it is making memories properly including 
> true dual port rams with separate always blocks. I will run some more 
> cases over the next few days.
> 
> One problem, it looks like all lists of signals are being mapped to 
> memory structures in Verilog, even true lists of signals as described in 
> 3.1.2 of the manual.

Yes. I figured this would be a feature :-)

> This won't synthesize properly and causes some
> cosimulation problem, specifically slicing of one of the signals.

Well spotted. I agree that this will cause problems.

> Is it possible for you to distinguish between a list for memory and a 
> true list of signals?

Yes. The difference is that a list intended for a memory will only
contain "anonymous" signals. They can only be accessed through list
indexing. In the other type of usage (as described in the manual) the
signals in the list will have a regular signal name at other levels of
the hierarchy. In this case, as the output Verilog code is flat,
the convertor has to choose which name to keep and declare: the "memory"
name, or the signal names.

In the code snapshot, the "memory" name is kept when it is higher in the
hierarchy. But this has problems as you point out. So instead, the
signal names should always be used when available. For conversion
purposes, such a list name cannot be referenced inside a generator -
this will result in an error.

I have already modified the code an checked it in. My test suite
continues to run unchanged, but now again signals are used in
the output of test_RandomScrambler.py. The code will be included
in a future snapshot with additional features - but you can thus
assume that it will work as desired.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html