Skip to content

Commit 5d388f0

Browse files
actions-useractions-user
committed
Merge branch 'main' of https://github.com/amichai-bd/fpga_mafia_wiki into shmuel_doc
2 parents 58beed0 + 151224d commit 5d388f0

27 files changed

+3363
-16
lines changed

‎docs/build_script/advanced_build_options.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ In case you don't provide a configuration.json file, the default configuration.j
1515
"I_MEM_LENGTH": 8192,
1616
"D_MEM_OFFSET": 8192,
1717
"D_MEM_LENGTH": 16384,
18-
"crt0_file" : "crt2_big_rv32i.S",
18+
"crt0_file" : "crt0_big_rv32i.S",
1919
"rv32_gcc" : "rv32i",
2020
"name" : "rv32i"
2121
}

‎docs/cache/Verif/Dedicated_test.md

Lines changed: 104 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,104 @@
1-
# Dedicated Test Intro
1+
# Dedicated Test Intro
2+
3+
We conduct a series of tests in our test bench to validate specific features and verify various cases that the cache might encounter during operation.
4+
5+
The diverse test suite covers scenarios such as back to back writes or reads requests to the same CL to check for data error or ensuring that fill requests are not sent unnecessarily.
6+
We simulate scenarios with loaded data to emulate cache hits, verifying that the cache responds correctly to expected hits and that any misses are flagged.
7+
8+
Then we started to create random tests to evaluate the behavior of the cache or memory subsystem by randomly generating read and write requests. The goal is to explore extreme cases and identify potential bugs that may not be uncovered in deterministic test scenarios.
9+
Our test will be composed of three key tasks
10+
11+
**create_addrs_pull**:
12+
Generates a diverse set of tag and set combinations.
13+
14+
```systemverilog
15+
task create_addrs_pull(input int local_num_tag_pull = V_MAX_NUM_TAG_PULL, // default values
16+
input int local_num_set_pull = V_MAX_NUM_SET_PULL, // default values
17+
output logic [7:0] tag_pull [V_MAX_NUM_TAG_PULL:0],
18+
output logic [7:0] set_pull [V_MAX_NUM_SET_PULL:0]);
19+
int i;
20+
for (i = 0; i < local_num_tag_pull+1; i = i + 1) begin
21+
tag_pull[i] = $urandom_range(8'h00, 8'hFF);
22+
end
23+
for (i = 0; i < local_num_set_pull+1; i = i + 1) begin
24+
set_pull[i] = $urandom_range(8'h00, 8'hFF);
25+
end
26+
endtask
27+
```
28+
**random_wr / random_rd:** Generates random write/read requests to stress-test the system.
29+
30+
```systemverilog
31+
task random_wr(input int local_min_req_delay = V_MIN_REQ_DELAY, // default values
32+
input int local_max_req_delay = V_MAX_REQ_DELAY, // default values
33+
input int local_num_tag_pull = V_NUM_TAG_PULL, // default values
34+
input int local_num_set_pull = V_NUM_SET_PULL // default values
35+
);
36+
logic [19:0] addr;
37+
logic [31:0] data;
38+
logic [4:0] id;
39+
int i;
40+
create_addrs(.local_num_tag_pull(local_num_tag_pull),
41+
.local_num_set_pull(local_num_set_pull),
42+
.addr(addr)
43+
);
44+
data = $urandom_range(0, 32'hFFFFFFFF);
45+
id = $urandom_range(0, 5'd31);
46+
wr_req(addr, data, id);
47+
i = $urandom_range(local_min_req_delay, local_max_req_delay);
48+
delay(i);
49+
endtask
50+
51+
//=======================================================
52+
//=======================================================
53+
task random_rd(
54+
input int local_min_req_delay = V_MIN_REQ_DELAY, // default values
55+
input int local_max_req_delay = V_MAX_REQ_DELAY, // default values
56+
input int local_num_tag_pull = V_NUM_TAG_PULL, // default values
57+
input int local_num_set_pull = V_NUM_SET_PULL // default values
58+
);
59+
logic [19:0] addr;
60+
logic [4:0] id;
61+
int i;
62+
create_addrs(.local_num_tag_pull(local_num_tag_pull),
63+
.local_num_set_pull(local_num_set_pull),
64+
.addr(addr)
65+
);
66+
id = $urandom_range(0, 5'd31);
67+
rd_req(addr, id);
68+
i = $urandom_range(local_min_req_delay, local_max_req_delay);
69+
delay(i);
70+
endtask
71+
```
72+
**Exemple of usage**
73+
74+
In this test, a total of 50 random read and write requests are sent to the design.
75+
Back-to-back requests and a mix of read and write operations are included to simulate real-world usage scenarios.
76+
The script aims to stress-test the design by introducing random delays and varying request types to uncover any corner cases or unexpected behavior.
77+
78+
```systemverilog
79+
LOCAL_NUM_TAG_PULL = 10;
80+
LOCAL_NUM_SET_PULL = 1;
81+
create_addrs_pull(.local_num_tag_pull(LOCAL_NUM_TAG_PULL),//input
82+
.local_num_set_pull(LOCAL_NUM_SET_PULL),//input
83+
.tag_pull(tag_pull), //output
84+
.set_pull(set_pull) //output
85+
);
86+
87+
// send 50 rd/wr request according to the RD_RATIO parameter
88+
for(int i = 0; i<50; i++) begin
89+
if(V_RD_RATIO > $urandom_range(0, 100)) begin
90+
random_rd(.local_min_req_delay(15), //input
91+
.local_max_req_delay(16), //input
92+
.local_num_tag_pull(LOCAL_NUM_TAG_PULL), //input
93+
.local_num_set_pull(LOCAL_NUM_SET_PULL) //input
94+
);
95+
end else begin
96+
random_wr(.local_min_req_delay(15), //input
97+
.local_max_req_delay(16), //input
98+
.local_num_tag_pull(LOCAL_NUM_TAG_PULL), //input
99+
.local_num_set_pull(LOCAL_NUM_SET_PULL) //input
100+
);
101+
end
102+
end
103+
104+
```

