Intel - Altera .... concern? happiness??

Much has been said about this great commercial operation: Intel acquires Altera. 

For those who work with FPGAs and even more, for those who likes Altera FPGAs, this news rise a big concern. And if we add that while I was at Intel I saw Intel acquiring and selling whole groups of IC designers as fries potates... my concern escalated to unknown levels. 

I found an interesting article about this topic. It explains very clear, as always when is written by Kevin Morris, concerns and assumptions about the future of this union. 

I leave here the link to the article: 

Altera’s Long Game 

Hope you enjoy it !

Error: "cannot match operand(s) in the condition to the corresponding edges. . ." "An edge descriptor must be applied to an expression of size 1"

Introduction

Recently a student of mine asked me to review her Verilog code because she had problems and could not find how the error was originated. Obviously, the synthesis tool used generated an error message, and obviously that message did not give any idea of ​​what was the source of the problem. The first thing I did, and that sometimes works for me, is to synthesize the code into the tool of competition (X or A), and .... the result was the same: encrypted error message. The second thing that I usually do in these cases is "google" the error message. I did that and I found nothing ! ... I had no other choice but to study the issue and try to find out the source of the error.
Below you can find details of the problem, error messages and finally the solution ....

Encrypted messages Error

ISE generates the following error message:


"ERROR:Xst:904 - "../../RTL_Src/semaforo.v" line 64: An edge descriptor must be applied to an expression of size 1."
 
The Quartus' error message:

"Error (10200): Verilog HDL Conditional Statement error at semaforo.v(64): cannot match operand(s) in the condition to the corresponding edges in the enclosing event control of the always construct"

The lines of code corresponding to the line number indicated by the error message are:

At first sight, there is nothing wrong with the code. I checked each statement of these lines, every symbol, every name many times and everything looked perfectly fine.
Another thing I did it was to go to the reference error message generated by the tool. When using ISE the error is Xst ISE: 904:

when you double-click on the link of the error, the following message shows up in ISE:

Does it helps the 'help' ?.... nooooo !!!

Quartus directly had no link or further explanation of the error message itself.

Well, after many workarounds; as always, the solution was very simple. Actually the problem was not in the code itself, but in the definition of clk and rst.

These are the first lines of code where E / S are defined:

Can you find the problem ? .....

PROHIBITED continuing reading before finding the error .... :)

Just for saving a few lines of code, clk and rst were defined in the same line as the two bits vectors sensor and button .... so clk and rst are actually defined as vectors of two bits, so the instruction negedge or posedge can not determine which edge to execute.

As usual,  once one found the error, one says: "How come I can’t find it sooner!", "How easy is the solution !", etc. etc ... What I did find strange is that compilers can not generate a simpler error message, with a better indication of the problem and a better guide to the solution.

Well, I hope you find this article useful.

Design Partitioning Based on Clock Domain

Introduction

When the system to design has several modules and each of these modules has its own clock, and the modules interact with each other, it is convenient to perform what is called partitioning based on clock domain, and follow a few simple rules regarding how to make the partition as well as how to name the I/O signals, and the communication signals between modules.

Partition Design

Suppose we have a system like the one shown in the figure below:

In this case the system has been divided into three modules A, B and C. This division is based on the different clocks in the system and the functionality of each module; so each module in this partition has its own clock. Thus, each module has what is commonly called its own clock domain (clock domain).
 

This partition of a system based on clock domain is important for several reasons, mainly it facilitates the work of the synthesis tool, improve the calculation task of the static timing analysis tool, save working time for the place and route tool. Another advantage of such partitioning is that it saves a lot of CPU processing time in complex systems.

Synchronizers

By making the partition based clock domain, and if the modules must interact with each other is needed some kind of synchronization between the communication signals, as each signal has its own clock domain. This synchronization can be performed by synchronizers or by FIFOs (not the purpose of this blog to explain the different methods of synchronization). For example, if a signal from Module A needs to be read in Module B a synchronizer is needed that synchronizes the signal from the A module based on the aclk clock, with the bclk clock of the module B. Similarly, if you want to send a signal from the Module B to the module A, a synchronizer is required to pass from the bclk domain to the aclk domain.
 

Thus, all main modules has only a single clock, while synchronizer modules have multiple clocks.

Signals Naming

With this type of partition is easier to follow a naming convention for the signals. Thus, all signals that are only controlled by a single clock, are named by referencing the clock domain names. For example the signals of the module A that are only controlled by the clock A, aclk, can be named beginning with the letter a (referencing the module A), so you can name the signals as adata, aaddr, aen, etc.. the same for signals controlled by blck, Module B, bdata, baddr, ben, etc.
 

On the other hand signals that cross clock domains (through synchronizers) should be named in such a way to facilitate the origin and destination of the signal. For example, if the signal ack must cross the bclk domain to the aclk domain, it could be named b2a_ack.
 

Using this type of naming convention can easily identify what are the different signals crossing clock domains. One of the great advantages of doing this is that you can write the corresponding constraint of false path to ease the work of static analysis tool time.

Other Benefits of Partition by Domain Clock

In addition to ease of timing closure, the advantages of design partitioning are better floorplanning for synthesis and; therefore, a reduction in area, performance, and potentially lower power. The synthesis tool is able to do a better job because there is only one clock in the module and the design can be easily optimized for area, speed, or power.
Also, by having the clock domain separated modules, existing synthesis tools allow each module to be individually optimized (either per area, speed or power). 

It's all for today .....

I hope to be useful .....

"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 ...