A.L.S.E the FPGA Experts

What is IO Checker ?

2024-03-14T17:18:01Z

If you are involved with designing a board with an FPGA on it, starting with the schematics and ending in a functional PCB, then this article is four you !

Rationale

Today more than ever, doing things quickly and right the first time is critical in any project.

For HDL and Digital Design, we have created efficient training courses that help achieving rapid success through rigorous coding and a robust Methodology.

But when it comes to schematics and PCB layout, the situation is much more complex.
One of the issue is the complexity of modern FPGAs (with hundreds or thousands of pins to assign, with a lot of different power supplies, and with electrical standards and pin out constraints that are extremely difficult to manage).
Indeed, there are many other issues (from creating valid hardware to anticipating signal integrity issues) but the task of managing power supply nets and creating all the pin assignments in general is often underestimated… until it needs to be performed !

In any case, nobody wants to receive a batch of prototypes to discover the FPGA is not usable due to incorrect pin assignments ! Do you plan for the cost (and delay) of a complex PCB respin ?

A big helper

We have discovered and we use now IO Checker, from HDL Works. It removes the frustration of long, painful, and error-prone task of assigning all the pins between the schematics and the FPGA tools, including the pins that don't show in the source code (Supplies, Grounds, NC, Programming, JTag, Special purposes, external memories, etc). IO Checker knows the purpose of all the pins of your FPGA !

We can help you verify your schematics, but we think it's better if you can handle this yourself, especially to optimize your iterations, reduce your schematics and FPGA design time, and make sure the transition to the PCB will be smooth and without error.

See for yourself

On the HDL Works website, you will find the IO Checker section and this Introduction video which clearly presents IO Checker.

You'll find another video showing how to create, verify and maintain the pin assignment constraints.

Take a look at the videos !

Practical Example

We have the plan to write an Application Note showing how we used IO Checker to verify a very complex Agilex 7 board. Stay tuned.

Floating Points in FPGAs

2024-02-28T09:58:01Z

Are you tempted about using Floating Point vectors (“Reals”) in your next FPGA project ? Can this be done ? How ? Is it a good idea ?

Then this Application Note (an extract from our FPGA Design Training course) is for you…

UARTs & RS232

2024-02-13T10:57:34Z

In 2024, some may consider that UARTs (and RS232) are a thing of the past.
They couldn't be more wrong !

An RS232 link is the simplest way to exchange any kind of information between to points ! From the simplest microprocessors to the most complex Systems On Chips and Embedded processors, all have at least one UART. This is a fundamental means to monitor and debug a system.

And, good news !
* A UART is very simple to design in an FPGA.
* It is a very small block easy to add in a nearly full FPGA.
* It can run at very high speeds, easily at 1 Mega bauds.

This Application Note will teach all you need to know from the low level physical protocol to the designing your own UART in any FPGA !

RS232 & UARTs Basics

Using the LT24 / ILI9341

2022-09-07T09:18:53Z

This (2017) complete Application Note shows how to control the LT24 LCD Display from an FPGA kit. Even if you use a different LCD controller, or a different FPGA kit, you could be interested in the techniques used in this Application Note.

Gowin

2022-09-07T08:51:01Z

If you just bought the TEC0117 GOWIN LittleBee FPGA module, you can follow this small Application Note to go through the whole process of setting up the Gowin tools, creating a simple project and testing it on the FPGA board.
If you don't have the board, you can still follow the step to have a view of the Gowin design flow.

This small and simple Application Note was created since the available Gowin documentation is spread over many documents and videos.

Note : the TEC0117 GOWIN LittleBee FPGA module should be available again from Trenz Electronic mid-April 2024.

Whether you have the module or not, you can follow the steps to discover the Gowin FPGA design flow. This document has been update end Feb 2024.

Designing for Stratix 10 & Agilex FPGAs

2017-08-16T10:21:19Z

The Intel 14 nm Stratix 10, and even more the newer Intel 10 nm Agilex FPGA families offer unprecedented performance.

However, taking full advantage of these architectures and associated design tools requires to adopt new design techniques and use a new generation of tools. We have the proper trainings offer to help customers.

This ApNote is merely an illustration of how to achieve simply good performance with little efforts. Ultimate performance will require more efforts, but starting from a sound design will always help.

NUMERIC_STD Issues.

2017-03-01T13:28:56Z

Description

The IEEE numeric_std library issued (eg) in Nov 1994, and which (as of 2022) is still used in the latest versions of the Simulation and Synthesis tools, implements incorrectly the multiplications of signed/unsigned vectors by an integer. Moreover, the resize function it includes can produce incorrect results without warning.

