[HN Gopher] Launch HN: SiLogy (YC W24) - Chip design and verific...
___________________________________________________________________
Launch HN: SiLogy (YC W24) - Chip design and verification in the
cloud
Hi everyone! We're the cofounders of SiLogy (https://silogy.io/).
We're building chip design and verification tools to speed up the
semiconductor development cycle. Here's a demo:
https://www.youtube.com/watch?v=u0wAegt79EA 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":
https://www.youtube.com/watch?v=rtaaOdGuMCc). 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. 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.) We combine three capabilities: _Test
orchestration and running_ : 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. _Test results and
statistics_ : 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. :) _Collaboration_ : 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. 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. 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. 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:
https://dash.silogy.io/signup/
Author : pkkim
Score : 56 points
Date : 2024-03-07 18:38 UTC (4 hours ago)
| zachbee wrote:
| 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.
| UncleOxidant wrote:
| 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.
| pkkim wrote:
| 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.
| pkkim wrote:
| Just to clarify though, we are targeting both ASICs and
| FPGAs.
| pwarner wrote:
| 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.
| pkkim wrote:
| 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.
| bgnn wrote:
| 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.
| UncleOxidant wrote:
| "design verification powered by Verilator"
|
| 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.
| pkkim wrote:
| Thank you! Yes, we're very excited for the new chips that will
| be developed in the coming years, and we'd love to help them be
| born.
| karthityrion wrote:
| 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?
| pkkim wrote:
| 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 place, instead of implemented with a
| bunch of handrolled, bespoke tooling.
| karthityrion wrote:
| Thank you! So will it be a web-based wave viewer and
| debugger?
| pkkim wrote:
| 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.
| SiliconCowboy wrote:
| 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.
| pkkim wrote:
| UVM support is a high priority for us, and our current
| infrastructure should make it basically drop-in once it's
| ready. Drop me an email if you are interested (email in bio),
| we will be sure to let you know when it's ready! :)
| pclmulqdq wrote:
| 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.
|
| 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.
| pkkim wrote:
| Thanks for the observations. It's true that every company that
| needs this eventually figures something out.
|
| The difference is (a) our customers don't want to be in the
| devops business, and for startups especially it's a severe
| barrier to entry that we can make disappear, and (b) we are
| going to keep investing in our products (especially
| collaboration tools and integrations with waveforms, logs, etc)
| long past the point where a chip company would decide their
| internal tools are "good enough" (hint: they're generally not).
|
| UVM support is one of the next items on our priority list.
| imakwana wrote:
| I noticed there are some GitHub Repos actively working on
| enabling UVM on Verilator:
|
| https://github.com/MikeCovrado/GettingVerilatorStartedWithUV.
| ..
|
| It would be an amazing leap to enable UVM fully on Verilator.
| Looking forward to it.
| reflexe wrote:
| 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.
|
| 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)
|
| In any case, good luck. Glad to see some HW-related startups.
| pkkim wrote:
| 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 to leave comments for
| coworkers on waveforms and logs in the browser like in Google
| Docs, etc.
|
| Out of curiosity, what do you mean by "Smaller companies get
| help from larger companies in development and verification"?
| reflexe wrote:
| 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 so
| many people for a relatively short period. However, I am not
| fully sure how involved they were in the pre-silicon
| verification process, but at least in some cases they were
| very involved in the development.
| bgnn wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-07 23:00 UTC)