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

Free VHDL plugin for Eclipse?

Last month, we released our VHDL IDE as an Eclipse plugin. Before that, it was only available as a standalone product. There were two main reasons for releasing the VHDL Eclipse plugin version. First, many users requested features that we would never implement, such as support for C, PHP or ClearCase. Of course, we could integrate existing Eclipse plugins, but we did not want to overload our standalone product. Instead, we want the standalone VHDL IDE to be lean enough, so that we can support all the plugins we package. Releasing the VHDL Eclipse plugin version allows users to customize their IDE in any way.

The second reason for releasing as an Eclipse plugin was that the Eclipse user community is a natural target audience for our tool. Engineers that have previously developed (embedded) software on Eclipse, will likely also look for an Eclipse-based solution for VHDL development.

Now, a few weeks after launching the VHDL Eclipse plugin, we are seriously considering opening up even more towards the Eclipse community.

Today, you have to sign up on our website before you can install the plugin. Each user gets a customized update site. This is probably a bit of a security overkill. We think it would be better if anybody could download and install our plugin without first signing up on our website.

But there you have a few problems: What happens if the user does not enter a valid license key to try or buy the product? Should the plugin just be disabled until a the valid license is entered, forcing the user to visit our website and sign up for a license key? There must be a smoother path.

So here is what we were thinking: suppose that the plugin, without a valid license key, behaves like a normal, traditional VHDL editor. With syntax highlighting and code templates, but without syntax checking, without hierarchy view, without navigation and refactoring support. Whoever wants to use this editor, can do so forever, without spending any money. Users that want to experience intelligent VHDL support of the complete VHDL plugin can sign up for a free 2-week evaluation or they can purchase a license.

The free VHDL plugin would not have any unique features. It would be about as good as any of general-purpose editors out there, but it would be nicely integrated with your existing Eclipse IDE. So you would have basic VHDL support and all of the benefits of version control, issue tracking and integration with C/C++ or any other language you need.

We're still working out some technical details, but we feel this may be the next natural step for Sigasi to take. What do you think? Let us know in the comments, or on twitter.

Quick diff / compare with

In Sigasi HDT for VHDL, as in any other Eclipse plugin tools, you can easily compare your current file with older versions. There are two methods for doing this: a side-by-side graphical diff, or a quick diff, which is directly available inside your editor.

Quick diff

To the left of your editor view, you can see colored markers on the lines that have been changed since you last saved your file. (if you have line numbers enabled, the line number will be colored). If you hover your mouse over the colored part, you see what that line looks like on the copy on your hard drive.

Instead of comparing your VHDL code to the version saved on disk, you can also compare to the your version control system (I like that better). Set the options for quick diff (or turn it off) at: Window > Preferences > General > Editors > Text Editors > Quick Diff

Compare

You can also see a side-by-side diff of your code by right-clicking in the editor and then selecting Compare With. You can compare with

  • Local history
  • Any revision from your version control system

The local history is especially useful if you have made a lot of edits, but have not committed intermediate version to your version control system.

Hyperlinks in VHDL comments

Hyperlinks in VHDL commentsHyperlinks in VHDL comments

Make URLs in your VHDL comments clickable, by holding down the CTRL key!











Why hardware designers should switch to Eclipse

[pdf]

Introduction

Integrated Development Environments (IDEs) have long been the primary tool for software engineers. Like an airplane cockpit, an IDE is the control center from which the engineer accesses all of the data and tools that he needs. IDEs, and especially Eclipse, have proven to be extensible, open, high quality platforms.

However, until now, IDEs have not been popular in hardware development circles. This is partly because many of the available IDEs for hardware development have not lived up to the potential of IDEs that is typical in the software world. Instead, IDEs tend to be overly complex, closed, and they lock the customer in.

Today, though, Eclipse is finally gaining traction among EDA (electronic design automation) and FPGA companies. One such EDA company, Sigasi, has just released the first commercial VHDL plugin for Eclipse. Now, at last, hardware design teams can use Eclipse as a basis for their own customized IDEs, based on the commercial and open-source plugins that they need in their central cockpit for hardware design.

Cockpit view

Head-Up Display of a commercial airplane landing.Head-Up Display of a commercial airplane landing.The cockpit of a fighter jet is a powerful control center. Everything the pilot needs is right there, within the reach of his hands. The pilot can access dozens of subsystems, including navigation, flight management, guns, and missiles, among others, through hundreds of buttons and dozens of displays.

