For many engineers, the first lines they write in a new VHDL file are "LIBRARY ieee;" swiftly followed by the USE clauses. But what exactly is a VHDL library?
In its simplest form, a library is a directory on a server or computer that contains VHDL packages, entities, and architectures, thereby allowing these items to be used across multiple projects. These directories and library names are then mapped into the EDA tools allowing the "LIBRARY <name>" to be determined -- without this mapping, the tools would not be able to find the library and hence the files. (Click here to see a larger version of this image):
A ModelSim screen showing the various library mappings required for a project.
Commonly-used libraries -- such as "IEEE" and "STD" -- are provided with the tool itself, and no mapping is thus required. This may also be true of other libraries, depending upon an EDA tool's functionality (for example, the powerful ModelSim software simulator libraries, which require no additional mapping in ModelSim). These may be supplied pre-compiled in the case of a simulation tool, or as VHDL source code in the case of an FPGA implementation tool like the Synplify synthesis tool from Synopsys or the ISE (Integrated Software Environment) from Xilinx.
If you are designing using Xilinx FPGAs, then libraries that commonly require mapping into simulation tools are the Xilinx "unisim," "unimacro," "xilinxcorelib," and "simprim" libraries as illustrated in the images below. (Click here and here to see larger, more detailed versions of these images.) These libraries are used to simulate Xilinx functional primitives, or implementation timing simulations in the case of the "simprim" library. To successfully use these libraries in a simulation tool, they must not only be mapped in the simulation tool, but also compiled in ISE for your selected simulation tool.
Modelsim screen showing the library mapping context box.
Xilinx ISE library compilation.
Another thing you will come across is the "WORK" library, which is the currently designated working library. It is into this library that compiled results are placed. How the working library is designated varies from tool to tool. In the case of ModelSim, for example, the WORK library may be declared during the setting up of a project; alternately, it can be specified using the "vmap" command ("vmap work <library path>" for example). For this reason, it is a bad idea to create a library called "work," as this can lead to confusion and all sorts of issues later on.
Both the "STD" and "WORK" libraries within VHDL are implicitly declared; hence, you do not need to declare them within a VHDL file.
As an engineer, you will generally wish to partition your design into a number of libraries. For example, if you are designing numerous FPGAs for a project and these devices share common components, then you may decide to declare a common components library and also have a separate library for each of the devices. This allows the commonly used components to be located in a central place should updates to those components be required.
If you wish to use a package within a defined library, you must declare this using the "USE" clause. This allows you to pick and choose the packages within a library you wish to use. Within the "IEEE" library, for example, you will wish to use the "std_logic_1164" and "numeric_std" packages, but you may not wish to use the "math_real" or "math complex" packages. For example, consider the statement "USE std_logic_1164.ALL." In this case, the "ALL" keyword at the end allows visibility of all names within the package. It is possible to limit visibility be declaring specific names in place of the "ALL" keyword. When combined, the "LIBRARY" and "USE" clauses are referred to as "the context clause."
Once you have your library structure all set up, you should hopefully find it easier to reuse your code, if required. However, depending on how complex your structures are, you may need to consider using configurations to correctly manage your current design to ensure you are pulling in the correct entities and architectures. I will address these in a future "Ask Adam" column, as I think we have covered enough here for one blog.
For the vast majority of designs, VHDL's libraries feature isn't necessary for anything other than using the standard libraries (std_logic_1164, numeric_std).
Any organization that practices code reuse will find it easier to keep the code modules in a source-code-control system and pull in the source for each module as needed. There's no real point to compiling the source down to a netlist and sharing only the netlist. You don't save any time (synthesis is generally not a time sink) and now you have to deal with keeping track of binaries and you still have to maintain the library interface. That's too much work for basically no benefit.
So, basically, yeah, VHDL libraries exist. Don't bother with them.
duane: First, I've read that libraries can be used in both Verilog and VHDL. The Verilog that I've gotten to so far doesn't need any libraries and has everything I've needed built into the language. The clock buffer that I've instantiated seems like it would be pulled from a library, but nothing is needed along the lines of a library declaration or include. Does Verilog just search and find the libraries as long as they are in a search path?
I think it's worth emphasizing that a VHDL library is a specific feature of the language. That is the point I was trying to make in my first post in this thread. Again, the concept of a VHDL library is exactly the same as it is for a C program which links to some precompiled library. In VHDL you "use" a library and package and include the library in the project in a tool-specific manner (makefile, whatever). In C, you #include a header and link in a library in a tool-specific manner (makefile, whatever). As part of all of this, the analyzer (compiler) can check to see if the component instantiation matches the component definition.
Verilog doesn't have any concept of a library as such. You don't "include" anything. You basically instantiate a lower-level entity. Then in a tool-specific manner, the back end "linker" is told about precompiled modules which include the stuff you want. But there is no checking at compile time whether the module instantiation matches anything that exists (this is the point of the component declaration in the package).
So in Verilog your clock buffer gets instantiated but there's nothing to tell the compiler that the instantiation is correct. You find out when the design is fleshed out by the linker. The other question I have relates to using the libraries. In Verilog, if I write HDL for circuitry that doesn't do anything, Verilog ignores it and doesn't configure that part of the HDL code. Does VHDL do the same thing, or does it configure every function that is in the package being used?
When you use a library/package in VHDL, you're telling the analyzer: "here are some definitions." Obviously you don't use everything in, say, the numeric_std library with each design, so the tools do what you expect: anything that's not used in the design doesn't exist.
Now let's be clear: if you say "write HDL for circuitry that doesn't do anything," that's a separate issue from libraries. It's common to have an entity which has some output ports you don't use (FIFO flags, for example). When you instantiate the FIFO, regardless of whether it's in a library or not, if you don't use the almost-empty flag, then it will be optimized away along with all of the logic which drives it. This happens in VHDL and in Verilog.
The following code sample shows how to use Relative Location constraints with a VHDL generate statement. The code is a simple example showing how to auto-generate the Relative Location constraints for several instantiated FDE components. This methodology can be used with virtually any primitive. Note The user must create the itoa function.
Duane Benson 1/28/2013 12:41:04 PM User Rank Blogger
Timely
Adam - This blog is very timely as I'm stepping back and looking at VHDL now. I've got a couple of questions that perhaps you (or anyone else here) could clarify for me.
First, I've read that libraries can be used in both Verilog and VHDL. The Verilog that I've gotten to so far doesn't need any libraries and has everything I've needed built into the language. The clock buffer that I've instantiated seems like it would be pulled from a library, but nothing is needed along the lines of a library declaration or include. Does Verilog just search and find the libraries as long as they are in a search path?
The other question I have relates to using the libraries. In Verilog, if I write HDL for circuitry that doesn't do anything, Verilog ignores it and doesn't configure that part of the HDL code. Does VHDL do the same thing, or does it configure every function that is in the package being used?
I'm looking for advice in creating hard-placed libraries in Xilinx devices. I mean, how would you implement in VHDL a library of blocks in which at least mapping is totally controlled?.
VHDL is the logic description, and has nothing to do with how the back-end place and route tools do their jobs. This is no different from schematic entry.
Having said that, certainly the VHDL can include pragmas and attributes which the synthesis tool can pass on to the back-end stuff.
Go back and read what I wrote in the first comment on Adam's post. A VHDL library is a convenience that allows you to not provide VHDL sources (for hard-core black boxes, for IP whose source you don't want to release, etc) to the analyzer and elaborator at build time.
What you probably want to do is to use the synthesis tool to create netlists (NGC) which include placement constraints. Your source HDL will probably have a lot of instantiated primitives which makes setting placement constraints easier at the cost of making the code unreadable. Then you need a wrapper for your black box which is a component instantiated in your code. How to do this? I have no idea. I've never needed to create a black box.
And don't forget that mapping is specific to one device (family and package), so going from, say, Spartan 3AN 200 to 700 might break your placement constraints.
(I'll avoid saying that async design in FPGAs is a fool's errand. Ooops.)
@Garcia -- with the right timing constraints and if-def statments and a C preprocessor program(GNU or similar) one could have vendor call outs for each vendor one wanted to use based on a #define statement. This would allow the library to run on both brand A and brand X as well as possibly others - If you can get it to work with timing constraints, it might open up some new speed/price points for FPGA's that are presently unmet by the more expensive Achronix parts by using conventional FPGA's for greater speed.
@William: Thank you very much for the info, I'm going to take a deeper look to the user guide. Time constraining may suppose a workaround to the task I'm performing.
Previously, in order to describe the hardware mapping and relative P&R of the library, I used RLOC constraints & RPMs... but when migrating the code, I noticed that these have become unsupported!!
Does somebody knows if RLOC directives & RPMs are still available in ISE14 (or Vivado)??
If so... where can I get more detailed information?
Here we discover how to use the XADC (Xilinx Analog-to-Digital Convertor) in the Zynq All Programmable SoC to read the chip's internal temperature and voltage parameters and output them over an RS-232 link.
The Zynq All Programmable SoC comes equipped with programmable analog capabilities that can be used in a wide variety of applications, including defense, industrial, and automotive systems.
In the case of a real-world use model, we want to store our software program and configuration bitstream in nonvolatile memory and configure the device after the power comes on.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.