HDL-FPGA Coding Style Guide

Based on all my years of professional and educational experience I'd like to introduce a document detailing general guidelines for VHDL coding style as well as some related to FPGA architecture. 

Even though I've tried to summarize the most important points, it results in a lengthy document, but it still is useful when starting a new project, or as a reference for coding in HDL (VHDL or Verilog) / FPGA.

Link to the document is as follows. ..... ;) ......

Suggestions are welcome in case any of you have a 'guide/point' that I've missed in the doc.

Have a GrAt DaY ! 

"Warning: NUMERIC_STD, "=": metavalue detected, returning FALSE". ISim, Xilinx

Introduction 

Whenever it’s possible I avoid using ISIM (the ISE embedded simulator). Among other things, it has poor support, and also very encrypted Warnings and Errors messages. In the last project I worked, I had no choice but using ISim, and when I was finishing the top level simulation I got the famous warning "Warning: NUMERIC_STD," = "metavalue detected, returning FALSE". And I say famous, because I goggled it in the web and found many entries, but almost none gave me an idea of what happened and even less how to fix it. Well, that is the reason I’m writing this post, to tell you what this means and at least one concrete way to find a clue where or how this Warning is generated.

What is it "Metavalue Detected" ? 

This message means that the simulator encountered as a result of an expression a non-numeric value, which can be for example "UUUU" or "XXXX" or some other value.

Commonly this result is obtained during the initialization of the system under test, and depending on the type of test it can repeat this message periodically or just once. As an example,  in the following figure you can read the messages I got during my simulation.

How to find the source of the warning message? 

As it can be seen from the figure shown above, there is nothing that looks "rare/strange" in the waveform of the various signals shown, so that, the solution is not at simple sight.

One way to find the source of this warning message, at least in this particular case that I’m showing you, it is to try to see the different internal signals of the whole system described in VHDL. To do this, go to the panel called "Instance and Processes" and click on the arrow that is next to the test bench, show in the figure above, click on the arrow next to top_tb. The name of the instance of the component under test in the test bench appears, in this case I called 'uut'. Again click on the arrow that is next to 'uut' and the various sub-components of the system are now listed. The following figure details what it was explained.

The next step is to select each sub-component and adding the different E/S and internal signals to the waveforms window (Wave Window). Select a sub-component by simply click on its name, then in the 'Objects' panel all the E / S and internal signals  of this sub-component appear. Then select all signals (because we do not know which one is malfunctioning), and add then to the Wave Window.

The following figure details the steps explained.

In the figure above, I have added to the Wave Window all the signals of the cont_4bits_1 sub-component. I can also add the signals of the other sub-components, freq_div_1 and bcd_7seg_1, but it happened that just adding the signals of cont_4bits_1, I found part of the problem. How? ... Well, once I added the signals of this sub-component, I run the simulation again, and immediately I visualized something that caught my attention .... what was that? .. well, try to find it out by yourself in the following figure.:

What do you see weird ???? .......

Yes ! ( I guess you found it out J )…  the last two signals, count and i_count, are not defined ('U' = undefined) .... We found something! ....

Possible Solutions

Now I come to this point, the steps to follow are two:

1) review the VHDL / Verilog subcomponent cont_4bits_1, and check especially initializing the count and i_count vectors.

2) review the bench test and verify the value given to the signal that initializes the system, commonly called reset.

In one of the two sides is the origin of Warning, and the solution to work with .....! ... (In my particular case it was a no well defined reset value in the test bench....).

Finally a note for those using ModelSim, you can read in various forums that ModelSim has an option for this type of Warnings (based on 'metavalues') that allow you to ignore them. Of course I DO NOT share that view, because it is always good to know the origin of the Warning. In my particular case if I had used ModelSim and had used the option to ignore these Warning, I had never encountered the problem that I found with the reset signal. . .

Well, I hope you find it useful ... reminded me if so!

See you soon ...

Delta Time 'View' in ModelSim

Introduction

For some people learning the language the concept of delta time is one of the most tough to understand. It's not the objective of this article to discuss about delta delay, but to let you to know the tools available in ModelSim to 'see' the delta delays.

How to 'see' the delta delays

