myhdl-list Mailing List for MyHDL (Page 86)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

A MyHDL project was posted on hack a day by [hardsoftlucid].

http://hackaday.com/2012/06/11/programming-fpgas-with-python/

Enjoy,
Chris Felton

gmail test

On 06/09/2012 09:41 PM, Christopher Felton wrote:
> <snip>
>>>
>>> 1) avoid the issue by using the interpreter
>>> to do the lookup outside of the generators
>>
>> Are there any limitations to this as far as referencing and assignment goes?
>>
>
> Best of my knowledge there are no restrictions.  You just have to follow
> the strict coding pattern to locally reference attributes.  The
> attributes can *not* be used in the generator (this is for the current
> conversion support, not the proposed).  I have been surprised with some
> of my recent experiments, though.
>
> Off topic, what do we call a function with generators that models
> hardware and potentially convertible.  In Verilog we have /module/ but
> that overlaps with Python /module/.  VHDL we have /entity/ and
> /architecture/ but it is not a similar enough to use one of those terms.
>    We don't want to use /function/ because it is too general.  What is
> the most appropriate term, /MyHDL function/?
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

On 06/09/2012 09:41 PM, Christopher Felton wrote:
> <snip>
>>>
>>> 1) avoid the issue by using the interpreter
>>> to do the lookup outside of the generators
>>
>> Are there any limitations to this as far as referencing and assignment goes?
>>
>
> Best of my knowledge there are no restrictions.  You just have to follow
> the strict coding pattern to locally reference attributes.  The
> attributes can *not* be used in the generator (this is for the current
> conversion support, not the proposed).  I have been surprised with some
> of my recent experiments, though.

?

> Off topic, what do we call a function with generators that models
> hardware and potentially convertible.  In Verilog we have /module/ but
> that overlaps with Python /module/.  VHDL we have /entity/ and
> /architecture/ but it is not a similar enough to use one of those terms.
>    We don't want to use /function/ because it is too general.  What is
> the most appropriate term, /MyHDL function/?

I have addressed the terminology problem at the end of this
section in the manual:

http://www.myhdl.org/doc/current/manual/intro.html#parameters-and-hierarchy

As you can see, I think "module" is the right word, and if there
is ambiguity, use "MyHDL module".

I believe "module" is the generally accepted term in hardware design.
Verilog uses that word as the keyword, VHDL and MyHDL something else.
And of course, there is the complication that Python uses the keyword
to mean something different.

An advantage of using "MyHDL module" is that it doesn't refer to how
this is implemented exactly, which could be a function, method or class.

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

On 06/09/2012 09:41 PM, Christopher Felton wrote:
> <snip>
>>>
>>> 1) avoid the issue by using the interpreter
>>> to do the lookup outside of the generators
>>
>> Are there any limitations to this as far as referencing and assignment goes?
>>
>
> Best of my knowledge there are no restrictions.  You just have to follow
> the strict coding pattern to locally reference attributes.  The
> attributes can *not* be used in the generator (this is for the current
> conversion support, not the proposed).  I have been surprised with some
> of my recent experiments, though.

?

> Off topic, what do we call a function with generators that models
> hardware and potentially convertible.  In Verilog we have /module/ but
> that overlaps with Python /module/.  VHDL we have /entity/ and
> /architecture/ but it is not a similar enough to use one of those terms.
>    We don't want to use /function/ because it is too general.  What is
> the most appropriate term, /MyHDL function/?

I have addressed the terminology problem at the end of this
section in the manual:

http://www.myhdl.org/doc/current/manual/intro.html#parameters-and-hierarchy

As you can see, I think "module" is the right word, and if there
is ambiguity, use "MyHDL module".

I believe "module" is the generally accepted term in hardware design.
Verilog uses that word as the keyword, VHDL and MyHDL something else.
And of course, there is the complication that Python uses the keyword
to mean something different.

An advantage of using "MyHDL module" is that it doesn't refer to how
this is implemented exactly, which could be a function, method or class.

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

<snip>
>>
>> 1) avoid the issue by using the interpreter
>> to do the lookup outside of the generators
>
> Are there any limitations to this as far as referencing and assignment goes?
>

Best of my knowledge there are no restrictions.  You just have to follow 
the strict coding pattern to locally reference attributes.  The 
attributes can *not* be used in the generator (this is for the current 
conversion support, not the proposed).  I have been surprised with some 
of my recent experiments, though.

Off topic, what do we call a function with generators that models 
hardware and potentially convertible.  In Verilog we have /module/ but 
that overlaps with Python /module/.  VHDL we have /entity/ and 
/architecture/ but it is not a similar enough to use one of those terms. 
  We don't want to use /function/ because it is too general.  What is 
the most appropriate term, /MyHDL function/?

Regards,
Chris

On 06/09/2012 03:48 PM, Tom Dillon wrote:
> On 06/08/2012 04:11 PM, Jan Decaluwe wrote:
>> On 06/08/2012 05:28 PM, Tom Dillon wrote:

>> I think you also refer to the fact that in MyHDL we
>> have tried to avoid to define such dedicated types.
>> For example, there are no Module, Memory or ROM objects:
>> we use generic Python types for the purpose.
>>
>> This has definitely been a design goal, because I
>> believe the more general and minimalistic, the better.

> I honestly don't know enough about this to have much of an opinion. I
> too like things as simple as they can to be effective. My thought was it
> might keep the core MyHDL simpler and push the complexity of conversion
> off to the classes. And thought that while making a class it would be
> simpler to provide direction to conversion than have conversion
> understand and convert many possible structures.

It is not necessarily a question of many possible structures;
it is more reusing standard types as the first choice
when there is no apparent advantage of a dedicated type:
e.g. list of Signals, tuple of ints.

Note the big advantage of standard types: you can use
the dedicated Python syntax to manipulate them.

For the case of attribute lookup, it could be different
because I currently don't see why it should matter (and
make it easier) what type the "container" object is.
Anything that supports attribute lookup (getattr) should
work, restrictions may be more work than supporting the
generic operation. But if this proves to be wrong, we
can consider a dedicated type, or a good choice of a
standard type.

>> However: if there is a good case to be made why a dedicated
>> type can significantly simplify things, I have nothing
>> against that in principle.
>>
>> Now to this specific case. The problem is to support
>> conversion of attribute lookup for signals, in target
>> HDLs that do no have such a capability. Within the
>> context of how MyHDL does things there are 2 options:
>>
>> 1) avoid the issue by using the interpreter
>> to do the lookup outside of the generators
>
> Are there any limitations to this as far as referencing and assignment goes?

There shouldn't. What you do with attribute lookup outside the
generator is to create a new name in the namespace where the
generator looks for objects to use. It should not matter
how these names are created.

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

On 06/08/2012 04:11 PM, Jan Decaluwe wrote:
> On 06/08/2012 05:28 PM, Tom Dillon wrote:
>> First let me say, I don't know much about the code that does the
>> conversion but let me throw something out here.
>>
>> What if we limited ourselves to using a class to define the
>> containers? Once in a class, could we not push off some of the
>> conversion complexity to methods in the class. Basically, have some
>> hooks in conversion that would allow the class to be queried about
>> the conversion details.
>>
>> I know it is not done that way now and we are trying to make
>> conversion sort of invisible to the user but this might allow more
>> complex signal containers without adding to the complexity of
>> conversion.
> I think what you propose is to define a dedicated base class
> with useful methods and require users to subclass it if they
> need conversion.
Yes, I that is what I was thinking.
>
> I think you also refer to the fact that in MyHDL we
> have tried to avoid to define such dedicated types.
> For example, there are no Module, Memory or ROM objects:
> we use generic Python types for the purpose.
>
> This has definitely been a design goal, because I
> believe the more general and minimalistic, the better.
I honestly don't know enough about this to have much of an opinion. I 
too like things as simple as they can to be effective. My thought was it 
might keep the core MyHDL simpler and push the complexity of conversion 
off to the classes. And thought that while making a class it would be 
simpler to provide direction to conversion than have conversion 
understand and convert many possible structures.

>
> However: if there is a good case to be made why a dedicated
> type can significantly simplify things, I have nothing
> against that in principle.
>
> Now to this specific case. The problem is to support
> conversion of attribute lookup for signals, in target
> HDLs that do no have such a capability. Within the
> context of how MyHDL does things there are 2 options:
>
> 1) avoid the issue by using the interpreter
> to do the lookup outside of the generators

Are there any limitations to this as far as referencing and assignment goes?

I think that is OK. Since it is really low level work you are doing 
inside the generators and I would probably bury a lot of that inside the 
class.

>
> 2) support attribute lookup in generator code conversion,
> by supporting it in hierarchy extraction and in the
> AST traversal methods that do the conversion.
> The proposed mapping method is name mangling that
> flattens out the lookup hierarchy.
>
> 1) is supported now, 2) requires work. Ideally,
> both should be supported so that users have the choice.
>
> The question you raise is whether a dedicated base class
> would make 2) it easier. Currently, I don't see why, but I as
> always I'm very open to arguments to the contrary.

