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.
Clock the data register on the falling edge of ack to use the propagation times of req, data and ack to de-skew the data. The sender signals req and gates data at the same time and gates the data until the receiver drops ack, the receiver clocks data in at the fall of req so the data deskew and setup timeare the sum of req rising plus ack rising plus ack falling propagation times. The sender can change data at the fall of ack so the hold time is the sum of ack plus data propagation delays.
Did I miss something? Sorry, the waveforms got skewed when I posted this reply req fall should coincide with regclk
@Karl: thank you for the analysis. You have captured the most of the design working mechanism.
If you are interested in this topic, you can find a full entry point to more complex asynchronous designs in the AsyncArt project wiki. If you are a Xilinx ISE 14 user, you can even download a full working project with different demos inside (the "micropipelines" downloadable archive).
1) The tFFs toggle on the rising edge of the clock that is generated from the handshaking.
2) The width of the clock is mainly determined by the propagation delay between the blocks, including the switching delay of the circuits.
2) There is a race between data out and req out so data must be valid by the time that clock rises at LF (whatever that is).
Here is the input to my little simulator,
req0:1@1 // req0 becomes 1 at time = 1
2 phase clocking so req0 turns tFF0 clock active when tFF0 is off and tFF0 // toggles and drives the req input of the second block. tFF1 toggles on and becomes ack to the first block, The first block now knows the second block has received the data and when req0#2 (delayed by 2 units) falls that means ack from the first block was received, so tFF0 toggles to 0 and is ready to accept a new req) The req and ack on the right side of the second block may need to be tied together with some delay.
jandecaluwe 1/31/2013 12:03:53 PM User Rank Blogger
Re: Timely
@devel "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)."
That is not my experience at all. Any company I know that does serious VHDL design work uses libraries to organize it. Beyond a certain complexity, it seems that noone wants to use 'work' anymore.
Edit With "serious design work" I don't mean technical complexity or relevance, but merely management complexity. If the project requires a large design team, you have to organize it differently than with a small one.
"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."
I don't see what source code control has to do with VHDL libraries. VHDL libraries are just a way to organize your code into namespaces.
"So, basically, yeah, VHDL libraries exist. Don't bother with them."
I agree that there are a few problems with VHDL libraries. Like many sound VHDL concepts, they are harder to use than desirable (because of the double mapping between logical name and directories, unlike Java and Python namespaces for example). (If I may, Sigasi's interface has solved this brilliantly :-)) Also, they are somewhat limited, as they are not hierarchical.
Also, there used to be problems due to limited tool support. However, I assume that all VHDL tools fully support VHDL libraries at this point, so I don't see any reason not to use them to organize designs cleanly.
jandecaluwe 1/31/2013 11:46:14 AM User Rank Blogger
Re: About VHDL libraries
@devel "The main reason the language provides the library feature is pretty much the same reason C and other programming languages offer them. A library allows the engineer to share code in a compiled form without the source necessarily being available."
Strictly speaking, you don't need resource libraries for that purpose. All you need is the source of the package with the interfaces, and code compiled into 'work'.
Resource (non-'work') libraries are useful to do this cleanly. That is because they are VHDL's implementation of namespaces. In practice, you want to cleanly separate 3rd party code from your own work.
This also shows that the usefulness of resource libraries is certainly not limited to the use case you describe. They can be used to organize design work in general.
The reference to C is a little misleading, as C does not have namespaces.
actually, you don't need component declarations for compiled entities at all. just use an entity instantiation instead. just need the library declaration of where you compiled said entity into. this keeps package declarations/bodies for types, functions, constants, etc only.
my_dut : entity my_work.foobar
black boxes are the only thing I use component declarations for.
i've used this with no issues in modelsim, isim, XST, Synplify and quartus.
Awhile ago, I decided to see if I could come up with a practical use for VHDL libraries in the cases where I had access to the source code.
As noted, one could take an entity's source and analyze it into a library other than work. For this to be of use, then, one has to write a package (whose definition could be in the same source file as the entity but doesn't have to be, and shouldn't be if you're going to actually use libraries in this manner) which defines a component matching that entity. So both the entity and the package have to be analyzed into this new library (call it mylib).
Now in your instantiating source (call it mysource) you have to add library mylib; use mylib.thisstuff.all; for the component definition in the package to be visible to mysource.
Then you have to convince your synthesis and simulation tools to let you use a precompiled library. Remember you don't need the component source, you just need the package declaration. This is sorta easy with ModelSim and with Active-HDL. Dunno about ISIM. This might be a lot less easy with a synthesis tool. So you'll have to figure out how to get XST to create the netlist for the package separate from the main FPGA project.
So that's all a right royal pain, and if you have the source for your components, is likely a silly waste of time.
But here is where libraries, or at least packages (which are not the same, but people think of them as such), can be of use. Say you have a function log2() which determines the number of bits required to represent a given integer as some vector. Certainly you could define this function and put it in your entity's architecture's declarative section (between "architecture this of that" and the first "begin," the same place where you declare signals). This gives the function architecture scope, so if another entity needs this same function, you have to copy-and-paste it. So you have multiple copies of something. That's excessive and prone to problems.
Instead, put the function definition in a package body. Put this package body into its own source file, with a package header. Add this source file to your source-code-control repository as its own project. Add it to your FPGA project source tree in the manner by which your SCC does this (use Subversion's externals feature, for example). Also add the source file to your simulation or synthesis project. Remember that this source file needs to be analyzed before any entity which uses it. Analyze it into the work directory, which is the default.
Now in any entity source file that needs the log2() function, simply add "use work.myfunctions.all" (assuming that log2() is defined in a package called myfunctions) and then the function is visible to that entity and it all works.
User libraries I view libraries in VHDL as virtual containers in which entities and packages can be compiled for organization, clarity, and reuse. Many EDA tools map these virtual libraries into physical directories, since this is where intermediate compiled results are stored. Both Modelsim and ISim handle libraries this way. Many engineers refer to a package of component declarations as a library, but I don't. Some combine this package/library terminology with actual library use. I don't use component declarations except for black boxes, so I never use packages of component declarations.
I am an advocate of using user VHDL libraries when they are necessary and make sense. However, I believe most small designs do not need elaborate library layouts. The default work library is often sufficient. I like to keep the VHDL clean and generic and handle library creation and mapping with the EDA tool. Specific user library declarations are needed only at the level that instantiates a (top-level) entity of the library entities you are using. Here is a contrived example of a top-level module instantiating entities from two different VHDL libraries.
I have also used black box vendor libraries in the manner described by Devel.
Duane Benson 1/28/2013 3:38:38 PM User Rank Blogger
Re: Timely
Devel - Thanks for your input. I suspected as much. I know virtually nothing about VHDL, and there's still a significant amount of Verilog that I don't know. Looking at Libraries in VHDL as being similar in concept to a C header file makes a lot of sense. I just have to keep my brain out of software comparisons down in the code.
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.
Tweet This
