Comment by zachbee | Hacker News Reader

Comment by zachbee | Hacker News Reader

I'm a professional chip designer. And as somebody who's had to build this sort of internal tooling myself, I think this sort of product is desperately needed!

It makes sense to start with Verilator, because it's fast, easy, and open source, but it seems like it'll fall short on a lot of metrics. It seems like the big challenge is going to be making sure your tool can do everything that chip designers actually need to do. I remember spending almost a week bringing up gate-level simulation, which was a huge pain in the ass because our design used an ILM-based hierarchy. Handling things like X-propagation, timing constraints, mixed-language designs, and non-synthesizable models for mixed-signal IP is going to be really tricky, especially because they work differently in every simulator.

Is there any reason why you're not starting by targeting FPGA developers instead of semiconductor developers? It seems like the Verilator flow will do a much better job of fulfilling their needs, which are generally simpler, than fulfilling the needs of an ASIC team. Obviously in the long run, semiconductor developers are the bigger market, but you need far more features to be able to sell to ASIC teams.

I worked with some chip design and verification folks. They were very tolerant of slow results, waiting for licenses or infrastructure. Their processes were just built around those constraints. They didn't seem to have interest in removing them.

As an impatient software developer it was very interesting.

Yeah, our team has experience in both hardware and software. DV engineers have a really hard time and we're trying to make it better.

Project cycles are long. We are typically doing 1 tapeout/quarter. Chips are incredibly complex, and the physical design is a by definition slow process. Of couse everyone wants quicker tools/turnaround but bottleneck isn't RTL development, physical design and verification is.

Thank you! In fact we'll be helping our first customer with FPGA development. I don't know if we put a lot of thought into FPGAs vs semiconductors in terms of marketing but you raise good points, we'll discuss it.

Just to clarify though, we are targeting both ASICs and FPGAs.

I use verilator all the time for open source stuff, but it has a real problem not supporting Xs - I use them to detect uninitialised variables and taken undefined case statements (with full_case) etc allows me to force faults at the same time as giving clues for better synthesis.

I think that FPGA flows are different, because you can test stuff without a tapeout, a lot of debug stuff gets short circuited when you can design something bug and test it on an FPGA in minutes (or in my rather big case 12 hours and then testing on an AWS FPGA instance)

+1 on concerns about verilator not supporting X prop. Definitely a big difference between FPGA and ASICs.

The lack of X-prop in verilator is one of the reasons why a lot of OSS hardware designs are risky or unsuitable for ASIC integration... verilator is popular in OSS, and X-prop isn't a problem for FPGA because every bit in an FPGA is guaranteed to start at a known state.

So, Verilator assuming 0 by default instead of X means that a lot of OSS developers get away with bad coding habits that work perfectly in FPGAs, but can't reliably power up in an ASIC.

it's a little more than that - as I mentioned above you can assign xs in a case statement (or anywhere you like) as a signal to you synthesis tool when you don't care what value something is - that allows the synthesis tool to make better gates, and to cause simulations to fail if you were wrong about doing that

I wonder if FPGA developers are as likely to spend as much on tools? They're kind of used to having most of their tools from the FPGA vendors be free or if not free fairly inexpensive.

Reply on news.ycombinator.com