Re: [myhdl-list] MEP 107 assessment
Brought to you by:
jandecaluwe
Menu
▾
▴
Re: [myhdl-list] MEP 107 assessment
|
From: Oscar D. <osc...@gm...> - 2012-06-06 18:49:56
|
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
|
