Live data from Hacker News

Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

news.ycombinator.com

31–40 of 56 posts

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#31

I'm about to pull a "dropbox" here, but I am aware of many companies that already do this inside their Git infrastructure. It's not that hard to do when you combine verilator, testbenches in software languages, and cloud CI intended for software. This is one of the big advantages of greenfield designs (and FPGA companies): you can set things up for Verilator and/or CocoTB natively, and then you get to use things like…

The thing is too: Gitlab and GitHub CI are still kind of crap unless you put a bunch of work into them (gitlab in particular really don't what they're doing; they're not dumb but they aren't good enough).

Sell a workflow, not a prison.

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#32
post #31

I'm about to pull a "dropbox" here, but I am aware of many companies that already do this inside their Git infrastructure. It's not that hard to do when you combine verilator, testbenches in software languages, and cloud CI intended for software. This is one of the big advantages of greenfield designs (and FPGA companies): you can set things up for Verilator and/or CocoTB natively, and then you get to use things like…

The thing is too: Gitlab and GitHub CI are still kind of crap unless you put a bunch of work into them (gitlab in particular really don't what they're doing; they're not dumb but they aren't good enough). Sell a workflow, not a prison.

The functionality on offer here is equivalent to about 30 lines of Github Actions YAML to install verilator, run the tests, and upload the coverage information. [1]

Generating waveforms is free, Verilator already does that if you pass it the appropriate argument, either --trace or --trace-fst. We usually control that with a single CMake option.

Complex workflows can get nutty, but what's illustrated here is not a complex workflow.

[1]: https://github.com/NYU-Processor-Design/component-template/b...

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#33
I used to work at a fairly large fabless semiconductor company on the team that developed the internal tools for doing almost exactly what you were doing.

> Tooling hasn’t kept up. The state of the art in collaborative debugging is to walk to a coworker’s desk and point to an error in a log file or waveform file. Each chip company rolls out its own tooling and infra to deal with this—this was Kay’s (one of our cofounders) entire job at his last gig.

This is definitely an exaggeration, the tooling has always been a bit "dated" but vManager from Cadence has all the features you are describing (and more). I think nowadays they offer a fully managed cloud service as well. I'm guessing other vendors have similar offerings but we were primarily a Cadence shop.

On the topic of web viewing, do you know that engineers want this? In my experience, managers liked it because they could get an overview quickly, but the engineers hated it because it involved copy-pasting paths from the browser to their local tools.

We had vManager but some teams used their own test runner/manager with a web viewer(similar to your tool) and I ended up building a little TUI that the engineers could use instead. It worked almost the same, except it let you directly relaunch failing tests in an interactive simvision session for debugging, open log files in vim and open the coverage report for the regression.

Anyway, good luck! I always thought that the EDA industry was ripe for disruption, wish you guys all the best!

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#34
post #2

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…

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)

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#35
post #34
post #2

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…

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…

+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.

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#36
post #23
post #20

Earlier quoted context omitted.

In my experience in two HW companies that developed their own ASICs (one as a startup and one as a publicity traded company), we never developed any chip fully by ourself. In all of the cases there was another large company who helped to make the project work so we will actually end up with wafers. If you are not at the scale of NVIDIA/intel and release a new silicon every other month, it is not worth it to recruit s…

That's not correct. I've worked from start-ups to semiconductor giants. Always the first option to develop everything in house, if you can find the talent. This is pretty much industry standard.

What ASIC/semi start up that you know of is developing everything in house? That is absurdly complex and hundreds of millions of dollars...

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#37
As someone who's also done a lot of DV and DV tools, I love to see it. This gap was something I took away from attending DVCon last year and seeing all the papers from folks reinventing in the same verif tools.

Feeling inspired after DVCon, I was sick of how annoying our test infrastructure was to interact with so I built a vscode extension as a front end to the existing mature infrastructure. Handles running tests, regressions, opening logs of all kinds, launching vendor tools, jumping to definitions, hover over documentation on all our custom config files, even breakpoints that export to verdi. I've got about 30 people using it now which is pretty neat.

My main learnings are 1) boy it would be tough to make this generic enough to my existing infra without making it lose all the benefits 2) Switching away from my editor is a huge context loss, having tools directly inside my editor keeps everything moving faster.The thought of adding yet another important web page to my browser isn't pleasant. I specifically added features to my extension so I could avoid going to our internal regression results webpage.

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#38
I am a DV engineer, and I'm going to give some candid feedback: CI tooling is not what I spend most of my non-coding or verification-planning time on, so I wouldn't find much use out of this tool. Now that wasn't always true – I used to work somewhere that had horrible CI tooling. But that's just because the company didn't invest in someone to maintain that infrastructure. Given that, I don't think they'd pay an external vendor for a tool and require someone to maintain that tool as well.

However, I do have some problems that you may want to consider pivoting to or adding in the future:

1. A wrapper that works with all of the tools that EDA vendors offer as a back-end. Basically, CMake for SystemVerilog where I can just run `make` and compile, elab, and sim run in order. Every company I've worked for has made their own wrapper program which essentially re-creates this process and I've had to relearn it several times. If you had this wrapper, then you could easily just use other CI/CD pipeline which calls this tool. Bonus points if you can integrate it with VUnit or SVUnit unit testing frameworks.

2. SystemVerilog code generation. Something smarter than just "I wrote a Python script that prints SystemVerilog code to a file based on some config file and then you run your build with the file the Python just printed."

I'm sure there are others that I am not thinking of. But overall, I don't find a lack of CI to be the problem. It's the lack of tools that a CI pipe uses that's the problem.

ETA: Also, was it intentional to launch right on the tail of DVCon? If so, clever planning.

Re: Launch HN: SiLogy (YC W24) – Chip design and verification in the cloud

#40
As a hardware developer, I love seeing EDA tools getting YC's attention and resources. When hardware designers talk about how terrible EDA tools are though (myself included,) I find that it's a lot of the pot calling the kettle black. Most semiconductor companies have the most ancient IT infrastructure and tooling. Like at my current company, we're still using perforce. Instead of using SSH, my coworkers VNC into a server to run their terminals. A surprising number of them still use Notepad++!

Encouraging modern practices and enabling developers to migrate to newer development and development adjacent tools will be the huge value add with a product like this. At my company and some of the other companies I have worked for, we primarily use Synopsys for our tooling, but in reality, we use Cadence and Siemens tools occasionally. Being able to be more vendor agnostic, and tool agnostic, would be extremely useful. I noticed that you're using ventilator, but are there plans in the future to support other vendor tools?

Promoting the use of natively running apps (even if they're thin client web apps) is a huge win in my book too! VNC and VDIs are a terrible way to work. I really hate having to deal with the 40ms latency for every key and mouse event and font scaling that never works properly.

Another question I have, is about cost - I'm not a cloud billing guy, so I don't know the numbers off hand. But from my understanding, hardware development typically sees pretty high compute resource utilization, which is why I had always assumed that in-housing compute infrastructure made financial sense. Since it's on the cloud, how does it compare to on-prem computing from a cost perspective?

Post reply on HN