I will have to gain some more experience and see what makes the most 
sense to me. I guess it would come down to priorities as we have 
something that works now and would 2) be the next best enhancement to add.

On 06/07/2012 09:11 PM, Christopher Felton wrote:
> On 6/5/2012 3:52 PM, Jan Decaluwe wrote:
>> I have read and thought about MEP 107. Here is my initial
>> assessment.
>>
>> This MEP is strictly about conversion. This is explained in
>> the first paragraph, but I think it should be mentioned in
>> the title also, because this has proven to be an eternal source
>> of confusion. It should be made clear that all modeling
>> aspects being discussed are supported by MyHDL as it is today.
>
> All aspects being discussed are almost supported for modeling today.  It
> has been reported that the @always_comb decorator fails to extract the
> sensitivity list if a signal is buried in a structure.  I have 4
> examples below that demonstrate the issue (a control and 3 fails).
> There is the limitation that the structures cannot be used on the right
> hand side currently (at lest for the version of 0.8dev I tested this with).

always_comb is a rather "low-level" decorator, very close to
implementation and synthesizable code. I don't think it has
many uses in high-level modeling. Therefore, I don't think it
should try to support all kinds of high-level data structures.

I think things should currently work for lists of Signals, even
"hetero_list" unless not all items are Signals. In that case,
I think you get what you deserve :-) (even in Python,
I think lists are intended to consist of similar objects.)

But for dicts, I don't see the case. Again here, in
general, all members should become part of the sensitivity
list. We do that for lists, but I don't really see the
use case for dynamically indexed dicts. And if it's only
static indexing - again, attributes are the right tool.

I take the point for attribute lookup though - patches
welcome.

> In [76]: x = Signal(False)
>       ...: y = Signal(False)
>       ...: con1 = {'x':Signal(False)}
>       ...: con2 = [Signal(False),
>                    'gibberish',
>                    Signal(intbv(0, min=-234, max=19987))]
>       ...: class Container(object): x = Signal(False)
>       ...: con3 = Container()
>       ...:
>
> In [77]: @always_comb
>       ...: def sim_sig():
>       ...:     x.next = y
>       ...:
>
> In [78]: @always_comb
>       ...: def sim_con1():
>       ...:     x.next = con1['x']
>       ...:
> ---------------------------------------------------------------------------
> AlwaysCombError                           Traceback (most recent call last)
> ...
> AlwaysCombError: sensitivity list is empty
>
> In [79]: @always_comb
>       ...: def con2():
>       ...:     x.next = con2[0]
>       ...:
> ---------------------------------------------------------------------------
> AlwaysCombError                           Traceback (most recent call last)
> ..
> AlwaysCombError: sensitivity list is empty
>
> In [80]: @always_comb
>       ...: def sim_con3():
>       ...:     x.next = con3.x
>       ...:
> ---------------------------------------------------------------------------
> AlwaysCombError                           Traceback (most recent call last)
> ...
> AlwaysCombError: sensitivity list is empty
>
>
> Regards,
> Chris F.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

On 06/08/2012 05:28 PM, Tom Dillon wrote:
> First let me say, I don't know much about the code that does the
> conversion but let me throw something out here.
>
> What if we limited ourselves to using a class to define the
> containers? Once in a class, could we not push off some of the
> conversion complexity to methods in the class. Basically, have some
> hooks in conversion that would allow the class to be queried about
> the conversion details.
>
> I know it is not done that way now and we are trying to make
> conversion sort of invisible to the user but this might allow more
> complex signal containers without adding to the complexity of
> conversion.

I think what you propose is to define a dedicated base class
with useful methods and require users to subclass it if they
need conversion.

I think you also refer to the fact that in MyHDL we
have tried to avoid to define such dedicated types.
For example, there are no Module, Memory or ROM objects:
we use generic Python types for the purpose.

This has definitely been a design goal, because I
believe the more general and minimalistic, the better.

However: if there is a good case to be made why a dedicated
type can significantly simplify things, I have nothing
against that in principle.

Now to this specific case. The problem is to support
conversion of attribute lookup for signals, in target
HDLs that do no have such a capability. Within the
context of how MyHDL does things there are 2 options:

1) avoid the issue by using the interpreter
to do the lookup outside of the generators

2) support attribute lookup in generator code conversion,
by supporting it in hierarchy extraction and in the
AST traversal methods that do the conversion.
The proposed mapping method is name mangling that
flattens out the lookup hierarchy.

1) is supported now, 2) requires work. Ideally,
both should be supported so that users have the choice.

The question you raise is whether a dedicated base class
would make 2) it easier. Currently, I don't see why, but I as
always I'm very open to arguments to the contrary.

Note that I have not argued that 2) is extraordinarily
complex - I don't think it is. But will require
a couple of days of intensive work, so I think the issue
is more the usual one of time, priorities, motivation,
and personal requirements.

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

On 6/8/12 10:28 AM, Tom Dillon wrote:
> First let me say, I don't know much about the code that does the
> conversion but let me throw something out here.
>
> What if we limited ourselves to using a class to define the
> containers? Once in a class, could we not push off some of the
> conversion complexity to methods in the class. Basically, have some
> hooks in conversion that would allow the class to be queried about the
> conversion details.
>
> I know it is not done that way now and we are trying to make
> conversion sort of invisible to the user but this might allow more
> complex signal containers without adding to the complexity of conversion.

First forgive me for not reading all of this thread, but I had to jump
on this one.  

Duh, obviously that is the way to do things. But that is just my
instinct.   It would be very interesting to see the class documentation
to see exactly what the design would be. Which is why I started drafting
class documents for floating point signals, a long while ago, even
though it has errors, it is a step in the right direction. 

http://wiki.myhdlclass.com:8080/FloatingPoint

And I fixed the code on this page.

wiki.myhdlclass.com:8080/SignalClass

Thank you Jan D,  for pointing out the problem.  It even has a tiny test
harness.

It is not just about ease of implementation, you really have to look at
this from the marketing point of view. 

If you are a python developer, then the obvious thing is to have signal
containers, and be able to convert them.  That is just how python
developers think.  But that has nothing to do with the marketing
perspective.

>From the marketing perspective we want to have a bunch of signal types
that make sense to new users.  There are two sets of users.  Hardware
developers, and software developers, and some overlap.  I obviously
speak for the latter group.  Although some would say I do not speak for
them. 

As a software guy IntBV just leaves me cold.   Why would I ever want an
integer that runs from -23 to +19.  Give me a break.  A billion
transistors, how many do I need to save?  Our limitation is on the
complexity we can manage.   At least for me.

Software engineers like ints, floats real, complex.  I like characters,
and strings, strings sent down a line serially. I would love to see a
signal type called Object ID.   I am sorry I missed the conversation on
this discusson list, Let me ask an obvious marketing question.  Would
everyone please post what kinds of signal types they are looking for.  
How many people want floats?  How many people want complex numbers?  How
about audio, video, long long, short ints, and all that weird stuff? 
What am I missing??  What signal types does this market of users want?  
It would be great to see a list of signal types, and the number of users
who want to see each type.

Maybe if we just had a float,  all of us but one person would be happy. 
And my apologies if this question has already been answered. 

Me I wanted floats, and I wanted the hardware modules to process them. 
It took me quite a while to figure out how to do all of that in the
appropriate way.  Still have not implemented it.  That will come.  But
the point is that the absence of floats was a huge barrier to my
actually starting to use MyHDL.  Instead I went off and studied hardware
floating point design.   Then I started documenting all kinds of things,
including the float documentation.   It is an interesting way to
implement floats without having to write the floating point operations
in MyHDL. 

And of course the new users will want to see a list of different types
that MyHDL supports.  Not things like IntBV, but things that they
recognize, floats, complex, strings, things that smooth the mental
transition to MyHDL from wherever they come from.

Statements like

    Signals are objects, or hierarchies of objects.  Since Verilog and
    VHDL do not natively support signal hierarchies,  MyHDL does all the
    conversion and mapping for you, giving significant development
    advantages over using lower level tools. 

are very attractive to customers like me. 

Conversion of containers just does not resonate with my needs. 

And yes eventually they may find out that a signal cannot be a
dictionary or a list, or it can be but does not convert, but frankly who
cares.  Particularly since VHDL and Verilog cannot iterate over
dictionairies.  And yes, I know that there are people who care, who did
post to this thread with why they care, but seriously, from a marketing
point of view it is not important.

Then again the marketing point of view is not the only point of view,
but it is an important one.   It is not really about marketing.  It is
about what is the set of abstractions that we publish to the world.   A
rich list of signal types that MyHDL supports would be a huge
improvement over the current abstractions that MyHDL publishes to the
world. 

I hope that helps.  And do feel free to attack my point of view, I learn
a lot from it.  But attacking me personally really does not accomplish
anything.

"Be hard on issues soft on people"

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDLClass.com:8080

