Sigasi's Blog

This website hosts blogs on multiple topics that relate to the world, work and lives of Sigasi team members.

Sigasi HDT
All blog posts related to our product, Sigasi HDT: tips and tricks, howtos, feature discussions, ...
Jan on HDL design
Jan's blog about his personal views on HDL design. Relevant for the future, but aware of the past.
VHDL
Posts that will make you a better VHDL designer, regardless of the tools you use.
Developing for Eclipse
We develop on top of Eclipse, so we have some experience in this field. In this feed, we share some of this experience.

You can easily subscribe to each of these blogs by clicking the rss icons. It is also possible to subscribe to all blog posts

A 20-year old relationship

Posted Tue, 2009-11-17 11:37 by jdecaluwe

Next year, in 2010, my relationship with VHDL will be 20 years old. It has been a good journey, but I can't say that it was love at first sight.

The first chip I designed while at Alcatel was done with Verilog. I remember that I was quite happy with Verilog. However, at the time (1990) there was this idea that very soon VHDL would take over the whole market. I remember very well how that idea was cultivated by a start-up CAD company called Synopsys.

At a certain point, management decided to switch to VHDL. So I promptly wrote a memo explaining why that decision was wrong, and why Verilog would prosper, using the kind of pro-Verilog arguments that I have been reading over and over again since. I believe that is why I understand the pro-Verilog camp well: I was once part of it.

Over the years my relationship with Verilog deteriorated into a love-hate relationship that eventually ended with a separation with mutual consent. I just had too many bad surprises. I often felt that Verilog was like a nice looking building on very shaky foundations. Therefore, I eventually settled for the solid ground of VHDL's strong typing and delta cycle algorithm.

In retrospect, the pro-Verilog analysis in my memo to management wasn't wrong. Verilog really has prospered, even though the building doesn't look nice anymore because of too many additions from too many architects. However, management's decision to switch to VHDL wasn't wrong either. VHDL has prospered too.

Late 1991, I co-founded a design services company, and we faced the choice between Verilog and VHDL. Our strong point was a methodology based on the vision that I presented in my previous blog post: digital hardware design is a kind of software development. We concluded that VHDL was a better language to support that vision. And in fact, VHDL has kept its promises and things have turned out pretty well. VHDL has been a good choice for us.

Copyright policy of IEEE

Posted Thu, 2009-11-12 09:03 by pfaes

Of course our users want to have access to all standard libraries. The most important libraries are std.standard and the IEEE libraries, including std_logic_1164 and std_numeric. A more recent standard is IEEE 1076.2-1996. This standard defines two packages: math_real and math_complex. IEEE does not allow the distribution of the source code of these packages. In order to serve our users, we have packaged the best legal alternative: a preliminary draft of these packages.

Recently, we have noticed some problems with this draft. A user informed of an inconsistency between the draft and the official standard. We knew this was a problem. We had planned to incorporate an official version of the standard in our tool, but it was not on our top-3 priorities. However, when a user posts a problem like this, we assign extra priority points.

So I purchased the official source code of the standard from the IEEE. This standard is protected by copyright law, but I'd like to republish the copyright header of the file, under the principle of fair use:

-- Copyright 1996 by IEEE. All rights reserved. 
-- 
-- This source file is an essential part of IEEE Std 1076.2-1996, IEEE Standard 
-- VHDL Mathematical Packages. This source file may not be copied, sold, or 
-- included with software that is sold without written permission from the IEEE 
-- Standards Department. This source file may be used to implement this standard 
-- and may be distributed in compiled form in any manner so long as the 
-- compiled form does not allow direct decompilation of the original source file. 
-- This source file may be copied for individual use between licensed users. 
-- This source file is provided on an AS IS basis. The IEEE disclaims ANY 
-- WARRANTY EXPRESS OR IMPLIED INCLUDING ANY WARRANTY OF MERCHANTABILITY 
-- AND FITNESS FOR USE FOR A PARTICULAR PURPOSE. The user of the source 
-- file shall indemnify and hold IEEE harmless from any damages or liability 
-- arising out of the use thereof.

Allow me to paraphrase this:

  1. Don't copy this file unless you pay us.
  2. You can use this file to implement the standard.
  3. But make sure your customers cannot do not see the original file.
  4. Make sure nobody sues us.