Fixing these functions is not difficult but my attempts to have the VHDL working group fix this library have been unsuccessful. As a consequence, you should understand and take into account these “features”. This is the purpose of this page.

Multiplication issue : Functions affected

Here are the original prototypes (in IEEE.numeric_std) :

 -- Id: A.17 function "*" ( L: UNSIGNED; R: NATURAL) return UNSIGNED; -- Result subtype: UNSIGNED((L'length+L'length-1) downto 0). -- Result: Multiplies an UNSIGNED vector, L, with a non-negative -- INTEGER, R. R is converted to an UNSIGNED vector of -- SIZE L'length before multiplication. -- Id: A.18 function "*" ( L: NATURAL; R: UNSIGNED) return UNSIGNED; -- Result subtype: UNSIGNED((R'length+R'length-1) downto 0). -- Result: Multiplies an UNSIGNED vector, R, with a non-negative -- INTEGER, L. L is converted to an UNSIGNED vector of -- SIZE R'length before multiplication. -- Id: A.19 function "*" ( L: SIGNED; R: INTEGER) return SIGNED; -- Result subtype: SIGNED((L'length+L'length-1) downto 0) -- Result: Multiplies a SIGNED vector, L, with an INTEGER, R. R is -- converted to a SIGNED vector of SIZE L'length before -- multiplication. -- Id: A.20 function "*" ( L: INTEGER; R: SIGNED) return SIGNED; -- Result subtype: SIGNED((R'length+R'length-1) downto 0) -- Result: Multiplies a SIGNED vector, R, with an INTEGER, L. L is -- converted to a SIGNED vector of SIZE R'length before -- multiplication.

Multiplication Issue

As we can see above (in the comments), when multiplying a vector by an integer, the integer is converted into a vector of the same width as the other operand !!!

As a consequence, the result's width is forced to two times the width of the signed/unsigned vector, just as if the vector was squared (multiplied by itself), which absolutely does NOT make sense.

The result is either too short or too large.

Consequences

