Re: [myhdl-list] MEP 107 assessment

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

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.