Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 56 posts

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

#21

Post by pkkim »

karthityrion wrote: post #19
pkkim wrote: post #15

Earlier quoted context omitted.

Hey, good question, thanks. We speed up developers in two ways: For debugging individual tests, we have a web based log viewer and web based waveform viewer, so you can share test results or look at waves via a URL, instead of opening VNC. More holistically, we're building a chip focused workflow that will make tests first class -- infrastructure to track tests, and by extension measure design health, will be in one…

Thank you! So will it be a web-based wave viewer and debugger?

Those will certainly be a big part of it. But we’ll also be adding a lot more dev friendly tooling around it as well.

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

#22

Post by bgnn »

pwarner wrote: post #13
zachbee wrote: 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 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.

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.

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

#23

Post by bgnn »

reflexe wrote: post #20
pkkim wrote: post #17

Earlier quoted context omitted.

Hey, thanks! CI is one component of our platform. Most other CI tools are pretty agnostic about how tests are structured, though. We also integrate a way to structure your tests into groups so you can control when each test is called. For example, if one test out of 500 fails, it's super easy to rerun that one test with verbose logging and wave dumping enabled. We then also track test pass/fails over time, have tools…

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.

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

#24

Post by iron2disulfide »

I find your company fascinating, having also worked on chips (and chip dev tooling) for much of my career.

> But they want to work on chips, not devtools!

I have long had a gut feeling that there's an entire industry of frustrating tools specifically to keep that industry alive. I once was shocked to learn that my company had bought licenses for a tool specifically to combine multiple IP-XACT specs into one... basically just parsing several XML files and combining their data! Outrageous.

RE orchestration: It's easy-ish now since it sounds like you're starting out with (free) open source tools, but once you start looking at things like license fair-share, you might find yourself starting to build yet-another-Slurm/LSF.

Any reason for buck2 vs bazel? Bazel seems more active (O(thousands) questions on StackOverflow for Bazel vs O(hundreds) for buck).

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

#25

Post by nickelpro »

pclmulqdq wrote: post #11

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…

This is my feeling too, it's pretty trivial to do this stuff in any CI infrastructure.

At NYU we have this entire process built into very trivial CMake and Github Actions stuff.

Here's an example: https://github.com/NYU-Processor-Design/PurdNyUart

You can see we have 100% test coverage, illustrated by CodeCov, and our CI runs the test suite on each PR. This is very normal in the software world and I guess I don't understand why the hardware world would need a specialized provider just to run Verilator for you.

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

#26

Post by pclmulqdq »

nickelpro wrote: post #25
pclmulqdq wrote: post #11

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…

This is my feeling too, it's pretty trivial to do this stuff in any CI infrastructure. At NYU we have this entire process built into very trivial CMake and Github Actions stuff. Here's an example: https://github.com/NYU-Processor-Design/PurdNyUart You can see we have 100% test coverage, illustrated by CodeCov, and our CI runs the test suite on each PR. This is very normal in the software world and I guess I don't und…

It's not in gitlab's CI infrastructure, but I have continuous integration set up in a private server for https://gitlab.com/specbranch/r5lite and also for my company's proprietary hardware.

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

#27

Post by pkkim »

iron2disulfide wrote: post #24

I find your company fascinating, having also worked on chips (and chip dev tooling) for much of my career. > But they want to work on chips, not devtools! I have long had a gut feeling that there's an entire industry of frustrating tools specifically to keep that industry alive. I once was shocked to learn that my company had bought licenses for a tool specifically to combine multiple IP-XACT specs into one... basica…

Yeah, you make some good points, orchestration has been historically painful -- we've personally seen the headaches that come with scheduling on slurm and lsf; I'd guess some of the most thorough bikeshedding in history has been around tinkering with slurm's multifactor scheduling logic. We're trying to not to re-invent the wheel with orchestration, and we're in the midst of building interfaces to hook into slurm, instead of replacing it entirely :)

As for buck2, we decided to go with it for a few reasons:

More forgiving with gradual adoption, from our experience -- running non-sandboxed actions in bazel is a pain, buck2 has been much easier to plug into existing flows.

Buck2 installation is easier, and by extension, is simpler to embed into our test runner.

Respectfully, bazel's implementation is a monolith beyond comprehension -- if we want to modify buck2, and package our own fork, we have confidence that we could do that.

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

#28

Post by nickelpro »

pclmulqdq wrote: post #26
nickelpro wrote: post #25

Earlier quoted context omitted.

This is my feeling too, it's pretty trivial to do this stuff in any CI infrastructure. At NYU we have this entire process built into very trivial CMake and Github Actions stuff. Here's an example: https://github.com/NYU-Processor-Design/PurdNyUart You can see we have 100% test coverage, illustrated by CodeCov, and our CI runs the test suite on each PR. This is very normal in the software world and I guess I don't und…

It's not in gitlab's CI infrastructure, but I have continuous integration set up in a private server for https://gitlab.com/specbranch/r5lite and also for my company's proprietary hardware.

Ya and I've seen similarly basic support in small IP houses that support Verilator alongside whichever proprietary suite the house uses.

Is there a need here? Are there IP design houses that are so bad at CI infrastructure that "we run Verilator for you" is a value add?

I don't mean to denigrate the OP, just wondering what the market is. Undergrads build this stuff and let me tell you my undergrads are not a particularly talented group.

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

#29

Post by gsmecher »

You should talk with Metrics (metrics.ca), who are walking a similar path and have a few years' head start. They are a solid team and are likely to be open and friendly about their direction and challenges. Metrics has an independently developed mixed-language simulator that claims decent standards compliance with both VHDL and SystemVerilog. It's an impressive feat that puts them in a different class from Verilator (for now - Verilator is moving fast these days, thanks to Antmicro's excellent work.)

In my opinion, the extraordinarily poor design productivity associated with RTL designs is unlikely to change much until we can change the languages themselves. Yes, EDA vendors' tendency to extract maximum revenue for minimum tooling is a cherry on top, but solving that problem alone does not resolve the underlying productivity crisis.

For example: when I implement a complex datapath in VHDL, I become responsible for verifying every nook and cranny of both the signal path and the scheduled design that implements it. If I can effectively do design entry in HLS, I no longer need to verify the scheduled design by hand. That's a very big win.

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

#30

Post by pkkim »

gsmecher wrote: post #29

You should talk with Metrics (metrics.ca), who are walking a similar path and have a few years' head start. They are a solid team and are likely to be open and friendly about their direction and challenges. Metrics has an independently developed mixed-language simulator that claims decent standards compliance with both VHDL and SystemVerilog. It's an impressive feat that puts them in a different class from Verilator…

Hey, we'd love to talk to them. We've heard about them a bit but not from their customers so far. If you have an intro we'd appreciate it, otherwise we'll reach out.

Verilog is not the best language, totally agreed on that. Right now we're not in a place to change that, but maybe one day!

Post reply on HN