Share |
Login Form
Newsletter



Receive HTML?

Latest Members


Creating an Open Source-based FPGA Design Flow Hot

 
User rating
 
4.5 (6)

The combination of modern FPGAs and recent developments in open source electronic design automation (EDA) and intellectual property (IP) technology have brought the cost of starting an FPGA design outfit down to practically zero. This has paved the way for folks ranging from college graduates to full-blown professionals setting up shop in their basements.


The Design Warrior's Guide to FPGAsNote: This article was abstracted from my book, The Design Warrior's Guide to FPGAs (Devices, Tools, and Flows), with the kind permission of my publisher, Newnes (an imprint of Elsevier). [See also my book FPGAs: Instant Access]

Note: My book (The Design Warrior's Guide to FPGAs) hit the streets in 2004. The following article is based on the "state of play" back then, but – of course – a lot of things have changed since those days of yore, so please keep this in mind while reading the following article.

Note: One more point before we leap into the fray with gusto and abandon is that it is not my purpose to recommend the use of less well-supported tools. Low-cost FPGA vendor-supplied tools are preferred for cost-sensitive setups, while more powerful tools from the larger and/or specialist EDA vendors are preferred as designs increase in size and complexity. Having said this, if you are trying to create an FPGA design "shop" at home on a limited (or non-existent) budget, the open source tools presented here may well be of interest.


Something you don't really see a lot of are small "two-guys-in-a-garage" type design houses focused on developing ASICs. This isn't particularly surprising, because the design tools required to develop this class of device tend to be so horrendously expensive at $100,000-and-up on a good day. (Of course, the fact that actually having a chip fabricated costs millions of dollars is also a bit of a showstopper.)

By comparison, the combination of modern FPGAs and recent developments in open source electronic design automation (EDA) and intellectual property (IP) technology have brought the cost of starting an FPGA design outfit down to practically zero. This has paved the way for folks ranging from college graduates to full-blown professionals setting up shop in their basements.

In addition to actually knowing what you are doing with regards to creating digital logic designs, starting a successful FPGA design house requires a few fundamental pieces:

  • A development platform,
  • A verification environment
  • Formal verification (optional)
  • Access to common IP components
  • Synthesis and implementation tools
  • FPGA development boards (optional)


The Development Platform: Linux
Created by the Finnish engineer Linus Torvalds (and friends) starting around 1990. Linux is quickly becoming the predominant platform for ASIC and FPGA development. Even though the majority of FPGA synthesis and implementation tools originated on Microsoft Windows, most are starting to be – or already have been – ported to Linux.

Linux and GNU provide many invaluable tools for hardware and software development. Some common Linux tools (in no particular order excepting one that pleased the author) include:

  • gcc: C remains the fastest modeling language around for simulation and verification. If your designs are so large that they choke your HDL (Verilog or VHDL) simulation capability, you might consider creating a cycle-accurate C model and compiling it using the open source GNU C compiler (gcc).

  • make: The make utility is used to automate your build process. In the context of hardware, the term "build" can refer to anything from simulation, HDL code generation, and logic synthesis to place & route. In order to tell make which files you wish to process and which files depend on other files, you have to define these files and their relationships in a file called a makefile.

  • gvim: Derived from "visual interface", VI is the classic UNIX text editor. The vim utility is an enhanced version of VI, and gvim is a graphical user interface (GUI) version of vim. The gvim utility extends VI with syntax highlighting features and all sorts of other cool macros. With in-built support for both Verilog and VHDL, gvim is an ultra-fast "never take your fingers off the keyword" design entry tool.

  • emacs: Considered by many hackers to be the ultimate editor, EMACS (from "Editing MACroS") is a programmable text editor with an entire LISP interpreter system inside it. More powerful and more complex than VI, EMACS now has modules available for use in developing Verilog and VHDL-based representations.

  • cvs: Standing for "Concurrent Versions System," CVS is the dominant open-source network-transparent version control system and is applicable to everyone from individual developers to large, distributed teams. CVS supports branching, multiple users, and remote collaboration. It maintains a history of all changes made to the directory (folder) tree and files it is instructed to manage. Using this history, CVS can recreate past states of the tree and show you when, why, and by whom a given change was made. So if you accidentally mess up your RTL code or decide you want to re-synthesize a version of your design from 3 months ago … no problem, CVS will help you deal with this type of thing.

  • perl: Scripting languages are often used for one-off programming jobs and for prototyping. In the context of electronic designs, they are also used to "tie" a number of tools in the flow together by controlling the ways in which the tools work and by organizing how data is passed between them. Standing for Practical Extraction and Report Language, PERL is historically one of the more widely used scripting languages. Developed by Larry Wall, PERL has jokingly been described as "The Swiss Army Chainsaw" of UNIX (and Linux) programming, and many hardware design flows are still "glued" together using PERL scripts.

  • python: Arguably more powerful than perl, the Python language is an "all-singing-all-dancing" scripting language that has evolved into a fully-fledged programming language. Invented by Guido Van Rossum in 1990, and named after Monty Python due to Guido's love of the Flying Circus, Python can be used for anything from "gluing" together the design flow, to high-level modeling and verification, to creating custom EDA tools (see also the additional discussions on Python later in this article).

  • diff: A relatively simple – but incredibly useful – utility, diff is used to quickly compare source files and detect and report differences between them.

  • grep: Standing for Globally search for a Regular Expression and Print the lines containing matches to it (phew!), grep is used to quickly search a file or group of files to locate and report on instances of a particular text string or pattern.

  • openssl: Whether you are a large or small company, it pays you to ensure the security of your intellectual property (IP). One aspect of this comes when you wish to transmit your IP over a network or over the Internet to your collaborators or customers. In this case, you really should consider encrypting the IP before waving it a fond farewell. One solution is the open source OpenSSL project, which features a commercial-grade, full-featured toolkit implementing the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols as well as an industrial-strength general-purpose cryptography library.

  • openssh: Is your design team spread across the planet? The Secure SHell (ssh) utility is a program for logging into a remote machine and for executing commands on a remote machine while providing secure encrypted communications between two un-trusted hosts over an insecure network. An open source version of the ssh suite, OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. OpenSSH also provides a variety of secure tunneling capabilities and authentication methods.

  • tar, gzip, bzip2: These are different utilities that can be used to compress and archive your work.

Obtaining Linux
Until recently, the leading distributors of Linux have been Red Hat Inc. (www.redhat.com) and MandrakeSoft (www.mandrakesoft.com). However, Gentoo Linux (www.gentoo.org) is rapidly becoming a favorite amongst developers. Gentoo has a unique package distribution system that automatically downloads, compiles, and installs packages to your Linux machines. Want Icarus Verilog? Just type:

$ emerge iverilog

… and in a few minutes you'll find that Icarus has been installed and is ready to rock and roll!

 


The Verification Environment
You can argue about this back and forth, but many would say that the verification environment is the most critical part of the design flow. Anyone can bang away on the keyboard and produce HDL, but it's the verification tools that provide designers with feedback to steer the design toward a correct implementation.

Icarus Verilog
The predominate open source verification tool is a Verilog compiler known as Icarus (http://icarus.com/eda/verilog). In its basic form, Icarus compiles a Verilog design into an executable that can be run as a simulation. Truth to tell, Icarus is primarily used as an event-based simulator, but it can also handle basic logic synthesis for Xilinx FPGAs.

Verilog is a complex language, and Icarus's author – Stephen Williams – has done an excellent job with his Verilog implementation. In fact, Icarus Verilog's language coverage and performance exceeds that of some commercial simulators.

Dinotrace and GTKWave
Icarus Verilog discussed above is strictly a command line tool. (Command line tools are preferred in UNIX and Linux environments because they are easy to glue together with Makefiles.)

Icarus does not provide a graphical user interface (GUI) to display simulation results. Rather, it can produce industry-standard value change dump (VCD) files that can be used downstream in the design flow by standalone waveform viewing applications.

Enter Dinotrace and GTKWave, which are GUI utilities that can be used to display simulation results in VCD format. Both of these waveform viewers can scroll through a simulation, add trace lines, and search for patterns. Dinotrace (www.veripool.com/dinotrace) is a solid tool, but with limited functionality. By comparison, GTKWave (/www.cs.man.ac.uk/apt/tools/gtkwave) started out a little rough around the edges, but has seen modest development in recent months.

Covered code coverage
When verifying a design, access to functional coverage metrics is important to ensure that your test vectors are hitting the corner cases in your design.

Covered (http://covered.sourceforge.net) is a Verilog code coverage utility that produces the code coverage metrics associated with a simulation. More specifically, Covered analyzes Verilog source and the VCD data produced from an Icarus Verilog simulation to determine the level of functional coverage.

Covered currently handles four types of coverage metrics: line coverage, toggle coverage, combinational coverage, and finite-state-machine coverage.

Verilator
The hot design issue these days is how to handle System-on-Chip (SoC) designs, which require the integration of hardware and embedded software on a single chip. Many FPGAs host embedded hard processor cores or have access to soft processor cores.

The real trick in an SoC design involves verifying the hardware and software integration. Enter Verilator (www.veripool.com/verilator.html), which converts Verilog into cycle-accurate C++ models. The ability to auto-generate C/C++ models from RTL source code is a powerful verification tool. This allows the software to integrate directly with the C/C++ version of the RTL for simulation purposes.

In addition to hardware/software coverification, Verilator can also be used for general-purpose Verilog simulation, because simulating with cycle-accurate C gives much faster run times than can be obtained with an event-based HDL simulator. All you have to do is to compile the output C code using gcc (see The Development Platform discussions above) and run. (Note that Icarus also has C code-generation capabilities.)

Python
Python (www.python.org) is a very useful high-level scripting and programming language that is becoming is world-renowned for its "rapid implementation" capabilities. Not surprisingly, Python is shaping up as a "power tool" for digital design and verification engineers, particularly for tasks such as system modeling, test bench construction, and general design management.

In fact, many design firms are starting to discover that it's easier and faster to begin by creating Python models rather than Verilog or VHDL representations. Once these Python models have been verified via simulation, the design team undergoes the RTL coding process constantly referencing their "golden" Python models.

MyHDL (www.jandecaluwe.com/Tools/MyHDL/Overview.html) is a Python framework for high-level system modeling. It uses recent feature additions to the Python language (generators) to mimic concurrent operations. MyHDL also has the ability to connect to Icarus Verilog for mixed Python/Verilog simulation.

 


Formal verification
As the Dutch mathematician and computer pioneer Edsger Wybe Dijkstra once said, "Program testing can be used to show the presence of bugs, but never to show their absence."

 

Although hardware simulation remains the predominant means for system testing, the only way to ensure a system is correct is by means of formal verification. Unlike simulation, formal verification mathematically proves a system's implementation meets some form of specification.

The two main types of formal verification are model checking and automated reasoning. Model checking is a technique that explores the state-space of a system to ensure certain properties – typically specified in the form of "assertions" – are true. A sub-discipline called equivalence checking – which compares two representations of a system (for example, RTL and a gate-level netlist) to determine whether or not they have the same input to output functionality – is a form of model checking. By comparison, automated reasoning uses logic to prove (much like a formal mathematical proof) that an implementation meets an associated specification.

Open source model checking
The predominant open source model checker is SPIN (http://spinroot.com), which has been under development for almost 20 years by Dr. Gerard J. Holzmann at Bell Labs. A rather cunning beast, SPIN recently received the Software and System Award by the Association for Computing Machinery (ACM). This is no small honor, because previous award recipients have been UNIX, SmallTalk, TCP/IP, and the World-Wide-Web.

SPIN accepts an input specification with an integrated system model using a language called PROMELA. By means of this language, users can create complex assertions in the form of "never-claims", which define a series of events that should never occur in the system. Given a model and a specification, SPIN exhaustively searches the state space for violations.

The main drawback with SPIN is that it's primarily intended for asynchronous software verification, and thus employs a technique called explicit verification. Although explicit verification is ideal for verifying software protocols, the technique tends to be inefficient for large hardware-based designs.

For moderately sized hardware designs, a symbolic model checker is the way to go. Unlike explicit verification, symbolic model checking uses binary decision diagrams (BDDs) and propositional satisfiability algorithms (SAT) to contain the problem and, if possible, avoid state-space explosion (The abbreviation "SAT" comes from the first three letters of "satisfiability".) Fortunately, there is a high-quality open source symbolic model checker called NuSMV (http://nusmv.irst.itc.it).

Open source automated reasoning
The advantage of the model checking approach discussed in the previous section is that it's an automated process: click the button then wait for the result. The drawback is that you may have to wait for a very long time.

Even though the symbolic representation used by NuSMV provides a leg up on explicit model checkers, state-space explosion is still an imminent threat. It doesn't take long before a system's size grows beyond the practical limitation of a model checker. Another problem associated with model checking is that it's limited in expression, to the extent that some complex assertions simply can't be specified in a model-checking environment. Enter automated reasoning, otherwise known as automated theorem proving.

Automated reasoning does not share the limitations of model checking. For example, system size is not as relevant because automated reasoning does not search the state-space. More importantly, automated reasoning supports a much higher level of expression for accurately modeling complex and intricate specifications.

Unfortunately, what is gained in some areas is lost in others. Despite its name, automated reasoning is not a fully automatic process. In the real world, the verification engineer conducts the proofing process with the assistance of the tools. Furthermore, in order to use the tools effectively, the verification engineer needs to be well versed in proof strategies, mathematical logic, and the tools themselves. This is a non-trivial learning curve, but if you're willing to invest the time and effort, automated reasoning is arguably the most powerful form of verification.

Unlike model checking, where open source tools struggle to compete with commercial applications, the open source tools for automated reasoning are at the world's leading edge. Three of the most popular are HOL (http://hol.sourceforge.net), TPS (http://gtps.math.cmu.edu/tps.html), and MetaPRL (http://cvs.metaprl.org:12000/metaprl/default.html).

What actually is the problem?
Like any tool, formal verification is only as good as the engineers using it. Even on a good day, formal verification can only answer the question:

"Does my implementation meet the specification?"

… but the critical question remains:

"Is my specification correct?"

Evaluations of real-world designs show that most system failures are not due to a faulty implementation per se. Even without the use of formal verification, designs tend to correctly implement the requirements more often than not. The root causes of most failures are usually the requirements themselves.

Open communication and collaboration are the best ways to ensure a correct specification, and – at the time of writing – the only known tool that can tackle this problem is the cerebral cortex.


Access to common IP components
A useful rule-of-thumb if you are a small design house (or even a large design house) is to try to avoid "reinventing the wheel." Over time, every design firm acquires a library of frequently used components that it can pull from to speed the design process. In fact, a design firm's capabilities are sometimes judged by its intellectual property (IP) portfolio.

OpenCores
Fortunately for aspiring designers, they already have access to a vast IP library in the form of OpenCores (www.opencores.org). As the industry's premier open source hardware IP repository, OpenCores collects projects with cores ranging across arithmetic units, communication controllers, coprocessors, cryptography, DSP, forward error correction coding, and embedded microprocessors. Furthermore, OpenCores also stewards Wishbone, which is a standardized bus protocol for use in SoC projects.

OVL
Designers can spend as much as 70% of a design's total development time in the verification portion of the flow. This has created the need for access to libraries of verification IP. For this reason, Accellera (www.accellera.org) started the Open Verification Library (OVL) to address the need for common IP verification components.


Synthesis and implementation tools
Synthesis (both logic synthesis and physically-aware synthesis) is one major step in the FPGA design flow that not completely addressed by open source technology. Unfortunately, this situation is unlikely to change in the immediate future due to the complexity of the FPGA synthesis problem.

At the time of writing, Icarus (see The Verification Environment discussions earlier in this article) is the only open source tool known to synthesize HDL to FPGA primitives. The only other low-cost options are the synthesis and implementation tools from the FPGA vendors themselves (these should be the primary choice for a low-cost setup).

When a design approaches the capacity of a top-of-the-line device, however, even FPGA vendor-provided synthesis tools start to become inadequate for the task. This means that in the case of large, "bleeding-edge" designs, you may have no choice but to fork out the cash for a high-end synthesis tool.


FPGA development boards
If a design firm decides to get involved with physical hardware, FPGA development boards are a must.

OpenCores (see the Access to Common IP Components discussions earlier in this chapter) does offer a few FPGA development board projects, but most designers would be better served by purchasing professional development boards.

On the bright side, money spent on boards can be saved in other areas. For example, a clever engineer can turn a small FPGA evaluation board into a highly capable logic analyzer (hmmm, this sounds like a potential OpenCores project!).


Miscellaneous "stuff"
Some other odds-and-sods that might be of interest are as follows:

  • http://www.easics.be Click the "WebTools" link to find a CRC utility that allows you select standard or custom polynomials and generate associated Verilog or VHDL modules.
  • http://www.veripool.com A collection of Verilog-based tools (this is the home of Dinotrace and Verilator)

While surfing the web, one can meander into a lot of other open source projects related to EDA and FPGAs. Unfortunately, most are dormant or have been abandoned without achieving a useful level of functionality. Having said this, should you run into something useful – or if you have created something useful – please feel free to contact me at This e-mail address is being protected from spambots. You need JavaScript enabled to view it for inclusion in a future, super updated and enhanced version of this article.

User reviews

View all user reviews

Average user rating from: 6 user(s)

To write a review please register or login.
Overall:
 
4.5
 
 

Re nice article, but...

Overall:
 
4.0
Clive Maxfield Reviewed by Clive Maxfield
April 13, 2010
Comments (0)
Report this review
 

Good Catch re Linus being Finnish and not Swedish -- the great thing about TechBites is that you can quickly contact the author to request "tweaks" to an article to correct things like this (I just made that correction by the way).

Hmmm, what a coincidence ... your name being "Mive Claxfield" and mine being "Clive Maxfield" ... a more suspicious man than myself might think someone was "pulling my plonker" as they say in England...

 

Nice article, but...

Overall:
 
4.0
Mive Claxfield Reviewed by Mive Claxfield
April 13, 2010
Comments (0)
Report this review
 

Linus Torvalds is Finnish, not Swedish. The book is wrong too.

 

More tools: TCL, Subversion

Overall:
 
4.0
Evgeni Stavinov Reviewed by Evgeni Stavinov
March 03, 2010
Comments (0)
Report this review
 

I'd also add TCL - tool command language - to the list. It's a de-facto standard in all EDA tools.

Also Subversion for source control. At this point it's more popular than CVS.

 

Valid or verified?

Overall:
 
5.0
Henry Davis Reviewed by Henry Davis
January 05, 2010
Comments (0)
Report this review
 

Max,

You've hit on some very thorny problems. First, in my experience mainline functionality is almost universally correct. The failures mos frequently occur in the margins - cases where nobody thought of that particular combination as anything that somebody would really try, and what do do about semantic mismatch in the english language. It's amazing how imprecise English is in practice.

This in turn leads to the inescapable conclusion that complete validation isn't possible.

 

Fedora Electronics Lab (FEL)

Overall:
 
5.0
Shawn J. Goff Reviewed by Shawn J. Goff
January 05, 2010
Comments (0)
Report this review
 

Great coverage on OSS FPGA design tools! The only project I know of that wasn't covered is the Fedora Electronics Lab ( http://spins.fedoraproject.org/fel/ ). It is a respin of Fedora with lots of EDA tools in it.

 
 
View all user reviews
Written by :
Clive Maxfield
 
 






Latest Content
User rating
 
0.0 (0)