On 6/8/2012 10:28 AM, Tom Dillon wrote:
> First let me say, I don't know much about the code that does the
> conversion but let me throw something out here.
>
> What if we limited ourselves to using a class to define the containers?
> Once in a class, could we not push off some of the conversion complexity
> to methods in the class. Basically, have some hooks in conversion that
> would allow the class to be queried about the conversion details.
>
> I know it is not done that way now and we are trying to make conversion
> sort of invisible to the user but this might allow more complex signal
> containers without adding to the complexity of conversion.
>

I think we have definitely narrowed the scope, that Signal Container 
will be reserved to attributes (at least in the near-term).  The 
conversion of attributes is more reasonable with the resources we have.

Jan D. also mentioned, he would like the idea of attribute referencing, 
tips&tricks, discussed in depth, white-paper, before deciding if 
attribute signal containers should be implemented (doesn't stop anyone 
from working on the attribute conversion).  Such a discussion should 
expose the "use-cases" people have used or naturally attempt.

I summarized my thoughts as on attribute referencing as,

The Good (or the pretty)
   1. Supported today, as others stated
   2. Deep containers
   3. Many generators low number of references

The Bad (or the ugly)
   2. Shallow containers many attributes
   3. Managing local reference names space redundant
      (many containers in the interface)

Regards,
Chris Felton

First let me say, I don't know much about the code that does the 
conversion but let me throw something out here.

What if we limited ourselves to using a class to define the containers? 
Once in a class, could we not push off some of the conversion complexity 
to methods in the class. Basically, have some hooks in conversion that 
would allow the class to be queried about the conversion details.

I know it is not done that way now and we are trying to make conversion 
sort of invisible to the user but this might allow more complex signal 
containers without adding to the complexity of conversion.

On 06/08/2012 05:20 AM, Jan Decaluwe wrote:
> On 06/07/2012 01:19 PM, Christopher Felton wrote:
>> On 6/5/2012 3:52 PM, Jan Decaluwe wrote:
>>> I have read and thought about MEP 107. Here is my initial
>>> assessment.
>>>
>>> This MEP is strictly about conversion. This is explained in
>>> the first paragraph, but I think it should be mentioned in
>>> the title also, because this has proven to be an eternal source
>>> of confusion. It should be made clear that all modeling
>>> aspects being discussed are supported by MyHDL as it is today.
>> Agree, will make the change to the title as soon as possible.
>>
>>> One aspect of conversion is that it is unavoidable to consider
>>> the capabilities and restrictions of the conversion targets
>>> VHDL and Verilog, with special attention to synthesis. I think
>>> that aspect is taken into account insufficiently.
>>>
>>> Basically, the MEP proposes conversion support for various
>>> types of Signal object lookup. The example given is:
>>>
>>>         myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>>>
>>> and the proposed conversion is:
>>>
>>>         myObject_x = ListOfSignal_10 + DictOfSignal_fred
>>>
>>> Conceptually, these 3 cases are very similar: lookup based on
>>> a manifest attribute name, index, string. The immediate question
>>> is why we would need support for 3 almost identical cases.
>>> The answer is that this example is not representative for
>>> the main purpose of a List or a Dict data structure.
>>>
>>> The essence of a List or a Dict is lookup based on a
>>> *variable* index (integer or string). But this can only be
>>> supported by a mapping to an equivalent data structure in
>>> the target. Note that MyHDL conversion supports this today
>>> for "homogenuous" lists. However, I don't know how this
>>> would work for a "heterogenuous" list or for a dictionary.
>>>
>>> There may be solutions based on pointers, access types,
>>> or SystemVerilog data structures, but I doubt all this
>>> is worth the trouble, especially because there is little
>>> chance that such beasts would be supported by synthesis.
>>> Synthesis is not the only, but an important application
>>> of the converted code.
>>>
>>> Of course conversion could be restricted to the case of
>>> manifest indices. But that is a bad solution for the following
>>> reasons:
>>>
>>> 1) when support for heterogenuous lists or dictionaries is
>>> advertized, it is unavoidable that people will expect this
>>> to work with variable indices. So it raises expectations that
>>> cannot be met and will only result in frustrations.
>>> 2) there is a superior alternative available, which is
>>> attribute lookup. Better direct people to that solution
>>> immediately.
>>>
>> First, MEP-107 fails to clearly address the use cases
>> you mention for heterogeneous lists and dictionaries.
> Indeed.
>
>> I agree it should be removed and MEP-107 to only propose
>> conversion of attributes which are convertible types.
>>
>> I strongly disagree that *synthesis* was insufficiently
>> taken into account.  But it is hard to determine this by
>> the information provided in the MEP.  The point I hoped,
>> covered synthesis adequately, is that a referenced convertible
>> type would convert to a canonical type, i.e converted to
>> a unique net name.  It is clear now that this alone did
>> not provide sufficient information on how the canonical
>> conversion would handle anything but the trivial literal
>> index.
> Exactly. The MEP should describe
> the desirable feature can be implemented.
>
>> For the canonical conversion, complex types always need
>> to be unrolled.  Unrolling should support variable index
>> and iteration.  But this strays from the current conversion
>> goal; to have a closes as possible one-to-one mapping from
>> MyHDL to the lower-HDL.
> Yes, that was intuitively how I approached it.
> That may have been a little too fast. But still,
> without such a mapping, I foresee all kinds of complexities
> that may make a solution impractical.
>
> Example: currently, tuple of constants support does a kind
> of unrolling. When the converters sees:
>
>      a.next = TupleContainer[i]
>
> it maps this in-place to a case statement with all the choices.
>
> But I don't like this, because it only works for this specific
> pattern, e.g. not when such indexing is used in a general
> expression:
>
>      a.next = TupleContainer[i] + 1
>
> Historically, this was done to support ROM
> inferencing, but a much better solution would be to factor
> the case out in a function so that it can be used in general.
> Or perhaps an array in VHDL, which would be a one-to-one mapping.
>
> (Note: if ROM inferencing works with such a function also, we should
> change it like that.)
>
>> This means that the converter has
>> to do more work (increased complexity in an already complex
>> piece of code).
>> Is this practical?  Impossible to tell from MEP-107.
>> For hetero-lists and dictionaries to be proposed as signal
>> containers a new MEP with much more detail will need to
>> be created.  In addition the MEP needs to cover the common
>> use cases of hetero-lists and dictionaries and clearly
>> identify what would not be convertible.  I *do* think it
>> is worth-while creating the MEP regardless if we decide
>> to implemented the features or not.
> Yes, if we find a reasonable way to implement it.
>
> Let me share some ideas. Probably, "unrolling" would mean
> to create functions listing all choices like I
> described above. For lists, this means that homo-lists
> and hetero-lists are mapped in a completely different way.
> Mmm. Then the function should to some "homogenization" of
> the return type - otherwise, it can never work with
> a language like VHDL. So in effect, the convertor should
> turn it into a homo-list anyway. And this process may depend
> on how and where that list is used - meaning that several
> functions might be required, each of them listing all the
> possible choices. Mmm.
>
> For dicts, one has to decide how to map the string key
> to some type supported by synthesis in Verilog and VHDL,
> so that it can be used to check the choices in the
> unrolling case statement. Constants? Enums?
>
> Finally, assignment would require other ways of
> unrolling, e.g. procedures in VHDL.
>
> In short, a lot of work and complexity for a feature for
> which I suspect many may say: "but I will never use
> dynamic indexing". Which brings me again to my earlier
> point: in that case, let's just use attribute lookup
> which is exactly suited for the purpose.
>
>> Which brings up the question, if a MEP is declined,
>> where and how is it best to document why the MEP is
>> declined?  Is it in the MEP?  Or are future questions
>> referred to some other document?
> In such a case, I think that should be part of
> a note in the MEP. I think that is how it
> works with Python.
>
>> In summary, I agree hetero-lists and dictionaries
>> should be removed from MEP-107.  And we can debate if
>> attribute conversion should be implemented :)
> My feeling is that we will easily find a consensus about
> attribute lookup. The remaining question would be priority
> and who will do it. (I would like to hear more feedback
> from others about the "workaround" that is being
> discussed currently.)
>
> If we find a way to do it for hetero-list and dicts, that
> info could be factored out in a separate MEP to document
> the ideas. (If we find it's not worth the trouble or no
> one wants to implement it, it can still be declined of
> course. But at least this would avoid that people start
> reinventing the wheel sometime in the future).
>
>
>> Regards,
>> Chris Felton
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>

