eFuse compiler ============== The GF180MCU eFuse compiler is an open-source tool for generating non-volatile one time programmable (OTP) memory blocks based on `eFuse cells `_ for the GlobalFoundries GF180MCU technology. Source code is hosted on GitHub under the Apache-2.0 license: https://github.com/egorxe/gf180_efuse_compiler . .. attention:: eFuse IPs generated by the compiler are not ASIC-proven yet, all the timings and other details in this document are preliminary. Installation ------------ The easiest way to get all the tools required to run the compiler would be using a Nix environment provided in the repository by running ``nix-shell`` (`LibreLane-compatible Nix `_ is required). Nix-environment is derived from the `wafer.space project template `_. Additionally the open source GF180MCU PDK should be installed and environmental variable ``PDK_ROOT`` should be set to it's location and variable ``PDK`` to specific PDK variant (for example gf180mcuD). The recommended way to install the PDK is either by cloning it from a `wafer.space repository `_ or by installing a latest one with the `ciel tool `_. If PDK_ROOT/PDK variables are not provided, the PDK is assumed to be located in the ``gf180mcu/gf180mcuD`` subdirectory in the compiler repository root. To clone the latest version of the compiler, wafer.space-provided PDK and start the Nix environment: .. code-block:: bash git clone https://github.com/egorxe/gf180_efuse_compiler cd gf180_efuse_compiler git clone https://github.com/wafer-space/gf180mcu nix-shell Alternatively it's possible to create a compatible environment on a Linux system manually by providing the following tools in the PATH: 1. Python 3.8+ with klayout package (0.29+, could be installed with pip). 2. KLayout 0.29+ (for DRC & LVS). 3. magic (any version compatible with GF180MCU PDK). 4. Xyce (7.8+). 5. LibreLane with recent GF180MCU support (3.0.0+). Capabilities ------------ The current version of the compiler is capable of generating eFuse memory IPs with several different interfaces. There are two basic eFuse blocks (`efuse_array` and `efuse_array_async`) and several digital wrappers around them. For each variant, a full set of files required for IP integration, such as LEF, GDS, SPICE and Verilog model files, is generated by the compiler. Liberty and SPEF files are generated only for IPs with digital wrappers. Compiler flow script supports automatic DRC/LVS and SPICE simulation verification of generated blocks, see :ref:`sec_general_cmd_args` for the details. Supported interfaces are described in the respective sections of the :ref:`sec_modules` chapter: 1. :ref:`efuse_array`. A building block for the synchronous eFuse arrays. Could be 16, 32, or 64 word deep, with a word of arbitrary width. 2. :ref:`efuse_wb_mem`. A synchronous eFuse memory block with the Wishbone bus interface. Width should be divisible by 8, and depth should be a power of 2. Generated as a digital wrapper for the `efuse_array`. 3. :ref:`efuse_spi_mem`. A synchronous eFuse memory block with the SPI interface. Currently, the width should be exactly 8, and the depth should be a power of 2. Generated as a digital wrapper for the `efuse_array`. 4. :ref:`efuse_array_async`. An asynchronous eFuse array with all eFuse bits stored in latches on read. Currently, the only supported width is 8, and the depth is always 1. 5. :ref:`efuse_async_mem`. Small digital wrapper around the `efuse_array_async` which automatically reads eFuse bits into latches once after reset deassertion. .. _sec_general_cmd_args: Command line parameters ----------------------- A flow script for the eFuse generation and verification, ``efuse.py``, is located in the repository root. It requires two mandatory parameters: basic eFuse block depth in words and a single word width. Important optional parameters are: * ``--async-efuse`` - selects asynchronous eFuse variant. * ``--digital-wrapper`` - selects a digital wrapper to generate. Available options are ``wishbone`` or ``spi`` for the synchronous eFuse and ``async`` for asynchronous. Defaults to none. * ``--digital-depth`` - selects depth for digitally wrapped blocks. Should be a multiple of basic block depth. Defaults to a single basic block depth. * ``--digital-width`` - selects width for digitally wrapped blocks. Currently, it is limited to the basic block width and should not be changed. * ``--skip-drclvs`` - by default the compiler flow will run the DRC and LVS verification of the basic eFuse block with KLayout. This option will disable these checks. * ``--xyce-netlist`` - controls which SPICE netlist will be used for the verification in Xyce analog transient simulation. Available options are none, schematic, extracted, pex, and all. By default, a parasitic extraction netlist is used. Currently for the synchronous eFuse variants only the basic block will be simulated in Xyce and for the asynchronous variant only the wrapped one, simulation will fail for asynchronous block without a wrapper. For example, to generate a minimal possible basic array with 16 1-bit eFuse words, run: ``./efuse.py 16 1`` To generate a 128x8 array with a Wishbone interface, skipping the Xyce verification, run: ``./efuse.py --digital-wrapper=wishbone --xyce-netlist=none --digital-depth=128 64 8`` To generate a 8-bit async eFuse block with a digital wrapper, run: ``./efuse.py --async-efuse --digital-wrapper=async 1 8`` Output files ------------ Runtime files will be produced in the temporary ``runs`` directory, and resulting output files will be copied to the ``macros`` directory. In ``runs``, the subdirectories with names derived from the run start times are created for each run, and the latest is always referenced by the ``last`` symlink. In the ``macros`` directory, output files are arranged by the resulting basic blocks. For the first example in the previous section, all output files will be stored in ``macros/efuse_array_16x1``. Outputs include: GDS, LEF, SPICE (generated schematic and from magic PEX), and Verilog (behavior model and blackbox) files. With the digitally wrapped blocks, a file structure will be slightly more complex. Output files for the basic block will still be present in the same subdirectory of ``macros``, but the resulting IP with a digital wrapper will be stored one level deeper. For the second example in a previous section, the output files will be in ``macros/efuse_array_64x8/efuse_wb_mem_128x8``. On each successful run completion, the previous output files in the corresponding macro subdirectory will be automatically rewritten, if they existed, keeping only the digital wrapper subdirectories with parameters different from the last run.