Why hardware designers should switch to Eclipse

[M. Norton]

A steep learning curve is a Good Thing.  If it was shallow, it would
take you a very long time to learn it.

Alright, you got me. I used the phrase in a vernacular way
without being terribly precise. Let me be specific.

With emacs, coming at it with little to no prior knowledge, there are
a great many skills that need to be acquired to become proficient with
merely editing text, let alone achieving the productivity required to
achieve success in a reasonable amount of time for a complex HDL
project, in particular compared to a text editor whose interface that,
through use of various other common text editing utilities and
applications, might be relatively intuitive.

With Sigasi, at least upon light inspection, I thought it had a great
many features that might be useful for the casual HDL designer without
the necessity of becoming fully proficient with emacs. I believe
emacs is probably the superior environment, not the least of which is
the FOSS nature of the software compared with the Sigasi, but it is
not a trivial task to learn it.

I didn't try Sigasi with anything very large, and I did not try to
customize it. I stepped through the tutorial/feature list, thought
"hey that's interesting" and went back to my development in emacs. I
would hope that the Sigasi developers are reading this thread and
noticing all the complaints from others and considering ways to
mitigate those experiences. Still simply because I do not need the
features at the price doesn't mean no one would find value with it,
which is all I was trying to express originally.

As for the "steep learning curve" comment, I did a little research on
Google and it's an interestingly common mis-use of the concept so I'll
have to find some other way of saying what I intended to say .

Mark Norton

 

[John_H]

Think about it.  When you graph the learning curve, what are the axes?

uhhh.... "steep learning curve" is a bad thing. The axis aren't
knowledge gained versus time but knowledge required versus competence.

It's not like a "quantum improvement" where a quanta is the lowest
measurable unit. Learning curves haven't been misused in this
engineer's opinion. Perhaps until now.

 

[Gabor]

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.

I've published a white paper on this subject.http://www.sigasi.com/content/why-hardware-designers-should-switch-ec...
I'd be interested to know what you guys think.

kind regards

Philippe Faes
Founding CEO Sigasihttp://www.sigasi.com

Any plans to support the other half of hardware developers in
the Verilog camp? Most of my projects are either all Verilog
or mixed VHDL / Verilog. For just code entry I either use
the chip-vendors brain-dead editor, which at least highlights
known device primitive names so I don't need the Libraries
Guide every time I instantiate them, or I use MED with my
own language customizations.

Regards,
Gabor

 

[Philippe]

Any plans to support the other half of hardware developers in
the Verilog camp?

We do want to support Verilog and SystemVerilog in the future.
However, for now we concentrate on VHDL.
http://www.sigasi.com/faq/what-about-systemverilog-and-other-languages

Philippe

 

[Andy Peters]

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.

I've published a white paper on this subject.http://www.sigasi.com/content/why-hardware-designers-should-switch-ec...
I'd be interested to know what you guys think.

kind regards

Philippe Faes
Founding CEO Sigasihttp://www.sigasi.com

I'm another long-term emacs user. Eclipse is the standard environment
for the Xilinx SDK and I quickly discovered that I did not like it.
It's slow, and completely non-obvious, and has a lot of hidden
directories and files in the project directories and at least in the
Xilinx-specific environment I had no idea which of those magic files
were actually important to the build process and which were cruft.
(And Xilinx didn't have a good answer.)

You want a good IDE for C programming? Apple's Xcode. I am not
kidding.

But for VHDL, nothing beats emacs and Reto's vhdl-mode. And why should
I pay to get something that doesn't do nearly what emacs/vhdl-mode
does?

-a

 

[Nico Coesel]

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.

I couldn't agree more. I have read the other responses but what I read
there is: I don't know Eclipse and I don't want to learn. I used to be
among those until I gave Eclipse a good try.

After getting used to the not so obvious layout and terms I understood
the underlying ideas which are really nifty. Nowadays I develop
everything with Eclipse because it helps me to keep a good overview on
my projects.

 

[Nico Coesel]

Hi Alan,

I've been using Makefiles and Emacs for many years. Using Eclipse I
have to search the hierarchy of perspectives, menus, tabs, etc. to
click a button in order to add -Os to CFLAGS for gcc!

Also I don't like the concept of workspaces which are using files and
directories in a fixed place in the file system (even it it's your
home directory). I like to check out my design (being software or HDL)
from a revision control system anywhere and build it there, which
means using relative pathnames.

Not true. Your can check out a project in any place and Eclipse will
be perfectly happy since it will recreate the makefiles before
building.

 

[whygee]

I've published a white paper on this subject.
http://www.sigasi.com/content/why-hardware-designers-should-switch-eclipse
I'd be interested to know what you guys think.

Philippe Faes
Founding CEO Sigasi
http://www.sigasi.com

everybody preaches for his own church ;-)

yg

 

[whygee]

BLOOOAAAATTTEEEEDDDDD

oh yes, that too.

Eclipse is painful to use for me. I'm a Vi guy.

Let the Vi/Emacs wars ensue

anyone with me in favor of nano ?

yg

 

[Patrick Maupin]

After getting used to the not so obvious layout and terms I understood
the underlying ideas which are really nifty.

