4 ms·

I went to CMU for a BS in EE, I used a lot of verilog, and also a bit of Cadence for layout in one class. But I've worked as a software engineer since then. I

by ploxiln 10y ago

I went to CMU for a BS in EE, I used a lot of verilog, and also a bit of Cadence for layout in one class. But I've worked as a software engineer since then. I totally agree that HDL tools are astonishingly crap. The market is just so much more specialized, expensive, locked down and closed. Imagine that you had to use the Intel compiler to get source code compiled for intel processors. You had to use their special headers, you practically had to use their huge 8GB Intel IDE with a million lists and buttons, you had to choose what features were on your intel processor (VT-X? SSE4?). Imagine AMD is the same, but separate. This is all closed source stuff of course. And you have to use it to run on any smartphone/laptop/desktop/server class processor. Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. All the related tools we use wouldn't have much of a reason to exist because just about everyone had to use the huge IDEs for each vendor anyway. The vendor stuff is huge and inefficient and crap, because features sell, and crap doesn't not sell because there's no meaningful competition. To be more specific, "crap" means high bloat and low reliability. Crashes, inexplicable errors and failures. Huge amounts of bloat. But you can make a tweak and try again move on, so any sane hardware person just gets used to it, it's not like they can do anything about it.

metaphor 10y ago
Apologies but I really can't tell if your point is against the proprietary nature of reconfigurable devices, or vendor tool bloat. > Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. This is quite easy to imagine when you remove the key element which allows these L7 abstractions to be meaningful: an underlying kernel with a well defined interface. What equivalence does the reconfigurable world have when every target device requires its own unique "kernel", if you will? I can't think of any...which would explain why 3rd-party tools are constrained to synthesis, while place-and-route is an explicit function of the vendor tool. Perhaps we too easily conflate the size of the tool with the size of the target? On the flip side, supposing there were some open reconfigurable interface standard, I don't think this would fly in the current market given the high-performance nature of these devices. Top two FPGA vendors apparently change slice/CLB structure every generation, let alone agree on an open fabric interface standard. > Crashes, inexplicable errors and failures. Huge amounts of bloat. Putting the whole kit and kaboodle aside and focusing on just synthesis, isn't it strange that even the big, specialized 3rd party vendor tools (e.g. Cadenace, MG, Synopsis) suffer just as much? I think it's a genuinely difficult problem given the multi-disciplinary nature of the things EDA engineers have to deal with. As much as I dislike dealing with flake tools, I'm nevertheless humbled by their challenges.
- gluggymug 10y ago
  You've pretty much hit the nail on the head. What people outside of the EDA field fail to understand is they are coding at a much higher level. RTL does not model all the aspects of the logic. You have different signal delays due to lots of different reasons: fanout, wire lengths etc. As you go through different stages of synthesis via these tools, a lot of decisions are made governed by the constraints files. Each decision affects the performance of the design. It's slow because it's doing a lot of work to optimize speed or area. Some designs won't fit the constraints. Then it reports errors. The tools are trying to help. The end product is the physical device. The various models are all just abstractions of the physical device. The tools are reporting the problems on the abstractions to assist you to improve the physical device. If you can understand the reports, you can improve things, either altering the RTL or adding more constraints. The point being that the only time RTL is actually run like a software program is during simulation. This simulation is only an approximation of how the actual thing will work. It is not like SW. The tools do a lot of other things with that RTL. Maybe if people don't throw garbage in, it wont crap itself trying to figure it all out.
pjmlp 10y ago
> Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. All the related tools we use wouldn't have much of a reason to exist because just about everyone had to use the huge IDEs for each vendor anyway. I don't need to imagine, none of them existed when I started programming.
pawadu 10y ago
> The vendor stuff is huge and inefficient and crap Thankfully, we now have a pretty decent open source alternative: http://www.clifford.at/icestorm http://www.clifford.at/icestorm and you are welcome to contribute!
- metaphor 10y ago
  Interesting project, but it hardly qualifies as "a pretty decent open source alternative" considering it targets a single family of FPGAs from a vendor with comparatively insignificant market share. P.S. The only dabblings I've had with Lattice devices was designing a custom tool to configure legacy (pre-JTAG) ispLSI family of CPLDs using our tech, not theirs. Goal was to eliminate their obsolete tool chain (ispLever Classic and piece of shit USB dongle) from the configuration management loop for existing stable applications in longterm lifecycle sustain mode.
