Updated User Documentation (markdown)

User-Documentation.md

@@ -131,17 +131,23 @@ The simulation also reports the status of the simulation. For example, the repor
 
 The format is [`time_delay`] `command` @ (`bank`, `address`), so `[10000 ps]  RD @ (0,   840)` means 10000 ps delay before a read command with bank 0 and address 840. Notice how each read command has a delay of 10000 ps or 10 ns from each other, since this has a controller clock of 100 MHz (10 ns clock period) this shows that there are no interruptions between sequential read commands resulting in a very high throughput. 
 
-A short report is also shown in each test section:
-> --------------------------------
-DONE TEST 1: LAST ROW
-Number of Operations: 2304
-Time Started: 363390 ns
-Time Done: 387980 ns
-Average Rate: 10 ns/request
---------------------------------
+A short report is also shown in each test section:  
+> DONE TEST 1: LAST ROW  
+Number of Operations: 2304  
+Time Started: 363390 ns  
+Time Done: 387980 ns  
+Average Rate: 10 ns/request  
 
-This report is after a burst write then burst read. This report means there were 2304 write and read operation, and the average time per request is 10 ns (1 controller clock period of 100 MHz). The average rate is optimal since this is a burst write and read. But for random write and read
 
+This report is after a burst write then burst read. This report means there were 2304 write and read operation, and the average time per request is 10 ns (1 controller clock period of 100 MHz). The average rate is optimal since this is a burst write and read. But for random writes and reads:  
+> DONE TEST 2: RANDOM  
+Number of Operations: 2304  
+Time Started: 387980 ns  
+Time Done: 497660 ns  
+Average Rate: 47 ns/request  
+
+
+Notice how the average rate increased to 47 ns/request. Random access requires occasional precharge and activate which takes time and thus prolong the time for every read or write access.
 
 # Sample Projects
 -