On 06/07/2012 01:19 PM, Christopher Felton wrote:
> On 6/5/2012 3:52 PM, Jan Decaluwe wrote:
>> I have read and thought about MEP 107. Here is my initial
>> assessment.
>>
>> This MEP is strictly about conversion. This is explained in
>> the first paragraph, but I think it should be mentioned in
>> the title also, because this has proven to be an eternal source
>> of confusion. It should be made clear that all modeling
>> aspects being discussed are supported by MyHDL as it is today.
>
> Agree, will make the change to the title as soon as possible.
>
>>
>> One aspect of conversion is that it is unavoidable to consider
>> the capabilities and restrictions of the conversion targets
>> VHDL and Verilog, with special attention to synthesis. I think
>> that aspect is taken into account insufficiently.
>>
>> Basically, the MEP proposes conversion support for various
>> types of Signal object lookup. The example given is:
>>
>>        myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>>
>> and the proposed conversion is:
>>
>>        myObject_x = ListOfSignal_10 + DictOfSignal_fred
>>
>> Conceptually, these 3 cases are very similar: lookup based on
>> a manifest attribute name, index, string. The immediate question
>> is why we would need support for 3 almost identical cases.
>> The answer is that this example is not representative for
>> the main purpose of a List or a Dict data structure.
>>
>> The essence of a List or a Dict is lookup based on a
>> *variable* index (integer or string). But this can only be
>> supported by a mapping to an equivalent data structure in
>> the target. Note that MyHDL conversion supports this today
>> for "homogenuous" lists. However, I don't know how this
>> would work for a "heterogenuous" list or for a dictionary.
>>
>> There may be solutions based on pointers, access types,
>> or SystemVerilog data structures, but I doubt all this
>> is worth the trouble, especially because there is little
>> chance that such beasts would be supported by synthesis.
>> Synthesis is not the only, but an important application
>> of the converted code.
>>
>> Of course conversion could be restricted to the case of
>> manifest indices. But that is a bad solution for the following
>> reasons:
>>
>> 1) when support for heterogenuous lists or dictionaries is
>> advertized, it is unavoidable that people will expect this
>> to work with variable indices. So it raises expectations that
>> cannot be met and will only result in frustrations.
>> 2) there is a superior alternative available, which is
>> attribute lookup. Better direct people to that solution
>> immediately.
>>
>
> First, MEP-107 fails to clearly address the use cases
> you mention for heterogeneous lists and dictionaries.

Indeed.

> I agree it should be removed and MEP-107 to only propose
> conversion of attributes which are convertible types.
>
> I strongly disagree that *synthesis* was insufficiently
> taken into account.  But it is hard to determine this by
> the information provided in the MEP.  The point I hoped,
> covered synthesis adequately, is that a referenced convertible
> type would convert to a canonical type, i.e converted to
> a unique net name.  It is clear now that this alone did
> not provide sufficient information on how the canonical
> conversion would handle anything but the trivial literal
> index.

Exactly. The MEP should describe
the desirable feature can be implemented.

> For the canonical conversion, complex types always need
> to be unrolled.  Unrolling should support variable index
> and iteration.  But this strays from the current conversion
> goal; to have a closes as possible one-to-one mapping from
> MyHDL to the lower-HDL.

Yes, that was intuitively how I approached it.
That may have been a little too fast. But still,
without such a mapping, I foresee all kinds of complexities
that may make a solution impractical.

Example: currently, tuple of constants support does a kind
of unrolling. When the converters sees:

    a.next = TupleContainer[i]

it maps this in-place to a case statement with all the choices.

But I don't like this, because it only works for this specific
pattern, e.g. not when such indexing is used in a general
expression:

    a.next = TupleContainer[i] + 1

Historically, this was done to support ROM
inferencing, but a much better solution would be to factor
the case out in a function so that it can be used in general.
Or perhaps an array in VHDL, which would be a one-to-one mapping.

(Note: if ROM inferencing works with such a function also, we should
change it like that.)

> This means that the converter has
> to do more work (increased complexity in an already complex
> piece of code).

> Is this practical?  Impossible to tell from MEP-107.
> For hetero-lists and dictionaries to be proposed as signal
> containers a new MEP with much more detail will need to
> be created.  In addition the MEP needs to cover the common
> use cases of hetero-lists and dictionaries and clearly
> identify what would not be convertible.  I *do* think it
> is worth-while creating the MEP regardless if we decide
> to implemented the features or not.

Yes, if we find a reasonable way to implement it.

Let me share some ideas. Probably, "unrolling" would mean
to create functions listing all choices like I
described above. For lists, this means that homo-lists
and hetero-lists are mapped in a completely different way.
Mmm. Then the function should to some "homogenization" of
the return type - otherwise, it can never work with
a language like VHDL. So in effect, the convertor should
turn it into a homo-list anyway. And this process may depend
on how and where that list is used - meaning that several
functions might be required, each of them listing all the
possible choices. Mmm.

For dicts, one has to decide how to map the string key
to some type supported by synthesis in Verilog and VHDL,
so that it can be used to check the choices in the
unrolling case statement. Constants? Enums?

Finally, assignment would require other ways of
unrolling, e.g. procedures in VHDL.

In short, a lot of work and complexity for a feature for
which I suspect many may say: "but I will never use
dynamic indexing". Which brings me again to my earlier
point: in that case, let's just use attribute lookup
which is exactly suited for the purpose.

> Which brings up the question, if a MEP is declined,
> where and how is it best to document why the MEP is
> declined?  Is it in the MEP?  Or are future questions
> referred to some other document?

In such a case, I think that should be part of
a note in the MEP. I think that is how it
works with Python.

> In summary, I agree hetero-lists and dictionaries
> should be removed from MEP-107.  And we can debate if
> attribute conversion should be implemented :)

My feeling is that we will easily find a consensus about
attribute lookup. The remaining question would be priority
and who will do it. (I would like to hear more feedback
from others about the "workaround" that is being
discussed currently.)

If we find a way to do it for hetero-list and dicts, that
info could be factored out in a separate MEP to document
the ideas. (If we find it's not worth the trouble or no
one wants to implement it, it can still be declined of
course. But at least this would avoid that people start
reinventing the wheel sometime in the future).

>
> Regards,
> Chris Felton
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

On 6/5/2012 3:52 PM, Jan Decaluwe wrote:
> I have read and thought about MEP 107. Here is my initial
> assessment.
>
> This MEP is strictly about conversion. This is explained in
> the first paragraph, but I think it should be mentioned in
> the title also, because this has proven to be an eternal source
> of confusion. It should be made clear that all modeling
> aspects being discussed are supported by MyHDL as it is today.

All aspects being discussed are almost supported for modeling today.  It 
has been reported that the @always_comb decorator fails to extract the 
sensitivity list if a signal is buried in a structure.  I have 4 
examples below that demonstrate the issue (a control and 3 fails). 
There is the limitation that the structures cannot be used on the right 
hand side currently (at lest for the version of 0.8dev I tested this with).

In [76]: x = Signal(False)
     ...: y = Signal(False)
     ...: con1 = {'x':Signal(False)}
     ...: con2 = [Signal(False),
                  'gibberish',
                  Signal(intbv(0, min=-234, max=19987))]
     ...: class Container(object): x = Signal(False)
     ...: con3 = Container()
     ...:

In [77]: @always_comb
     ...: def sim_sig():
     ...:     x.next = y
     ...:

In [78]: @always_comb
     ...: def sim_con1():
     ...:     x.next = con1['x']
     ...:
---------------------------------------------------------------------------
AlwaysCombError                           Traceback (most recent call last)
...
AlwaysCombError: sensitivity list is empty

In [79]: @always_comb
     ...: def con2():
     ...:     x.next = con2[0]
     ...:
---------------------------------------------------------------------------
AlwaysCombError                           Traceback (most recent call last)
..
AlwaysCombError: sensitivity list is empty

In [80]: @always_comb
     ...: def sim_con3():
     ...:     x.next = con3.x
     ...:
---------------------------------------------------------------------------
AlwaysCombError                           Traceback (most recent call last)
...
AlwaysCombError: sensitivity list is empty

Regards,
Chris F.

On 06/07/2012 01:45 PM, Christopher Felton wrote:

>
>       But the embedded bus might not be the best example
>       because in your object container you might want some
>       methods that retrieve the correct signals per usage.
>
>       clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetPeriphalSignals()
>       clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetControllerSignals()

Again, quite a useful technique that should be part of some white paper!

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

On 6/6/2012 2:04 PM, Jan Decaluwe wrote:
> On 06/06/2012 05:47 PM, Oscar Diaz wrote:
>
>> Like you said at beginning of the email, this works fine in
>> simulation, but conversion fails when you try to access container
>> members directly on generators. A workaround I've been using is to use
>> references to local names on elaboration. Taking the example from MEP:
>>
>> def ex1(clk, srst, xyz):
>>
>>       z = xyz.z
>>       x = xyz.x
>>       y = xyz.y
>>
>>       @always(clk.posedge)
>>       def hdl():
>>           z.next = x + y
>>
>>       return hdl
>
> This example got me thinking. I have never used it like that
> but it is a great example of how elaboration can be
> used to support powerful features which are not convertible
> at first sight. It may be that many users are not
> aware of this possibility.
>
> What I was thinking - is this really a workaround, or is it
> rather a desirable coding pattern (with the nice side effect
> that it is supported today)?
>
> Suppose MEP 107 were implemented, we could write
> the example as follows:
>
> def ex1(clk, srst, xyz):
>
>         @always(clk.posedge)
>         def hdl():
>             xyz.z.next = xyz.x + xyz.y
>
>         return hdl
>
> Is this really clearer, especially if there would be a number
> of generators which could be much more complicated than
> in the example?

The examples I believe illustrate attribute container are
clearer:

