Documentation

Guide How to: integrate ASIC technology into ESP

Latest update: 2023-09-19

This guide illustrates how to setup your ASIC project and how to integrate ASIC technology into ESP. At this moment, ESP memory integration supports only accelerators integrated into ESP using Stratus HLS. Refer to the guide How to: design an accelerator in SystemC (Cadence Stratus HLS) in the case you need a new accelerator integrated.

Note: Make sure to complete the prequisite tutorials before getting started with this one. This tutorial assumes that designers are familiar with the ESP infrastructure and know how to run basic make targets to create a simple instance of ESP, integrating just a single core.

0. Prerequisites

ASIC technology integration requires at least the Verilog and the Liberty models/views for high level synthesis (HLS) and RTL simulation.

1. Project setup

The ESP FPGA flow uses the FPGA specific board under <esp>/socs as working directory for the SoC configuration, simulation, FPGA prototyping and validation. The ESP ASIC flow, instead, creates a directory structure outside the ESP repository. The directory structure has two main folders in addition to the ESP repository: technology folder and project folder. The technology folder has four directories: lib for memories, standard cells and gpio liberty files, verilog for memories, standard cells and gpio verilog models, mem_wrappers for the memory wrappers, and pad_wrappers for the IO wrappers. The project folder is the design working directory for the SoC configuration, RTL simulation and all ASIC flow downstream steps.

To create the ASIC directory structure execute the following steps:

# Create the main folder for your project and move the folder
mkdir project_x
cd project_x

# Clone ESP repository
git clone git@github.com:sld-columbia/esp.git

# Update the submodules
cd esp
git submodule update --init --recursive

# Move to asicgen folder
cd esp/tools/asicgen

# Edit the file asic_defs.sh with your project version and technology used
vim asic_defs.sh

DIRTECH_NAME="sky130"
PROJECT_NAME="projec_x_v1.0"

# Execute asic_dirstruct.sh script
./asic_dirstruct.sh


Once you have executed the steps above the project directory structure will be as follows:

project_x
├── project_x_v1.0
│   ├── Makefile             
│   ├── ESP_ASIC_TOP.vhd     # ESP top level RTL
│   ├── chip_emu_top.vhd     # ESP top level wrapper to enable FGPA emulation
│   ├── esp_defconfig        # ESP SoC default configuration
│   ├── fpga_proxy_top.vhd   # FPGA proxy
│   ├── grlib_config.in
│   ├── grlib_defconfig      
│   ├── pads_loc.vhd         # default pad types (horizontal = 1 vertical = 0)
│   ├── vsim.tcl             # Modelsim script for simulation using DCO
│   ├── systest.c            # main system simulation output
│   ├── testbench.vhd        # Top level testbench
│   └── top.vhd              # Top level composed by chip_emu_top and fpga_proxy_top
├── sky130
│   ├── lib                  # Technology folder for liberty files
│   ├── verilog              # Technology folder for memory verilog models
│   ├── dco_wrappers         # DCO verilog wrappers folder
│   ├── mem_wrappers         # Memory verilog wrappers folder
│   └── pad_wrappers         # IO verilog wrappers folder
└── esp      


From now on, project_x_v1.0 is the working directory folder and the esp repository will be used ASIS.

Note: Do not create the directories manually, use the script for that!!!

Back to top

2. Memory integration

Memories are pervasive in ESP. They can be found in the IO tile for bootrom, in the CPU tile for L1 and L2 cache hierarchies, in the MEM tile for shared L3 cache hierarchy, in the accelerator tile for private local memory, and in the SLM tile for higher on-chip memory capacity. In this guide we will integrate ASIC memories into ESP, configure a SoC and perform RTL simulation stressing all tile types that have memories. This guide uses open-source memories generated by OpenRAM targeting Skywater 130 nm technology to exemplify the flow. The user, however, can follow this guide with the technology of your preference.

ESP memory requirements

Although we work hard to make ESP as flexible as possible, ESP architecture has a few memory requirements listed below for each tile.

IO/AUX tile:
Two dual ports (1R1W) memories. The first of the size of 4096 addresses and 16 bits word length (4096x16). The second of the size of 256 addresses and 32 bits word length (256x32). They can be register files instead of memories.
One single port memory of 2048 addresses 8 bit word length (2048x8).

CPU tile:
One single port memory of 256 addresses and 64 bits word length (256x64) for Ariane L1 cache.
One single port memory of user choice address size and 64 bits word length for L2 line cache.
One single port memory of user choice address size and 24 bits word length for L2 mixed cache. This memory must support single bit write mask.

