[myhdl-list] Keeping hierarchy for conversion
Brought to you by:
jandecaluwe
From: Oscar D. <osc...@gm...> - 2012-07-17 18:23:12
|
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 -- 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 |