My general thinking is that IOs should be analog circuits?

Not if you are using synthesis flow tools to do top-level floorplanning, placement, and routing.

How far are we from a 'quick-start' template project that does digital synthesis flows to GDS

I dont fully understand the meaning of "analog circuits or not" that you are using here. Pad-Cells contain both Analog and Digital parts. From my point of view, they are mixed-signal circuits 🙂 This is my current concept for generating Pad-Cells: https://docs.google.com/document/d/1fmhtB9cKA1N4bY1OUkKoevnkYZcq3AQwWMameUd8Fks/ , it tries to explain the various parts of the IOs, and how they could be generated.

Hi @Philipp Gühring. Thanks for sharing the document about pad cell. You mentionned a tool you wrote to generate the pad frame (sometimes called also "pad ring" ). Are you aware of https://github.com/YosysHQ/padring ? It worked relatively well - I was able to use it to start a floorplan for testing OpenRoad

Yes, it was developed shortly after my tool. I havent used it yet, though. I think it is more interactive, and mine is more automated, if I remember correctly.

There is no user interaction in this tool - It is 100% based on a text description of the padring (which is good 🙂 )

Yes, but you still have to write that text description. My generator just takes the core and builds the pad frame around it automatically.

Ah ok. But from my experience in IC design, you really want to quicly "fix" your padring early in your design process - You adjust it of course during the whole design process, but always in sync with the other steps (macro placement, power routing, etc..)

My approach was more in TheOpenRoad way: You put your Verilog in, you get a full chip design out.

Hmm - Honestly, that's not going to work without taking in account constraints like ESD, ground bounce, power domains and other stuff like bounding constraints. I think it would be better to have a tool similar to padring that takes a quite rigid description of the padring and generate a def and eventually in "front of it" a tool that could quicky generate an configuration file for it from a verilog netlist (or another standard file format)

It highly depends on your application and on the process node. When you do a small completely digital chip on a 1um process node (like LibreSilicon, CDTA, ...) it should work fine out of the box with my approach. When you do a mixed signal SoC, you likely want a more manual approach.

No problem - I hope to get the agreement of my management to release some scripts I've made to do the floorplanning and the padring of a Risc-V prototype with an OpenRoad flow

Cool!

@Philipp Gühring A few comments on your document: • The ESD structures are typically also the output drivers of the IO cell. • I don't follow the comment that guard rings are not needed because libresilicon uses STI. The guard rings are there to avoid latch-up. In general it is advised to put as much bulk and well contacts as possible in the IO cells. IO cell used for input are externally driven with much higher drive strengths than one normally finds on a chip together with overshoot and undershoot of the signals. This will lead to charge injection in bulk and well and one needs to get rid of that charge ASAP to avoid that parasitic thyristors fire and cause latch-up. For this reason also often one find recommendations/rules that the logic part of the IO cell has to be put a certain distance from the ESD structures etc. • You can't use SPICE type simlators to simulate the snap-back curves of an ESD clamp. The snapback curve will cause convergence problems. You can use SPICE to check certain derived rules like resistance between points etc. I did evaluate Magwel product when still at imec but this is not spice like simulation; it is a Maxwell solver optimized for ESD performance check. This tool will also cost you I think a 6 digit figure.

Thanks a lot for your comments, they are highly appreciated! • I thought the ESD structures are primarily for the input protection. I'll have to read up on that again. Thanks for the hint. • This specification document was made 2 months ago for Pad-Cells for the LibreSilicon 1um process. Back then I asked David whether we need Guard-Rings, and his answers was that we dont need them, but I forwarded your comments to him now, perhaps he changes his mind now. (Back then I was happy that this would make the design simpler 🙂 • Thanks, I am well aware that SPICE simulators arent sufficient for snap-back (there is one paper though that claims that you can combine 2 BSIM transistors within SPICE to simulate snapback), and I was researching alternative simulators intensively. You can see most of what I found in the references at the bottom.

@Philipp Gühring I like this from the intro "... and less convergence issues" 😁

It occurs to me that pad rings are sort of like C libraries ... complex and hard to validate and debug, and if you fail to debug them properly, your chip stops having functional IO