The official name of this challenge is “Chipalooza Challenge #3 (Wafer.Space GF180MCU)”, informally “Wafer.Space (1)” or “GF (1)”. All designs must conform to all requirements of the GF180MCU process: DRC, voltage limits, and so on.

  1. The official start date for Chipalooza Challenge #3 is Monday, August 17, 2026.
  2. The challenge is 18 weeks long, counting from the start date and ending on the tapeout date.
  3. Designers may work as individuals or as a team. It is preferable to keep teams to three people or fewer, but this is not a requirement.
  4. Proposals are due two weeks from the start of the challenge: August 31, 2026.
  5. Proposals need to provide the following:
    1. The type of IP block
    2. List of I/O, including test ports
    3. Functional description of the IP block
    4. A target specification with all relevant characteristics, including average, minimum, and maximum values (as appropriate), and absolute limits
    5. An outline of a test plan for validating the IP block through measurement
    6. List of any equipment available for use in testing (sent separately from the proposal)
    7. CVs of the designers (sent separately from the proposal)
    Personal and institutional details are left out of the main proposal document; that document ultimately becomes part of the IP block's documentation in its repository.
  6. The proposed IP block should be useful within the context of a system-on-chip (SoC). This includes all IP blocks created for the Efabless Chipalooza Challenge #1, as well as additional useful blocks like PLLs, programmable filters, etc. Designers may assume availability of the following external resources:
    1. Supply voltages at 3.3V (digital) and 5.0V (analog)
    2. A bandgap-referenced bias voltage
    3. Up to 2 bandgap-referenced current sources
    4. Up to 24 digital controls (inputs) and 12 digital test signals (outputs) as needed
    5. Up to 4 shared analog signal lines (multiplexed by project)
    6. Up to 4 dedicated pins, which may be any digital or analog pad from the pad library
    Any exceptions to this resource list need to be approved.
  7. The target specification of the circuit is up to the designer, but should be good enough to be attractive to an SoC designer looking for an IP block to use within a system. The design will need to meet the given specification in post-layout verification. Changes to the target specification mid-design must be approved.
  8. The harness chip will be designed with a 3.3V logic library and a dual 3.3V core, 5.0V periphery pad library. Analog designs which expect to operate over the voltage range of the periphery should be designed to operate between 3.3V and 5.0V, but may operate at a relaxed specification at 5V if needed.
  9. Up to 18 designs can be accommodated on a single test chip. The ratio of submitted proposals to completed designs is unknown, so more proposals may be accepted than will fit on the test chip. If more designs are completed through layout and final verification than the test chip can accommodate, some designs may be delayed to the second Wafer.Space challenge (a 1-year delay).
  10. Every design must be put in a public git repository: GitHub, GitLab, Codeberg, or any other, as long as it is publicly accessible. The repository must contain all files needed to completely reproduce and verify the IP block, as well as use it as a component in a larger system.
  11. The design must be verifiable with open source EDA tools. This does not prevent the design from being created with commercial tools, but if the project cannot be verified as meeting specifications with open source tools, it will be rejected. AI may be used in support of circuit design but must not be a requirement for the end user of the IP block to use, verify, or modify it.
  12. All source files needed to generate all views of the design must be available in the repository. It must be possible for anyone using the design to modify it as needed for their purposes, using open source EDA tools.
  13. The full behavioral description of the circuit must be documented, with documentation available in the repository. Documentation may be in any reasonable format: plain text, markup, LibreOffice, PDF, etc. Some plain-text files (TBD) will be required for automated handling of the IP blocks for top-level chip integration.
  14. Avoid putting unnecessary data dumps into the repository. Sign-off data is required (final DRC and LVS results). Simulation results should be summarized in plots, not raw data; but it must be possible to reproduce the raw data from the design sources in the repository on demand.
  15. Every design must be licensed under a standard open source license, preferably Apache 2.0. Other similar licenses will be considered. In no case may a design use sources that would violate the terms of the source's license or the Apache 2.0 license.
  16. Every design should follow the repository template (once available). Every attempt will be made to keep the template as flexible as possible. The repository template will contain scripts for running basic sign-off verification, runnable by anyone cloning the repository, showing a verified result.
  17. Post-layout designs must be verified over PVT corners for commercial spec (maximum 110°C is acceptable; a wider spec is obviously preferred).
  18. Layout will be restricted to the size of slots available on the test chip assembled for tapeout. The slot size and I/O configuration (TBD) will be specified in the template repository, with a template layout for the “wrapper” cell around the project IP block. The designer is responsible for wiring up the IP block inside the wrapper cell.
  19. Project designs may need to share one or more analog pins through analog multiplexers (up to four shared signals available). Any limitations on the amount of resistance between the pad and project should be noted, so multiplexer switches can be designed accordingly. Approval needs to be given for any project requiring sole access to a pin (analog or digital), because the harness chip is pin-limited and design slots vary in the number of dedicated pins from zero to four.
  20. The harness (test) chip will be located at gf180mcu_ocd_chipalooza and will be fully documented, describing the SPI interface, the allocation of resources to each project, the chip pinout, and other information.
  21. The challenge stages are gated by reviews:
    1. Proposal review (week of August 31)
    2. Schematic design and pre-layout simulation review (week of October 5)
    3. Layout design and post-layout simulation review (week of November 2)
    4. Final design review (week of November 23)
  22. Designs not ready for tapeout by the final design review will not make it to Wafer.Space tapeout.
  23. Awards will be given for completed designs. The award schedule will be posted shortly after this challenge launch (around August 23).
  24. Any updates that modify the terms of the challenge will be announced in the fossi-chat.org/#Chipalooza forum. There will be updates regarding specifics of layout and test which have yet to be determined (see the “TBD” items above).

How is this different from Challenge #2? The resource list, pin budget, and voltage rails are specific to the GF180MCU process and the Wafer.Space harness chip. See Challenge #2's rules for comparison if you are working across both processes.