MEM tile:
One single port memory of user choice address size and 64 bits word length for L3 line cache.
One single port memory of user choice address size and 28 bits word length for L3 mixed cache. This memory must support single bit write mask.
One single port memory of user choice address size and 16 bits word length for L3 shared cache.

Note: The user address size for L2 and L3 caches must match. For instance, if a 256 address size is choosen for L2 line cache, the same address size has to be used for L2 mixed caches and all L3 level caches.

SLM tile:
One single port memory of user choice address size and 64 bits word length.

Accelerator tile:
The number of memory ports will depend on the accelerator used. The memory size, however, is flexible. ESP identifies all memories available for accelerators to automatically generate memory banks aiming to minimize memory area. According to the accelerator, some memory sizes will have a better performance and area efficiency. We suggest to have different memory sizes available for both types, dual and single ports. For instance: 256x8, 256x16, 256x32, 256x64, 512x32, 512x64, 1024x32, 1024x64.

Back to top

Technology setup

Once you have generated all required memory macros for your target technology, you should copy/link the models to the respective folder in the project. In this guide we use soft links to avoid having multiple copies of the technology files.

Link the memory verilog models inside project_x/sky130/verilog:

project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_dp_256x32/sky130_sram_dp_256x32.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_dp_4096x16/sky130_sram_dp_4096x16.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_dp_512x32/sky130_sram_dp_512x32.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_sp_2048x8/sky130_sram_sp_2048x8.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_sp_256x64/sky130_sram_sp_256x64.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_sp_512x16/sky130_sram_sp_512x16.v
project_x/sky130/verilog > ln -sf /tech/sky130/memories/sky130_sram_sp_512x64/sky130_sram_sp_512x64.v
project_x/sky130/verilog > ln -sf /tech/sky130/libraries/sky130_fd_sc_hs/latest/verilog/sky130_fd_sc_hs__tt_025C_1v80.v
project_x/sky130/verilog > ln -sf /tech/sky130/libraries/sky130_fd_io/latest/verilog/sky130_fd_io__top_gpiov2.behavioral.v


Link the memory liberty models and the standard cell liberty model inside project_x/sky130/lib:

project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_dp_256x32/sky130_sram_dp_256x32_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_dp_4096x16/sky130_sram_dp_4096x16_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_dp_512x32_1r1w/sky130_sram_sp_512x32_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_2048x8/sky130_sram_sp_2048x8_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_256x64/sky130_sram_sp_256x64_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_512x16/sky130_sram_sp_512x16_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_512x24/sky130_sram_sp_512x24_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_512x28/sky130_sram_sp_512x28_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/memories/sky130_sram_sp_512x64/sky130_sram_sp_512x64_TT_1p8V_25C.lib
project_x/sky130/lib > ln -sf /tech/sky130/libraries/sky130_fd_sc_hs/latest/timing/sky130_fd_sc_hs__tt_025C_1v80.lib
project_x/sky130/lib > ln -sf /tech/sky130/libraries/sky130_fd_io/latest/timing/sky130_fd_io__top_gpiov2_tt_tt_025C_1v80_3v30.lib


Note 1: In this guide, we use a dual port 32 bits word length memory to replace the single port 28 bits word length memory for illustration purpose only.
Note 2: In this guide, we use single corner liberty to keep the guide short. We highly recommend, however, to link multiple liberty corners to enable multi-mode multi-corner timing analysis.

In the next section we will generate the memory wrapper skeletons and edit them to comply the ESP expected memory protocol with OpenRAM memory generated protocol.

Back to top

ASIC memory list file

The memory wrapper skeletons are automatically generated based on the asic_memlist.txt specification file. The user needs to create this file in the project working directory (project_x/project_x_v1.0) compliant with the following syntax:

<type> <macro_name> <addr_size> <word_size> <area> <port_type>

Where:
<type> is the tile type (llc, l2, l1, slm, io, acc)
<macro_name> is the memory model module name
<addr_size> is the wrapper number of addresses
<word_size> is the wrapper word length
<area> is the memory model area
<port_type> is the number of memory model port (dual or single)


Following an example of the asic_memlist.txt for the sky130 memories.

