In a bit of a self promotional move, though probably pretty relevant to this group, I'd like to mention
formatting link
which I released on Monday, and
formatting link
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.
which reminded me why your post didn't get much of a feedback even though I found the content rather interesting.
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!".
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.
Believe me, even though I might have sounded harsh, I paid a lot of attention to it!
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:
formatting link
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.
OK.
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.
I'm conscious of this, and am doing my best to minimise lock-in, now and for the future (see here:
formatting link
). 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.
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.
Yes.
.
I don't see a reason why we can't have both.
:)
Your feedback is greatly appreciated! I'm happy to continue this discussion here or privately.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.