1.  If there are many attributes in a shallow container.

     The example we have been using is an embedded bus
     like wishbone.  If you had to explicitly reference
     each signal in the container in each module this
     adds redundant code.

     But the embedded bus might not be the best example
     because in your object container you might want some
     methods that retrieve the correct signals per usage.

     clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetPeriphalSignals()
     clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetControllerSignals()

     But in general a shallow container with many attributes,
     IMO, would be clearer without references.

2.  If you have multiple containers.  Managing variable
names become redundant.

     def MyModule(con1, con2, con3):
         con1_x = con1.x
         con1_y = con1.y
         con2_x = con2.x
	con2_y = con2.y
         ...

The examples where I believe referencing is clearer are:

1. Deep containers.
     someContainer.inAnother.yetAnother.toGetTo.x.next = y

2. Possibly, the many generators on small number of
container references.  Because you can simply type 'x',
'y', and 'z' everywhere instead of 'xyz.x', 'xyz.y', 'xyz.z'.

I think both have there uses.  One method obviously has an
advantage, as you mentioned, it is supported today.

>
> When I use classes now, I often get the instance variables
> of the 'self' variable once, especially when methods are
> complex. But this must be done per method. In this case,
> because of the scoping rules, we would have to do it only
> once for all generators in the module. The result would be
> a simplification of all code that follows.
>
> An valid argument for "signal containers" such as xyz is that it
> simplifies interfaces, and makes it easier to modify them.
> Even that could be simpler with the first pattern, because
> it would tend to localize a change (e.g. a name change
> in the interface would have to be done at just one location
> and the code would still work).
>
> As a minimum, we should consider writing a whitepaper/page
> "How to use inferfaces in convertible MyHDL", to
> describes the current state of the art.
>

I agree, simplifying interfaces is a big plus.

Regards,
Chris

On 6/5/2012 3:52 PM, Jan Decaluwe wrote:
> I have read and thought about MEP 107. Here is my initial
> assessment.
>
> This MEP is strictly about conversion. This is explained in
> the first paragraph, but I think it should be mentioned in
> the title also, because this has proven to be an eternal source
> of confusion. It should be made clear that all modeling
> aspects being discussed are supported by MyHDL as it is today.

Agree, will make the change to the title as soon as possible.

>
> One aspect of conversion is that it is unavoidable to consider
> the capabilities and restrictions of the conversion targets
> VHDL and Verilog, with special attention to synthesis. I think
> that aspect is taken into account insufficiently.
>
> Basically, the MEP proposes conversion support for various
> types of Signal object lookup. The example given is:
>
>       myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>
> and the proposed conversion is:
>
>       myObject_x = ListOfSignal_10 + DictOfSignal_fred
>
> Conceptually, these 3 cases are very similar: lookup based on
> a manifest attribute name, index, string. The immediate question
> is why we would need support for 3 almost identical cases.
> The answer is that this example is not representative for
> the main purpose of a List or a Dict data structure.
>
> The essence of a List or a Dict is lookup based on a
> *variable* index (integer or string). But this can only be
> supported by a mapping to an equivalent data structure in
> the target. Note that MyHDL conversion supports this today
> for "homogenuous" lists. However, I don't know how this
> would work for a "heterogenuous" list or for a dictionary.
>
> There may be solutions based on pointers, access types,
> or SystemVerilog data structures, but I doubt all this
> is worth the trouble, especially because there is little
> chance that such beasts would be supported by synthesis.
> Synthesis is not the only, but an important application
> of the converted code.
>
> Of course conversion could be restricted to the case of
> manifest indices. But that is a bad solution for the following
> reasons:
>
> 1) when support for heterogenuous lists or dictionaries is
> advertized, it is unavoidable that people will expect this
> to work with variable indices. So it raises expectations that
> cannot be met and will only result in frustrations.
> 2) there is a superior alternative available, which is
> attribute lookup. Better direct people to that solution
> immediately.
>

First, MEP-107 fails to clearly address the use cases
you mention for heterogeneous lists and dictionaries.
I agree it should be removed and MEP-107 to only propose
conversion of attributes which are convertible types.

I strongly disagree that *synthesis* was insufficiently
taken into account.  But it is hard to determine this by
the information provided in the MEP.  The point I hoped,
covered synthesis adequately, is that a referenced convertible
type would convert to a canonical type, i.e converted to
a unique net name.  It is clear now that this alone did
not provide sufficient information on how the canonical
conversion would handle anything but the trivial literal
index.

For the canonical conversion, complex types always need
to be unrolled.  Unrolling should support variable index
and iteration.  But this strays from the current conversion
goal; to have a closes as possible one-to-one mapping from
MyHDL to the lower-HDL.  This means that the converter has
to do more work (increased complexity in an already complex
piece of code).

Is this practical?  Impossible to tell from MEP-107.
For hetero-lists and dictionaries to be proposed as signal
containers a new MEP with much more detail will need to
be created.  In addition the MEP needs to cover the common
use cases of hetero-lists and dictionaries and clearly
identify what would not be convertible.  I *do* think it
is worth-while creating the MEP regardless if we decide
to implemented the features or not.

Which brings up the question, if a MEP is declined,
where and how is it best to document why the MEP is
declined?  Is it in the MEP?  Or are future questions
referred to some other document?

In summary, I agree hetero-lists and dictionaries
should be removed from MEP-107.  And we can debate if
attribute conversion should be implemented :)

Regards,
Chris Felton

On 06/06/2012 08:49 PM, Oscar Diaz wrote:

> Just to be sure, what are you meaning with dynamic indexing?

An index which is not a constant.

> My first
> thought was this is when the index is a mutable object, or that it can
> change on runtime. For that case conversion is done with RAM
> inference, and only for lists.

Some confusion here. Ram inference is done after converson, by
a synthesis tool that recognizes a certain pattern. Also, mutability
is a characteristic of python objects. "Constantness" depends
on how objects are used in code.

>  However, I also thought of, what if the
> index is an immutable, and can be treated as a constant at runtime?

Should work today.

> I understand that, in RAM (and also ROM) inference, the index must be a
> Signal, and fails for any other type.

Should work with a plain intbv variable also.

> If this MEP covers index lookup,
> that other immutable types could be treated as the selection of a
> signal in a container.

Indexing with a constant should work today also.

What is not supported currently is "heterogenuous" lists (lists in
which not all member have identical bit widths), and this is what
the MEP proposes. But I don't see how for the general case,
because the target HDLs are not so dynamic as Python.

> Or, maybe it's matter of coding style? What approach is more
> "pythonic" or more convenient for conversion? IMHO, in design both
> approaches (attribute and dict index) are equally valid. I guess this
> could be a matter of debate in the list.

Attributes are normally the first choice to define the
names of instance variables.

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

On 06/06/2012 05:47 PM, Oscar Diaz wrote:

> Like you said at beginning of the email, this works fine in
> simulation, but conversion fails when you try to access container
> members directly on generators. A workaround I've been using is to use
> references to local names on elaboration. Taking the example from MEP:
>
> def ex1(clk, srst, xyz):
>
>      z = xyz.z
>      x = xyz.x
>      y = xyz.y
>
>      @always(clk.posedge)
>      def hdl():
>          z.next = x + y
>
>      return hdl

This example got me thinking. I have never used it like that
but it is a great example of how elaboration can be
used to support powerful features which are not convertible
at first sight. It may be that many users are not
aware of this possibility.

What I was thinking - is this really a workaround, or is it
rather a desirable coding pattern (with the nice side effect
that it is supported today)?

Suppose MEP 107 were implemented, we could write
the example as follows:

def ex1(clk, srst, xyz):

       @always(clk.posedge)
       def hdl():
           xyz.z.next = xyz.x + xyz.y

       return hdl

Is this really clearer, especially if there would be a number
of generators which could be much more complicated than
in the example?

When I use classes now, I often get the instance variables
of the 'self' variable once, especially when methods are
complex. But this must be done per method. In this case,
because of the scoping rules, we would have to do it only
once for all generators in the module. The result would be
a simplification of all code that follows.

An valid argument for "signal containers" such as xyz is that it
simplifies interfaces, and makes it easier to modify them.
Even that could be simpler with the first pattern, because
it would tend to localize a change (e.g. a name change
in the interface would have to be done at just one location
and the code would still work).

As a minimum, we should consider writing a whitepaper/page
"How to use inferfaces in convertible MyHDL", to
describes the current state of the art.

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

2012/6/6 Jan Decaluwe <ja...@ja...>:
> On 06/06/2012 05:47 PM, Oscar Diaz wrote:
>> 2012/6/5 Jan Decaluwe<ja...@ja...>:
<snip>
>>> Conceptually, these 3 cases are very similar: lookup based on
>>> a manifest attribute name, index, string. The immediate question
>>> is why we would need support for 3 almost identical cases.
>>> The answer is that this example is not representative for
>>> the main purpose of a List or a Dict data structure.
>>
>> I guess we propose the 3 cases for completeness, to cover all
>> possibilities. Although I agree that maybe lists is not the best
>> container for heterogeneous set of signals.
>
> My argument is that such completeness is not possible (or
> not practical) because the essential feature of a list
> of dict (dynamic indexing) cannot be supported. Incompleteness
> is a guaranteed source of confusion.

