In a bit of a self promotional move, though probably pretty relevant
to this group, I'd like to mention
[snip]
As a reminder and a caution for future posting:
http://www.faqs.org/faqs/usenet/advertising/how-to/part1/
which reminded me why your post didn't get much of a feedback even
though I found the content rather interesting.
for easing the migration from GUI to command-line use of FPGA tools,
and more effective project/build management.
I want to say that I'm on your side when you say that a "command-line"
use of FPGA tools is a nice to have, but I have to admit that the
overall tendency is to use GUI and integrated environments where the
designer has the (deceived) perception that everything is at his own
hand and control.
We can argue a lifetime on what is better, but IMHO the market has
chosen its horse and is not the command-line, regardless efficiency
drawbacks.
The portability problem is often used as an argument to propose yet
another model that will have eventually the same problems of portability
that previous models had. That is why I always intend portability in the
sense that is easy to carry around for it doesn't depend on system's
features or device's features and ultimately tool's features.
In addition I believe most of the designers out there are not really
moving from a linux machine to a windows machine every day and they
don't switch from an ABC device to a CBA device every other day and
whenever they would be in the place where they *have to* switch, it's
going to be a hard day and no magic can be at hand but a previously
thought through approach to design in an as abstract way as possible.
Hardware Description Languages have been invented for good because they
give the designer a mean which will help him looking at the big picture
instead of the gates and flops actually used. And this level of
abstraction has an enormous potential that most of the time is
overlooked in the names of concepts like "optimization" or "I had to put
that GCLK buffer otherwise it wouldn't work!".
The project is at an early stage, and more features will be added with
time. Praise, constructive feedback, and well-mannered bashing are
welcome, of course... be as honest as this group knows how to be (feel
free to email me privately as well). Finally, I'm looking for early
adopter projects, and offer my help with the setup.
Talking about scalability problems, how do you intend to provide help on
the long run? Say you have 10 million users instead of 10, I think
numbers do play a difference.
On top of it, what make your company different from yet another EDA
company willing for designers to adopt their approach and strangle them
with incompatibility features that will shackle them for the rest of
their life?
Since is not open-source and is profit oriented, do you think it's
enough to say that your approach "is better" to convince designers to
change their habits?
After all a designer wants to design as much as a painter wants to
paint. If art can be made with any tool available in your garage,
hardware can follow the same line and be built with just an editor or
any available tool you have in your computer (maybe a text editor is
enough!).
That is why IMHO we should foster good designing approaches that will
enhance the portability in terms of code, as opposed to project structure.
The project approach is borrowed from the management world and has
nothing to do with HDL. Indeed I always asked myself why should I create
a project when my goal is to describe how a piece of hardware should
work. "Project" is a name poorly defined, a concept poorly defined, with
no boundaries and no constraints and that is the root of all your and
our problems.
Thanks for your attention,
Believe me, even though I might have sounded harsh, I paid a lot of
attention to it!