Re: [myhdl-list] MEP 107 assessment

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

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