During dogfights (one-on-one acrobatic fights), a fighter jet pilot needs to keep his attention focused on the enemy aircraft. He cannot afford to keep looking down at his dashboard in order to check his weaponry status. Instead, he uses what is known as a Head-Up Display (HUD). This display consists of a transparent screen through which the pilot looks at his opponent. At the same time, the HUD projects extra information like air speed and altitude on the screen. This way, the pilot can keep his head up and remain looking at the surrounding environment, while still keeping track of critical data.

HUDs have been shown not only to improve fighting capabilities, but they also improve the capability to fly in bad weather conditions. Today, HUDs are also used in commercial airliners, allowing landing and takeoff even when visibility is low, by augmenting reality with additional information. Even high-end automobiles and motorcycle helmets are now being equipped with HUDs, which illustrates their broad applicability.
A HUD is not a substitute for pilot skills, but it enhances the pilot's capabilities to levels that are unreachable without this technological support.

Toolkit mess

Like an airplane pilot, any electronics engineer or software engineer needs all the technological support he can get.
Unlike a pilot, the typical hardware designer does not have all of the controls he needs at the tips of his fingers, nor does he have a head-up display. Information is scattered across different files: documentation, high-level models, RTL models, build scripts, simulation results, wave traces, synthesis log output, etc. Different files that deal with the same part of the project might contain consistent information -- or they might not.
Inspecting all of these different files requires different programs, many of which barely interact.

Suppose an engineer is checking the log output of a synthesis run. If a warning shows up in the logs, he then has to manually navigate to the corresponding design file and line number. However, once he finds the location, does he remember the relevant details about the warning or does he again have to switch tools to look them up?
Similarly, a small bug can become extremely costly if is detected late: processing the bug report, compensating your customer, chasing the bug down, fixing it...all add time, which means money. Managers should seriously consider every single tool that can possibly help avoid this mess. They should also look for ways to increase the overall productivity of their engineering teams. Bad decisions, bad tools, and bad processes kill productivity.

IDE is the cockpit for developers

Software engineers, like hardware designers, continuously work with code, documentation, build scripts, and logs. What can they use as their cockpit?
For decades, software engineers have looked for and built platforms that improve the usability of their tools and the quality of their work. Since the 1990s, the generally accepted cockpit for software development has been the Integrated Development Environment (IDE). IDEs have come in different flavors and have been produced by different companies. Borland Developer Studio, Microsoft Visual Studio, IntelliJ IDEA, Netbeans, and Eclipse are some well-known examples.

The IDE is, in many ways, a cockpit for the software engineer. It is the single access point for interactive compilation, debugging, navigation, and editing of code. However, IDEs do not only serve as a cockpit, they also offer advanced HUDs. The IDE will flag syntactic and semantic errors immediately in the code, similar to spell a checker. It will also provide extra information, for example about data types, in mouse-over pop-ups.
Modern IDEs even have autopilot-like features. They will suggest automated fixes for common mistakes, like using an undeclared variable. IDEs also help in performing tedious and repetitive code modifications, while still leaving the helm -- and the ultimate decisions -- to the engineer.

The IDE's job as prominent tool is not finished until the software engineer is completely satisfied with his code. At that time, other tools, like the automatic test, build and integration systems kick in. These tools do not require the same level of interaction that the IDE provides and they are often executed as scripted batch jobs.

Eclipse

Eclipse is an open source IDE with an open and extensible plugin system. It is an open platform that nurtures a thriving community of companies and volunteers who use Eclipse as the foundation for their projects.

Whatever revision control system you use, whatever programming or scripting languages you use, whatever issue tracker you use, there is a very good chance that you will find support in one of over a thousand available plugins. Each team can configure their own flavor of Eclipse, tailored to their specific needs.
With the introduction of Eclipse, IDEs are no longer proprietary closed systems. Support is not limited to a monopolist vendor: hundreds of companies and contractors provide support and build custom plugins.

Eclipse for hardware development

IDEs are a self-evident choice for software development. Even in EDA-land, Eclipse is omnipresent for embedded software development. The list of official Eclipse Associate and Solution Members includes such companies as Mentor Graphics, Altera, Xilinx, Tensilica, ARM, Ericsson, Freescale Semiconductors, Nec and Intel. Both major FPGA vendors, Xilinx and Altera, use the power of Eclipse as an open platform for the development of their embedded software development tools. So -- why is it not used for hardware design?

