# ASIC Project Report Team00
Edison Wang & Vamber Yang
## 1. CPU & Cache Structure
#### Our ASIC-Project design features:
- **4-Stage** pipeline CPU with **novel forwarding logic**
- **N-Way** configurable Cache with **write back** policy
- Various Optimizations

### CPU pipeline stages:
- IF_stage:
- **IF_top**: This stage receives instruction from the Instruction Cache and two control signals(used to flush instructions or stalling), and it passes the correct instruction and PC to DE stage.
- **Instruction Cache**: The instruction cache outputs new instruction at a positive clock edge.
- **PC_unit**: This unit resolves correct PC to pass into the Instruction Cache.
- **Branch Predictor**: The Branch Predictor holds both Brach Target Table and Branch History Table to predictor a seen branch instruction. It also outputs its prediction(T/NT) and predicted_PC(32-bits) along the pipeline to judged by the branch_resolver in EX stage.
- DE_stage:
- **Register File**: This unit contains 32 registers(x0-x31), and the Regfile is synchronously write and asynchronously read. When writting into the Regfile, it receives RD's address, write data, and writen enables signal from Mem+WriteBack Stage.
- **Immediate Generator**: This unit generates immediate according to the type of instruction decoded.
- **Struct Generator**: This unit generates and decode useful information(36 bits) from the instruction, such as if the instruction is branch, does it require RD, etc. The information it generated will be passed to the following stages and eliminate any decode process in later stages.
- Note: We can pass 36'd0 as a nop struct to flush an instruction instead of flushing all the control signals. This generator also processes parallel with register access and forwarding mux, so it will not be the critical path.
- EX_stage:
- **ALU**: A 32-bits ALU that can perform specified operations in the spec.
- **Branch_Resolver**: This unit will check if the branch predictor's prediction was correct and send the result to flush logic in Mem+WriteBack Stage.
- **Other Control Signals**: As mentioned in the DE_stage/Struct Generator section, all the control signals are already decoded. We can directly access them from the struct without decoding anything. This ensures our control logic will not become the critical path.
- MW_stage:
- **Flush Logic**: This unit simply outputs a control signal to all the previous stages if there is a miss prediction.
- **CSR File**: The CSR File will be written at the positive clock edge if needed.
- **Data Cache**: The data cache outputs a 32-bits data according to the instruction after positive edge.
- **Load Process Unit(LDX)**: The LDX takes in data from D$ and parse it to appropriate format.
- **Other Control Signals**:As mentioned in the DE_stage/Struct Generator section, all the control signals are already decoded.
### Forwarding Logics:
#### Key Idea: Designing a forwarding logic such that the Critical Path does not contain both Memory + EX stage.

