u/OurLordX

I'm running a CV32E40P-based SoC through the open-source ASIC flow using LibreLane 3.0.6, sky130A, and sky130_fd_sc_hd, and I'm trying to sanity-check the Fmax I'm getting.

After post-route STA with extracted parasitics (RCX), my worst setup path is entirely inside the CV32E40P multiplier:

startpoint : ex_stage_i.mult_i.mulh_CS[0]
endpoint   : ex_stage_i.mult_i.int_op_a_msu[19]
logic depth: 82 stages
data path  : 26.9 ns
             19.5 ns cells
              7.4 ns repeaters / long nets

With a 22 ns clock target, I get roughly:

ff_n40C_1v95    +12.8 ns slack  -> ~110 MHz Fmax
tt_025C_1v80     +7.4 ns slack  ->  ~68 MHz Fmax
ss_100C_1v60     -5.7 ns slack  ->  ~36 MHz Fmax

So at the slow corner I'm effectively limited to around 36 MHz, while TT is closer to 68 MHz.

A few things I'm wondering about:

1. Does ~36 MHz at ss_100C_1v60 sound reasonable for CV32E40P on SKY130/HD? I'm mostly trying to figure out whether this is in the expected ballpark or whether something in my flow/physical design is clearly suboptimal.
2. Has anyone pipelined or otherwise modified the CV32E40P multiplier for timing? The critical MULH path goes through the multiplier state machine (STEP0 -> STEP1 -> STEP2). Since the state advances every cycle, I don't think simply declaring it multicycle would be functionally correct.
3. How would you approach the physical side? Around 28% of the critical-path delay is from buffers/repeaters on long nets. The full SoC is fairly large (~13 mm²) because it also contains an accelerator and several SRAM macros. Would you normally:
   • constrain the CPU into a tighter placement region,
   • improve macro placement / floorplanning,
   • use a different standard-cell library,
   • or tackle the multiplier architecture itself first?

I'm not looking for a magic OpenROAD setting — mainly interested in real-world SKY130 numbers from people who have implemented CV32E40P or similar RISC-V cores.

Is ~35–40 MHz slow-corner signoff basically expected here, or does this look like I'm leaving a lot of performance on the table?

We are developing a CV32E40P-based RISC-V microcontroller on a Xilinx Nexys A7 FPGA and are planning a future ASIC implementation.
Our current architecture includes:

CV32E40P RISC-V core
8 KB Instruction Memory (IMEM)
8 KB Data Memory (DMEM)
1 KB Boot ROM
UART, GPIO, I2C and Timer peripherals
AXI4 / AXI4-Lite interconnect
MMCM-based clock generation
A custom AI accelerator with approximately 30 KB of local memory

We are trying to make our RTL as ASIC-friendly as possible before freezing the architecture and would appreciate advice from engineers who have gone through FPGA-to-ASIC migrations.

For memories of this size (8 KB IMEM, 8 KB DMEM, 1 KB Boot ROM, and 30 KB accelerator memory), how realistic is it to find suitable SRAM/ROM macros in a typical ASIC flow?

Are these memory sizes commonly available as foundry macros, or would we likely need to generate custom SRAMs (e.g., OpenRAM), split them into multiple banks, or redesign parts of the memory architecture?

We currently use an FPGA MMCM for clock generation. In an ASIC implementation, is it common to replace this with a foundry PLL macro, or should the clocking architecture be redesigned from the beginning?

What are the most common mistakes teams make when moving an AXI-based FPGA SoC to ASIC? Are there any lessons learned regarding clock/reset architecture, timing closure, memory integration, DFT, or physical design?

For the 30 KB accelerator memory, would multiple SRAM banks be preferable to a single larger SRAM macro from an area, power, or performance perspective?

Looking at this architecture, what would you change today before tape-out planning to avoid painful redesigns later?

Our goal is to minimize FPGA-specific dependencies and make the transition to ASIC as smooth as possible.

Hi everyone,

I am currently working on a RISC-V based microcontroller SoC project for an FPGA/ASIC-oriented design competition. The system is built around a CV32E40P core, and I am trying to integrate a small AI accelerator into the SoC.

The target AI use case is a lightweight keyword-spotting style inference engine, inspired by TensorFlow Lite Micro Speech. The input feature format is planned as a 49x40 int8 feature matrix. The accelerator is not intended to be a full general-purpose NPU; it is designed as a small fixed-function accelerator for a specific inference workload.

My current accelerator architecture idea is:

UART-Stream Input
      |
      v
Input Buffer RAM
      |
      v
Compute Engine
  - MAC-based processing
  - Conv / FC / MatMul style operations
      |
      v
Argmax / Result Register
      |
      v
Interrupt to RISC-V CPU

The SoC-level control model is:

CV32E40P CPU
    |
AXI4-Lite
    |
AI Accelerator Control/Status Registers

The accelerator contains:

- AXI4-Lite control/status interface
- UART-stream input interface
- Local input buffer RAM
- Weight ROM for fixed trained model parameters
- Optional Bias ROM
- FSM-controlled MAC engine
- Accumulator registers, likely int32
- Argmax result block
- Done/interrupt output to the CPU

The basic data type plan is:

input_data  : int8
weight_data : int8
multiply    : int8 x int8
accumulator : int32
result      : class index / score

The reason I am thinking of using ROM for weights is that the model is fixed after training, so the accelerator can read trained weights internally instead of loading them dynamically through AXI. The input feature data, however, is variable and would be stored in RAM/buffer.

I initially tried a more parallel compute structure, but FPGA utilization became too high and Vivado placement failed. So now I am considering a more serial/FSM-based design with a small number of MAC units, reading input RAM and weight ROM sequentially.

My questions are:

1. Does this architecture make sense for a small FPGA-based AI accelerator?
2. Is using Weight ROM for fixed int8 model parameters a reasonable approach?
3. Would a serial/FSM-controlled MAC engine be more practical than a highly parallel design for a limited FPGA device?
4. Should I implement only FC/MatMul first, or is it still reasonable to include a small Conv2D block?
5. Are there any major architectural mistakes in this approach?
6. What would you recommend to reduce LUT/FF/DSP usage while keeping the design acceptable for an SoC demonstration?

Any feedback, criticism, or suggestions would be very helpful. I am still learning digital design and SoC integration, so I would especially appreciate practical FPGA/RTL design advice.

Thanks in advance.