There's a term for that: "Stockholm Syndrome"

 

[Nico Coesel]

There's a term for that: "Stockholm Syndrome"

Ah, no well-founded remarks so I must be right.

 

[Patrick Maupin]

Ah, no well-founded remarks so I must be right.

No, seriously. "After getting used to the not so obvious layout" = "I
used to think it was crap"

but then, later: "I understood the underlying ideas which are really
nifty." = "I underwent a religious conversion."

Now this is partway tongue-in-cheek, but when you start off by
spouting bullshit like "I have read the other responses but what I
read there is: I don't know Eclipse and I don't want to learn." I
really don't know what kind of a response you expect, because that's
not a real argument either, just projection about your experience. In
short, that's your *interpretation* of what people wrote, and so my
*response* to your provocative interpration of what others wrote is
that my *interpretation* of what you wrote is that the Borg has taken
over your brain.

My experience is that the most highly technical people are most
comfortable with an editor and a command line. A good software
analogue for RTL development is something like Linux Kernel Hacking.
There are several guides for this, for example:

http://kernelnewbies.org/KernelHackingTools

The only guides where somebody talks about using an IDE are for some
embedded crap like code warrior where the vendor is pushing their IDE
to people who are on the fringe of development. An IDE can be useful
for somebody who doesn't want a deep understanding of some piece of
code and just wants to go in and make a change. However, I don't want
that person working on my hardware!!!

Regards,
Pat

 

[Nico Coesel]

No, seriously. "After getting used to the not so obvious layout" =3D "I
used to think it was crap"

but then, later: "I understood the underlying ideas which are really
nifty." =3D "I underwent a religious conversion."

Now this is partway tongue-in-cheek, but when you start off by
spouting bullshit like "I have read the other responses but what I
read there is: I don't know Eclipse and I don't want to learn." I
really don't know what kind of a response you expect, because that's
not a real argument either, just projection about your experience. In

My experience is that people don't like change and like to stay stuck
in old unproductive methods. Sometimes you need to push people
forward.

to people who are on the fringe of development. An IDE can be useful
for somebody who doesn't want a deep understanding of some piece of
code and just wants to go in and make a change. However, I don't want

Thats rubbish. Perhaps true for the simple IDEs intended to give
people a quick start. I don't like those either.

Eclipse is a whole other story though. It is designed to aid working
on complex projects. I have several projects that share a common code
base and some of those projects result in 10 to 20 slightly different
binaries. Eclipse helps me to organize such projects. A makefile
keeping all the defines and projects definitions apart would be a
nightmare. And that is besides the many aids Eclipse provides like
having a list of types, variables, defines and functions from a file,
showing call hierarchies, shading parts that are not getting compiled,
refactoring (renaming symbols), comparing versions from a version
control repository, etc, etc.

Ofcourse you can do all this with a command line tools but it is way
less productive and more prone to errors than having everything
presented to you in a GUI. I never liked developing while peeking
through a key-hole. When I need to work on an software project I
always load the source into Eclipse because it allows me to examine
the structure of a piece of software very quickly. Where is this
function called from? Just open the call hierarchy. What is this
define? Just move over it with the mouse pointer. Where is the define
or symbol declared? Shift-click and you'll have the answer. Open a .h
file for examination by shift-clicking on it.

Not to mention debugging. Its all there. And I forgot the best thing:
Eclipse works the same way for different languages. Writing and
debugging a C/C++ program works the same way as debugging a PHP
script. Eclipse is about learning one workflow and apply it to any
language.

Bottom line is: I really wish Xilinx would drop ISE and move on to
Eclipse. ISE is a typical example of an IDE that is intended to get a
quick start but runs out of air very quickly.

 

[whygee]

My experience is that people don't like change

My experience is that people apreciate things that work
and does not distract them from their work. Re-learning,
re-configuring, re-mastering new tools all the time
is what makes engineering a terrible job today.

and like to stay stuck
in old unproductive methods.

If it works, it's productive.
Then why would there be a thread on comp.arch.fpga
about someone selling his own old tools ?

Sometimes you need to push people forward.

yeah, obsolete their tools and force them to switch,
renew the license and get some more cash from the cow.

Ofcourse you can do all this with a command line tools but it is way
less productive and more prone to errors than having everything
presented to you in a GUI.

but you can't automate a GUI.
where is my productivity when I have to spend minutes
clicking on dialogs, on boxes and on "OK" buttons
everytime I recompile my VHDL in Actel's Libero ???
oh, and because it's a rather complex piece of pieces of SW,
I have to _wait_ for each tool to complete, before I am
allowed to click on the next dialog for the next tool in the chain.

> Bottom line is: I really wish Xilinx would drop ISE and move on to
Eclipse. ISE is a typical example of an IDE that is intended to get a
quick start but runs out of air very quickly.

so you propose to replace it with another ... bloated interface ?
Oh yest it's based on Java so it must be much better...

yg

 

[Patrick Maupin]

My experience is that people don't like change and like to stay stuck
in old unproductive methods. Sometimes you need to push people
forward.

