Frequently Asked Questions

I have budgeted for a 10mm² chip area. The test chip I put on the last run was 6.6mm², and a reasonable estimate for project slot size on that would be 520µm × 250µm. If I scale that chip size up to 10mm², the slot size would be around 750µm × 340µm, although based on Chipalooza Challenge #1 results, the smaller area is probably sufficient. I will have to see the set of proposals before I make a final decision on that.

This will depend on how the projects can be arranged on the chip; there will be some crossbar connectivity allowing projects to share some pads, and projects will be able to have dedicated pads. Most of this will be determined at the time of full-chip integration. It is very important that your proposal declare how many pads are needed, and if any of the pads must be low resistance and cannot be shared. If too many projects demand exclusive access to pads, some last-minute arbitration is going to happen.

I may elect to change the design of either the voltage or current reference, but based on the existing designs that were taped out on the first SG13CMOS5L run, and assuming they get tested in time and are known to work, the feature set of these designs is:

• Current reference: a 5-bit current source iDAC (32 values over four scales, minimum 50nA, maximum 10.32µA).
• Voltage reference: two scales (low scale 0.3V to 2.4V in steps of 0.3V, high scale 0.4V to 3.2V in steps of 0.4V).

You may want to make your circuit block optionally self-biasing based on a configuration input. That allows a designer using your block to run it completely self-contained at the likely expense of some performance.

The original test chip tapeout used an SPI interface to a digital bus much like the “logic analyzer” on Caravel, but with 128 bits output (control) and 128 bits input (status). I want to avoid turning it into a full microcontroller like Caravel, but I will probably add features to it such as a sequencer, data capture, and routing to dedicated digital outputs; the number of outputs will double so each project can get 16 bits. But it may make more sense for projects to get a larger shared bus of, say, 32 bits, in addition to a handful of signals for power-up and enable that would be unique to each project. Ideas for what this control/status interface should look like are welcome.

There will be a dedicated power-on signal for every slot driving the power pFET switch. An additional digital enable is encouraged on every block, but would simply use one line of the digital bus for this purpose.

This is related to analog pin sharing. I will need to think carefully about how to allot pads to projects. I have an “openframe” design that allows each pad type to be selected automatically. I could allocate 2 dedicated pins per project, or 4 shared pins per project, or some combination, including some number of pins available to many projects. The proposal must have a list of I/O pins used by the project and should note where pins may or may not be multiplexed, so I can allocate pins around the padframe accordingly.

Short answer: you can request a dedicated digital input pin for your project.

You will be limited to the current set of available IHP pads, so please check the pad library documentation. Building your own high-speed driver is discouraged for the first run, since that adds an untested/uncharacterized block to the path of your untested/uncharacterized project. An output divider is preferred.

The power switch on my IHP test tapeout simulates as nominally 1.4 ohms. The waffle pFET is automatically drawn, so I can make it any reasonable size needed. I will probably upsize it a bit to get the nominal resistance below 1 ohm, so you can assume that.

Like the power pFET, the switch resistance can be made as low as needed, within reason. I did not have the time to put a multiplexer on my IHP test chip, but the equivalent multiplexer on the sky130 Chipalooza test chips had a nominal resistance of 220 ohms. There should be plenty of room on the test chip, so I will upsize this to get the nominal resistance down to 50 ohms for the IHP tapeout.

IHP is offering packaging of parts with a standard 64-pad frame in QFN packages, which is my preferred solution. A board solution like Wafer.Space has with the 140-pin mezzanine connector is a good choice, especially if I can get Tim Ansell to sell assembled break-out boards on the Wafer.Space site. If I can get that done, I will design a board much like the Chip Foundry Caravel development board, with a USB-to-SPI interface, but otherwise simpler and more analog-friendly.

I think the full corner set is available for sg13cmos5l, although whether every available device is modeled at all corners, I don't know. Magic has high/low/typical corners for resistance and capacitance extraction. I would assume commercial spec. The IHP standard cells are characterized for 1.08V to 1.65V and −40°C to +125°C, although if hitting the high temperature corner is difficult, +110°C is probably acceptable. Given that the target application for the IP blocks is to fit in a digital SoC system, going outside these ranges is unnecessary. The last time I looked, I only saw one set of standard cells for sg13cmos5l, characterized at both 1.2V and 1.5V. I would assume 1.2V as the target, assuming that's what people are designing SoCs to operate at on the sg13cmos5l process.

Try to keep the block to as few metal layers as you can, since the goal is for blocks to be used in SoCs, and they typically want free access to the top two metal layers for power routing. But digital place & route can work around macros, so I would not hesitate to add metal 4 to a MoM cap to increase capacitance instead of increasing circuit area. Note that the top thick metal layer is practically useless for fingered MoM caps anyway, due to the large spacing requirement.

Be aware that fill will be placed throughout your block automatically, so use fill block if you need it, or, preferably, create your own fill (e.g., fill empty space with power- and ground-connected metal that acts as supply decoupling, which will be handled by R-C extraction and accounted for in simulation). Large areas of fill block are problematic, so avoid them if possible.

Yes, a team can submit more than one proposal, and can prepare more than one design. However, there are a limited number of awards and limited space on the test chip, so if there are multiple projects of the same type with similar specifications, possibly only one of them will make it to tapeout.

The plain-text files will just be informational, probably just simple markdown or even just “key: value” pairs; although it's more likely that a template Makefile will be added with a simple API covering the basic steps of generation and validation, such as make run-drc or make run-corner-sims or something like that.

I hope the EDA tools have now developed to a state where everything operates smoothly no matter where a PDK is located, as long as the environment variables PDK_ROOT and PDK are set and the tools are in the executable path such that typing klayout or xschem finds the tools without having to type the full path. Use of IIC-OSIC-TOOLS or ciel is encouraged—although, of course, there's always a soft spot for those who compile all tools from scratch and run them locally regardless of the pain threshold. For the record, the sign-off system is most likely going to be using IIC-OSIC-TOOLS.

Yes, of course the challenge is open to international participants! There wouldn't be much point in it otherwise.

The plan is to have packaged chips assembled onto daughterboards and mailed to the designers along with a test board. Since all designs will be on the same chip, any of the designers can in principle test everybody else's circuits, so those who have good instrumentation on hand are hoped to be willing to do more of the testing.

As Open Circuit Design is based in the United States, shipping from here will be subject to U.S. ITAR restrictions. However, it may be possible for participants to get packaged parts directly from IHP under E.U. rules.

At least for now, send all proposals by email to chipalooza@opencircuitdesign.com.