llc sky130_sram_sp_512x64 512 64 283536 single
llc sky130_sram_dp_512x32 512 28 294077 dual
llc sky130_sram_sp_512x16 512 16 110981 single
l2 sky130_sram_sp_512x64 512 64 283536 single
l2 sky130_sram_sp_512x24 512 24 128492 single
l1 sky130_sram_sp_256x64 256 64 175672 single
slm sky130_sram_sp_512x64 512 64 283536 single
io sky130_sram_dp_4096x16 4096 16 913452 dual
io sky130_sram_dp_256x32 256 32 197460 dual
io sky130_sram_sp_2048x8 2048 8 267554 single
acc sky130_sram_dp_256x32 256 32 197460 dual
acc sky130_sram_dp_512x32 512 32 294077 dual
acc sky130_sram_sp_512x64 512 64 283536 single


Note: Even though a dual port 32 bits word length memory is being used for the L2 mixed cache, the address size in the file remains 28 bits word length.

Once this file is ready, execute the following command:

project_x/project_x_v1.0 > make mem_wrapper


A file called cache_def_mem_asic.v is generated in the working directory in addition to the memory wrapper skeletons in project_x/sky130/mem_wrappers.

In the next section we will edit the wrappers connecting the memory macro ports to the memory wrapper ports.

Back to top

Memory wrappers edition

Move to the directory project_x/sky130/mem_wrappers. Under this directory you will see the following files:

LLC_SRAM_SP_LINE_512x64.v
LLC_SRAM_SP_MIXED_512x28.v
LLC_SRAM_SP_SHARED_512x16.v
L2_SRAM_SP_LINE_512x64.v
L2_SRAM_SP_MIXED_512x24.v
L1_SRAM_SP.v
SLM_SRAM_SP_512x64.v
IO_DP_4096x16.v
IO_DP_256x32.v
IO_SP_2048x8.v
ACC_SRAM_DP_256x32.v
ACC_SRAM_DP_512x32.v
ACC_SRAM_SP_512x64.v
llc_lib.txt
l2_lib.txt
l1_lib.txt
slm_lib.txt
io_lib.txt
acc_lib.txt


The library text files (<mem>_lib.txt) gives the user the control of which memories to use according to the memory type. For instance, if there are several memories with different sizes available for accelerators but the user wants a specific memory for the FFT accelerator, it is just comment out all other memories in the acc_lib.txt file. This will force ESP to use only the uncommented memories for the FFT accelerator. By default, ESP selects the memory that gives the smaller area for each tile type.

Each memory wrapper skeleton, shown below for the ACC_SRAM_DP_256x32, has the module name, its inputs and outputs compliant with ESP, the memory macro instantiation and a commented glue logic the user can adapt to match the ESP and the technology dependent memory macro protocols.

ESP expects single cycle memories compliant with the following protocol for single and dual port memories:

Single Port

Port name Diretion Active Description
CLK0 Input N/A Clock port 0
CE0 Input High Chip enable port 0
A0 Input N/A Address port 0
Q0 Output N/A Output data port 0
WE0 Input High Write enable port 0
WEM0 Input High Write mask enable port 0
D0 Input N/A Input data port 0

Dual Port

Port name Direction Active Description
CLK0 Input N/A Clock port 0
CE0 Input High Chip enable port 0
A0 Input N/A Address port 0
Q0 Output N/A Output data port 0
CLK1 Input N/A Clock port 1
WE1 Input High Write enable port 1
WEM1 Input High Write mask enable port 1
A1 Input N/A Address port 1
D1 Input N/A Input data port 1

Following the final edited wrapper for the memory generated by OpenRAM targeting Skywater 130 nm technology.

The user has the freedom to change all memory wrappers body to integrate its memory macros. This include instantiating multiple memory macros to compose a single wrapper. The module name, input and output ports, however, must remain the same.

In our example above for the LLC mixed cache, for instance, we are using only 28 bits of data and setting the remaining most significant bits to zero in the memory macro interface.

Once the memory wrappers are completed, the memory integration is ready. The next section will detail a similar process for the technology IO cells integration.

Back to top

3. Pad integration

For each technology, there are different IO cells according to its functionality and vendor. Therefore, support all interfaces that can exist for each cell type, vendor and technology is a challenging task. ESP supports the basic digital IO cell interfaces for inputs, outputs and bi-directional ports. ESP also has an additional 3 bits interface (CFG) for outputs that can be changed through CSR. Even though this interface was added with slew rate and drive strength configuration in mind, the user has freedom to use for other purposes.

The following sections details the IO cells integration process starting from the pad wrapper skeletons generation and finishing with the wrappers edition.

ASIC pad list files

