Re: [myhdl-list] MEP 107 assessment

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

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