Just to be sure, what are you meaning with dynamic indexing? My first
thought was this is when the index is a mutable object, or that it can
change on runtime. For that case conversion is done with RAM
inference, and only for lists. However, I also thought of, what if the
index is an immutable, and can be treated as a constant at runtime? I
understand that, in RAM (and also ROM) inference, the index must be a
Signal, and fails for any other type. If this MEP covers index lookup,
that other immutable types could be treated as the selection of a
signal in a container.

>
>
>>>
<snip>
>>
>> I think there's another case: indices resolved at elaboration time.
>> But this is a topic of what election is more elegant: having a index
>> lookup or use getattr().
>
> getattr, dynamic attribute lookup is not discussed in the MEP
> and would also be hard to support in conversion.

Ok, I suspected that :)
>
>>
>> Suppose I have a constant with the name of the signal I need to use.
>> If the container is a dict, I can access by
>> "dict_container[the_signal_str]", but if the container stores the
>> signals as attributes, I have to access it by "getattr(obj_container,
>> the_signal_str)".
>>
>> Personally I've been using dicts as signal containers because:
>> 1. Visually, an index lookup is clearer to me as a signal inside a
>> container than an attribute (I know, this is extremely subjective,
>> surely I could be proven wrong here).
>> 2. Subclassing dict allows me to add some convenient methods that only
>> use on elaboration. For instance, different signal references for
>> different cases.
>>
>> Let me give an example: I use a wishbone object by subclassing dict.
>>
>> class WishboneBus(dict):
>>      def __init__(self, DataWidth=16, AddressWidth=8):
>>          self["clk"] = Signal(False)
>>          self["rst"] = Signal(False)
>>          self["dat_i"] = Signal(False)
>>          self["dat_o"] = Signal(False)
>>          ....
>>      def get_signals_ref_master(self):
>>          return {"clk": self["clk"], "rst": self["rst"], "dat_i":
>> self["dat_i"], "dat_o": self["dat_o"], ...}
>>
>>      def get_signals_ref_slave(self):
>>          return {"clk": self["clk"], "rst": self["rst"], "dat_i":
>> self["dat_o"], "dat_o": self["dat_i"], ...}
>
> I don't understand why it has to subclass dict and why
> the instance variables can't be just attributes of self,
> as is usually done. This would not prevent you from using dicts
> in the get-* methods if you want.

I guess that was my first approach to use containers, before trying
class attributes. And also it was more natural when I needed to
iterate through signal names. Of course, I can also iterate through
attributes, but it's a bit more complex (iterate through dir() output,
make an iterator, select only signals and ignore other members). Just
to be clear, all this extra stuff was only used on elaboration. Inside
generators I just do indexing from a container.

Or, maybe it's matter of coding style? What approach is more
"pythonic" or more convenient for conversion? IMHO, in design both
approaches (attribute and dict index) are equally valid. I guess this
could be a matter of debate in the list.

Also, I thought dicts were easier to support in conversion than
attributes, but after seeing a bit of the source code it seems I was
wrong.

>
>
>> So, my "master" component will have the correct signal references
>> (dat_i from container is dat_i for master) and "slave" component will
>> have a different mapping (dat_i from container is dat_o for slave).
>> I'm not sure how to do this using attribute lookup.
>>
>> Like you said at beginning of the email, this works fine in
>> simulation, but conversion fails when you try to access container
>> members directly on generators. A workaround I've been using is to use
>> references to local names on elaboration. Taking the example from MEP:
>>
>> def ex1(clk, srst, xyz):
>>
>>      z = xyz.z
>>      x = xyz.x
>>      y = xyz.y
>>
>>      @always(clk.posedge)
>>      def hdl():
>>          z.next = x + y
>>
>>      return hdl
>>
>>
>> Best regards.
>>
>> PD: sorry I joined late to this discussion. In fact, I'm still trying
>> to keep update with latest posts.
>>
>>>
>>> --
>>> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>>>      Python as a HDL: http://www.myhdl.org
>>>      VHDL development, the modern way: http://www.sigasi.com
>>>      World-class digital design: http://www.easics.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>
>>
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a HDL: http://www.myhdl.org
>     VHDL development, the modern way: http://www.sigasi.com
>     World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

On 06/06/2012 11:17 AM, Jan Decaluwe wrote:
> On 06/06/2012 05:47 PM, Oscar Diaz wrote:
>> 2012/6/5 Jan Decaluwe<ja...@ja...>:
>>> I have read and thought about MEP 107. Here is my initial
>>> assessment.
>>>
>>> This MEP is strictly about conversion. This is explained in
>>> the first paragraph, but I think it should be mentioned in
>>> the title also, because this has proven to be an eternal source
>>> of confusion. It should be made clear that all modeling
>>> aspects being discussed are supported by MyHDL as it is today.
>>>
>>> One aspect of conversion is that it is unavoidable to consider
>>> the capabilities and restrictions of the conversion targets
>>> VHDL and Verilog, with special attention to synthesis. I think
>>> that aspect is taken into account insufficiently.
>> At first I thought a signal container should map to VHDL records
>> (sorry, I don't know if Verilog has something similar), but it seems
>> that records are rarely used in IPs (I mean, synthesizable code).
>> Besides, it is clear that generated code is not meant to be
>> "human-friendly" readable, but behaviorally equivalent with the source
>> model. So a plain names conversion is sufficient.
> 2 reasons why records are a no go:
>
> * no support in Verilog
> * in VHDL, they fix the in/out direction for all members,
> something we definitely do not want.
>
>>> Basically, the MEP proposes conversion support for various
>>> types of Signal object lookup. The example given is:
>>>
>>>       myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>>>
>>> and the proposed conversion is:
>>>
>>>       myObject_x = ListOfSignal_10 + DictOfSignal_fred
>>>
>>> Conceptually, these 3 cases are very similar: lookup based on
>>> a manifest attribute name, index, string. The immediate question
>>> is why we would need support for 3 almost identical cases.
>>> The answer is that this example is not representative for
>>> the main purpose of a List or a Dict data structure.
>> I guess we propose the 3 cases for completeness, to cover all
>> possibilities. Although I agree that maybe lists is not the best
>> container for heterogeneous set of signals.
> My argument is that such completeness is not possible (or
> not practical) because the essential feature of a list
> of dict (dynamic indexing) cannot be supported. Incompleteness
> is a guaranteed source of confusion.
>
>
>>> The essence of a List or a Dict is lookup based on a
>>> *variable* index (integer or string). But this can only be
>>> supported by a mapping to an equivalent data structure in
>>> the target. Note that MyHDL conversion supports this today
>>> for "homogenuous" lists. However, I don't know how this
>>> would work for a "heterogenuous" list or for a dictionary.
>>>
>>> There may be solutions based on pointers, access types,
>>> or SystemVerilog data structures, but I doubt all this
>>> is worth the trouble, especially because there is little
>>> chance that such beasts would be supported by synthesis.
>>> Synthesis is not the only, but an important application
>>> of the converted code.
>>>
>>> Of course conversion could be restricted to the case of
>>> manifest indices. But that is a bad solution for the following
>>> reasons:
>>>
>>> 1) when support for heterogenuous lists or dictionaries is
>>> advertized, it is unavoidable that people will expect this
>>> to work with variable indices. So it raises expectations that
>>> cannot be met and will only result in frustrations.
>>> 2) there is a superior alternative available, which is
>>> attribute lookup. Better direct people to that solution
>>> immediately.
>> I think there's another case: indices resolved at elaboration time.
>> But this is a topic of what election is more elegant: having a index
>> lookup or use getattr().
> getattr, dynamic attribute lookup is not discussed in the MEP
> and would also be hard to support in conversion.
>
>
>> Suppose I have a constant with the name of the signal I need to use.
>> If the container is a dict, I can access by
>> "dict_container[the_signal_str]", but if the container stores the
>> signals as attributes, I have to access it by "getattr(obj_container,
>> the_signal_str)".
>>
>> Personally I've been using dicts as signal containers because:
>> 1. Visually, an index lookup is clearer to me as a signal inside a
>> container than an attribute (I know, this is extremely subjective,
>> surely I could be proven wrong here).
>> 2. Subclassing dict allows me to add some convenient methods that only
>> use on elaboration. For instance, different signal references for
>> different cases.
>>
>> Let me give an example: I use a wishbone object by subclassing dict.
>>
>> class WishboneBus(dict):
>>       def __init__(self, DataWidth=16, AddressWidth=8):
>>           self["clk"] = Signal(False)
>>           self["rst"] = Signal(False)
>>           self["dat_i"] = Signal(False)
>>           self["dat_o"] = Signal(False)
>>           ....
>>       def get_signals_ref_master(self):
>>           return {"clk": self["clk"], "rst": self["rst"], "dat_i":
>> self["dat_i"], "dat_o": self["dat_o"], ...}
>>
>>       def get_signals_ref_slave(self):
>>           return {"clk": self["clk"], "rst": self["rst"], "dat_i":
>> self["dat_o"], "dat_o": self["dat_i"], ...}
> I don't understand why it has to subclass dict and why
> the instance variables can't be just attributes of self,
> as is usually done. This would not prevent you from using dicts
> in the get-* methods if you want.

