5 ms·
As a hardware designer (well, mostly a hardware verification engineer), I feel that this kind of comment is a pure misconception from software people that gets
by sweden 6y ago
As a hardware designer (well, mostly a hardware verification engineer), I feel that this kind of comment is a pure misconception from software people that gets echoed time after time in HN.
I generally see a lot of more effort and good quality tools in hardware verification than in software validation. The hardware design and verification industry is not really 30 years behind the curve compared to software development.
Hardware and software are two very different problems with their own set of constraints. It's actually more often that you see software barely tested being deployed in the wild to millions of users rather than hardware. Hardware bugs tend to get more attention because you can't really deploy a patch to fix the issue.
- artemonster 6y ago> 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 6y agoThose 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 6y 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 6y 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 6y 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 6y agoThe 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.
- im_down_w_otp 6y agoHave 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 6y agoValgrind 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 6y agoValgrind 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 6y agoIt'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.
- rcxdude 6y agoHaving worked with both HDLs and software tooling, I don't think it's too far off the mark. HDL tooling is terrible software: it's hard to use, buggy, expensive, opaque, and the support is terrible unless you're a huge customer. Hardware verification and development works still through sheer effort, and because there's a strong business incentive to get things right the first time due to the huge costs of a respin. With better tools this could be done faster and cheaper with similar reliability, but perhaps there isn't enough to be gained to make it worth the effort (and either way I don't think the companies currently working on the tooling are capable of making anything else: this would need disruption to really make a difference, and the barriers to entry are huge).
- kingosticks 6y agoWe get decent support from our main tooling providers. We do spend a chunk on licenses but I don't think we'd be considered a huge customer. And yes, the software has bugs (with expensive consequences) so good support is very important.
- tails4e 6y agoHardware design flows are complex and do have bugs, but not in the way it sounds. In general HDL synthesis produces a design that matches what the user wrote, so a logic bug in a synthesis engine is rare. The bugs exist in the 'other stuff', like trying to convince the tool to be efficient about how it created the design, or smart about how it's trying to close timing. Getting a working though the tools design is easy, getting an optimal design is hard. HDLs themselves have issues, but there is a wealth of quality checking tools built around them that mitigate them, and indeed mitigate/flag poor coding from inexperienced designers (to a degree). What's interesting is FPGA tools, as much as they are derieded, are much better than their Asic counterparts in terms of functionality and user friendliness.
- balfirevic 6y ago> I feel that this kind of comment is a pure misconception from software people that gets echoed time after time in HN. But the comment came from a hardware designer, at least the grandparent one (from artemonster)?
- naringas 6y ago> I feel that this kind of comment is a pure misconception from software people I really hoped you were referring to the secrecy
- tails4e 6y agoYes, hardware must be right first time. Proving that is difficult, so logic equivalence, formal proof, code coverage are all standard. What's optional in many software QA flows would be absolutely required in HW flows. Proof of functionality is paramount
- rowanG077 6y agoI don't agree. I agree that if compare random software project x to a random hardware project y that the hardware project will do a lot more verification. But that doesn't really compare to state of the art of what's possible in software. Property based testing, symbolic execution etc all have incredible power that afaik is not available in the hardware world. I'm just a hobbyist who uses FPGA's but it's way way easier for me to ensure a function has some properties compared to a VHDL module or whatever.