When i open PACE window (ISE 6.1)to create area constrainte (region), in the design broser window (top most left window in PACE) there are 3 folders : I/O pins, Global Logic and Logic, this last one should containe the logic of my design(by blocks) but its empty, Why? how to fixe this? is it because the tool dont keep the heararchy of the design??? Note: this happen when i use VHDL entrance to ISE tool,but does not if i use Synplify to synthesis my design and then i entre EDIF file to ISE(her i can see and plce my blocks).
This is very important for me since i need to place manualy some blocks of my design to get a better speed.
I'm not an expert on this (I've barely begun to use the tool), but wouldn't you normally do this in the Floorplanner? The Floorplanner comes up blank for me, but then I open .ncd, and the design layout is displayed. I think this is where the manual placement is supposed to occur.
If you have choosen Property Keep Hierarchy "NO", then you can place only hole design. When you select Keep Hierarchy "Yes" then you can place allso sub modules and so on.
Yes, the option keep_hierarchy = 'yes' did realy help to solve this, but the area occupation increases because of this and i have no idea how to overcome this, or at least reduce it...??? I will conceder the incremental design to see what it gonna give.
In general, with a well thought out design hierarchy, KEEP_HIERARCHY=TRUE generally does not have much effect on area. There are three reasons that come to mind as to why you could see an increased area due to KEEP_HIERARCHY. The first happens only when you do not register the boundaries of your hierarchy (particularly the outputs). If you have a data path that transverses several levels of hierarchy from start to finish, it is possible when you use KEEP_HIERARCHY that that path would not be as optimized as it could be and in order to retain the proper footprint and logic within the hierarchy that it would need more logic levels (LUTs) to build that data. Again, if you register the outputs of each module hierarchy, this can not happen. The next place that you may see in increase in logic used has to do with resource sharing. Synthesis tools can identify arithmetic operators (and other logic) and restructure it to use less logic. For instance:
if (SELECT) C = A+B; else C = C+D;
The following logic can use one adder with two MUXes on the inputs or use two adders with one MUX on the output. Both implementations yield the same result but would have different logic utilization. If however it was coded so that one adder is in one hierarchy and one is in another, that opportunity to combine the two adders could not happen. Again, with registered outputs at the hierarchy boundaries, this becomes a less likely scenario but can happen if you do not. Finally, synthesis tools do some optimizations like removal of duplicate registers that can be obstructed with the use of KEEP_HIERARCHY. In general this should not account to a large increase in design size and is somewhat rare but can certainly happen.
The other thing that can happen with hierarchy retention is a performance degradation. This too generally only has a significant effect on designs with poorly chosen hierarchy boundaries. The biggest cause of performance degradation with this methodology is the same as I mentioned above where added logic levels (LUTs) are needed to form a function in which the data path spans several hierarchy layers. This not only adds to the resources necessary but also adds to the time it takes to get from one point to another. Another time performance can be hindered by KEEP_HIERARCHY is with register duplication. If an input or output signal at a hierarchy boundary has several sources or loads (a high fan-in/fan-out) it can limit the synthesis and back-end tools ability to do register or logic duplication to ease timing. Since you are trying to keep the original boundaries to the interface, the tools can not add ports to the interface in order to do this duplication.
Keeping hierarchy for a design has many benefits for improved constraint entry, floorplanning and verification and sometimes can improve performance and reduce runtimes but you must be careful in how the original design hierarchy is laid out in order to not get the opposite effects. So what should you do. As mentioned before, register the hierarchy boundaries where possible (especially the outputs). This is a good design practice to follow in general. Understand where resource sharing opportunities exist in your design and change the hierarchy to take advantage of this to save resources and can also improve timing. Also, be alert to where you feel critical timing paths may exist in the design (i.e. paths with lots of logic level, high fan-outs, etc.) Try to either keep those contained within a level of hierarchy, do manual duplication or other design practices to ensure this methodology will not hurt you more than it will help you. And finally, be selective in where you keep your hierarchy. rarely is it advantageous to keep everything in the design. On retain the hierarchy that will help you with constraint entry, floorplanning and/or verification and let it flatten elsewhere. In general, the most benefits are seen when you do not take a global approach of keeping or flattening a design and instead are selective in what hierarchy should stay and what should go.
A fairly good document on this topic is the Synthesis and Verification Design Guide
formatting link
In Chapter 6 there is a section called Design hierarchy and Simulation that explains most of the concepts I mention above. Also there is a section in the "General HDL Coding Styles" chapter on resource sharing if you are interested.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.