I'll explain in few steps the procedures to follow to find out how many delta delays happens until a signal has an stable value.
First, here is the simple code I'll use

 1 library ieee;
 2 use eee.std_logic_1164.all;
 3
 4 entity aoi is
 5 port(A, B, C, D: in std_logic;
 6      E         : out std_logic);
 7 end aoi;
 8
 9 architecture beha4 of aoi is
10 signal O1, O2, O3:std_logic;
11
12 begin
13 b4: process(A, B, C, D, O1, O2, O3)
14  begin
15   E  <= not O3;
16   O1 <= A and B;  
17   O2 <= C and D;  
18   O3 <= O1 or O2;
19 end process b4;
20 end dflow1;

and this is the simple test bench used

 1 library ieee;
 2 use eee.std_logic_1164.all;
 3
 4 entity aoi_tb is
 5 end aoi_tb;
 6
 7 architecture test of aoi_tb is
 8 signal O1, O2, O3   : std_logic;
 9 signal a, b, c, d, e: std_logic;
10 component  aoi is
11   port(A, B, C, D: in std_logic; E: out std_logic);
12 end component;
13
14 begin
15    a <= '0', '1' after 6 ns;
16    b <= '0', '1' after 5 ns, '0' after 8 ns;
17    c <= '0', '1' after 7 ns;
18    d <= '0';
19
20 uut: aoi  port map(
21   E => e, a => a ,b => b ,c => c, d => d
22   );
23 end test;
24

Once you have executed the test bench, the Wave window will show the respective waveform, as you can see in this figure (a point to keep in mind is that you will likely have to add the internal signals, in this case O1, O2, O3, to the Wave window):

So, if you want to know the delta delays that happened at the simulation time 8 ns, you have to: 
1- Place a cursor on the 8 ns simulation time.
2- Click on the 'Expanded Time Delta Mode" button

3- Click on the "Expand Time at Active Cursor" button

4- Click on the "Zoom In At Active Cursor"

5- ReAdY !

The following figure details the above steps and the expected result.

Other way

ModelSim offers another way of seeing the delta delay. In the 'View->List' option, the signals and their respective events and delay are detailed in a table. 

The following figure is the respective 'list' of the above case. 

FINALLY

So, if you ever had doubt on how the delta delays works, here is an easy way of find it out !. 

See you soon.... 

Quartus-ModelSim: How to customize the waveforms to facilitate the debug

In a previous blog I described how to customize the waveforms in ModelSim in the Xilinx ISE environment. Due to the request of many of you, I now describe the waveform customization for the Altera Quartus users.  

As you'll read in the application note that I present; when invoking any simulation (functional or gate level) from the Quartus environment, ModelSim is automatically started up, displaying the waveforms resulting from the test bench in the panel called Wave View. Due to the ModelSim's settings (detailed in a script file) by default, only the entity signals are displayed in the waveform viewer, no other signal ... So, once opened this Wave View window if you wish to display internal signals of the design under test, or change the position and / or color of the signals, or add dividers, and many other features offered by ModelSim, you can do it (following certain steps explained later), but once you close ModelSim all modifications are lost!. Hence, when you run the same simulation again, you must start again with the modifications. The problem sound familiar?????

In the 'Application Note' that I present here, I detail the steps to follow, so that when you invoke ModelSim from Quartus, the Wave View will contain all the information you set and saved for proper verification and easy debug.

Here is the link to download the 'Application Note':  AN-08 C7T

Until next time!

ISE-ModelSim: How to Customize the Wave View Window

In case your simulation is executed using ModelSim, when you invoke any kind of simulation within the ISE environment, ModelSim is automatically opened. By default one of the window that comes up is the Wave View window. In this window only the top entity signals are shown, and ... no any other signal ... So if you want to see internal signals of your design, or maybe you want to change the position and/or color of a signal, maybe you want to add dividers,or utilize many other features offered by ModelSim, you can do that in the window that is automatically opened, but. . . any change in the Wave View window will be kept until ModelSim is closed. When running the same simulation again, you should start with the changes that you want once again from scratch.

I've written a kind of application note that describes the necessary steps to follow, so when you invoke ModelSim from ISE, the Wave View will open (keep) any change you have done to the initial (default) window, containing all the information you want/need for proper verification and easy debug:

C7T AN-05

Happy design!