I was wondering the same thing, as that is how I do it now.

I think I may late joining in on this topic.

A couple of comments and a question below:

On 06/05/2012 03:52 PM, Jan Decaluwe wrote:
> I have read and thought about MEP 107. Here is my initial
> assessment.
>
> This MEP is strictly about conversion. This is explained in
> the first paragraph, but I think it should be mentioned in
> the title also, because this has proven to be an eternal source
> of confusion. It should be made clear that all modeling
> aspects being discussed are supported by MyHDL as it is today.
>
> One aspect of conversion is that it is unavoidable to consider
> the capabilities and restrictions of the conversion targets
> VHDL and Verilog, with special attention to synthesis. I think
> that aspect is taken into account insufficiently.
>
> Basically, the MEP proposes conversion support for various
> types of Signal object lookup. The example given is:
>
>       myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>
> and the proposed conversion is:
>
>       myObject_x = ListOfSignal_10 + DictOfSignal_fred
>
> Conceptually, these 3 cases are very similar: lookup based on
> a manifest attribute name, index, string. The immediate question
> is why we would need support for 3 almost identical cases.
> The answer is that this example is not representative for
> the main purpose of a List or a Dict data structure.

I am not familiar with the current limitations for dicts, but if we used 
only the list would it not work? As long the list was defined properly 
and only used once since we consider them memories now. By using a 
constant, you would only ever be able to read one location from the 
memory. Probably not what you want.

What you would be trying to do is change how we use lists, I now 
consider lists as a memory when you try to covert them. But I suppose 
they could also be more of a register file, so that all locations could 
be used at the same time.

Obviously the structure of the HDL generated for the memory case vs the 
register file would need to be different. We had to code the list to 
memory specifically so synthesis would find them.

I personally don't think we need to be able to convert more types than 
is necessary to get the job done. So if you have to live with a certain 
coding style to get it to convert that is fine with me.

What are the advantages of lists and dicts as signal containers over 
classes?

On 06/06/2012 05:47 PM, Oscar Diaz wrote:
> 2012/6/5 Jan Decaluwe<ja...@ja...>:
>> I have read and thought about MEP 107. Here is my initial
>> assessment.
>>
>> This MEP is strictly about conversion. This is explained in
>> the first paragraph, but I think it should be mentioned in
>> the title also, because this has proven to be an eternal source
>> of confusion. It should be made clear that all modeling
>> aspects being discussed are supported by MyHDL as it is today.
>>
>> One aspect of conversion is that it is unavoidable to consider
>> the capabilities and restrictions of the conversion targets
>> VHDL and Verilog, with special attention to synthesis. I think
>> that aspect is taken into account insufficiently.
>
> At first I thought a signal container should map to VHDL records
> (sorry, I don't know if Verilog has something similar), but it seems
> that records are rarely used in IPs (I mean, synthesizable code).
> Besides, it is clear that generated code is not meant to be
> "human-friendly" readable, but behaviorally equivalent with the source
> model. So a plain names conversion is sufficient.

2 reasons why records are a no go:

* no support in Verilog
* in VHDL, they fix the in/out direction for all members,
something we definitely do not want.

>> Basically, the MEP proposes conversion support for various
>> types of Signal object lookup. The example given is:
>>
>>      myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>>
>> and the proposed conversion is:
>>
>>      myObject_x = ListOfSignal_10 + DictOfSignal_fred
>>
>> Conceptually, these 3 cases are very similar: lookup based on
>> a manifest attribute name, index, string. The immediate question
>> is why we would need support for 3 almost identical cases.
>> The answer is that this example is not representative for
>> the main purpose of a List or a Dict data structure.
>
> I guess we propose the 3 cases for completeness, to cover all
> possibilities. Although I agree that maybe lists is not the best
> container for heterogeneous set of signals.

My argument is that such completeness is not possible (or
not practical) because the essential feature of a list
of dict (dynamic indexing) cannot be supported. Incompleteness
is a guaranteed source of confusion.

>>
>> The essence of a List or a Dict is lookup based on a
>> *variable* index (integer or string). But this can only be
>> supported by a mapping to an equivalent data structure in
>> the target. Note that MyHDL conversion supports this today
>> for "homogenuous" lists. However, I don't know how this
>> would work for a "heterogenuous" list or for a dictionary.
>>
>> There may be solutions based on pointers, access types,
>> or SystemVerilog data structures, but I doubt all this
>> is worth the trouble, especially because there is little
>> chance that such beasts would be supported by synthesis.
>> Synthesis is not the only, but an important application
>> of the converted code.
>>
>> Of course conversion could be restricted to the case of
>> manifest indices. But that is a bad solution for the following
>> reasons:
>>
>> 1) when support for heterogenuous lists or dictionaries is
>> advertized, it is unavoidable that people will expect this
>> to work with variable indices. So it raises expectations that
>> cannot be met and will only result in frustrations.
>> 2) there is a superior alternative available, which is
>> attribute lookup. Better direct people to that solution
>> immediately.
>
> I think there's another case: indices resolved at elaboration time.
> But this is a topic of what election is more elegant: having a index
> lookup or use getattr().

getattr, dynamic attribute lookup is not discussed in the MEP
and would also be hard to support in conversion.

>
> Suppose I have a constant with the name of the signal I need to use.
> If the container is a dict, I can access by
> "dict_container[the_signal_str]", but if the container stores the
> signals as attributes, I have to access it by "getattr(obj_container,
> the_signal_str)".
>
> Personally I've been using dicts as signal containers because:
> 1. Visually, an index lookup is clearer to me as a signal inside a
> container than an attribute (I know, this is extremely subjective,
> surely I could be proven wrong here).
> 2. Subclassing dict allows me to add some convenient methods that only
> use on elaboration. For instance, different signal references for
> different cases.
>
> Let me give an example: I use a wishbone object by subclassing dict.
>
> class WishboneBus(dict):
>      def __init__(self, DataWidth=16, AddressWidth=8):
>          self["clk"] = Signal(False)
>          self["rst"] = Signal(False)
>          self["dat_i"] = Signal(False)
>          self["dat_o"] = Signal(False)
>          ....
>      def get_signals_ref_master(self):
>          return {"clk": self["clk"], "rst": self["rst"], "dat_i":
> self["dat_i"], "dat_o": self["dat_o"], ...}
>
>      def get_signals_ref_slave(self):
>          return {"clk": self["clk"], "rst": self["rst"], "dat_i":
> self["dat_o"], "dat_o": self["dat_i"], ...}

I don't understand why it has to subclass dict and why
the instance variables can't be just attributes of self,
as is usually done. This would not prevent you from using dicts
in the get-* methods if you want.

> So, my "master" component will have the correct signal references
> (dat_i from container is dat_i for master) and "slave" component will
> have a different mapping (dat_i from container is dat_o for slave).
> I'm not sure how to do this using attribute lookup.
>
> Like you said at beginning of the email, this works fine in
> simulation, but conversion fails when you try to access container
> members directly on generators. A workaround I've been using is to use
> references to local names on elaboration. Taking the example from MEP:
>
> def ex1(clk, srst, xyz):
>
>      z = xyz.z
>      x = xyz.x
>      y = xyz.y
>
>      @always(clk.posedge)
>      def hdl():
>          z.next = x + y
>
>      return hdl
>
>
> Best regards.
>
> PD: sorry I joined late to this discussion. In fact, I'm still trying
> to keep update with latest posts.
>
>>
>> --
>> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>>      Python as a HDL: http://www.myhdl.org
>>      VHDL development, the modern way: http://www.sigasi.com
>>      World-class digital design: http://www.easics.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>

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

2012/6/5 Jan Decaluwe <ja...@ja...>:
> I have read and thought about MEP 107. Here is my initial
> assessment.
>
> This MEP is strictly about conversion. This is explained in
> the first paragraph, but I think it should be mentioned in
> the title also, because this has proven to be an eternal source
> of confusion. It should be made clear that all modeling
> aspects being discussed are supported by MyHDL as it is today.
>
> One aspect of conversion is that it is unavoidable to consider
> the capabilities and restrictions of the conversion targets
> VHDL and Verilog, with special attention to synthesis. I think
> that aspect is taken into account insufficiently.