The pad wrapper skeletons are automatically generated based on the asic_padlist.txt specification file. The user needs to create this file in the project working directory (project_x/project_x_v1.0) compliant with the following syntax:

<direction> <macro_name> <location>

Where:
<direction> is the pad type (in, out, io)
<macro_name> is the pad model module name
<location> is the location of the pad (H for horizontal, V for vertical)


The location follows the illustration:

  _____________
 |\           /|
 | \   V(0)  / |
 |  \       /  |
 |   \     /   |
 |    \   /    |
 |     \ /     |
 | H(1) \ H(1) |
 |     / \     |
 |    /   \    |
 |   /     \   |
 |  /       \  |
 | /   V(0)  \ |
 |/___________\|


Following an example of the asic_padlist.txt for the sky130 gpiov2 pads. .

in sky130_fd_io__top_gpiov2 H
in sky130_fd_io__top_gpiov2 V
out sky130_fd_io__top_gpiov2 H
out sky130_fd_io__top_gpiov2 V
io sky130_fd_io__top_gpiov2 H
io sky130_fd_io__top_gpiov2 V


Note: All direction (in/out/io) and both types (H/V), are required. Since sky130 gpiov2 has only one inout model that can be configured in the three directions, we specified the same macro module in all six models.

Once the file is created, the user can generate the pad wrapper skeletons by running the following target:

project_x/project_x_v1.0 > make pad_wrapper


We provide a default file, pads_loc.vhd, that configures which pad, H or V, is used for each IO signal. The default file accounts for one Memory tile instantiation only. If the user would like to use more than one Memory tile or would like to change the pad configuration (H and V), a customized file has to be generated.

We provide a make target that generates the VHDL file based on a text file (pads_loc.txt) with the following format:

<signal> <index> <location>

where:
<signal> is the design port
<index> is the index of the port if it is an array
<location> is the location of the pad (0 for V and 1 for H)


Following is an example of the pads_loc.txt.

clk_div_acc0 0 0
clk_div_acc1 0 0
clk_div_cpu 0 0
dummy 0 0
erx_clk 0 0
erxd 0 0
erxd 1 0
erxd 2 0
erxd 3 0
erx_dv 0 0
etx_clk 0 0
ext_clk_acc0 0 0
ext_clk_acc1 0 0
ext_clk_cpu 0 0
fpga_clk_in 2 0
fpga_clk_in 3 0
...


To generate the customized pads_loc.vhd, run the target:

project_x/project_x_v1.0 > make pad_location


In the next section, we will edit the pad wrappers skeletons to be compliant with ESP IO protocol.

Back to top

Pad wrappers edition

Back to top

Move to the directory project_x/sky130/pad_wrappers. Under this directory you will see the following files:

INPAD_H.v
INPAD_V.v
IOPAD_H.v
IOPAD_V.v
OUTPAD_V.v
OUTPAD_H.v


Each pad wrapper skeleton, shown below for the IOPAD_H.v, has the module name, its inputs and outputs compliant with ESP and the pad macro instantiation.

ESP expects the pads be compliant with following protocol for input, output and bi-directional pads:

Input pads

Port name Diretion Active Description
PAD Inout N/A Pad inout port
Y Output N/A Chip input pin

Output pads

Port name Diretion Active Description
PAD Inout N/A Pad inout port
A Input N/A Chip output pin
CFG Input High Pad configuration (3 bits)

Bidirectional pads

Port name Diretion Active Description
PAD Inout N/A Pad inout port
Y Output N/A Chip input pin
A Input N/A Chip output pin
OE Input High Pad output enable pin
CFG Input High Pad configuration (3 bits)

The CFG is controlable by CSRs and can be used to configured the pad drive strength, slew rate, or any other option available in the pad model. Its default value (on reset) is 011.

We illustrate below the final edited pad wrappers. Since the pads of location H and V have the same interface, we are illustrating only one of them.

Input pad

Output pad

Bi-directional pad

Bear in mind that. in the example above, some pad inputs are in different power domain than the core (VDDC and VDDHIB). HLD_H_N, ENABLE_H, and ENABLE_INP_H are in the VDDIO power domain. ENABLE_VSWITCH_H is in the VSWITCH power domain. We tied them to high or low because the verilog model requires for correct simulation. Therefore, this configuration is for simulation purpose only and, for logic synthesis and downstreams physical design steps, these ports should be connected to their appropriate power domain.

The user has the freedom to change all pad wrappers body to integrate its pad macros. The module name, input and output ports, however, must remain the same.