Multiplying a vector by 1 (or a small integer) creates a vector twice as large.
Quite inefficient, a bit ridiculous, but relatively harmless.
Multiplying a 128-bits vector by 7 (eg) creates a 256-bits results.
Same remark as above.
The result of Multiplying an 8-bits unsigned vector by 256 is a 16-bits vector (okay by chance) but with a value of ZERO ! See the test case included.
This is definitely VERY WRONG :-( and the multiplication result is not usable.
Multiplying a 8-bits signed vector by 1000 (decimal) produces an incorrect result (actually V * 232) and the result is limited to 16 bits anyway.
This is also very wrong.

Note that simulators will typically issue truncation warnings during the simulation (run-time) in the most offending cases, or refuse to compile if the result width is not what the user believed (which is how I uncovered the issue).
But Synthesis tools will compile and generate hardware which can potentially produce incorrect results, and this is not acceptable.

Are these functions useful ?

Certainly. They are required by the principle of numeric_std which is to extend arithmetic operators to vectors that represent numbers (signed and unsigned).

Moreover, Synthesis tools are usually relatively smart when they see multiplications by constants, in which case they know how to replace the multiplication by adder(s).

However, their use has been limited (which explains why the incorrect implementation hasn't been reported heavily before). One can note that the older Synopsys library “std_logic_arith” did not provide the multiplication of signed/unsigned vector by integers, and therefore could not have the same problem.

Repairing NUMERIC_STD ?

Fixing the affected functions is not complicated : it suffices to convert the natural or integer into a 32-bits vector ! The resulting width at least starts making some sense (=Operand width + 32) and no truncation / incorrect result can occur. If the result is still too large for you (like when you multiply by an integer range), you just have to resize the result. If you lose information in the resize (you resized into a too short vector), YOU WILL NOT GET A WARNING.

BUT, the issue is that numeric_std will probably never be fixed !

So you have to take care of your code and make sure you are not affected by the library errors, as explained below.

Conclusion

In spite of the library clumsiness (shift operators, resize issue, and this bug in particular), I still keep recommending using numeric_std instead of other non-IEEE libraries.

My VHDL Coding Style Guide is updated :

Do not multiply signed/unsigned vectors by Integers.
- Use slices and adders if you multiply by an integer constant
- Convert the integer in a properly sized signed or unsigned vector before multiplying.
- Keep in mind that if resize creates an incorrect value due to truncation, you will NOT be warned !

and the older recommendation remains :

Avoid using shift/rotate operators from numeric_std (use slices & concatenation)

And finally : kudos to the brilliant Technical Support at Mentor / Model Technology !

VHDL Coding Guide

2016-11-08T18:34:05Z

By our (long) experience, many designers code without using any Coding Guide.
From the smallest one-man operation to the largest multi-national company, this is never a good thing.
However, we have also seen some totally counter-productive Coding Guides ! (usually in large companies).
This was the motivation in creating this document in 2004. Surprisingly, this Guide has remained extremely stable, it has been unsed with permission in a lot of companies throughout the world, and the 2018 edition is very close to the original version, which is an indication of its quality !

Introduction

These rules and coding style are the result of more than 25 years of HDL design and teaching experience, hundreds of complex ASIC & FPGA projects, hundreds of thousands of lines of code, and the development of a very rich portfolio of complex IPs serving customers all over the world.

This Coding Guide is “reasonable”: small and simple enough to be easily remembered, “no-nonense” in that only useful rules have been kept. However it is covering a lot of the usual mistakes and it can significantly enhance the quality of the VHDL code.

Caveat

It is probably useful to remind at this stage that :

Following the rules is not sufficient per se: this Coding Guide is in no way teaching the fundamental principles that any HDL designer must master to create efficient and reliably working designs.
It is the purpose of our Training Courses and especially our “FPGA Design Reliability” course !

The other way around is also true: some of these rules can be bent while a correct, working, design is achieved, if there is a good understanding of the potential issues that may result.

The Naming Conventions proposed here are not absolute rules. You may decide to adopt other naming conventions, but it is not acceptable to not have any naming convention enforced at all!

In summary, this document is only proposing a number of recommendations that, if followed, will reduce the design risks and globally augment the code quality and reliability.

Copyright ALSE

These Coding Rules are copyright ALSE. If you want to reproduce them or use them by any means, you must contact ALSE and request an authorization. However, strictly personal use is allowed.

Obtaining the full document

You can view the complete Guide using the link below.

Do I need SystemVerilog ?

2016-09-23T17:06:12Z

We assume you are an FPGA Designer.
If you're not already fluent in SystemVerilog (SV), then you may wonder whether it's worth the effort (to learn this huge new language).
We'll try here to provide some answers.

You've been using VHDL for years (or just beginning), and you hear sometimes that you should abandon it right away and switch to SystemVerilog (sometimes noted “SV” in the following). But you may also hear horror stories about people discouraged by the breadth and complexity of SystemVerilog.

At ALSE, we've been there, done that.

As a 32+ years-old French Design House, initially with a majority of European customers, our main design language has been VHDL, though we had our share of Verilog designs for some customers. We still have a slight preference for VHDL against Verilog at least for design, but we've convinced ourselves long ago that SystemVerilog was a clear long-term winner.
And quite logically, for our complex IPs, we have switched a while ago to SystemVerilog. If you attend one of our Trainings, you'll see how enthusiastic we are about using SystemVerilog !

Let's see some facts about this “Language War” and bust some myths.

Note

If you are an ASIC designer, then you already master Verilog ! Because Verilog is absolutely compulsory in ASIC flows.
If you are an FPGA Designer, you may or may not know Verilog already.

Any Designer should master both VHDL and Verilog

It's not a new fact ! Neither VHDL nor Verilog did grab all the shares and we still see both being used throughout the world and various industries. If you receive an IP, it can be in Verilog or VHDL (and now SystemVerilog for recent ones).
In some (many) FPGA design flows, you'll see the tool generate or use Verilog anyway…
If you use behavioral models (like for memories), chances are they'll be in Verilog.

If you only master one of the two languages, you have no excuse ! With our instructor-led training, we teach Verilog to VHDL designers in just one (intense) day. That's all it takes. So it's clearly a modest investment, and it does allow you to be at ease with HDL code in both languages.

Do I need Verilog before SystemVerilog ?

SystemVerilog is a superset of Verilog, which it does encompass. So if you start from scratch, you would need in any case to learn the Verilog concepts before learning all that has been added on top of it.

Another reason to start with Verilog, then add SystemVerilog extensions, is that it will help you understand how to write code that remains compatible with the Verilog tools and flow. In many cases, you may need to stay within the Verilog language boundaries (because of some tools).

Isn't SystemVerilog a HUGE language ?

Yes !
With a 1315 pages Language Reference Manual for the P1800-2017 version, and (at least) FIVE complex languages rolled into one, it's hard to disagree ! By the way: thanks to Accellera, the SystemVerilog 1800-2017 IEEE LRM is available free of charge !

But this doesn't mean you have to learn ALL of it at once ! The trick is to learn (and master) exactly what you need and not more (well, it's already quite significant). You'll see that you can take advantage of 80% of the language benefits with only 20% of the efforts, and that's exactly what us, Engineers, love to hear.

And what about UVM ?

UVM is a completely different story (than SystemVerilog) ! You must learn SystemVerilog, but you might want to adopt UVM for Verification.

The only relationship is that UVM is based on SystemVerilog Verification Classes, so you can't learn UVM without learning SystemVerilog and specifically its Object-Oriented-Programming (OOP) part (“the Verification Classes”).
But clearly, you can take advantage of SystemVerilog while not using UVM.

We will dedicate a separate article to UVM, just note at this point that it's way harder to learn and master than SystemVerilog for Design & Verification!

Keep in, mind that, at ALSE, we have UVM expertise not only to train you, but also to help you and take care of designing for you the complex testing environments based on UVM that you need.

The Best Path to SystemVerilog

After applying it to ourselves and teaching it to hundreds of Engineers, we have accumulated a lot of success in the following approach :

Learn “Verilog for VHDL Users” if you're not fully up-to-speed yet with Verilog (1 or 2 days)
Learn “SystemVerilog for Design & Verification” (3 days) … and stop here, at least for a while !

You will master :

Coding style for efficient RTL while taking advantage of the superior features of SV.
Interfaces (which are absolutely suitable for synthesis !)
SystemVerilog Assertions !
This is a fantastic way to enhance your code and ease the verification.
Advanced semantic for safer code and more efficient logic optimization
Better expressiveness
How to avoid usual pitfalls
How to work around some irritating “features”
How to take advantage of some tools to secure the code But the highest gains in productivity will come from the Verification features of SV :
ABV : using SV Assertions for both RTL and Verification modules.
Note that Assertions also provide free functional coverage !
Test benches (aka test fixtures) and behavioral models.
For both, SV offers a tremendous improvement over VHDL.
Stimuli Generation (Constrained Random).
Functional coverage (from SVA and Covergroups).
Cover-driven simulation to minimize simulation time while ensuring that coverage goals are met.
Enhanced data types to facilitate Modelling and Verification.

Yes, we can teach this -and more- in just 3 (intensive) days.

Reasonable Pain, Huge Gains !

You can augment radically your productivity as well as the quality of your designs, and make your Verification fly.

You'll master and use :

Assertions (SVA) -everywhere !-
Interfaces
Enhanced Synthesis constructs
Enhanced Data types for Synthesis
Packages
Enhanced Data types for Modelling and Verification
Constrained Random
Functional Coverage
Cover-driven simulation
Basics of Enhanced Process control
And maybe a bit of DPI
Understand how to enhance your design & verification Methodology.

It's often just not an option

Verification is more and more demanding and certification authorities -for the first time- start mentioning explicitly SystemVerilog (and UVM) as the right tools to achieve the certification goals. One of the magical words is “Functional Coverage”. Gone are the days when the famous “100% statement coverage” made the quality dept guys happy.

And if your project deserves the use of formal tools, you'll remember that they take SVA as input !

As a conclusion, the question is not IF you'll adopt SystemVerilog, but just WHEN.
The early adopters phase is long gone now. You just need to prepare yourself in the most efficient way.
And we can help you.

Utilities

2016-09-20T21:44:56Z

© 2009 ALSE. All rights reserved. NOTICE OF DISCLAIMER about Free IPs and other information on the ALSE Web site. ALSE is providing design, code, or information “as is.” By providing the design, code, or information ALSE makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. You are entirely responsible with any use you make of the provided information, code or design. ALSE expressly disclaims any warranty whatsoever with respect to the adequacy of the information, or to the suitability to any use beyond education, including but not limited to any warranties or representations that this information is free from claims of infringement and any implied warranties of merchandability or fitness for a particular purpose.

These utilities are free to use, with the usual disclaimer above: use this at your own risk.

SystemVerilog definition files for Crimson Editor.
unzip into Crimson's base installation directory.

Verilog RTL ROM Generator
This Tcl/Tk utility reads in a memory contents file in Intel-Hex format and produces synthesizable Verilog code for the ROM.

VHDL Quick Reference sheet.
Standard RTL & Test bench templates and Numeric_std reminder, all in one sheet.

Numeric_std cheat sheet.

CPU_Time.
Utility (Tcl) to capture the current Date & Time information (“wall clock time”) from within a VHDL simulation. (c) ALSE, for use with ModelSim. Your batch simulation can record start and end time in the VHDL output. Great also for simulation run-time optimization.