- **MW(Previous ALU's result) to ALU Forwarding**:
- When there are data dependency with adjacent instructions(Not for load instruction), we need to forward the result of earlier instruction to the later one to avoid one cycle of stalling. (See example below)
- We decide to store the result of eariler into a register in Mem+WriteBack stage and forward it back directly to a mux in EX stage for the next instruction. We choose to do it this way because this appraoch causes minimal amount of impact on the critical path without stalling.

| Instruction\Cycle | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ----------------- | ---- | ---- | --- | --- | --- | --- | --- |
| add x4, x5, x6 | IF | DE | EX | MW | | | |
| add x7, x4, x5 | | IF | DE | EX | MW | | |

- **MW to DE Forwarding**:
- When there are data dependency with two instructions with a gap, we need to forward the register ALU result in Mem+WriteBack Stage to Decode Stage to avoid one cycle of stalling. (See example below)
- We decide to forward the result in Mem+WriteBack stage to the mux in DE stage after register file access. This forwarding logic solves data dependency for both regular instruction and memory access instructions(loads). More importantly, this forwarding logic adds zero time to the critical path because the time we wait for the Memory to load data out can happen in parallel with Register File access and Decode logics in DE stage. We consider this forwarding logic the core of our CPU pipeline design.

| Instruction\Cycle | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ----------------- | --- | --- | --- | --- | --- | --- | --- |
| lw x4, 0(x5) | IF | DE | EX | MW | | | |
| and x0, x0, x0 | | IF | DE | EX | MW | | |
| add x7, x4, x5 | | | IF | DE | EX | MW | |

- **Load Hazard**:
- The first forwarding logic is not capable of resolve adjacent data dependency for load instructions because if we forward the result of a load to EX stage, the critical path will become EX_stage + MW_stage. This will almost double our critical path, and we anticipate that modern complier will try its best to avoid this. Thus, our solution is to insert a bubble when there is a such dependency, the MW to DE forwarding logic will then greacefullly solve the remaining part of the forwarding with no impact on the critical path.

| Instruction\Cycle | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ----------------- | --- | --- | --- | --- | --- | --- | --- |
| lw x4, 0(x5) | IF | DE | EX | MW | | | |
| add x7, x4, x5 | | IF | DE | X | EX | M | |

### Cache Structure:

- **Write Back Policy**:
- There are two main options for designing an L1 cache:
* 1: Write Through + No Allocate
* 2: Write Back + Write Allocate
- Ultimately, we decided to go with the Write Back option, because it's much more performant. Consider a simple matrix multiplication program, each store-type instruction under Write Through would cost minimally 2 stalls under current ExtMemModel.v implementation. Whereas a store-type write hit will have 0 stalls for the CPU under the Write-Back Policy

- **Cache FSM and Performance**:

| Condition | Stalls |
| -------- | -------- |
| Write hit | 0 |
| Read hit | 0 |
| Write miss | 4 |
| Read miss | 3-5 |
| Eviction | 10-13 |

(Assuming Memory not busy)

#### The cache FSM resolves the following design challenges

1. How to maintain data when Mem is busy
2. How to read the next data block from Mem while writting previous block into sram
3. Eviction Logic, how to read out the dirty block from sram while writting back to Mem
4. When to stall the CPU

#### Cache DataPath and Controller
- To manage the complexity of our SRAM, we divide and conquer cache into its datapath and controller, and both of which are further divided into smaller functional modules.
* Cache DataPath.v contains
* tag_array (a module stores data for dirty/valid bit and tag)
* data_array (a module that provides a simple interface for (2R)/(1R1W) for 128 bits data
* Cache Controller contains
* tag_vontroller ( a controller for just cache)
* main_controller (the main controller for the FSM)
* superstate_controller (used in early-release optimization, explained in Q7)

#### N-Way Set Associative Cache
- Due to the significant eviction penalty that write back policy suffers, we decided to upgrade our cache from Direct Map into N-Way Set Associative. Having a N-Way cache will improve our CPI, as our cache can now prioritize flushing the line that's valid but not dirty. And fortunately, most of the heavy work has already been offloaded into the cache controller when we first coded our Direct Mapped cache. To make our N-Way cache, we only needed to slighly modify our datapath module, and use a random eviction policy.

## 2. Post-Syn

- The post-synthesis critical path length **achieves 657 ps** with 100 ps uncertainity. It's essentially the pure EX stage datapath.

- This is our critical path because our design is performance driven, thus, we think make sure EX stage is critical path will ensure highest frequency and give the highest performance.

- **Remark**: We believe our 4-stage design is actually **faster than the traditional 5-stage** risc-V design. Because any 5-stage design must be lower bounded by the EX stage (forwarding mux + PC mux + ALU). However, our forwarding mux (purple mux in above diagram), is only a 2 way mux (selecting RS1 / ALU_forwarding). Whereas the 5-stage design needs a 3 way forwarding mux (seleting rs1 / ALU_forwarding / WriteBack_fowarding).

 
 

## 3. Floorplan
#### Floorplan Diagrams
Floorplan View

Amoeba View
Placement View
#### Our design's floorplan strategy is auto by Innovus because we choose to make N-way set associative Cache for both Instruction Cache and Data Cache. There are over a hundred srams needed to be placed with 8-way set associative Cache. We also made some detailed structural changes after many rounds of place&routes, and our clock tree yeiels a good quality of right skewed diagram.

 
 
 
 

## 4. Post-Par critical Path

The post-place-and-route critical path length is **1189 ps**. This path passes through the Instruction Cache, Instruction Fetch stage, and back to Instruction Cache. This path is different from post-synthesis critical path because the srams have to reside outside of the ALU. There are extra wires travels from CPU to Cache, and the wire delay is relatively higher than gate delay. The eighth longest path in our post-place-and-route report is actually EX stage(less traveling than CPU to Cache) which is only 9 ps faster than this, and this also proves that wire delay is causing the difference.

Howevever, it's still notable to mention that **the true critical path is still EX-stage**. The 1189ps above is the timing objective which met both setup-time and hold-time constrains. If we decrease our timing objective down to **950ps**, the number 1 critical path is still EX-stage:

## 5. Area
#### Post-PAR total area utilization + top 10

Depth  Name                                   #Inst  Area (um^2) 
-----------------------------------------------------------------------------------------------------------------
0      riscv_top                              14023  46212.12128 
1      cpu                                    9822   20477.08512 
1      mem                                    4134   25465.59776 
2      cpu/branch_predictor_unit              1741   3854.25216  
2      mem/dcache                             2292   13278.55744 
2      cpu/PC_unit_module                     331    540.27648   
2      mem/icache                             1807   12118.92256 
2      cpu/MW_DE_Hzd_module                   14     27.76032    
2      cpu/LW_Hzd_module                      15     28.22688    
2      cpu/ALU_ALU_Hzd_module                 46     83.51424    

The default area constraint in par.yml is 350*400 = 140000 um^2
Thus, the density is 46212.12128/140000 = 33.00 %

(Note: the cache size is actually a parameter to our design of N-Way SA cache,
the above illustrates the default configuration, but we used a bigger D cache when
we ran the simulation)

 
 
 
 

## 6. Power
#### Innovus Power Report

Total Power
-----------------------------------------------------------------------------------------
Total Internal Power:        4.78555121 	   59.7331%
Total Switching Power:       2.32759862 	   29.0530%
Total Leakage Power:         0.89840478 	   11.2139%
Total Power:                 8.01155463
-----------------------------------------------------------------------------------------


Group                           Internal   Switching     Leakage       Total  Percentage 
                                Power      Power         Power         Power  (%)        
-----------------------------------------------------------------------------------------
Sequential                         1.898      0.1152      0.2823       2.295       28.65
Macro                                  0     0.03089           0     0.03089      0.3856
IO                                     0           0   1.831e-06   1.831e-06   2.285e-05
Combinational                      1.013       1.184      0.4633       2.661       33.21
Clock (Combinational)              1.751      0.8389      0.1316       2.722       33.97
Clock (Sequential)                0.1234      0.1584     0.02129      0.3031       3.783
-----------------------------------------------------------------------------------------
Total                              4.786       2.328      0.8984       8.012         100
-----------------------------------------------------------------------------------------


Rail                  Voltage   Internal   Switching     Leakage       Total  Percentage 
                                Power      Power         Power         Power  (%)        
-----------------------------------------------------------------------------------------
VDD                      0.63      4.786       2.328      0.8984       8.012         100


Clock                           Internal   Switching     Leakage       Total  Percentage 
                                Power      Power         Power         Power  (%)        
-----------------------------------------------------------------------------------------
clk                                1.875      0.9973      0.1529       3.025       37.75
-----------------------------------------------------------------------------------------
Total                              1.875      0.9973      0.1529       3.025       37.75
-----------------------------------------------------------------------------------------

 
 
 
 

## 7. Cycles and Optimization

| test | cycles(1 bit predictor) | cycles(2 bits predictor) | cycles(Optimal) |
| --------- | ------ | --- | ------ |
| CacheTest | 2873000 | 2848116 | 2848116 |
| Sum | 17534007 | 17366373 | 17366373 |
| Replace | 17538090 | 17366444 | 17366444 |
| Final | 5974 | 6617 | 5974 |
| Fib | 5289 |5292 | 5289 |

### The answer to this question leads to the 3 main optimization we did:

- #### Two-Level Branch Predictor
- 1 bit global predictor controls where set of Branch History Table to look up
- Configurable number of entries in both Branch History Table and Branch Target Table
- Constant access time, we use LogN(N is size of the Table) bits of the PC to access the tables

- #### N-Way SA Cache
- As mentioned in the above section, a write-back policy Cache can especially benefit from a Set Associative Cache in order to reduce the eviction penalty. As the cache can now prioritize flushing the line which is valid not not dirty. Therefore we made a N-Way configurable cache.

- #### Early Release Feature
- Normally on a read miss, the Cache will need to stall the CPU at least 5 cycles. 1 cycle for the cache requesting data from memory, and ensued that, reading 128 bits of data per cycle from the memory, for 4 consecutive cycles.
- However, we realize if the read miss' data can be found in the first or second round of 128 bits data from the memory, we can stop freezing the CPU once the relevant data is written to data_array, letting CPU going back to work, while the cache is finishing reading the remaining data from the memory into the data_array.
- This will improve our read miss from 5 to 3 cycles in the best case senario.
- Despite this feature seems easy to implement, it actually requries adding a new FSM on top of the existing 12 state FSM for cache. The main difficulty is to handle the case when the cache is currently early-releasing a previous memory instruction, but suddenly a new write/read miss comes in.

## 8. Post-Par Benchmark

| test | seconds |
| -------- | -------- |
| CacheTest | 0.00338925804 |
| Sum | 0.02066598387 |
| Replace | 0.02066606836 |
| Final | 7.10906e-6 |
| Fib | 6.29391e-6 |

## 9. No Bugs

The CPU and Cache is fully functional in pre-syn, post-syn, post-par. But to get there, let's just say ... We got really good at reading waveforms

 
 
 
 

## 10. Other Optimization
- The 3 main optimizations for our design were illustrated in Q7. However, we believe the true optimizations did not happen in the end after we realized everything is functional. But rather ..
- The true optimization happened in the beginning when we were taking a long time with our design, thinking critically about the CPU's critical path.
- The true optimization happened along the way, as we are coding each small functional module and writting lines of verilog, we are thinking about how to make them faster.
- The true optmization also happened between the constant back and forth between "make syn" and checking the timing_report. Our goal is to ensure that EX stage is the critical path post synthesis. However, during our developement process, that was rarely the case. We often find we have incorrectly wired signals between modules, or the cache controller was taking too long, such that in the end the critical path became something else that's longer than EX stage. The constant iterations between "make syn" and "fixing code" is what preserved our critical path.

### Side Optimization : Load-Type Predictor
#### (not deployed but functional)

At one point during our development, we were concerned that the MW (Mem + WriteBack) stage could be longer than EX stage and becoming our new critical path. One major component of the MW stage is the LDX module, which processes data coming out from D-cache based on the type of load instruction (LW vs LB vs LHU etc). And this LDX module will add at least 100ps to MW stage's critical path.

But probabilistically speaking, most load instruction will be load word. What happens if we predict all load instruction as load word, so we can directly connect D-Cache out into the writeback mux (see diagram on the right). This will immediately reduce 100 ps from MW stage's critical path.

If we mispredict, we just stall the CPU by one cycle, and use the correct LDX data calculated from the previous round, so the misprediction penalty is only 1 cycle.

## 11. Words for Staff
Out of all the projects we've been through at Berkeley, the ASIC one definitely hits differently. At this point, the number of hours devoted is no longer the best measurement for our effort nor for this experience. What words to say ? Not sure ... I guess initially we are just happy that our CPU and Cache are workingly properly. But looking back at ourselves in lab2, we were still in the primodial stage of a VeriLoger (struggling not to create latches), to now, capable of pulling a somewhat complex system together; the various design obstacles and optimization hindrances and how we overcome them; our overly unjustified obsession to lower the clk period; and how the identity of waveform transform from an enemy (symolizes bugs) to become our greatest ally for bebugging. All these moments, regardless how frustrating, angry, estatic they seemed, now all convolved into one priceless memory. And we hope this memory, unlike our cache, would not be evicted.

We want thank our ASIC TAs and professor Sophia, "thank you !".