Re: [myhdl-list] MEP 107 assessment

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

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