5 ms·

> I feel that this kind of comment is a pure misconception from software people that gets echoed time after time in HN. but this is NOT a misconception. Show

> I feel that this kind of comment is a pure misconception from software people that gets echoed time after time in HN. but this is NOT a misconception. Show them actual tools that constantly crash and lag on you, that demand checking out licence for a runtime which costs 5-100k/Year, show them environment in which we have to write our code - they will laugh at you. This was exactly the state of the software industry 30 years ago and this industry is long past that stage.

sweden 7y ago
Those are some very empty counter arguments but I will try to answer them anyway. EDA tools are expensive, yes. But you are not just paying for the tools, you are paying for all the engineering support being those tools. Bugs and problems happen in any development tool and those companies are ready to pick up the phone at any time of the day to help you with anything you might face, whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. And they have actual engineers on the other end of the line who know the product like the palm of their hand. While this might sound superficial, it is extremely important when you are racing towards a $100M dollar deadline for your project.
- jdc 7y ago
  > EDA tools are expensive, yes. But you are not just paying for the tools, you are paying for all the engineering support being those tools. So I can buy the tool without the support contract? > Bugs and problems happen in any development tool [...] So it's automatically a wash? Why bother trying to improve things if there will always be bugs, right? > [...] whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. I'm not impressed. This is a kludge. > And they have actual engineers on the other end of the line who know the product like the palm of their hand. Okay, that actually sounds pretty nice.
  - sweden 7y ago
    > So I can buy the tool without the support contract? Probably not but it's not something you would like to. Cutting corners is a really bad idea when it comes to hardware development because once it is out there, there is not going back. Having access to a professional engineering work force that knows how the tool works and know it will ready and interpret the Verilog and process it can make a difference between a 5 minutes delay and 2 week delay in the project. > So it's automatically a wash? Why bother trying to improve things if there will always be bugs, right? You are distorting my words. I'm not saying that we should be complacent and just accept incompetence.
  - buckminster 7y ago
    >> [...] whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. > I'm not impressed. This is a kludge. So how would you handle it? Tell the customer you'd love to fix their problem but they have to wait for the next formal release?