In these examples, we used only one bit of CFG to control the output slew rate. The usage of all 3 bits will depend on the pad configurability and on the user decisions.

Back to top

4. SoC generation

Once all technology models, liberty and verilog, are in the respective folders and the memory and pad wrappers are completed, ESP SoC can be generated. In this tutorial, we are going to generate a SoC with the following tiles: IO, CPU (Ariane), MEM, SLM, and Acc (FFT).

The first step is to run High Level Synthesis of FFT to have a RTL based on the technology standard cell and memory timing models linked in project_x/sky130/lib. Then, we will generate the ESP SoC as usual. Finally we will simulate all tiles in our SoC.

HLS using ESP integrated FFT accelerator

To run HLS, execute the following command under project_x/project_x_v1.0:

project_x/projec_x_v1.0 > make fft_stratus-hls


ESP will run HLS for the already integrated FFT accelerator and will use the memory wrappers to generate the Private Local Memory (PLM) specified under project_x/esp/accelerators/stratus/fft_stratus/hw/memlist.txt.

The HLS results are saved in project_x/esp/tech/sky130/acc and project_x/esp/tech/sky130/memgen.

Back to top

SoC configuration

The next step is to configure ESP SoC. Run the following command under project_x/project_x_v1.0 to call the ESP graphical interface:

project_x/project_x_v1.0 > make esp-xconfig


The composition of the SoC will have one IO tile, one MEM tile, one CPU (Ariane) tile, one SLM tile and one Acc (FFT) tile according to the image below.

Note we changed the size of the shared local memory to 64KB. The user can specify a range of sizes in the graphical interface and ESP will generate memory banks according to the SLM memory wrappers available in project_x/sky130/mem_wrappers/slm_lib.txt.

Once the SoC is configured, click in generate and close the window.

To generate the SLM banks with the size specified in the configuration, run the following step:

project_x/project_x_v1.0 > make mem_slmgen

The user can find the generated bank under project_x/esp/tech/sky130/memgen/slm_gen.

ESP is now ready for RTL simulation.

Back to top

SoC RTL simulation: main system

The first simulation will confirm the IO tile, the CPU tile and the MEM tile are working properly. This simulation loads the bootloader into IO tile. Then, the IO tile starts the CPU tile which reads the bootram and executes read (instruction/data) and write (data) requests to the MEM tile. The MEM tile accesses the external memory according to the CPU tile requests. If the simulation succeed, a “Hello from ESP” message will show in the prompt.

Run the following command to execute the Modelsim simulation and confirm all memories were properly integrated.

project_x/project_x_v1.0 > make sim


Once all files were compiled and loaded, execute the simulation in Modelsim:

VSIM 1> run -all


Differently from FPGA, ASIC simulation does not have a simulation stop. Hence, type “ctrl c” to have Modelsim terminal back and close the tool.

Back to top

SoC RTL simulation: accelerator

The second simulation will test the accelerator functionality in the SoC. This simulation invokes the accelerator baremetal program which directly accesses the MEM tile to read and write data. Three memory coherence protocols are tested: Non-coherent DMA, LLC-coherent DMA, and Coherent DMA.

Run the following commands to simulate the accelerator:

project_x/project_x_v1.0 > make fft_stratus-baremetal
project_x/project_x_v1.0 > TEST_PROGRAM=soft-build/ariane/baremetal/fft_stratus.exe make sim

VSIM 1> run -all


The prompt will state “PASS” for the three coherence modes. You can execute the same steps from previous section to close the tool.

Back to top

SoC RTL simulation: shared local memory

Lastly, if your ESP configuration has the SLM tile, run the following command to confirm the memories integrated into SLM can be read and write properly:

project_x/project_x_v1.0 > make slm_rw_test-baremetal
project_x/project_x_v1.0 > TEST_PROGRAM=soft-build/ariane/baremetal/slm_rw_test.exe make sim
VSIM 1> run -all


The prompt message “Completed with 0 errors” confirms the test succeeded.

Back to top

5. Clocking strategy and DCO integration

There are several ways to provide the clock for the SoC. The simplest one is having a single clock for the whole system driven by an external (off-chip) oscillator. There are other factors in play, however, that can require more complex clocking schemes. For instance, SoCs that must operate in higher frequencies (GHz) need to generate the clock internally. In addition large SoCs can have blocks operating in different frequencies, demanding a clock divider or their own clock generator.

This section details the clocking strategy options ESP supports and a Digital Clock Oscillator (DCO) specification and integration for high speed SoCs.

