Re: [myhdl-list] Keeping hierarchy for conversion

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

2012/7/17 Christopher Felton <chr...@gm...>:
> This topic has popped up from time to time.  I haven't
> had time to read your post thoroughly but I wanted to
> bring attention to some old posts, in case you were
> unaware of them, that discuss this topic.
>
> http://thread.gmane.org/gmane.comp.python.myhdl/1484
> http://thread.gmane.org/gmane.comp.python.myhdl/1484/focus=1488
> http://thread.gmane.org/gmane.comp.python.myhdl/2019

Oops, my fault, I didn't check past posts deep enough. I agree my
first reason for hierarchy keeping can be easily solved by
user-defined code (mea culpa, I'll withdraw that example). However,
for my second example I should remembered saying floor-planning,
because this is a more general motivation for this proposal (and right
now it's very difficult to do floor-planning with MyHDL).

>
> In an ideal world it would probably be nice to have
> an option to keep hierarchy but I think there a many
> technical obstacles that make it impractical(?).  As
> discussed in the first thread the two step approach
> is required.  I don't know if the two step approach
> could be generalized to a single function call.

I implemented something similar to that "two step" approach: first
iterate through available sub-components, do toVHDL() for each one of
them, and then generate the top module. Of course, I assume my design
as structural at the top, and next sub-components are converted in the
usual way. However, I think it's possible to extend it for complex
hierarchies.

Don't misunderstand me, IMHO flattening hierarchy is one of the most
powerful feature of MyHDL because I can do very sophisticated things
in elaboration. But, after my recent experience, I advocate for
"selective" hierarchy keeping; for instance, a top module with several
sub-components, in a one-level-deep hierarchy. This top module could
be marked with a function attribute (something like
"topmodule.keep_hierarchy=True") that instructs the converter to walk
through sub-components, call normal converter for each of them and
finally do component instantiation and port mappings. That's the
reason I thought on a separate function for this kind of conversion.

>

I'm sorry to "bring back" previous discussions (I hope I'm not
reviving past flames), but since I've been studying the conversion
code, I'm ready to put better arguments (and code) to solve this
pending issue. And, as I was saying, personally I really need this
feature for my projects.

>
> Regards,
> Chris
>
> On 7/17/2012 1:23 PM, Oscar Diaz wrote:
>> Hi
>>
>> I want to start a discussion about keeping the hierarchy on conversion
>> and how to implement. Although flattening feature of current converter
>> is a nice "killer feature", I can provide couple examples which it's
>> needed to keep hierarchy inside a design:
>>
>> 1. Special instances on an FPGA: suppose you need an special component
>> (my experience is limited to Xilinx, I guess Altera and other vendors
>> had similar features), for instance a block RAM. Sometimes I need to
>> explicitly use a block RAM in a particular configuration, I know
>> exactly how to instantiate it in VHDL, and I can write a MyHDL
>> equivalent model for simulation. However, when converting, it is
>> difficult to write code that synthesizer use to infer a block RAM. And
>> for other special components it can be worse (ICAP, PLL, DCM, and
>> others).
>>
>> 2. Partial re-configuration [1]: design tools can work only with
>> structural descriptions because it needs complete information about
>> boundary signals between sub-modules. A converted MyHDL design only
>> has a top module with all the sub-modules flattened in multiple
>> process (or always blocks in Verilog).
>>
>> It's worth mention that, for the previous examples, it's explicit
>> stated the need to keep hierarchy, and those components will be
>> instantiated in the nearest-top component (I mean, in VHDL it will be
>> some component declarations, instantiations and port mappings).
>>
>> Now the question is: how to implement it? I've been thinking and
>> working on it for a long time, and those are some of my thoughts
>> (disclaimer: since I'm more accustomed to VHDL to Verilog, I'll give
>> only examples with VHDL, Verilog should be somehow alike):
>>
>> * Current converter rely on flattening the structure before do actual
>> conversion. Perhaps a different function is convenient/needed here?
>> something like "toVHDL_keep_hierarchy()" can run through the
>> hierarchical structure and call toVHDL() for its internal components.
>> This is "relatively" easy to implement in the case of simple
>> hierarchies (for instance, a top module with sub-components), but
>> mixed "keep-hierarchy" components with "normal" components could be
>> tricky without deep changes to converter code (something probably not
>> desirable right now).
>>
>> * Internally, converter needs to generate a separate output file for
>> that component and also need component declarations to put in that
>> file. Perhaps a function that infer the external interface of a
>> component is needed, something that toVHDL() already do internally to
>> generate the entity declaration, and would be nice to move to another
>> function for this purpose.
>>
>> * user-defined code, if used, must declare almost the entire code
>> (interface declaration is inferred from the call signature). Other
>> option is point to an external file, and in this case, its interface
>> must match the call signature.
>>
>> Since I was in a hurry to have "keep hierarchy" feature in my
>> projects, I wrote a custom converter, but it's tightly coupled to my
>> specific designs (for instance, I use objects instead of functions to
>> declare components, and my converter looks through those specific
>> objects and its attributes. Also, there's a separate mechanism for
>> interface declaration). However, I want to decouple that code for
>> general use, and I want to hear your opinions.
>>
>> Best regards, Oscar
>>
>> PD: <spam warning> Part of the code I mentioned is part of a
>> open-source project I've been working in, and I think now I can
>> present it to the list. Its called NoCModel, and it's available on
>> github (https://github.com/dargor0/nocmodel), also I keep a copy on
>> opencores. </spam>
>>
>> [1] http://en.wikipedia.org/wiki/Partial_re-configuration
>>
>
>
>
>
> ------------------------------------------------------------------------------
> 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