I can live with item 1, 2 and 4. IEEE invested money in creating this standard, so they want to safeguard their intellectual property rights. They also want to make sure nobody sues them. I understand. But, unlike their other VHDL standard libraries, they prohibit EDA vendors from redistributing the source code (item 3). That's hard to understand. Especially since the novelty of this particular package is questionable. Because of this copyright restriction, EDA vendors provide only a compiled version of the packages. As a result our users have to guess what's in the standard, because they will not buy a copy from IEEE for $86 plus taxes.

I remember one of my first programming labs in college. The assignment was to provide a set of header files and functions for manipulating complex numbers, including conversion from polar to Cartesian coordinates and vice versa. Basically the same thing I find in IEEE standard for mathematical packages. I would not argue about the relevance of the standard. It is very useful that all VHDL designers can use the same, standardized packages. However, the copyright restrictions seem too far-fetched.

The official version of math_real.vhd contains 593 lines of code. Only 53 of those lines consist of actual VHDL code (i.e. not comments). Similar ratios apply for the math_complex package, adding up to about 150 declarations in total, all of them referring to trivial and well-known mathematical values and definitions (π,2π,π/2 and arctan, sin, arctanh). Again: it's useful that this is standardized, but why do we need to keep the source code of these packages a secret from the general public? We don't do this for all the ANSI-C standard libraries, do we?

I'm sure I'm missing an important point here. Please help me out in the comments.

VRGT8CJXEPGK
XUFVPTR2Y2E2

[Announce] Jan on HDL Design

Posted Tue, 2009-11-10 08:25 by jdecaluwe

I met Hendrik and Philippe, Sigasi's founders, for the first time in early 2008. They explained their plans and showed me a prototype of their IDE for VHDL. That prototype has since evolved into the product you all know and love: Sigasi HDT.

I was intrigued. We had a few more meetings, and I decided to join them in their efforts to get the company off the ground. My main motivation: the idea behind Sigasi HDT coincides completely with my own vision on hardware design.

For their PhD work Hendrik and Philippe had been doing both software and hardware development. For software, they used modern methodologies and tools, such as an Eclipse-based Java IDE. They found that sophisticated features such as intelligent autocompletion and automated refactorings improved productivity and code quality significantly.

Naturally, they looked for something similar for hardware development. However, to their suprise, they found nothing that came even close. Out of this frustration grew the idea for a tool that would make the most modern software development techniques available to the hardware designer. That was the origin of Sigasi HDT.

My own career has been guided by the vision that digital hardware design can be viewed as a kind of software development. That explains why I am so excited about Sigasi HDT. However, even today, almost 20 years after I subscribed to this vision, I hesitate to write it down. It is still often met with scepticism. For example, it is still often asserted that "one shouldn't write HDL code like a software engineer". However, I believe the sceptics have it wrong. They misunderstand how a good software engineer actually thinks and works.

Today, I am announcing a blog about my personal views on HDL design. I believe they are relevant for the future, but I will talk frequently about the past. Insight in the past is very helpful to understand the issues, especially for younger engineers. If you are interested, you can easily follow my contributions on this page or via an RSS feed.

Subversive recognizes SVN projects

Posted Thu, 2009-10-29 09:36 by pfaes

One of our users had the following problem regarding our brand new SVN support (loosely paraphrased):


When checking out a project using Sigasi HDT and the SVN plugin, all works fine. However, we would like to check out a design database containing several projects, scripts and libraries. We then import a project from this directory tree: File > Import > General > Existing projects into workspace.

Using this method, Sigasi HDT does not recognise the project as SVN project.

In order to use the SVN plugin on an existing project do the following:

  1. Check with which version you have checked out your SVN project and set the same version in the SVN plugin.
  2. Right-click your project and select Team > Share
  3. Sigasi HDT will now detect the .svn directories and offer to use those settings.

Check out hardware project from SVN

Posted Tue, 2009-10-27 11:36 by pfaes

check out hardware project from SVNcheck out hardware project from SVN

The new Sigasi HDT supports SVN (Subversion) out of the box. This screencast shows you how to check out a project from SVN.











Syndicate content