Clocking strategy

ESP supports three main clock strategy:

  • Dual external: One clock source for the tiles and one for the NoC; both tiles and NoC clock sources are driven externally
  • Multi DCO: Each tile has its own DCO. Similarly, the NoC has its own DCO located inside the IO tile
  • Single DCO: There is only one DCO in the IO tile clocking the full SoC

In the ESP configuration GUI the user can select each of these strategies. According to the selection, a message will appear in the white box below detailing the selected configuration.

The user can also specify the clock relationship between the NoC and the tiles. By selecting the “has synchronizer” box, ESP understands the NoC communicates asynchronously with the tiles and automatically inserts an asynchronous FIFO in their interfaces.

Except for the “Dual external” clocking strategy, the option we used for RTL simulation above, the user needs to provide a DCO mapped to the target technology compliant to ESP specification. The following sections details the DCO specfication and its integration to ESP for RTL simulation, logic synthesis, and place and route steps.

Back to top

DCO specification

ESP provides 21 mapped registers the user can leverage to configure its own DCO block. For reference, we provide in esp/rtl/techmap/inferred/ a technology unmapped example of a DCO we used in our projects. DCO_common.v has the primitives that need to be mapped to the target technology. DCO.v instantiates the primitives in the DCO top-level.

The following figure illustrates our reference DCO architecture:

The following table details the reference DCO interface:

Port name Diretion Active Description
RSTN Input Low Divider reset
EN Input High Enable the DCO oscillation
CC_SEL Input N/A Coarse tune bits, the larger the value, the lower the CLK frequency (6 bits)
FC_SEL Input N/A Fine tune bits, the larger the value, the lower the CLK frequency (6 bits)
EXT_CLK Input N/A External clock source (Backup clock)
CLK_SEL Input N/A Select clock: 0: DCO clock; 1: External clock
FREQ_SEL Input N/A Divider for tile clock. 00: DCO clk, 01: DCO÷2, 11: DCO÷4 (2 bits)
DIV_SEL Input N/A Divider ratio for test clock: 1: ÷2; 2: ÷4; 3: ÷8; …; 7: ÷128 (3 bits)
CLK Output N/A High-speed clock for tile logics
CLK_DIV Output N/A Divided clock. Routed off chip for testing

Regardless the user DCO architecture choice, Spice simulation of the technology mapped DCO is highly recommended for frequency and jitter characterization in corners.

Back to top

DCO integration

ESP treats the DCO as a macro block, similar to memories and standard cells. Therefore, it is expected the following views preferably generated after place and route stages:

  • DCO.v, DCO_common.v -> verilog used for RTL and netlist simulation
  • DCO_tt.sdf -> standard delay formar (SDF) used for RTL and netlist simulation
  • DCO.lib -> liberty view used for logic and physical synthesis
  • DCO.lef -> layout exchange format (LEF) used for logic and physical synthesis
  • DCO_pp.v -> verilog with power connections used for LVS
  • DCO.gds -> used for DRC and LVS

Following our example for “project_x” using the technology skywater 130nm, the DCO.v, DCO_common.v, and DCO_tt.sdf must be located at project_x/sky130/dco_wrappers. The DCO.lib in project_x/sky130/lib.

As long as the file and module names as well as the interface match the reference provided and the views are located in the specified folders, the DCO is automatic integrated into ESP.

Since the current document targets RTL integration only, the remaining views locations will be detail in the future.

Back to top

SoC RTL simulation: main system using DCO clocking

To enable Modelsim to simulate the DCO with the annotated delays the user needs to remove the comments inside project_x/project_x_v1.0/vsim.tcl to match the following:

#echo "Restarting simulation with SDF annotation for DCO and delay line"
set sdf ""
set TECHLIB $::env(TECHLIB)
set ESP_ROOT $::env(ESP_ROOT)
set VSIMOPT $::env(VSIMOPT)
foreach inst [find instances -nodu -bydu DCO] {
    append sdf "-sdfmax "
    append sdf [string map {( [} [string map {) ]} $inst]]
    append sdf "=${ESP_ROOT}/rtl/techmap/${TECHLIB}/dco_wrappers/DCO_tt.sdf "
}
append sdf "-suppress 3438"
eval vsim $sdf $VSIMOPT


Similar script can be used for XCelium simulator.

The RTL simulation targets are the same detailed in previous section. For “Hello from ESP” simulation, for instance, execute:

project_x/project_x_v1.0 > make sim


Back to top