digler999 10y ago
> Crashes, inexplicable errors and failures. I bought a xilinx spartan dev board 10 years ago and it was just like this. ISE was 4gb of java bloatware, 2 gb (!) more of "updates", crashed frequently, barely ran, imploded under its own weight. I managed to make some lights go blinky and said "eff this". It's sad to hear that 10 years later nothing has changed.

by ploxiln 10y ago

metaphor 10y ago

Apologies but I really can't tell if your point is against the proprietary nature of reconfigurable devices, or vendor tool bloat. > Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. This is quite easy to imagine when you remove the key element which allows these L7 abstractions to be meaningful: an underlying kernel with a well defined interface. What equivalence does the reconfigurable world have when every target device requires its own unique "kernel", if you will? I can't think of any...which would explain why 3rd-party tools are constrained to synthesis, while place-and-route is an explicit function of the vendor tool. Perhaps we too easily conflate the size of the tool with the size of the target? On the flip side, supposing there were some open reconfigurable interface standard, I don't think this would fly in the current market given the high-performance nature of these devices. Top two FPGA vendors apparently change slice/CLB structure every generation, let alone agree on an open fabric interface standard. > Crashes, inexplicable errors and failures. Huge amounts of bloat. Putting the whole kit and kaboodle aside and focusing on just synthesis, isn't it strange that even the big, specialized 3rd party vendor tools (e.g. Cadenace, MG, Synopsis) suffer just as much? I think it's a genuinely difficult problem given the multi-disciplinary nature of the things EDA engineers have to deal with. As much as I dislike dealing with flake tools, I'm nevertheless humbled by their challenges.

gluggymug 10y ago
You've pretty much hit the nail on the head. What people outside of the EDA field fail to understand is they are coding at a much higher level. RTL does not model all the aspects of the logic. You have different signal delays due to lots of different reasons: fanout, wire lengths etc. As you go through different stages of synthesis via these tools, a lot of decisions are made governed by the constraints files. Each decision affects the performance of the design. It's slow because it's doing a lot of work to optimize speed or area. Some designs won't fit the constraints. Then it reports errors. The tools are trying to help. The end product is the physical device. The various models are all just abstractions of the physical device. The tools are reporting the problems on the abstractions to assist you to improve the physical device. If you can understand the reports, you can improve things, either altering the RTL or adding more constraints. The point being that the only time RTL is actually run like a software program is during simulation. This simulation is only an approximation of how the actual thing will work. It is not like SW. The tools do a lot of other things with that RTL. Maybe if people don't throw garbage in, it wont crap itself trying to figure it all out.

pjmlp 10y ago

> Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. All the related tools we use wouldn't have much of a reason to exist because just about everyone had to use the huge IDEs for each vendor anyway. I don't need to imagine, none of them existed when I started programming.

pawadu 10y ago

> The vendor stuff is huge and inefficient and crap Thankfully, we now have a pretty decent open source alternative: http://www.clifford.at/icestorm http://www.clifford.at/icestorm and you are welcome to contribute!

metaphor 10y ago
Interesting project, but it hardly qualifies as "a pretty decent open source alternative" considering it targets a single family of FPGAs from a vendor with comparatively insignificant market share. P.S. The only dabblings I've had with Lattice devices was designing a custom tool to configure legacy (pre-JTAG) ispLSI family of CPLDs using our tech, not theirs. Goal was to eliminate their obsolete tool chain (ispLever Classic and piece of shit USB dongle) from the configuration management loop for existing stable applications in longterm lifecycle sustain mode.

digler999 10y ago

> Crashes, inexplicable errors and failures. I bought a xilinx spartan dev board 10 years ago and it was just like this. ISE was 4gb of java bloatware, 2 gb (!) more of "updates", crashed frequently, barely ran, imploded under its own weight. I managed to make some lights go blinky and said "eff this". It's sad to hear that 10 years later nothing has changed.