Sigasi's VHDL plugin for EclipseSigasi's VHDL plugin for EclipseIn hardware design, there is no big culture that uses IDEs. Quite the contrary: some early IDE attempts were overly complex and locked in the customer. There was not enough control over the project build cycle (simulation and synthesis) and people were disappointed with the new user interface, which over-emphasized the use of a mouse over keyboard shortcuts. These experiences have scared away some electronics engineers from IDEs in general, which is a shame.

For EDA vendors with a near monopoly position, closed systems have been ideal to lock-in their users. Hence, they were not motivated to plug their tools into an open, collaborative system. However, since EDA companies do not have a track record of building intuitive graphical user interfaces (GUI), they should seriously consider moving their tools to Eclipse. This would be a win-win situation for both the EDA tool users and the EDA vendors. The users get a well-thought-out user interface that allows for extensive customization, while, on the other hand, the EDA vendors are able to focus on their core competence: writing EDA software.

Another reason why so few hardware designers use Eclipse today is the scarcity of EDA plugins. Recently, only a few open source projects existed that made a fair attempt at providing a plugin for hardware description languages. However, now that Sigasi has released its Hardware Development Toolkit (HDT) as an industry ready Eclipse plugin, the tipping point has been reached.
More and more, the industries of EDA and electronics are discovering Eclipse and are slowly embracing it.

Where to from here?

As increasingly more EDA tools become available as Eclipse plugins, Eclipse truly becomes the central cockpit for hardware developers, complete with a nice head-up display. Instead of learning to use several different tools with different keyboard shortcuts and GUI conventions, engineers will only have to face a single, smooth learning curve. Eclipse is a future proof platform that allows you to tailor your design environment to your specific needs.
Now is the moment to take some time to reevaluate IDEs for hardware design. Go download Eclipse, explore the plugins, and experience the power of a state-of-the-art hardware development cockpit.

What do you use for your hardware design? What do you think the future will bring? Let us know the comments section.

The most needed EDA innovation

Regular readers of my blog may be wondering what I have been doing during the past decade.
I have been talking about EDA innovations, both those that succeeded and those that didn't. But I realize that all technologies that I discussed may sound like old news, coming from the nineties of the previous century.

However, we are 2010 by now. Therefore, some of you may think that I am overlooking or underestimating the more recent innovations that are happening before my eyes. What about Constrained Random Verification? Assertion-based Design? SystemC? C-Based High-Level Synthesis?

I could try to defend myself by claiming, as I did in my previous blog posts, that I simply haven't seen a truly disruptive innovation yet. You could then subtly point out that perhaps I'm losing the sense for innovations, as I am growing older and no longer involved in day-to-day design work. These would all be reasonable arguments. However, I believe the honest answer is the following: in the past decade, I have been losing interest in the technological innovations in EDA. That is because I'm unhappy with the overall direction in which it has been going.

Let me explain with an example. Suppose you want to set up a state-of-the-art development flow for digital design. There is a good chance that you'll take a look at SystemVerilog, supposedly a standard that has all the newest technologies. The reality will be rather disappointing. Before you find out what parts of SystemVerilog are exactly supported by which vendor, and how you should use them, you will already have spent lots of money. Think I'm exaggerating? Then read this recent blog post from JL Gray, who certainly knows these matters better than I do.

More and more, innovation in EDA seems to be a matter of the happy few. It's worse than that actually: when access is restricted like that, we can't even be sure that those innovations are real. It becomes a matter of trust in authority instead of self-judgement. This is not the EDA that I like.

Look at how different things are in the software development world. From the smallest hobbyist to the largest engineering department in a high-profile company: we all have access to the same powerful and innovative tools: languages, compilers, IDEs, revision control systems, and methodologies. And this is not just about open source, but about a whole continuum of solutions and business models. For example, a platform like Eclipse maximizes reuse by easily accomodating both open and closed source third party plugins. As an other example, look at how successful companies like Apple and Google manage to mobilize thousands of third-party developers for their proprietary platforms.

In my opinion, EDA needs business models like those found in the software development industry. Rather than technology, those are the kind of innovations that I'm looking out for.

Syndicate content