Re: [myhdl-list] MEP : Signal Containers

[Oscar D. <osc...@gm...>]

2011/11/21 Christopher Felton <chr...@gm...>:
> On 11/21/2011 9:39 AM, Oscar Diaz wrote:
>> 2011/11/15 Christopher Felton<chr...@gm...>:
>>> The following is a *start* to a MEP that describes the conversion
>>> support for classes, lists, and dictionaries.  This is just a start of
>>> the enhancement description and does not include some of the mechanical
>>> (code changes) items worth identifying in a MEP.
>>
>> Thanks for making this draft. I'm mostly agree this MEP, I'll just add
>> some thoughts:
>>
>> * Since a class could be more powerful than a list or a dict,
>> container classes should allow enhanced features i.e. custom naming
>> scheme. We can propose hidden methods to support that features, in a
>> similar way of the special methods from the python data model:
>>
>> http://docs.python.org/reference/datamodel.html#special-method-names
>
> If we do this we would need to define a base class, something like
> SignalStruct, that would contain these features.  Past feedback indicate
> they would like general class/objects to be convertible without defining
> a special base class.
>
> I think general class/objects would need to be supported but having an
> additional MyHDL ojbect to help guide conversion would be useful.  Also,
> defining a SignalStruct object would make things easier (my guess) for a
> first implementation.  It might be a good spot to start with and explore
> the conversion routines.
>
>>
>> Right now I'm thinking about
>>
>> * It's not explicitly mentioned, but I guess the conversion step will
>> "flatten" the signal container. Although I agree on that, maybe we
>> could think about support to conversion to arrays or records (I speak
>> mainly for VHDL, I'm not that expert of Verilog).
>
> The argument against using VHDL records is to keep a similar conversion
> for Verilog and VHDL, IMO.  We don't want to use the SystemVerilog
> struct unless it is supported by the open-source compiler/simulators.
> Since we need to flatten it for Verilog I think flattening it VHDL is
> reasonable, least common denominator.
>
> My thought, if we have a special case for VHDL it would be more work to
> develop, maintain, and test.  Personally I like limiting the use of the
> underlying HDL as minimal as possible and maximum overlap between HDLs.
>
>>
>> * About the conversion of class methods, I think that should be in
>> another MEP, this one is to define signal containers. We should make
>> another MEP to add support for conversion of classes (not just class
>> methods). However, I do agree that the class methods must have support
>> for conversion, as you explained here, and I think it is easy to fix
>> the self argument issue in the conversion code.
>
> That is reasonable but I don't follow what you mean by the conversion of
> classes?  In my mind, once you have a mechanism to dig down and find the
> signal, I call them primitives (which is the main purpose of this mep).
>  And generator conversion is already supported (other than a generator
> that is defined in a class).

What I mean is a "standard" way to use classes. In my projects, I make
heavy use of inheritance to add generators on base components. Right
now I'm using a list of generators inside the classes, and just append
generators at __init__ or by calling methods from the extended
classes. On simulation, I make a big list with all the generators from
all objects instantiated' list of generators. It works nice on
simulation, but I wanted to do the same for conversion (I haven't
researched this last issue yet).

>
>>
>> That's all for now.
>>
>> Best regards.
>>
>> P.D.: Perhaps I can help with the VHDL code snippet:
>>
>> VHDL example conversion.
>> .. code-block :: vhdl
>>
>> entity foo is
>>      port (
>>          clk: in std_logic;
>>          MyObj_x: in unsigned(7 downto 0);
>>          MyObj_y: in unsigned(3 downto 0);
>>          MyObj_z: out unsigned(8 downto 0)
>>      );
>> end entity foo;
>>
>> architecture MyHDL of foo is
>>
>> begin
>>
>>      RTL: process(clk) is
>>      begin
>>          if rising_edge(clk) then
>>              MyObj_z<= MyObj_x + MyObj_y
>>          end if;
>>      end process RTL;
>>
>> end architecture MyHDL;
>>
>>
>
> Thanks for the code snip.
>
>> Right now I'm thinking about:
>> * custom naming scheme: something like "_names_iter(self)" method that
>> returns the desired names for each signal.
> I believe an object would need to be provided, that has special hooks
> and methods.  But the use of the object (e.g. SignalStruct) is optional.
>  Converting objects with Signal members should be convertible.  I will
> add this MyHDL object, SignalStruct, to the MEP and outline what you
> have suggested.
>
>> * late signal creation: suppose that I need to calculate the width of
>> a signal, but I already create the container object. A method that
>> create (or update) the signal objects just before simulation or
>> conversion can be defined.
> Late/dynamic signal creation is not an issue as long as it is done
> during elaboration.
>
>> * classes with special method names: what happen if I define the
>> __slot__ list? or if I define a custom __getattr__ or another methods?
>
> No methods would be used/inspected for conversion (ignoring generators
> for now), special methods shouldn't cause a problem.  A member of an
> object, if it is a convertible Signal or a convertible constant will be
> considered for conversion and flattened.
>
> Thanks for the feedback,
> Chris

Best regards
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> 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