Live data from Hacker News

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

news.ycombinator.com

41–50 of 56 posts

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

#41
post #36
post #23

Earlier quoted context omitted.

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

Pretty much most of them. They might buy a small IP or two here and there, but for the rest everyone develops their design mostly in house. It's not 100s of millions, that's a ridiculous amount of money unless you are designing like a huge CPU or TPU or so. We design (can't give company name) quite large chips with complex analog and digital in 7nm and 5nm as a start-up and our seed funding was less than 20 million. This is kind of bare minimum funding for a semi start-up anyhow.

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

#43
post #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 cofoun…

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

In my experience it's the opposite. While some firms issue Linux workstations to their engineers most use VDIs (and god forbid sometimes VNC) hosted in a datacenter that can be far from the office. The already poor latency becomes atrocious when they say open Verdi over LSF, which is X-forwarded from the host to the VM before getting encoded and sent to the client.

Web tools bring the interface and rendering over to the client side and allow for a much smoother experience even if the server is physically far away.

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

#45

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 s…

Thanks for your thoughts! We are indeed planning to add support for other vendor tools, including the Synopsys, Cadence, and Siemens simulators.

Cost for cloud vs on prem is very specific to design complexity. For the designs we're working with, we have seen that compute is cost effective on the cloud with respect to building out on-prem compute. We expect that to change as we support larger designs, and we have support for on-prem compute firmly on our roadmap.

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

#46

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 exte…

CI is a core component of our product, but it's also a building block that we're building lots of DV-specific features on top of. In fact, one of those features is a build wrapper sort of like Make/Bazel for compiling stimuli, feeding them into simulators, and doing post-processing. Essentially what you describe in point 1 but for verification. We'll likely open-source this so other CI platforms can use it too.

For the other problems you mentioned: we're currently just handling the verification piece of the puzzle for right now, we want to do one thing really well first. We feel your pain on the SystemVerilog code generation front, we've had to interact with similarly primitive code generation mechanisms. You can only go so far with the preprocessor and what gets generated during elaboration.

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

#48
post #35
post #34

Earlier quoted context omitted.

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…

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

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

#49
Thank you for tackling this critical problem for logic designiners. I think the tools available are much too old for fast paced workflows.

From my experience attempting to get a similar workflow down for my company:

I tried to use verilator a while back but ultimately I couldn't because it didn't have same constraints in the verilog language features that I was going to use in production. It doesn't even matter who was missing a feature, verilator or the proprietary tool, it was just about getting them to be same that caused the cognitive dissonance that I didn't want to deal with.

I ultimately decided to move away from verilator and use the clunky proprietary tools since it was what would be used in production. Getting "verilator compatibility" seemed like a "nice to have".

Second, the a winning local-first framework of verilator wasn't really established. You show in your example running a test from the yaml file using what looks like a bash script. Even as an experienced programmer who knows bash and sh well, I still find it very hard to write complex thoughts in it. The last high level attempt I found to bridge this gap is likely https://www.myhdl.org/ I don't know them personally, but it seemed like they had some very good thoughts on what makes writing good hardware level tests good. I think it would be worth reaching out to them if you haven't already.

The one thing that even more critical was a way to run our tests locally. The 10-20 seconds it takes to start a docker image (best case) in the cloud is really frustrating when you are "so close to finding a bug" and you "just want to see if this one line change is going to fix it". Once we got our whole pipeline going, it would take 1-6 minutes to "start a run" since it often had to rebuild previous steps that cache large parts of the design.

So I think you will want to see how you can help bring people's "local's first" workflows slowly into the cloud. Some tools (or just tutorials) that help you take a failing test, and run it locally and on the cloud will be really good especially as you get people to transition!

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

#50

Earlier quoted context omitted.

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 particul…

When you are trying to design high performance IP, you are often trying to ensure that your design is mathematically correct, inputs and outputs are matching a complicated 100 page specification. You are also trying to parse out the minimum set of workable requirements for "version 1" all with fitting into utilization constraints that ultimately are undefined.

Your mindset is really split. "Building up a software dashboard" to visualize your test results is really the last thing on your mind. You definitely don't want to be building the dashboard for all your customer's platforms.

Having somebody (a company) help on this front is really useful.

As a non-website designer, I used to think the same of tools like netlify, but they seem to be popular as ever, especially in a collaborative workspace when you need to handoff a project from one team to the next.

Post reply on HN