Re: [myhdl-list] Keeping hierarchy for conversion

[Christopher F. <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

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.

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
>