boldport

[saar drimer]

In a bit of a self promotional move, though probably pretty relevant
to this group, I'd like to mention

http://www.boldport.com

which I released on Monday, and

https://www.boldport.com/docs/fpgaproj

for easing the migration from GUI to command-line use of FPGA tools,
and more effective project/build management.

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.

Thanks for your attention,
saar.

 

[Alessandro Basili]

On 5/5/2011 12:58 PM, saar drimer wrote:

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!

saar.

 

[saar drimer]

On Jun 27, 1:08 pm, Alessandro Basili <alessandro.bas...@cern.ch>
wrote:

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.

I understand that we do agree that scripted flows are better, so
there's no need to argue. My view is that that horse is running out of
steam in the face of progress in development methods and complexity.
I'm not saying "nice to have", I'm saying that scripted flows are
*essential* if we want to adopt any of the good stuff that software
development has benefited from in the past decade. I'm talking about
revision control, transparent IP/code reuse and distribution,
modularity, team-based design, and so on. I also don't think it's the
"market" that's made a choice, it's the vendors that have bet on the
wrong horse. I've elaborated on this a bit here:

https://www.boldport.com/blog/?p=369

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.

That's a separate issue of generic vs architecture-specific design,
which I've not gotten into in the context of the structure I'm
proposing. Or, rather, I'm not arguing for either side.

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!".

OK.

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.

They sure do. 10 million is about two orders of magnitude off from my
rough estimate for the potential user space. But the answer is that I
don't know... I'll first deal with 10, then 100 and then see how
things go.

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?

I'm conscious of this, and am doing my best to minimise lock-in, now
and for the future (see here: https://www.boldport.com/blog/?p=103 ).
Of course, there's a certain investment of resources in learning /
adopting anything -- my hope is that what I'm proposing / offering has
enough benefit for people to make that investment. Maybe I'm wrong;
I'm testing my hypothesis right now.

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?

No; that's why I've written that long document. I tried to provide
reasoning behind every choice I made, hoping to get feedback and
revise as needed.

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!).

Yes.

That is why IMHO we should foster good designing approaches that will
enhance the portability in terms of code, as opposed to project structure..

I don't see a reason why we can't have both.

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!

Your feedback is greatly appreciated! I'm happy to continue this
discussion here or privately.