Chipalooza submission requirements and guidelines: Following these requirements and guidelines will ensure consistency across IP blocks, and ensure that IP can quickly be integrated into chipIgnite slots for the April tapeout. Proposal Proposal must be in PDF format unless otherwise approved (assuming that most formats will export PDF). Provide (short) CVs of designers, separately from the proposal Specify the IP block to be designed Specify the architecture to be used and how the specification will be achieved Indicate any likely challenges (e.g., difficult-to-meet specification) Specify any resources needed (e.g., external current source) Any additional circuitry or test points required for measurement of the block as a standalone IP must be noted. External resources must be open source. Circuits from external sources may only be used outside of the IP (such as a testbench) unless it is part of Chipalooza (e.g., the current bias generator). If more than one IP block is proposed by the same group, rank by preference in case of duplicate proposals. Any departure from specified pinout must be noted (and approved). The proposal must contain a plan for how the IP block will be connected into a Caravel user project environment, and how it will be tested and measured for characterization. The proposal may be submitted by posting to this channel or emailing to shuttle@efabless.com Proposals (but not CVs) will be publicly posted once all are received, as a placeholder for the public repository. After acceptance, proposals should be placed in the repository documentation. Repository Once a proposal has been accepted, each designer will create an open source (public) git repository and maintain it with the contents of the design. The git repo should ignore all large files that can be regenerated on demand, such as simulation data (ngspice raw files). Always commit any updates before any challenge milestone, and be prepared to make commits on demand as requirested by the challenge directors. Schematic All schematics will be done in xschem All schematics need title, date, version, and authorship Preferably use official title block (to be provided) IP block will contain no non-physical components other than simulation test points (e.g., zero-volt source) All IP components representing physical devices will be from the sky130A symbol libraries. All power and ground supplies will be explicit with the exception of any standard cells used, which may parameterize the power supply names. Testbenches will be separate schematic drawings. Every testbench will instantiate the same IP block symbol. Schematics should be clean and well organized. Independent sub-blocks should be put in their own schematic and instanced by symbol. Maintain one testbench schematic per electrical parameter being tested. Simulation All electrical parameters given in the IP block specification must be simulated. Schematic-captured netlist must meet all specifications. Specifications may only be redefined with agreement from Efabless. Simulations will be done in ngspice version 42 Any mixed-signal simulation will be done with ngspice Datasheet Simulation results must be presented in a datasheet format The datasheet may be in any format that can be viewed from the git repository. Datasheet will contain all electrical parameters and conditions as found in the spec All electrical parameters will have min/typ/max values as required by the spec. All plots defined in the spec will be included in the datasheet. Tentative layout floorplan should be provided with the datasheet at the time of the schematic design review. Layout All layouts will be done in klayout or magic The final form of the layout will be GDS. If designed in magic, all source .mag files will be included (including individual paramterized devices). All layouts will pass manufacturing rule DRC in klayout All layouts will pass full DRC in magic All layouts will pass LVS. All LVS will be done by extraction with magic followed by netlist comparison with netgen. Both schematic and layout must be extracted as subcircuits, including pins All layouts must have the origin placed on the lower left-hand corner of the bounding box The bounding box will be defined by the extent of geometry (but is represented by the prBoundary layer) The block should preferably occupy a compact rectangular area. Pins should be marked as ports and labeled. Pins should extend to the bounding box of the layout, or else must have a clear and ample routing path to the pin. Each power supply and each ground return must be on a single net. Pins must have ample surrounding space for auto-routing. Normally this means 2x the minimum metal distance between pins. All analog circuitry will be placed in a deep-nwell structure and surrounded by double guard rings. Pins positions will match the floorplan, if provided in the specification. Otherwise, assume a standard orientation of the block, and pins should be on the preferred route layers: m2 and m4 for pins on top and bottom; m1 and m3 for pins on right and left. The preferred layers for signal pins are m2 and m3. Maintain the exact pin names given in the specification. Maintain the same hierarchy between schematic and layout (to the extent that makes sense; "pcells", for example, are usually a layer of hierarchy in the layout that does not appear in the schematic) Simulation All circuits will be extracted with full R-C parasitics for post-layout simulation All layout must be flattened for R-C parasitic extraction, but the flattened layout should never be used to generate GDS. Datasheet The final datasheet must have results taken from R-C extracted post-layout simulation.

The metal layer limitations will be a problem for MiM caps.

@Luis Henrique Rodovalho: The metal layer limitations were not intended to apply to IP that requires MiM capacitors. It was meant to prevent designs from unnecessarily routing up in higher metal layers. Maybe I should re-word that statement. Many of these IP are pretty high-performance and aren't going to tolerate any random power routing over the top and will want to precisely control the structure of metal over the IP block.