At first I thought a signal container should map to VHDL records
(sorry, I don't know if Verilog has something similar), but it seems
that records are rarely used in IPs (I mean, synthesizable code).
Besides, it is clear that generated code is not meant to be
"human-friendly" readable, but behaviorally equivalent with the source
model. So a plain names conversion is sufficient.

>
> Basically, the MEP proposes conversion support for various
> types of Signal object lookup. The example given is:
>
>     myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']
>
> and the proposed conversion is:
>
>     myObject_x = ListOfSignal_10 + DictOfSignal_fred
>
> Conceptually, these 3 cases are very similar: lookup based on
> a manifest attribute name, index, string. The immediate question
> is why we would need support for 3 almost identical cases.
> The answer is that this example is not representative for
> the main purpose of a List or a Dict data structure.

I guess we propose the 3 cases for completeness, to cover all
possibilities. Although I agree that maybe lists is not the best
container for heterogeneous set of signals.

>
> The essence of a List or a Dict is lookup based on a
> *variable* index (integer or string). But this can only be
> supported by a mapping to an equivalent data structure in
> the target. Note that MyHDL conversion supports this today
> for "homogenuous" lists. However, I don't know how this
> would work for a "heterogenuous" list or for a dictionary.
>
> There may be solutions based on pointers, access types,
> or SystemVerilog data structures, but I doubt all this
> is worth the trouble, especially because there is little
> chance that such beasts would be supported by synthesis.
> Synthesis is not the only, but an important application
> of the converted code.
>
> Of course conversion could be restricted to the case of
> manifest indices. But that is a bad solution for the following
> reasons:
>
> 1) when support for heterogenuous lists or dictionaries is
> advertized, it is unavoidable that people will expect this
> to work with variable indices. So it raises expectations that
> cannot be met and will only result in frustrations.
> 2) there is a superior alternative available, which is
> attribute lookup. Better direct people to that solution
> immediately.

I think there's another case: indices resolved at elaboration time.
But this is a topic of what election is more elegant: having a index
lookup or use getattr().

Suppose I have a constant with the name of the signal I need to use.
If the container is a dict, I can access by
"dict_container[the_signal_str]", but if the container stores the
signals as attributes, I have to access it by "getattr(obj_container,
the_signal_str)".

Personally I've been using dicts as signal containers because:
1. Visually, an index lookup is clearer to me as a signal inside a
container than an attribute (I know, this is extremely subjective,
surely I could be proven wrong here).
2. Subclassing dict allows me to add some convenient methods that only
use on elaboration. For instance, different signal references for
different cases.

Let me give an example: I use a wishbone object by subclassing dict.

class WishboneBus(dict):
    def __init__(self, DataWidth=16, AddressWidth=8):
        self["clk"] = Signal(False)
        self["rst"] = Signal(False)
        self["dat_i"] = Signal(False)
        self["dat_o"] = Signal(False)
        ....
    def get_signals_ref_master(self):
        return {"clk": self["clk"], "rst": self["rst"], "dat_i":
self["dat_i"], "dat_o": self["dat_o"], ...}

    def get_signals_ref_slave(self):
        return {"clk": self["clk"], "rst": self["rst"], "dat_i":
self["dat_o"], "dat_o": self["dat_i"], ...}

So, my "master" component will have the correct signal references
(dat_i from container is dat_i for master) and "slave" component will
have a different mapping (dat_i from container is dat_o for slave).
I'm not sure how to do this using attribute lookup.

Like you said at beginning of the email, this works fine in
simulation, but conversion fails when you try to access container
members directly on generators. A workaround I've been using is to use
references to local names on elaboration. Taking the example from MEP:

def ex1(clk, srst, xyz):

    z = xyz.z
    x = xyz.x
    y = xyz.y

    @always(clk.posedge)
    def hdl():
        z.next = x + y

    return hdl

Best regards.

PD: sorry I joined late to this discussion. In fact, I'm still trying
to keep update with latest posts.

>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a HDL: http://www.myhdl.org
>     VHDL development, the modern way: http://www.sigasi.com
>     World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

I have read and thought about MEP 107. Here is my initial
assessment.

This MEP is strictly about conversion. This is explained in
the first paragraph, but I think it should be mentioned in
the title also, because this has proven to be an eternal source
of confusion. It should be made clear that all modeling
aspects being discussed are supported by MyHDL as it is today.

One aspect of conversion is that it is unavoidable to consider
the capabilities and restrictions of the conversion targets
VHDL and Verilog, with special attention to synthesis. I think
that aspect is taken into account insufficiently.

Basically, the MEP proposes conversion support for various
types of Signal object lookup. The example given is:

     myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']

and the proposed conversion is:

     myObject_x = ListOfSignal_10 + DictOfSignal_fred

Conceptually, these 3 cases are very similar: lookup based on
a manifest attribute name, index, string. The immediate question
is why we would need support for 3 almost identical cases.
The answer is that this example is not representative for
the main purpose of a List or a Dict data structure.

The essence of a List or a Dict is lookup based on a
*variable* index (integer or string). But this can only be
supported by a mapping to an equivalent data structure in
the target. Note that MyHDL conversion supports this today
for "homogenuous" lists. However, I don't know how this
would work for a "heterogenuous" list or for a dictionary.

There may be solutions based on pointers, access types,
or SystemVerilog data structures, but I doubt all this
is worth the trouble, especially because there is little
chance that such beasts would be supported by synthesis.
Synthesis is not the only, but an important application
of the converted code.

Of course conversion could be restricted to the case of
manifest indices. But that is a bad solution for the following
reasons:

1) when support for heterogenuous lists or dictionaries is
advertized, it is unavoidable that people will expect this
to work with variable indices. So it raises expectations that
cannot be met and will only result in frustrations.
2) there is a superior alternative available, which is
attribute lookup. Better direct people to that solution
immediately.

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

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (14)	Nov (4)	Dec
2004	Jan (1)	Feb (10)	Mar (19)	Apr (14)	May (1)	Jun (4)	Jul (10)	Aug	Sep (2)	Oct (7)	Nov (17)	Dec (12)
2005	Jan (6)	Feb (10)	Mar (17)	Apr (10)	May (9)	Jun (5)	Jul (26)	Aug (34)	Sep (10)	Oct (38)	Nov (71)	Dec (74)
2006	Jan (20)	Feb (20)	Mar (7)	Apr (2)	May (13)	Jun	Jul	Aug (4)	Sep (37)	Oct (43)	Nov (30)	Dec (33)
2007	Jan (3)	Feb	Mar	Apr	May (30)	Jun (9)	Jul (1)	Aug	Sep (8)	Oct (13)	Nov	Dec (4)
2008	Jan (13)	Feb (46)	Mar (25)	Apr (7)	May (20)	Jun (73)	Jul (38)	Aug (47)	Sep (24)	Oct (18)	Nov (9)	Dec (36)
2009	Jan (31)	Feb (24)	Mar (73)	Apr (13)	May (47)	Jun (28)	Jul (36)	Aug (2)	Sep (5)	Oct (8)	Nov (16)	Dec (29)
2010	Jan (34)	Feb (18)	Mar (18)	Apr (5)	May	Jun (24)	Jul (53)	Aug (3)	Sep (18)	Oct (33)	Nov (19)	Dec (15)
2011	Jan (9)	Feb (4)	Mar (39)	Apr (213)	May (86)	Jun (46)	Jul (22)	Aug (11)	Sep (78)	Oct (59)	Nov (38)	Dec (24)
2012	Jan (9)	Feb (22)	Mar (89)	Apr (55)	May (222)	Jun (86)	Jul (57)	Aug (32)	Sep (49)	Oct (69)	Nov (12)	Dec (35)
2013	Jan (67)	Feb (39)	Mar (18)	Apr (42)	May (79)	Jun (1)	Jul (19)	Aug (18)	Sep (54)	Oct (79)	Nov (9)	Dec (26)
2014	Jan (30)	Feb (44)	Mar (26)	Apr (11)	May (39)	Jun (1)	Jul (89)	Aug (15)	Sep (7)	Oct (6)	Nov (20)	Dec (27)
2015	Jan (107)	Feb (106)	Mar (130)	Apr (90)	May (147)	Jun (28)	Jul (53)	Aug (16)	Sep (23)	Oct (7)	Nov	Dec (16)
2016	Jan (86)	Feb (41)	Mar (38)	Apr (31)	May (37)	Jun (11)	Jul (1)	Aug (1)	Sep (3)	Oct (1)	Nov (5)	Dec (3)
2017	Jan	Feb (4)	Mar (2)	Apr (2)	May	Jun (3)	Jul (2)	Aug (2)	Sep (1)	Oct (2)	Nov (1)	Dec (1)
2018	Jan (1)	Feb (1)	Mar (7)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan (1)	Feb	Mar (2)	Apr (1)	May (1)	Jun (2)	Jul	Aug	Sep (1)	Oct	Nov (3)	Dec
2020	Jan (1)	Feb (2)	Mar	Apr (1)	May	Jun	Jul (1)	Aug (1)	Sep (1)	Oct	Nov	Dec (3)
2021	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (2)	Aug	Sep	Oct	Nov (12)	Dec (11)
2022	Jan (7)	Feb (2)	Mar (1)	Apr	May	Jun (1)	Jul (3)	Aug (2)	Sep (1)	Oct	Nov	Dec (1)
2023	Jan	Feb (1)	Mar (1)	Apr (3)	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2024	Jan (1)	Feb (2)	Mar (4)	Apr (2)	May (2)	Jun (1)	Jul	Aug (1)	Sep (1)	Oct	Nov	Dec (2)
2025	Jan (1)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

myhdl-list Mailing List for MyHDL (Page 86)

myhdl-list — Mailing list for discussions on MyHDL