- rcxdude 7y ago
  The level of quirkiness and bugginess in the tools is on another level to most software tools. You shouldn't need access to the engineers who built it in order to make it work, this basically increases costs and barrier to entry massively.
  - ip26 7y ago
    Many of the tools are bleeding edge, developing new features to support a new process node at the same time as the new process node is being developed.
    - rcxdude 7y ago
      This doesn't seem relevant to most of the tooling, which is not bleeding edge, and should be mature.
    - gchadwick 7y ago
      Certainly on the simulator/synthesis side you can still encounter straight-forward bugs in SystemVerilog features that were standardized over a decade ago (or find they're not implemented at all) or even simple parsing bugs (the kinds of bugs that would be trivial to find with some decent randomised testing of the parser). Things being bleeding edge and fast evolving in certainly true for some EDA tools or parts of them but there's lots of more bread and butter stuff that never feels quite right.
    - jfkebwjsbx 7y ago
      That is no excuse. A lot of software out there is bleeding edge, yet costumers do not tolerate crashes.
      - api 7y ago
        Sure, that's why important software never crashes. /sarcasm
        jfkebwjsbx 7y ago
- rsynnott 7y ago
  I mean, this sounds a lot like software 20 years ago. You can still get proper support for, say, IntelliJ if you want it, but tools and ecosystem have improved so much that it’s just not as important as it used to be. To be clear, I’m not claiming that hardware development is the same as software development. It’s not. It has different problems. But the tooling _does_ seem well behind.
  - ardy42 7y ago
    > You can still get proper support for, say, IntelliJ if you want it, but tools and ecosystem have improved so much that it’s just not as important as it used to be. How many people are doing hardware verification work vs. cranking out webapps with IntelliJ? JetBrains can invest a lot in software ergonomics because they're basically selling mass-market software. If you have sophisticated but niche software, your probably going to invest your engineering effort into the it's capability rather than its ergonomics.
    - rsynnott 7y ago
      I mean, to take one example of a company in the space: Xilinx has operating income of about 750mn per year. Jetbrains has operating income of about 80mn per year on revenues of 250mn. Given that I’d suggest that the reason that Xilinx’s development products have such a poor user experience vs IntelliJ is NOT that Xilinx is impoverished, but rather that the market has extremely low expectations so they don’t feel the need to spend on fixing them. This isn’t a problem unique to hardware-land; lots of verticals have incumbents who produce low quality products on large profits because, frankly, the competition is just as bad and there’s a high barrier to entry. I’m not sure what would fix this for hardware-land, though. Possibly more pressure from open source; that’s largely what did it for software development (though even before that, companies like Borland put more than the minimum effort in).
      - tails4e 7y ago
        Xilinx are not just writing software, they also must use R&D to develop the FPGA hardware, dev kits, IP, etc, so it's a very different scale to JetBrains' focus. Also in terms of Sofware, the really challenging aspects are under the hood, the place and route algorithms, the static timing engine, the system verilog simulator (which is itself a huge undertaking), the hardware debug cores, the HLS SW that compiles C to accelerated HW, then SDK for embedded processors, oh.. And of course... Finally the GUI/IDE. With all that's going on underneath, Vivado does a decent job of presenting it all in a logical way. I'm blown away that I can see a timing failure on any of a million nets and in a click cros probe it to a line of verilog. As for open source, SystemVerilog is an open standard, yet can you show me an open source simulator that competes with the free one that comes with Vivado?
im_down_w_otp 7y ago
Have you used software verification tools? They're almost universally terrible. In many cases incomprehensibly so. Many are free up front, but you pay for it one way or another. The level of sophistication and workflow integration of software verification tools, compared to hardware verification tools, also seems to lag significantly. I don't doubt that the hardware verification tools are expensive, buggy, and probably have terrible UX. However, all those things are also true of software verification tools, but where license cost is replaced by esoteria and incompleteness cost.
- vvanders 7y ago
  Valgrind is pretty robust and I've seen it integrated into many projects with little fanfare. Unit tests are just simulation runs. I've done VHDL/Verilog and tons of software, the HW tools do lag significantly in my experience.
  - im_down_w_otp 7y ago
    Valgrind is not in the class of verification tools I was referencing. How does it correlate to VHDL/Verilog in this context? I would expect things like MBD tools, model checkers, and proof assistants, and program extractors to be the software pipeline siblings to the kinds of tools that VHDL/Verilog integrate with.
    - vvanders 7y ago
      It's a tool to verify the software runs correctly and doesn't double free, write over the heap and a while bunch of failure. Unless you never run simulation and always trust the router? Not everything gets verified 100% in HW, otherwise we wouldn't have silicon errata. It's all a question of how deep you want to go in verification and what your costs are for screwing it up.

sweden 7y ago

Those are some very empty counter arguments but I will try to answer them anyway. EDA tools are expensive, yes. But you are not just paying for the tools, you are paying for all the engineering support being those tools. Bugs and problems happen in any development tool and those companies are ready to pick up the phone at any time of the day to help you with anything you might face, whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. And they have actual engineers on the other end of the line who know the product like the palm of their hand. While this might sound superficial, it is extremely important when you are racing towards a $100M dollar deadline for your project.

jdc 7y ago
> EDA tools are expensive, yes. But you are not just paying for the tools, you are paying for all the engineering support being those tools. So I can buy the tool without the support contract? > Bugs and problems happen in any development tool [...] So it's automatically a wash? Why bother trying to improve things if there will always be bugs, right? > [...] whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. I'm not impressed. This is a kludge. > And they have actual engineers on the other end of the line who know the product like the palm of their hand. Okay, that actually sounds pretty nice.
- sweden 7y ago
  > So I can buy the tool without the support contract? Probably not but it's not something you would like to. Cutting corners is a really bad idea when it comes to hardware development because once it is out there, there is not going back. Having access to a professional engineering work force that knows how the tool works and know it will ready and interpret the Verilog and process it can make a difference between a 5 minutes delay and 2 week delay in the project. > So it's automatically a wash? Why bother trying to improve things if there will always be bugs, right? You are distorting my words. I'm not saying that we should be complacent and just accept incompetence.
- buckminster 7y ago
  >> [...] whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you. > I'm not impressed. This is a kludge. So how would you handle it? Tell the customer you'd love to fix their problem but they have to wait for the next formal release?
rcxdude 7y ago
The level of quirkiness and bugginess in the tools is on another level to most software tools. You shouldn't need access to the engineers who built it in order to make it work, this basically increases costs and barrier to entry massively.
- ip26 7y ago
  Many of the tools are bleeding edge, developing new features to support a new process node at the same time as the new process node is being developed.
  - rcxdude 7y ago
    This doesn't seem relevant to most of the tooling, which is not bleeding edge, and should be mature.
  - gchadwick 7y ago
    Certainly on the simulator/synthesis side you can still encounter straight-forward bugs in SystemVerilog features that were standardized over a decade ago (or find they're not implemented at all) or even simple parsing bugs (the kinds of bugs that would be trivial to find with some decent randomised testing of the parser). Things being bleeding edge and fast evolving in certainly true for some EDA tools or parts of them but there's lots of more bread and butter stuff that never feels quite right.
  - jfkebwjsbx 7y ago
    That is no excuse. A lot of software out there is bleeding edge, yet costumers do not tolerate crashes.
    - api 7y ago
      Sure, that's why important software never crashes. /sarcasm
      - jfkebwjsbx 7y ago
rsynnott 7y ago
I mean, this sounds a lot like software 20 years ago. You can still get proper support for, say, IntelliJ if you want it, but tools and ecosystem have improved so much that it’s just not as important as it used to be. To be clear, I’m not claiming that hardware development is the same as software development. It’s not. It has different problems. But the tooling _does_ seem well behind.
- ardy42 7y ago
  > You can still get proper support for, say, IntelliJ if you want it, but tools and ecosystem have improved so much that it’s just not as important as it used to be. How many people are doing hardware verification work vs. cranking out webapps with IntelliJ? JetBrains can invest a lot in software ergonomics because they're basically selling mass-market software. If you have sophisticated but niche software, your probably going to invest your engineering effort into the it's capability rather than its ergonomics.
  - rsynnott 7y ago
    I mean, to take one example of a company in the space: Xilinx has operating income of about 750mn per year. Jetbrains has operating income of about 80mn per year on revenues of 250mn. Given that I’d suggest that the reason that Xilinx’s development products have such a poor user experience vs IntelliJ is NOT that Xilinx is impoverished, but rather that the market has extremely low expectations so they don’t feel the need to spend on fixing them. This isn’t a problem unique to hardware-land; lots of verticals have incumbents who produce low quality products on large profits because, frankly, the competition is just as bad and there’s a high barrier to entry. I’m not sure what would fix this for hardware-land, though. Possibly more pressure from open source; that’s largely what did it for software development (though even before that, companies like Borland put more than the minimum effort in).
    - tails4e 7y ago
      Xilinx are not just writing software, they also must use R&D to develop the FPGA hardware, dev kits, IP, etc, so it's a very different scale to JetBrains' focus. Also in terms of Sofware, the really challenging aspects are under the hood, the place and route algorithms, the static timing engine, the system verilog simulator (which is itself a huge undertaking), the hardware debug cores, the HLS SW that compiles C to accelerated HW, then SDK for embedded processors, oh.. And of course... Finally the GUI/IDE. With all that's going on underneath, Vivado does a decent job of presenting it all in a logical way. I'm blown away that I can see a timing failure on any of a million nets and in a click cros probe it to a line of verilog. As for open source, SystemVerilog is an open standard, yet can you show me an open source simulator that competes with the free one that comes with Vivado?

im_down_w_otp 7y ago

Have you used software verification tools? They're almost universally terrible. In many cases incomprehensibly so. Many are free up front, but you pay for it one way or another. The level of sophistication and workflow integration of software verification tools, compared to hardware verification tools, also seems to lag significantly. I don't doubt that the hardware verification tools are expensive, buggy, and probably have terrible UX. However, all those things are also true of software verification tools, but where license cost is replaced by esoteria and incompleteness cost.

vvanders 7y ago
Valgrind is pretty robust and I've seen it integrated into many projects with little fanfare. Unit tests are just simulation runs. I've done VHDL/Verilog and tons of software, the HW tools do lag significantly in my experience.
- im_down_w_otp 7y ago
  Valgrind is not in the class of verification tools I was referencing. How does it correlate to VHDL/Verilog in this context? I would expect things like MBD tools, model checkers, and proof assistants, and program extractors to be the software pipeline siblings to the kinds of tools that VHDL/Verilog integrate with.
  - vvanders 7y ago
    It's a tool to verify the software runs correctly and doesn't double free, write over the heap and a while bunch of failure. Unless you never run simulation and always trust the router? Not everything gets verified 100% in HW, otherwise we wouldn't have silicon errata. It's all a question of how deep you want to go in verification and what your costs are for screwing it up.