ngd2edif vs. ngc2edif

[valentin tihomirov]

I have some questions regarding Xilinx design flow.

What NGD and NGC files are? Is edif file created by the 2edif tools
synthesizable?

According to
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/ngdbuild2.html,
NGDBuild converts netlist (Edif, Ngc, Xnf) into logical design (ngd - logic
elements like AND gates, decoders, FFs, RAMs). This is called translation.
But what is a role of synthezier, isn't it XST that should generate netlist
of logic gates from RTL description? ActiveHDL IDE allows for functional,
post-synthess and timing (post-implementation) simulations. Sinthesis is
done using Sinplify; it includes two stages: compilation and mapping. After
syntesis, Xilinx implementation tools are used to get timing information.
Implementation consists of translation, mapping (again?) and P&R. Why
mapping is done twice?

Why two different libraries (Unisim and SimPrim) are used for syntesis and
implementation? Wouldn't it be more effective to use only one? Can I write a
structural edif file based on elements of those libraries (which one?) and
synthetize it effectively creating design from scratch bypassing synthesis?

Thanks.

 

[Brian Philofsky]

valentin tihomirov wrote:

I have some questions regarding Xilinx design flow.

What NGD and NGC files are? Is edif file created by the 2edif tools
synthesizable?

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.

According to
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/ngdbuild2.html,
NGDBuild converts netlist (Edif, Ngc, Xnf) into logical design (ngd - logic
elements like AND gates, decoders, FFs, RAMs). This is called translation.
But what is a role of synthezier, isn't it XST that should generate netlist
of logic gates from RTL description?

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.

ActiveHDL IDE allows for functional,
post-synthess and timing (post-implementation) simulations. Sinthesis is
done using Sinplify; it includes two stages: compilation and mapping. After
syntesis, Xilinx implementation tools are used to get timing information.
Implementation consists of translation, mapping (again?) and P&R. Why
mapping is done twice?

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.

Why two different libraries (Unisim and SimPrim) are used for syntesis and
implementation? Wouldn't it be more effective to use only one? Can I write a
structural edif file based on elements of those libraries (which one?) and
synthetize it effectively creating design from scratch bypassing synthesis?

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

Thanks.

 

[Brian Philofsky]

valentin tihomirov wrote:

I have some questions regarding Xilinx design flow.

What NGD and NGC files are? Is edif file created by the 2edif tools
synthesizable?

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.

According to
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/ngdbuild2.html,
NGDBuild converts netlist (Edif, Ngc, Xnf) into logical design (ngd - logic
elements like AND gates, decoders, FFs, RAMs). This is called translation.
But what is a role of synthezier, isn't it XST that should generate netlist
of logic gates from RTL description?

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.

ActiveHDL IDE allows for functional,
post-synthess and timing (post-implementation) simulations. Sinthesis is
done using Sinplify; it includes two stages: compilation and mapping. After
syntesis, Xilinx implementation tools are used to get timing information.
Implementation consists of translation, mapping (again?) and P&R. Why
mapping is done twice?

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.

Why two different libraries (Unisim and SimPrim) are used for syntesis and
implementation? Wouldn't it be more effective to use only one? Can I write a
structural edif file based on elements of those libraries (which one?) and
synthetize it effectively creating design from scratch bypassing synthesis?

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

Thanks.

 

[Brian Philofsky]

valentin tihomirov wrote:

I have some questions regarding Xilinx design flow.

What NGD and NGC files are? Is edif file created by the 2edif tools
synthesizable?

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.

According to
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/ngdbuild2.html,
NGDBuild converts netlist (Edif, Ngc, Xnf) into logical design (ngd - logic
elements like AND gates, decoders, FFs, RAMs). This is called translation.
But what is a role of synthezier, isn't it XST that should generate netlist
of logic gates from RTL description?

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.

ActiveHDL IDE allows for functional,
post-synthess and timing (post-implementation) simulations. Sinthesis is
done using Sinplify; it includes two stages: compilation and mapping. After
syntesis, Xilinx implementation tools are used to get timing information.
Implementation consists of translation, mapping (again?) and P&R. Why
mapping is done twice?

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.

Why two different libraries (Unisim and SimPrim) are used for syntesis and
implementation? Wouldn't it be more effective to use only one? Can I write a
structural edif file based on elements of those libraries (which one?) and
synthetize it effectively creating design from scratch bypassing synthesis?

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

Thanks.