Two Weeks Until Tapeout

14 days ago (essenceia.github.io)

The thing I love about blog posts like these is how it reminds me that the tech world is a vast ocean that encompasses so many disciplines; it's not all full stack web development.

Related: I did not understand 95% of what she wrote.

  • On some of my cover letters I wrote "full stack from the transistors upwards", because at one point or another I have shipped code in:

    - IC design software (at a startup bought by Cadence)

    - an IC (contract out of Dallas semi)

    - FPGA HFT acceleration

    - fixing some OS drivers for Windows CE

    - finding a compiler bug

    - various bits of embedded firmware in C and assembly for various platforms

    - debugging with a scope

    - desktop applications

    - a web server (defunct ZWS)

    - web apps (Perl. Long time ago)

    Somehow I've never written a react app.

    • When I first came to HN, I didn't know what `hn`, `pg`, or other initialisms meant. But I saw people boasting in the new vocabulary of "full stack developer." And I assumed that if companies loved "javascript down to redis" that they would really love that I could do front end all the way down to embedded development. Think of the problems all my full stack knowledge could solve!

      Never got an offer through "who's hiring" though.

  • I wrote here a couple days ago: "For a Hacker News degenerate, everything in the world revolves around bean-counting B2B SaaS CRUD crapps, but it doesn't mean it's all there is to the world, right?"

    • I didn't even know that 180nm was still a thing but clearly it is because apparently the cost difference is like USD 100M for 180nm vs USD 10B or more for the latest tech?

      Is it true that we will likely have these 180nm chips for things like light bulbs for the foreseeable future?

      18 replies →

I've probably worked on 70 chips over the last 30 years.

Tape out time always sucks. I'm in physical design which is fixing all the timing violations, DRC violations, LVS errors, and dealing with late design changes.

Working 80 to 100 hours a week for a month really sucks and makes you wonder why you didn't go into software.

When you combine it with a fixed shuttle date like in the article it is even worse because if you miss that date it might be another 1-2 months for the next shuttle instead of just a day for day slip when you control all the masks.

  • Don’t worry we have those 80 hour weeks in software too. I can think of a few examples. For example with mobile App Store review time used to be kind of like that. You submitted your app waited a few business days and prayed there wasn’t an obscure rejection that lead to an appeal which could take even longer. Very stressful when you are cueing up a launch and press releases on a certain date. you had to make sure you were done a few weeks in advance to account for everything.

    I don’t work much on apps anymore but I hear it’s somewhat better now.

    Another big area is compliance, those processes can take forever.

  • Can I ask how often you guys end up doing gate-level netlist ECOs, instead of re-running synthesis when you're close to a deadline? Also, post-fabrication, if a mistake is found, have you been able to fix it just with a new M1 or M2 mask, instead of paying for a full new mask set?

    • If the change is under 1000 logic cells and no new flip flops then we do a it as an ECO. If there are tons of new flip flops we resynthesize and start over.

      Lots of chips have metal spins to fix errors. The blank areas of the chips are filled with filler cells but most of them are special "ECOFILLER" cells that are basically generic pairs of N/P transistors like a gate array. These can then be turned into any kind of cell just by using metal. They are a little slower but work fine.

      I've worked at one huge company where they planned 3 full base layer mask sets and 1-2 metal spins for each full base layer set. This was when doing a chip on a brand new process node where you couldn't always trust the models the fab gave you so you wanted more post silicon characterization to recalibrate models.

      5 replies →

Incredible dive into something I’ve only dreamed of doing, this post is definitely one of my favorites. If the author is reading this, would love to know where you got those chairs!

> So when the opportunity arose to join an experimental shuttle using global foundries 180nm for FREE I jumped onto the opportunity and designed my own JTAG!

In case anyone wants a preview of what to expect.

  • > Because the official JTAG spec lives behind the impregnable IEEE paywall, a castle in which I am not permitted to set foot as a result of not having paid its lord my dues, the verification of the JTAG TAP was actually quite interesting.

> aka: For those not living in 2026, we have uncovered a new clue to the mystery of where all the low-power DRAM chips have suddenly vanished to!

I love the writing style!

A hugely entertaining blog post, despite subject matter that could easily result in very dry reading.

As someone who isn’t familiar with the deep details of the hardware side of the AI industry, I’m curious if these chips are “easy” to write AI software for, or if there is a big barrier. How significant is Nvidia’s moat on the software layer, which I often see talked about in articles, when people seem to be willing to adopt AI accelerators. And if AI accelerators can be adopted, why aren’t other competitors to Nvidia (AMD, Intel, etc) able to break in?

Out of curiosity, does anyone know how many of the tools involved in the Tiny Tapeout project are available open source?

Especially in the project roadmap section..

The licences for proprietary EDA tools are very expensive it seems and most EDA people i talked to didn't really care for any open source tools - as their companies paid for the licenses.

  • You're right that most professional designers historically haven't cared about open source tooling. But this is starting to change, largely because of the recent existence of open PDKs and the creation of better open tools like OpenROAD. I am a PhD student working in chip design, and about 90% of my work is done using open tools. You can see an image of one chip here, for example.

    https://github.com/kcaisley/frida

  • You can do the entire project roadmap with entirely open source tools and all the tiny tapeout tools are open source.

I'm shocked that SRAMs would be considered a luxury item for open silicon. They're essential for building anything that would be commercially viable, since area is far from free.

As a person that is using Librelane daily in their workflow, why did they skip Gate-level simulation? Iverilog won't ensure the circuit works after tapeout, CVC most likely will. SDF-annotated simulation actually shows data hazards, as well as transistor timings.

https://librelane.readthedocs.io/en/latest/usage/timing_clos...

  • > Once again, I used Cocotb as the abstracting layer allowing me to interface with multiple different simulators. Namely, icarus verilog for my standard verification and CVC for the post implementation timing annotated netlist.