‎docs/cache/Verif/post_proccess.md

Lines changed: 111 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,111 @@
1+
# Post Process and trackers
2+
3+
## Cache_pp
4+
5+
The Cache Post-Process script is designed to compare the top level tracker generated during the execution of a cache test against a reference model. It play a pivotal role in debugging and verification. The primary goal is to identify any differences between the two sets of trackers. The script will return the differences between the two files and help us fix different bugs in the code.
6+
We can easily run the cache PP script by using the `-pp`` flag while running our build.py script
7+
8+
## Cache_trk
9+
10+
Trackers are esential to our hardware testing. They keep an eye on what's happening inside our cache system, writing down every move it makes. Whether it's reading or writing data, or going through different stages of pipe or tq, trackers document it all.
11+
These trackers help us catch any weird behavior or mistakes in how our system handles information, helping us understand and fix issues and making sure everything runs ad it should. The motivation behind using trackers is to have a trustworthy record-keeper that helps us improve and perfect our hardware design.
12+
With each test execution we deploy a set of trackers, each assigned to record specific facets of our system's behavior.
13+
14+
### Cache top Tracker
15+
This tracker monitors the transactions at the top level of the cache. It observes high-level transactions within the cache, capturing information related to read and write operations.
16+
It aids in understanding the flow of data between the core and cache, facilitating the identification of potential issues or inefficiencies in transaction handling.
17+
18+
**Signals Tracked:**
19+
20+
| Signal | Description |
21+
| ------------ | -------------------------------------------------------- |
22+
| Time | Time of the cache operation |
23+
| OPCODE | Operation code |
24+
| address | Memory address being accessed |
25+
| REG/TQ_ID | Register or Transaction Queue ID |
26+
| tag | Tag bits of the cache address |
27+
| Set | Set bits of the cache address |
28+
| Data | Data associated with the operation |
29+
30+
31+
### Pipe I/O tracker
32+
This tracker monitors information related to requests and circulating within the cache pipeline.
33+
By capturing the specifics of these internal operations, it enables developers to diagnose performance bottlenecks, optimize data flow, and ensure seamless communication between different stages of the cache.
34+
35+
**Signals Tracked:**
36+
37+
| Signal | Description |
38+
|-------------|--------------------------------------------------|
39+
| Time | Timestamp of the event |
40+
| REQ/RSP | Request or Response indicator |
41+
| OPCODE | Operation code |
42+
| TQ ID | Transaction Queue ID |
43+
| Address | Memory address involved in the operation |
44+
| Rd Ind | Read indicator |
45+
| Wr Ind | Write indicator |
46+
| Data/Result | Data for a response or result of the operation. |
47+
| CL Data | Cache line data |
48+
49+
50+
### Pipe Stage tracker
51+
This tracker provides a detailed view of the cache pipeline stages. It is motivated by the need to analyze and optimize the cache's internal processing. It provides insights into hit/miss scenarios, data movement, and various stages of the pipeline, facilitating a comprehensive understanding of the cache's behavior.
52+
53+
**Signals tracked:**
54+
55+
| Signal | Description |
56+
|--------------------|----------------------------------------------------|
57+
| Time | Timestamp of the event |
58+
| OPCODE | Operation code |
59+
| TQ ID | Transaction Queue ID |
60+
| s_w_mru | MRU status |
61+
| Hit/Miss | Hit or miss indicator |
62+
| MB Hit Cancel | Merge Buffer hit cancel indicator |
63+
| Tag | Cache line tag |
64+
| Set | Cache set |
65+
| Offset | Offset within the cache line |
66+
| Data | Data involved in the operation |
67+
| s_w_valid | Set ways valid |
68+
| s_w_modified | Set ways modified |
69+
| s_w_tags | Set ways tags |
70+
| s_w_victim | Set ways victim |
71+
| s_w_hit | Set ways hit |
72+
| Fill Modified | Indicate the fill is for a write op |
73+
| Fill Rd | Indicate the fill is for a read op |
74+
| Dirty Evict | Dirty eviction bit |
75+
| CL Data Q3 | Cache line data at Q3 |
76+
| Data Array Address | Address in the data array |
77+
| CL Data | Cache line data |
78+
79+
80+
### Cache TQ tracker
81+
This tracker focuses on the Transaction Queue (TQ) entries. His role is to monitor TQ entries to aids ensuring proper synchronization between the core and cache, tracking state changes, and identifying any anomalies in the TQ.
82+
83+
**Signals tracked:**
84+
85+
| Signal | Description |
86+
|----------------|-----------------------------------------------|
87+
| Time | Timestamp of the event. |
88+
| ENTRY | TQ entry id |
89+
| State | Current state of the entry |
90+
| RD/WR | Indicates whether it's a read or write op |
91+
| CL Address | Cache line address |
92+
| MB Data | Merge Buffer data |
93+
| REG ID | Register ID |
94+
| CL Word Offset | Offset within the cache line |
95+
| Rd/Wr Hit | Indicates read or write hit |
96+
97+
### Cache ref
98+
These tracker log transactions between the core and cache.
99+
100+
**Signals tracked:**
101+
102+
| Signal | Description |
103+
|---------|--------------------------------------------------|
104+
| OPCODE | Operation code |
105+
| Address | Memory address involved in the operation. |
106+
| REG | Register involved |
107+
| Tag | Cache line tag |
108+
| Set | Cache set |
109+
| Data | Data involved in the operation |
110+
111+

0 commit comments

Comments
 (0)