My experience is that learning a new tool is only worthwhile if you
are going to use it a LOT and gain a LOT from it. My experience is
also that a cursory examination of a tool can usually give you a
reasonable feel for whether this is going to happen or not.

Thats rubbish. Perhaps true for the simple IDEs intended to give
people a quick start. I don't like those either.

See, those are the ONLY ones I like.

Eclipse is a whole other story though. It is designed to aid working
on complex projects. I have several projects that share a common code
base and some of those projects result in 10 to 20 slightly different
binaries. Eclipse helps me to organize such projects. A makefile
keeping all the defines and projects definitions apart would be a
nightmare. And that is besides the many aids Eclipse provides like
having a list of types, variables, defines and functions from a file,
showing call hierarchies, shading parts that are not getting compiled,
refactoring (renaming symbols), comparing versions from a version
control repository, etc, etc.

No, the nightmare is finding the configuration button to set the
project exactly right. IMHO, if you delegate the complex stuff to an
engine like this, you lose control over it rather than gain control.
And once again, I will refer you to Linux -- is your project really
more complicated, with more options, than the kernel? Do you really
think all the kernel hackers are Luddites?

Ofcourse you can do all this with a command line tools but it is way
less productive and more prone to errors than having everything
presented to you in a GUI. I never liked developing while peeking
through a key-hole. When I need to work on an software project I
always load the source into Eclipse because it allows me to examine
the structure of a piece of software very quickly. Where is this
function called from? Just open the call hierarchy. What is this
define? Just move over it with the mouse pointer. Where is the define
or symbol declared? Shift-click and you'll have the answer. Open a .h
file for examination by shift-clicking on it.

You haven't described anything in this paragraph that can't be done
with a decent modern editor.

Not to mention debugging. Its all there. And I forgot the best thing:
Eclipse works the same way for different languages. Writing and
debugging a C/C++ program works the same way as debugging a PHP
script. Eclipse is about learning one workflow and apply it to any
language.

Ahh, THERE is a difference between editors and IDEs. Yes, debugging.
Well, I write most of my software in Python and spend very little time
debugging. Most of my Verilog tests are self-checking, and I
sometimes look at waveforms, but very little else. I don't think I
have personally set a breakpoint in about 15 years, since I used to
have to write C/C++, so this is not very high on my priority list (and
wasn't really that high back when I WAS writing C). But I do know a
lot of people who start off writing really crappy software and then
debug it into shape, and most of them DO swear by their IDEs.

Bottom line is: I really wish Xilinx would drop ISE and move on to
Eclipse. ISE is a typical example of an IDE that is intended to get a
quick start but runs out of air very quickly.

While I think ISE has a lot of room for improvement, I think it's
really pretty good for what I want -- get a quick start, then copy the
command lines over to a real, text-based, diffable, version controlled
batch environment.

Having said that, the primary reason I even use ISE for this task is
because some of Xilinx's documentation really, REALLY sucks. For
example, try to find documentation on using impact in batch mode to
generate ACE files. It exists -- as an unorganized collection of HTML
one-liners designed to be invoked as help files from within impact GUI
mode.

Of course, one probable reason for that is that somebody started to
document how impact works in batch mode, and gave up because the
software sucks so badly that you can't accurately describe its
behavior without calling attention to just how bad it really is.

Regards,
Pat

 

[Nico Coesel]

My experience is that learning a new tool is only worthwhile if you
are going to use it a LOT and gain a LOT from it. My experience is
also that a cursory examination of a tool can usually give you a
reasonable feel for whether this is going to happen or not.

Which is why Eclipse is such a fine tool: it supports a lot of
languages and platforms so you'll need to learn one tool and get going
with many languages and platforms.

See, those are the ONLY ones I like.


No, the nightmare is finding the configuration button to set the
project exactly right. IMHO, if you delegate the complex stuff to an
engine like this, you lose control over it rather than gain control.
And once again, I will refer you to Linux -- is your project really
more complicated, with more options, than the kernel? Do you really
think all the kernel hackers are Luddites?

Yes, they are. My job includes kernel hacking and I'm finding the
total lack of proper documentation, comments and the obfusticated C++
objects simulation in C a big hurdle. IMHO the audio handling in the
Linux kernel is a complete mess. Kernel hackers may like the Linux
kernel the way it is now but in reality it is a cow's turd you want to
stir in as little as possible.

You haven't described anything in this paragraph that can't be done
with a decent modern editor.

In that case Eclipse contains a decent modern editor.

Ahh, THERE is a difference between editors and IDEs. Yes, debugging.
Well, I write most of my software in Python and spend very little time
debugging. Most of my Verilog tests are self-checking, and I
sometimes look at waveforms, but very little else. I don't think I
have personally set a breakpoint in about 15 years, since I used to
have to write C/C++, so this is not very high on my priority list (and

I wonder how much time you spend on finding a typo. A debugger is most
helpfull in those cases. I use the debugger mostly for verification so
I'm absolutely sure my software does what it is supposed to do and not
that the answer seems right.

Of course, one probable reason for that is that somebody started to
document how impact works in batch mode, and gave up because the
software sucks so badly that you can't accurately describe its
behavior without calling attention to just how bad it really is.

LOL!