Use think delay as miminum END_REQ delay

When the controller accepts requests in the same clock cycle as it
handles them, undeterministic simulations can occur as the outcome
depends on if the new request is accepted before the controllerMethod
is called or not.

Therefore, a minimum delay of one clock cylce should be used to always
handle request only in the next clock cycle, removing the disambiguity.

configs/README.md

@@ -313,3 +313,21 @@ An example follows.
     - maximum number of active transactions per initiator (only applies to "Fifo" and "Reorder" arbiter policy)
 - *RefreshManagement* (boolean)
     - enable the sending of refresh management commands when the number of activates to one bank exceeds a certain management threshold (only supported in DDR5 and LPDDR5)
+- *ArbitrationDelayFw* (unsigned int)
+    - number of clock cycles spent in forward arbitration to channel controllers
+- *ArbitrationDelayBw* (unsigned int)
+    - number of clock cycles spent in backward arbitration to initiator
+- *ThinkDelayFw* (unsigned int)
+    - minimum number of clock cycles between acceptance of a request to command issuance
+- *ThinkDelayBw* (unsigned int)
+    - minimum number of clock cycles until response is forwarded to the arbiter 
+- *PhyDelayFw* (unsigned int)
+    - number of clock cycles between command issuance and occupation on the command/data bus
+- *PhyDelayBw* (unsigned int)
+    - number of clock cycles between read data on the data bus and arrival in the channel controller 
+- *BlockingReadDelay* (unsigned int)
+    - constant number of clock cycles spent reading data in blocking mode
+    - **warning**: usage of blocking transport produces in inaccurate simulation results
+- *BlockingWriteDelay* (unsigned int)
+    - constant number of clock cycles spent writing data in blocking mode
+    - **warning**: usage of blocking transport produces in inaccurate simulation results