boldport

Discussion in 'VHDL' started by saar drimer, May 5, 2011.

  1. saar drimer

    saar drimer Guest

    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.
    saar drimer, May 5, 2011
    #1
    1. Advertising

  2. 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.
    >
    >
    Alessandro Basili, Jun 27, 2011
    #2
    1. Advertising

  3. saar drimer

    saar drimer Guest

    On Jun 27, 1:08 pm, Alessandro Basili <>
    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.
    saar drimer, Jul 5, 2011
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page