I am working in a VHDL code with a lot of SIGNALs that I should be able to see in the simulation on ModelSim to debug my design.
My question is whether is it necessary to declare outputs on my top-level entity so I can wire them an have access to those internal SIGNALs or is there any other way to access them from ModelSim?
If you can evaluate your design model interactively
Can you use a waveform dump display to debug your design? You can typically view any node in your design hierarchy.
If you need algorithmic or programmatic access for verification
Is your Modelsim -2008 compliant? For validation purposes in a testbench or block that is not synthesized you can use external names.
See IEEE Std 1076-2008, 8.2 External names. You can access signals, variables and constants by providing a pathname. External names are also described in Peter Ashenden's and Jim Lewis's book VHDL 2008 Just the New Stuff, Chapter 2.
In Modelsim
There's the show command which can access signals, processes, constants, variables, and entities. See the Modelsim Reference Manual, Commands, show. Commands can be entered from the command line or in macro files.
Related
I am using an Artix 7 FPGA and writing my code in Xilinx ISE.
I already have the Verilog code for the project I am working on. Unfortunately, I am not able to understand this module- The full code is posted here.
My goal is to find out where these 6 states are defined in the FSM: Reset (000), Wait for password (010), Compare (100), Log in successful (110), Login failed (111), and Do operation (101) and change the encoding to 4 bits.
I don't understand how the FSM in the image is there in the code.
Is anyone generous enough to help, please? Can I get a description of what is being done here?
The posted code is not Verilog RTL (Register Transfer Level) source code. Rather, its a post synthesis Verilog netlist. It contains the vendors primitives, look up tables (LUTS, buffers, etc). There is no way to understand the correlation between the bubble diagram and a post synthesis netlist in code linked to, its machine generated by the FPGA build tool (ISE in this case).
To correlate the bubble diagram and code, locate the corresponding Verilog source code that was used to create the netlist.
You might be able to locate the source code like this:
If you are on Linux, cd to near where the code is located and run
find . -iname '*.*v' | xargs grep 'Compare'
Here is an example of what a Verilog RTL state machine would look like:
https://www.asic-world.com/tidbits/verilog_fsm.html
The state variables and related logic are represented as parameter names (Verilog) or enumerations (in SystemVerilog). The state names are searchable using a text editor.
With VHDL '93 introducing direct instantiation, when would you actually use a component now when your entity is in VHDL? The following are the only time when a component is required I can think of:
Component maps to non VHDL source (Verilog, netlist etc)
You don't have the source yet and need something to compile against (eg. colleague hasn't finished their code yet)
You are binding different entity/architecture pairs to specific components in specific entities via configs. (but who ever actually does this? maybe if you have a simulation arch and synth arch - but again - never seen it used in any meaningful way)
I am discounting people who say that "A component lets me see the port map in the same file" or "having a component library allows me to see everything". This is mostly an old-school approach that people have got into the habit of. In my eyes, maintaining the same code in two places makes no sense.
Are there any others I've missed?
Sorry for the late response to Can't compile VHDL package - Modelsim error: (vcom-1576) expecting END
In addition to the use case listed by the OP and in compliance with his criteria of not so useful cases, I'll add two more cases:
To write platform independent code, one needs to implement e.g. an Altera and a Xilinx specific solution. This code will reference vendor specific libraries like alter_mf or unisim. Both vendor specific implementations can be selected by a if ... generate-statement, or since VHDL-2008 by a case ... generate-statement.
But even with generate-statements, this solution needs to instantiate components, because instances of a direct entity instantiation are bound regardless of the fact that some instances will never appear in the elaborated model. (I consider this a bug in the language - but there was no time to investigate and fix it for VHDL-2018.) Because an entity is immediately bound, the tool tries to load the referenced vendor library and it's packages.
Let's assume you compile on Altera with Quartus, it will complain about an unknown unisim library and a unknown vcomponents package. The same happens on Xilinx with Vivado complaining about an unknown altera_mf library.
Thus, to cut-off the (direct) instantiation tree, a component instantiation is needed.
This technique is used by the PoC-Library. See for example the PoC.misc.sync.Bits implementation for a standard double-FF synchronizer with different attributes applied to an Altera, Xilinx or generic implementation.
In the Open Source VHDL Verification Methodology (OSVVM), components are used for two use cases:
In a toplevel DUT, IP cores are instantiated as components so they can be replaced by dummy implementations. Either as unbound components or as components loading a dummy architecture. This can speed up simulations, reduce possible error sources in testing, replace complex slow implementations like MGTs or memory controllers with simpler and faster implementations, ...
In OSVVM, the test control is implemented in a separate entity called TestController. This entity has several architectures to implement the different test cases applied to the same test hardness. The architectures are bound with a toplevel configuration per test case / architecture. Thus, running a "testbench" means elaborating and simulating one of these configurations.
This is a question inspired by this question and answer pair: call questa sim commands from SystemVerilog test bench
The questions asks how Verilog code could control the executing simulator (QuestaSim). I saw similar questions and approaches for VHDL, too.
So my question is:
Why should a simulation (slave) have power of its simulator (master)?
What are typical use cases?
Further reading:
call questa sim commands from SystemVerilog test bench
VerTcl - A Tcl interpreter implemented in VHDL
Why? Can anyone answer "why"? Well, perhaps the product engineer, or developer at Mentor that drove the creation of such behavior can answer that. But lacking that, we can only guess. And that's what I'm doing here.
I can think of a few possible use cases, but they aren't something that cannot be done in another manner. For example, one could have a generic "testbench controller" that depending on generics/parameters could invoke certain simulator behavior. (Edit: After re-reading one of your links, I see that's the exact use case.)
For example, say I have this "generic" testbench code as:
module testbench;
parameter LOG_SIGNALS = 1'b0;
initial
begin
if LOG_SIGNALS
begin
// Log all signals in the design
mti_fli::mti_Cmd("add wave -r /*")
end
endmodule
Then, one could invoke this as:
vsim -c -gLOG_SIGNALS=1 work.testbench
The biggest use case for this might be if vsim is invoked from some environment. If one were to do a do file, I'm not sure one can pass parameters to the script. Say one had the following do file:
if {$log_signals} {
add wave -r /*
}
How does one set $log_signals from the command line? I suppose one could do that through environment variables, such as:
if { [info exists ::env(LOG_SIGNALS)] } {
add wave -r /*
}
Other uses cases might be to turn on/off the capturing of coverage data, list files, maybe even a quirky case of ending simulation.
But of course, all of these can be handled in other manners. And in manners I think are much more clear and much easier to maintain.
As for VerTCL, I find it fascinating. But incomplete. Or at very least barebones. I find scripted testenches exceedingly useful (we use them where I work). And VerTCL is a great way to do it (if you like TCL). But it does need some framework around it to read signals, drive signals, and otherwise manage a simulation.
Ideally, you wouldn't need a simulator API if the HDL was comprehensive enough to do all the functions that are currently left to the simulator. At its inception, Verilog was implemented as an interpreted language and the command line was the Verilog language instead of some other command line interface we see today based on Tcl.
But as simulators became more complex, they needed commands that interacted with the file system, platform, OS, as well as other features at faster pace than the HDL standard could keep up with. The IEEE HDL standards stop at any implementation specific details.
So simulation tool vendors developed command line interfaces (CLI) to meet user needs for debugging and analysis. These CLIs are robust enough to create stimulus and check behaviors that there can be an overlap in functionality of the CLI code versus what's in your testbench source code. So having an API to your simulators CLI can make it easier to control the flow of commands to the simulator and avoid duplication of procedures.
For example, maybe you want to start logging signals to add to a waveform after the design gets out of reset. From the CLI, you would have to set a watch condition on the reset signal that executes the logging command when reset goes inactive. Using the simulator API, you could just put that command in your bench in the spot in your where release reset.
I've recently just started learning VHDL again after not having touched it for years. The hope is to use it to develop a control system with various sensor interfaces, etc. I'm fairly competent in embedded C, which has been my go-to language for any embedded projects I've had up until this point, which makes learning VHDL all the more frustrating.
Basically, my issue right now, which I see as my biggest barrier in being able to progress with my intended project, is that I don't know how to develop and incorporate a module that I can just pass variables to and call (like a function in C) to carry out some task, i.e. display an integer 0-9999 on a 4 digit 7-segment display.
I know there are components in VHDL, but that seems like such a long winded way of performing one task. Is there a better way of doing this?
It seems to me like after you've done all the digital tutorials, there's a huge gap in the info on how to actually develop a full system in VHDL.
EDIT : further explanation re: third comment at the bottom. Apologies for the length of this!
VHDL has functions and procedures too, just like C. (OK, C calls its procedures "void functions"!) And, just like C, you can call them from sequential code using the same kinds of sequential code constructs (variables, loops, if statements, case-statements which have some similarities to C's switch), and so on.
So far, all this is synthesisable; some other VHDL features are for simulation only (to let you test the synthesisable code). So in simulation you can - like C - open, read and write files, and use pointers (access types) to handle memory. I hope you can see why these parts of VHDL aren't synthesisable!)
But what is different in VHDL is that you need a few extra lines to wrap this sequential code in a process. In C, that happens for you; a typical C program is just a single process (you have to resort to libraries or OS functionality like fork or pthreads if you want multiple processes)
But VHDL can do so much more. You can very easily create multiple processes, interconnect them with signals, wrap them as re-usable components, use "for ... generate" to create multiple processes, and so on. Again, all synthesisable : this imposes some restrictions, for example the size of the hardware (number of processes) cannot be changed while the system is running!
KEY: Understand the rules for signal assignment as opposed to variable assignment. Variables work very much as in C; signals do not! What they do instead is provide safe, synchronised, inter-process communication with no fuss. To see how, you need to understand "postponed assignment", delta cycles, wait statements, and how a process suspends itself and wakes up again.
You seem to be asking two questions here:
(1) - can I use functions as in C? Very much so; you can do better than C by wrapping useful types and related functions, procedures in a package and re-using the package in multiple designs. It's a little like a C++ reusable class with some stronger points, and some weaker.
(2) can I avoid entities, architectures and components altogether in VHDL? You can avoid components (search for "VHDL direct entity instantiation") but at some point you will need entities and architectures.
The least you can get away with is to write a single process that does your job, receiving inputs (clk, count) on signals and transmitting to the LEDs on other signals.
Create an entity with all those signals as ports, and an architecture containing your process, connecting its signals up to the ports. This is easy - it's just boilerplate stuff. On an FPGA, you also need to define the mapping between these ports and the actual pins your LEDs are wired to. Synthesise it and you're done, right? .. not quite.
Create another "testbench" entity with no external ports. This will contain your entity (directly instantiated), a bunch of signals connecting to its ports, and a new process which drives your entity's input ports and watches its output ports. (Best practice is to make the testbench self-checking, and assert when something bad comes out!) Usually "clk" comes from its own one-liner process, and clocks both testbench and entity.
Now you can simulate the testbench and watch your design working (or not!) at any level of detail you want. When it works - synthesise.
EDIT for more information: re: components, procedures, functions.
Entities/components are the main tool (you can ignore components if you wish, I'll deal with entities later).
Procedures and functions usually work together in a single process. If they are refactored into a package they can be re-used in other like-minded processes (e.g. operating on the same datatypes). A common abstraction is a datatype, plus all the functions and procedures operating on it, wrapped in a package - this somewhat resembles a C++ class. Functions also have uses in any declaration area, as initialisers (aka "factory" pattern in software terms)
But the main tool is the entity.
This is a level that is probably unfamiliar to an embedded C programmer, as C basically stops at the level of the process.
If you have written a physical block like an SPI master, as a process, you will wrap that process up in an entity. This will communicate with the rest of the world via ports (which, inside the entity, behave like signals). It can be parameterised via generics (e.g. for memory size, if it is a memory). The entity can wrap several processes, other entities, and other logic that didn't fit neatly into the process (e.g. unclocked logic, where the process was clocked)
To create a system, you will interconnect entities, in "structural HDL code" (useful search term!) - perhaps a whole hierarchy of them - in a top level entity. Which you will typically synthesise into an FPGA.
To test the system via simulation, you will embed that top level entity (=FPGA) in another entity - the testbench - which has no external ports. Instead, the FPGA's ports connect to signals inside the testbench. These signals connect to ... some of them connect to other entities - perhaps models of memories or SPI slave peripherals, so you can simulate SPI transactions ... some of them are driven by a process in the testbench, which feeds your FPGA stimuli and checks its responses, detecting and reporting errors.
Best practice involves a testbench for each entity you create - unit testing, in other words. An SPI master might connect to somebody else's SPI slave and a test process, to start SPI transactions and check for the correct responses. This way, you localise and correct problems at the entity level, instead of attempting to diagnose them from the top level testbench.
A basic example is shown here :
Note that he shows port mapping by both positional association and (later) named association - you can also use both forms for function arguments, as in Ada, but not C which only allows positional association.
What "vhdlguru" doesn't say is that named association is MUCH to be preferred, as positional association is a rich source of confusion and bugs.
Is this starting to help?
Basically there are two possibilities of handing information to an entity:
At runtime
Entities communicate with each other using signals that are defined inside a port statement. For better readability I suggest using std_logic_vector, numeric_std or even better record types where appropriate. See link below.
At synthesis time
If you want to set a parameter of an entity to a fixed value at synthesis time (for instance the size of a fifo) you might want to use a generic statement. See also link below.
I can also recommend reading this paper. It helped me a lot when coping with system that exceed a certain complexity:
A structured VHDL design method
Some simple generalizations for entity/component vs subprogram (function / procedure).
Use an entity when a reusable block of code contains a flip-flop (register).
Use a function do to a calculation. For RTL code, I use functions for small, reusable pieces of combinational logic.
I primarily use procedures for testbenches. I use procedures to apply a single transaction (waveform or interface action) to the design I am testing. For testbenches, I further use procedures to encapsulate frequently used sequences of transactions.
I am a newbie to VHDL and can't figure out how to debug VHDL code.
Is there any software that could probably give me an insight to the internal signals of my VHDL entity as time passes or something like that?
Please help.
As the other posts have pointed out, you'll likely need a simulator like GHDL. However, to debug your simulation, there are a few different methodologies:
Classic print statements -- just mix in writeline(output,[...]) in your procedural code. See this hello world example. If you're just getting started, then adding print statements will be invaluable. For most of the simulation debug that I do ( and that is part of my job ), I do almost all of the debug based on print statements that we've built up in our design and testbench. It is only for the final debug, or for more difficult issues that I use the next debug method.
"Dumping" the simulation ( for GHDL see this page and this one ). This is a cycle by cycle trace of your design ( or a subset of your design). It's as if you hook up a logic analyzer to every single wire in your design. All the info you could ever want about your design, but at a very low level -- the signal level. To use this methodology:
Create a simulation "dump". The base format for such a dump is a Value Change Dump or VCD. Whichever simulator you use, you'll need to read the documentation on how to create a VCD. ( You can also search "dump" in your docs -- your simulator may use a different file format for its dumps.)
Once you create a simulation dump, you then load your dump into a wave-form viewer. If you're using the gEDA package, then you would use gtkwave to view the dump.
note If you want to use GHDL and gtkwave to debug your VHDL code, you can install them on ubuntu with command:
% sudo apt-get install geda ghdl
( assuming you have root access to the machine running ubuntu)
Xilinx offers free version of its design suite: http://www.xilinx.com/tools/webpack.htm. Webpack contains VHDL simulator, although last time I tried I've liked ModelSim's simulator better. It might have changed though.
Wepack is also different from ModelSim as it's not only simulator but full-fledged FPGA design suite.
ModelSim's disadvantage is its license -- as far as I'm concerned it's free for students only.
The others mentioned here are likely more appropriate based on cost and availability. However the best HDL/netlist debugger I've used by far is Verdi.
What you are looking for is an VHDL simulator. There are several alternatives to choose from:
Mentors Modelsim
Xilinx ISim
Aldec Riviera and ActiveHDL
Simili
The Simili software is available as a free version with limited performance.
Once you have the simulator installed you need to learn how to use it. Generally you will have to write a testbench in VHDL too, but some of the simulators will let you create the stimuli signals from a graphical user interface. You can find a large number of examples of VHDL-based testbenches on this page: VHDL Tutorials.
In the simulator you are able to visually inspect the state of your design in the waveform viewer and also be able to set breakpoints in your code to debug the design.
Use a simulation software like ModelSim. This kind of software is usually quite expensive. In general if with your vhdl synthethizer you'll get some lightweight variant of it or similar software which is enough for smaller things.
For small jobs which don't push the language spec all the way, GHDL works fine as a simulator IME. As you push things further (and you must, you can't debug any sizeable piece of code just in silicon) you may find you need to spend some money on something like Mentor's Modelsim/Questa or Aldec's ActiveHDL/Riviera.
first i created test bench to test my component, used isim to simulate this test bench, i inserted break points in the main code areas, used the step into button to step into code, or the run button to jump to next break point
same as i am used to do with any programming language
The professional way to “Debug” VHDL is to create a “testbench”. Like everything else VHDL it’s complicated. Here’s a “how to testbench” link: vhdl Testbenches
I am very lazy. I am also not professional. I prefer to do what is known as “forcing”. If you are using Xilinx, ModelSim, or Vivado, then you have the ability to toss your VHDL code into a “simulation”. There you can add signals to a waveform, select those signals (right click on them) and force their values to be ‘0’ or ‘1’. Then after “forcing” your input, run the simulation for a few nanoseconds and look at the output.