Ask HN: Chip startups?
Are there any start-ups in the chip space? I think this falls in the 'sounds like a bad idea' bucket, but could be potentially good idea.
* very cash heavy(EDA tools, IP license, engineer wage, fab money,etc)
* very challenging technically(balance of computation, power, size,etc)
* lots of work needed on the software side(compiler,SDK,optimized libs,etc)
Hardware(circuit board related) startup is already challenging(cash heavy, logistic challenges,etc), chip startup is 100x more. The later is about more than one hundred people with hundreds of millions investment to just get started.
I 100% agree with your other points though. It costs an absolute fortune, and everyone always underestimates the software effort. It's probably 5-10x the hardware effort, depending on what your chip does.
Also another thing I didn't anticipate is how backwards all the tooling and people are in the chip design space. CI is a novel concept. I'm sure there are companies not using version control. Everything runs on TCL which is on par with BASIC. SystemVerilog is not a good language (though it does at least have an amazing reference manual). The standard verification method (UVM) is ok from an actual verification point of view but basically a who's who of worst practices from a programming point of view.
Maybe it's different elsewhere but I was amazed how much convincing I had to do to get people to adopt practices that are just taken for granted in the software world, like auto-formatters. There are a lot of luddites.
The only "ok this is actually pretty good" thing I've seen is formal verification which is basically magic.
In chip design, there are a lot of non-software people who have been burned by software people. Given the amounts of money flying around, there are always a lot of charlatans looking to take a chunk out of you.
We used to do CI--a complete CI on our chip took 4 days. The library took 3 weeks to go through CI. Version control sucks unless your data is text--generally that's only your Verilog. Tcl is a decent enough language--the problem is that the stuff you write is no more than a one off and the real product is your chip--so nobody is going to reward you for a "good" script in any language. SystemVerilog wasn't meant to be a good language--it's an EDA vendor lockin meant to extract maximal money from hardware people.
And I've seen more verification in hardware before shipping a product than I EVER have seen in any software role. Yes, even those with "good" testing.
So rather than just say "ok we won't do simulations of the full chip in CI; we'll just do module testbenches which are much quicker" you scrapped the whole thing?
> Version control sucks unless your data is text--generally that's only your Verilog.
So you don't use version control because it "only" works with the most important things in your repo?
> Tcl is a decent enough language
Sure, compared to Bash or BASIC or other ancient terrible languages. It's pretty terrible compared to any vaguely good language. Even PHP or 90s JavaScript are leagues better.
>the stuff you write is no more than a one off and the real product is your chip--so nobody is going to reward you for a "good" script in any language.
Yeah I've heard this from people at my company too. So do you really completely throw away your entire infrastructure and start from scratch for every chip? If not it's hardly a "one off". And yes, people are going to reward you - your future selves will say "thank god you didn't choose to use such a bug prone language that I spend all my time fixing basic type errors".
> I've seen more verification in hardware before shipping a product than I EVER have seen in any software role.
For obvious reasons. Chips are much simpler than software and therefore way easier to verify, and missed bugs are extraordinarily expensive. I bet FPGAs don't get as much verification.
Your post is exactly the sort of attitude I was talking about - thanks for the demonstration!
You think Verilog/VHDL and its simulations are the most important thing to a VLSI designer. That's a very narrow lens that clouds your thinking and is only applicable in the world of ASICs (that's not really true there, either, but I'm being generous).
Verilog/VHDL is of very little importance to chips with lots of analog or RF blocks. And, for extremely large chips, Verilog/VHDL generally takes a back seat to things like timing closure (and probably power consumption analysis) since once the Verilog/VHDL is written and tested, it's STATIC. As a VLSI designer, you have to close a block every 2 weeks and once it's closed it needs to stay that way or you'll never ship that chip. Repeat for 18+ months.
In that environment, version control is a nice way to validate that I haven't accidentally mangled something, but it doesn't have the same force as it does to software developers who have an infinitely malleable, continuously changing codebase. In fact, source control often gets in the way because non-text merging isn't arbitrarily resolvable. This means that you don't have nice distributed version control, you have the old-school Subversion-type of source control which locks files.
CI doesn't work in VLSI the way it does in software. Tests aren't infinitely fractal. Sometimes that job that creates the data for your static timing analyzer takes 5 hours and that's just how it goes and that's just the start of your pipeline. If you touch a header file in software, a long compile is a couple minutes. A couple of hours is an absurdly large software codebase. In VLSI design, a fundamental library component may take hours to check timing and generate timing values if your fab house generated new models. And that's just one of hundreds of library components. If your fab releases a new transistor model deck, it will take weeks for that to propagate through your design.
As for languages, Tcl is FINE. Creating scripting hooks is absurdly more complicated than you think (look at the grief KiCad has keeping Python supported--Blender had to create a whole GUI library from scratch to have Python hooks--Altium's Python scripting is still a horribly broken bodge). Tcl means that you get scripting hooks that work. I haven't seen any other language do it better yet. And the fact that you haven't been burned by floating point in VLSI and think Javascript, which only has floats, is a better language says something ...
Could things be better? Sure!
The fact that the pay is crap compared to FAANGs is the first problem. That's why most of us who know what we are doing have left VLSI design for software and can only be brought back with large chunks of cash.
As for Verilog/VHDL--the problem is that they are fit for purpose with hardware. If you want to displace them, you need to create something that takes into account the nature of simultaneity in hardware systems and makes it explicit. And, in modern programming languages, we've gone backward on that front--async makes simultaneity more implicit rather than less.
Scripting hooks could be better. Open source tools help because you have all the code.
Non-binary formats help because you can read and decode the dumb things. You can now also put everything into standard source control tooling.
Analog and RF are still the wild west in many ways. Computers are faster, but we really don't have fundamentally better ways of doing that kind of design than we did 20 years ago. It's a bit surprising that we don't have the equivalent of RF "standard cells".
There are, without doubt, luddites in VLSI. However, there are also a lot of greybeards with deep scars. Do not confuse the two even if they look very similar.
> Chips are much simpler than software and therefore way easier to verify
I've got a few friends who are waiting for your insights. One has a power grid that seems to oscillate at weird frequencies, another has a VCO that pulls on the 2nd full moon of the month, and another that can't run down 2 orders of magnitude in leakage current.
Do keep in mind that VLSI design is larger than the slice that you have been exposed to. Dismissing that will make it quite a lot harder to convince people of your positions.
Tell me more about this place where people don't get hung up on how I indent my comments.
In my experience an individual software component can be much more complex than a hardware component.
https://sambanova.ai/ - Enterprise AI and dataflow-as-a-service for established moodels
https://www.cerebras.net/ - AI accelerator, trying to compete with NVidia
https://www.graphcore.ai/ - Another AI accelerator company - UK based
https://femtosense.ai/ - Sparse NNs on very low power chips - cool hardware and software challenges
https://sima.ai/ - ML accelerators for embedded applications
https://ambiq.com/ - Not AI, but low power chips for wireless using some fancy tech that reduces energy leakage
There are dozens more, these are just the ones I've heard of.
https://groq.com/ - From the team that built the original TPU at Google
https://lightmatter.co/ - Light tubes instead of copper
https://www.esperanto.ai/ - RISC-V based Tensor computes chip, Founded by Intel Hybrid Parallel Computing Vice President Dave Ditzel.
https://www.furiosa.ai/ - AI accelerator company which show good results in MLPerf benchmark.
- https://www.sifive.com/ - RISC-V related company
- https://www.cerebras.net/ - Cerebras (AI accelerator)
Both of categories has other players, these are just two notable examples.
It's a bit ironic that someone complaining about confusing contractions is using confusing abbreviations.
- ONiO: Single-chip microcontroller with builtin energy harvesting and radio communication, enabling IoT devices without battery or dedicated charging.
- Ascenium: Software-defined CPU without an instruction set. Highly parallel architecture with extensive compiler integration.
- Disruptive Technologies: Single-chip compute + sensing with built-in battery for 10+ year operation.
This is marketing BS if I've ever heard it. Their "instruction set" is LLVM. They're doing nothing more than what Transmeta (dynamic/programmable ISA) or Lisp/Arm-Java machines (running higher level code at a machine level) did before them.
It would represent a true architectural revolution if it ever actually came to fruition. Lots of past discussion on HackerNews over the decade(!) it’s been under development.
I'm designing an affordable electron microscope for high schools and small businesses. While that doesn't sound like a chip startup, the long term goal is to create multipurpose tools that enable semiconductor fabrication with electron beam milling and chemical vapor deposition.
https://www.uhnder.com/ - radar on a chip
With enough funding, it's quite a good thing to work on. With Moore's law dead, the odds of success of weird chips got much better.
Jim Keller: Moore’s Law is Not Dead: https://www.youtube.com/watch?v=oIG9ztQw2Gc
I've jumped around it and didn't see any mention of cost/transistor going down. So I assume that isn't a respected engineer saying the opposite of what all the data clearly shows, and instead it's a hyped title to a talk about something slightly different.
None of that has any relation to Moore's law.
Batteries are not on Moore's Law and more of our systems are battery powered so portable electronics is not on Moore's Law. Transistors are not cheaper if you can't turn them on.
Power goes as area squared and voltage squared. We can't turn voltage down any further and cheaper transistors mean area goes up. This means that most computation chips are fairly close to their thermal limits. Transistors are not cheaper if your cooling solution costs 10x more.
HTTPS://wwww.fishnandsemi.co.uk/
We currently target AWS F1 FPGA instances, and custom ASICs are on our roadmap.
hn@ir.design
https://www.linkedin.com/jobs/view/3108025120/?refId=iI7RO%2...
It's so costly I don't know how other related startups can survive though.
https://www.google.com/search?q=chip+startups
I'm pretty impressed with the number of AI/neural network semiconductor startups right now.
A lot of things you see here could've been 'Googled', but what's the fun in that?