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 ! 

Assembly Code from the Zynq 'C' Code

Introduction

For those who made the first steps in microprocessor's programming using assembly language, still today is nice to see what is assembly code generated from the 'C' code. On the other hand, sometimes it's necessary to write a specific very high speed routine using assembly language. 

The SDK tool in the Vivado (Xilinx) development suite, has a command line that execute a utility that generates the assembly code from the written 'C' code. 

Use of the Xilinx Microprocessor Debugger (XMD) Engine

The XMD is a tool that facilitates debugging programs and verifying systems using the Dual ARM Cortex-A9 (as well as the MicroBlaze and Power PC).

The SDK provides what is called an XMD console, where it is posible to type an XMD command using a Tool Command Language (Tcl) kind of language. 

The XMD console can be open in two different ways: 

1. When the Debug perspective is activated, the XMD console is automatically open. 
2. In the C/C++ perspective, do Xilinx Tool -> XMD Console.

An screenshot of the XMD console (in the Debug perspective)  is shows below. 

The XMD console is an standard Tcl console, where it is possible to run any available Tcl commands. The command should be typed following the XMD% prompt. 

Note: there is a more complete (and newer) tool that replaces XMD in some aspects: the Xilinx System Debugger Command-line Interface (XSDB). SDK also provides an XSDB console (this will be explained in a short future). However, there are some commands that are exclusively executed in the XMD console, such as the command we will see next. 

So, getting back to the point of this post, to be able to see the assembly language (and even the machine code) generated from the 'C' code, the XMD command line to type the following: 

arm-xilinx-eabi-objdump -S <complete_path_of_my_project_name>.elf

Here is the complete XMD command typed in the XMD console, no executed yet (note the doble back slash symbol):

The result of this XMD command it shows below, along with titles explaining each part of the file: 

If you browse the resultant file, you will see that is a huge file. But, it's easy to follow if you have some experience in assembly language. 

So, I hope you like this post, moreover, I hope it's somehow useful ! ...

Error (in some versions): "undefined reference to Xil_ICacheDisable"

Introduction

This problem happened to me more than a year ago, and I've been asked about it for several other colleagues, so I post it now.... l 

Trying of doing the simplest project ever in Vivado, using the ZedBaord, I run into a problem that made me feel very bad.... 

How can I get 10 error messages ? !? !?  from the 'Hello World' project !

Finding the Problem 

So, I followed all the steps that many of the on-line tutorials explains to build the hardware for the 'Hello World' project... here is my design: 

I did the necessary steps in Vivado to open the SDK environment. Then in the SDK, I created a new Application Project based in the Hello World template. 

When I executed Build Project for the simple Hello World project, I got the following errors: 

I did a search in the web, nothing related came out. So, I investigated on my side and I found out that there is a kind of 'bug' for this version of the Vivado, 2015.1, that even though the DDR interface is not configured in the hardware, it is generated incompletely in the software. 

Thinking on this simple project, there is no need for using the external DDR available in the ZedBoard. Therefore, there is no need for enabling the DDR controller from the Zynq configuration window. However, solve the problem that generates the error messages you do need to enable the DDR interface even though you don't do any read/write to the DDR. 

Important Note: other versions of Vivado do not generate these errors. 

Once you enable the DDR interface in the Vivado environment and go back to the SDK, create a new Hello World application project and then execute a Build Project.... no errors should be generated this time... 

Filtering Warning/Info Messages in ISE

Introduction 

After executing some of the available processes in the ISE environment, various and numerous messages are generated. These messages let the designer know the “health” of the project. In some cases, you may want to suppress a particular message from appearing in the “Errors and Warnings Report”. For example, you may get a Warning message about unconnected pins that you intend to be unconnected. ISE allows you to suppress, actually filter, a particular message from subsequent runs of the software. The tool you can use for this purpose is the “Message Filters”.

Messages That Can Be Filtered

Not all the message generated by the different processes can be filtered. You can filter messages that begin with "WARNING" or "INFO" and are followed by a library name and message number. For example, the following message can be filtered:

In this Warning message, Xst is the library name, and 2677 is the warning message number.

Note: ERROR messages cannot be filtered. Likewise, messages for some processes cannot be filtered (for example, messages generated by third-party software, such as the Synopsys software). Anyway, if you try to filter a message that cannot be filtered, a dialog box will come up stating that the message cannot be filtered.

Procedures to Filter Messages in ISE

1. Once you have your project open, enable message filtering as follows:
• Open the Design Summary pane by doing Project -> Design Summary/Reports.
• In the upper pane of the Design Summary, in the Design Overview, select Summary.
• In the button pane of the Design Summary, select Enable Message Filtering.
• 

• Note: it is also possible to enable message filtering from the project properties options available at: Project -> Design Properties in the Project Settings pane.

1. In the Processes pane of Project Navigator, run the process which generate the messages to be filtered. For instance execute the Synthesize-XST process.
2. In the Design Summary pane, and in the option Errors and Warnings, select the process that generate the messages to be filtered, for instance select Synthesis Messages to filter the messages generated by the synthesis tool. Then, in the main Project Navigator window all the Warnings, Infos and Errors messages related to the synthesis tool should be displayed
3. To select which messages should be filtered, in the pane listing all the messages highlight (left mouse click) the message to be filtered. If there are several messages of the same type, just select one. Then right-click on the message to filter, and select:
• Filter All Instances of This Message - to filter out all messages with the same library name and message number, regardless of the message text.
• Note: there is another options in the filtering menu:
• Filter This Instance Only - to filter out all messages with the same library name, message number, and text. This option is for just one message in particular, for instance for a specific bit of a bus.
4. Just to be sure the filter has been correctly setting up, do Edit -> Message Filters, a new window will come up in which the selected Warning/Info to be filtered will be detailed. 
• 
5. In this window you can:
• Remove the filter: right-click the filter and select Remove, or click the Remove filter(s) button.
• Temporarily disable a filter, right-click the filter and select Disable.
• Activate a disabled filter, right click the Enable.
6. Re-run the process generating the messages to be filtered. Then, from both the console as well as from the Error and Warning pane the messages should be filtered.

• 
  
7. Note: Still the filtered messages are available. Select All Implementation Messages under the Errors and Warnings option in the Design Summary pane. The filtered messages will be displayed with a Yes in the Filtered column.

Caution! 

When you suppress a message, it does not fix the issue. 

Do not filter messages for issues that must be fixed. 

Filter when you know what you are doing. Then, you can focus in warnings that you do need to fix.

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