Hi everyone! We’re the cofounders of SiLogy (<a href="https://silogy.io/">https://silogy.io/</a>). We’re building chip design and verification tools to speed up the semiconductor development cycle. Here's a demo: <a href="https://www.youtube.com/watch?v=u0wAegt79EA" rel="nofollow">https://www.youtube.com/watch?v=u0wAegt79EA</a><p>Interest in designing new chips is growing, thanks to demand from AI and the predicted decline of Moore’s Law. All these chips need to be tested in simulation. Since the number of possible states grows exponentially with chip complexity, the need for verification is exploding. Chip developers already spend 70% of their time on testing. (See this video on the “verification gap”: <a href="https://www.youtube.com/watch?v=rtaaOdGuMCc" rel="nofollow">https://www.youtube.com/watch?v=rtaaOdGuMCc</a>).<p>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. But they want to work on chips, not devtools! The solutions they come up with are often inadequate and frustrating. That’s why we started SiLogy.<p>SiLogy is a web app to manage the entire digital verification workflow. (“Digital verification” means testing the logic of the design and includes everything before the physical design of the chip. It’s the most time-consuming stage in verification.)<p>We combine three capabilities:<p><i>Test orchestration and running</i>: The heart of our product is a CI tool that runs Verilator, a popular open-source simulator, in a Docker container. When you push to your repo or manually trigger a job in the UI, we install your dependencies and compile your binaries into a Docker image, and run your tests. You can also rerun a single test with custom arguments using the UI.<p><i>Test results and statistics</i>: We display logs from each test in the web app. We’re working on displaying waveform files in the app, too. We also keep track of passing and failing tests within each test suite, and we’re working on slick visualizations of test trends, to keep managers happy. :)<p><i>Collaboration</i>: soon you’ll be able to send a link to and leave a comment on a specific location within a log or waveform file, just like in Google Docs.<p>Unlike generic CI tools, we focus on tight integration with verification workflows. When an assertion fails, we show you the source code where it happened. We’re hard at work on waveform viewing – soon you’ll be able to generate waves from a failing test, with the click of a button.<p>Our roadmap includes support for the major commercial simulators: VCS, Xcelium, and Questa. We’re also working on a test gen framework based on Buck2 to statically declare tests for your post-commit runs, or programmatically generate thousands of tests for nightly regressions.<p>We plan to sell seats, with discounts for individuals, startups, and research labs (we’re working on pricing). For now, we’re opening up guest registration so HN can play with what we hope is the future of design verification. We owe so much of what we know to this community and we’d be so grateful for any feedback. <3
You can sign up here, just press "Use guest email address" if you don't want to give up your email: <a href="https://dash.silogy.io/signup/">https://dash.silogy.io/signup/</a>
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!<p>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.<p>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'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 Github actions to do continuous verification.<p>If you can get the commercial simulators and full support for the awful, ass-backwards, industry-standard verification frameworks (eg UVM), there's a great business here, but the trouble is going to be in getting there.
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.<p>> 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.<p>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.<p>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.<p>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.<p>Anyway, good luck! I always thought that the EDA industry was ripe for disruption, wish you guys all the best!
Not sure i am following, what problem your product is trying to solve? helping to write tests/run the tests/just organizing tests as a part of the CI pipeline? How is it different than just running tests? (Or is it the platform to run tests on?)
If you are trying to do CI for silicon, then what is your target market? From my experience, companies that design their own silicon are usually big enough to have their own custom pipeline for testing and verification and it would be quite difficult to convince them to switch. Smaller companies get help from larger companies in development and verification.<p>Do you have any tooling that won’t require the developer to write tests? (E.g. something that will ‘work’ with no effort from the developer’s POV - kind of sonarqube for vhdl/verilog)<p>In any case, good luck. Glad to see some HW-related startups.
"design verification powered by Verilator"<p>Nice, coincidentally saw this as I was about to fire up Verilator for the first time in a long time this morning. Good to see a chip development/EDA type company getting funding from YC. It seems like the sector was seriously underfunded during the social media funding frenzy of the late aughts and until recently. Given how things have turned out, I'm pretty sure we would've been a lot better off funding chip development/EDA instead of social media.
I find your company fascinating, having also worked on chips (and chip dev tooling) for much of my career.<p>> But they want to work on chips, not devtools!<p>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.<p>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.<p>Any reason for buck2 vs bazel? Bazel seems more active (O(thousands) questions on StackOverflow for Bazel vs O(hundreds) for buck).
When do you anticipate supporting UVM based testbenches? Verilator is definitely very fast, and SV assertions and coverage are powerful, however the lack of native UVM will require existing ASIC teams to develop new stimulus and checkers that they already have developed.
I might be missing something but how does the product reduce verification time? Isn't it just Verilator running on a cloud server? How does it help with debugging?
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.<p>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.<p>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.
This is awesome! As a software person who dabbles in hardware, I cannot believe that HW folks put up with such arcane, slow, and cumbersome tools. I think anyone who’s critical of this idea has no idea how good they could be having it.
Thank you for tackling this critical problem for logic designiners. I think the tools available are much too old for fast paced workflows.<p>From my experience attempting to get a similar workflow down for my company:<p>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.<p>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".<p>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 <a href="https://www.myhdl.org/" rel="nofollow">https://www.myhdl.org/</a> 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.<p>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.<p>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!
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 <i>and</i> require someone to maintain that tool as well.<p>However, I do have some problems that you may want to consider pivoting to or adding in the future:<p>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.<p>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."<p>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.<p>ETA: Also, was it intentional to launch right on the tail of DVCon? If so, clever planning.
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.)<p>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.<p>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.
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++!<p>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?<p>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.<p>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?