valentin tihomirov wrote:
The NGD file is the output of NGDBUILD and is written in a database format in terms of SIMPRIMs similar to NCD (the output of Map and Par). NGC is the output of XST and is a slightly different database format in terms of UNISIMs. Below, I will go into more explanation of SIMPRIMs and UNISIMs for your other question. In terms of NGD2EDIF, that tool's purpose was to create a simulation EDIF file for the Mentor QuickSim products. Since we no longer support QuickSim, ngd2edif is no longer shipped starting with the 6.1i release. As for ngc2edif, that tools main purpose is to supply edif versions of the NGC file as input to third-party synthesis tools in order to understand the contents of the NGC files for timing and area optimization and reporting. The output EDIF from either tool is not intended to be synthesizable or be using as an input for all or part of a design for ngdbuild.
The general purpose of a synthesis tool to to take an HDL description of a design in RTL (Register Transfer Level) and/or structural primitive components and create an output netlist in which specifies the base components and connectivity in terms of UNISIM components. Ngdbuild then takes that netlist, performs DRCs (Design Rule Checks) on the input netlist and translates the design from the logical domain (UNISIM) to the physical domain (SIMPRIM). Again I will talk more about UNISIM and SIMPRIM below to answer your other question.
Mapping might be an over used term here. In the sense of how the syntheisis tool is mapping, it takes the logic functions described by the engineer and "maps" it into a LUT (Look-Up Table) as well as other functions described in the code to their proper primitives. The Map function in ISE takes those primitives and maps them into larger blocks like IOBs and Slices. This is also knows as packing and I generally like to use the term packing when referring to Map's function since it is less likely to be confused with the mapping that the synthesis tool performs.
This is a good question I get from time to time and there are actually several answers to this question and I will only touch a few of them. First off the decision to use two separate libraries for the front-end design (UNISIM) and back-end design (SIMPRIM) was made several years ago as we transitioned from the XACT tools to the ISE tools that you use today. Back in the XACT days we ran into some issues with having the same library in the front-end and back-end design and decided to use separate libraries for each would some many of those issues and thus the SIMPRIM library was born. Some of the issues we though this could address included the fact that each library was used in different stages of the design and each simulation actually serves different purposes. In the early stages of the design, you want a fast behavioral representation of the component that is easy to use (instantiate and understand), runs fast and integrates well in an RTL design. During timing simulation, you want a model that works well in a pure-gate model (no RTL), very accurately reflects exactly how it is implemented in silicon and have very accurate timing information however since the tools generate the netlist, you would never need to instantiate them and for this case, absolute accuracy is more important than fast runtime (although both are always nice). By having separate libraries we are able to remove all timing information from the UNISIM library, create convenience macros like the BUFGDLL and the FDCE, able to add attribute checking to give initial DRCs to the design, and able to optimize and accelerate the library in way not possible if used for back-end simulation (as well as other things). As for the SIMPRIM library, without having to worry about people using it in front-end simulation which is where most people spend most of their time simulating, we are able to remove attribute checking (this is done as a part of the DRC in Build and Map), put full timing checks in the models, use models that more accurately reflect the actual silicon and add models that are used only for timing simulation like the X_BUF_PP in VHDL which does glitch checking that is not necessary or useful for front-end design.
There were actually many more reasons than this why we went to a two library system but I think what is said above illustrates the main points and benefits for this. I know this is somewhat unique and does take some getting used to but hopefully most will see benefits in every stage of simulation due to this forward thinking.
Hope this explains things for you. It is not always clear why decisions like these are made but when you know the background behind the decisions, it generally becomes much more clear why things are the way they are.
Good luck with your design,
-- Brian