reword
authorLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 4 Dec 2018 18:51:56 +0000 (18:51 +0000)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 4 Dec 2018 18:51:56 +0000 (18:51 +0000)
updates/003_2018dec04_microarchitecture.mdwn

index 64487a7d0e70b293c3bb78db23e2d6de60759192..88093b9539fc184391119edc96dffd0336818bf2 100644 (file)
@@ -106,6 +106,19 @@ to Reorder Buffers:
 * There's no clear way to handle branch prediction, where the Reorder
   Buffer of Tomasulo handles it really cleanly.
 
+However there are downsides to Reorder Buffers:
+
+* The Common Data Bus may become a serious bottleneck, as it delivers
+  data from multiple ALUs which may be generating results simultaneously.
+  To keep up with result generation, *multiple* CDBs may be needed, which
+  results in each receiver having multiple ports
+* The Destination field in the ROB has to act as a key in a CAM (Content
+  Addressble Memory).  As a result, power consumption of the ROB may be
+  quite high.  It may or may not be possible to reduce power consumption
+  by testing an "active" bitfield (separate from but augmenting the ROB)
+  to indicate whether Destination Registers are in use.  If inactive,
+  the CAM lookup need not take place.
+
 Whilst nothing's firmly set in stone, here, as we have a Charter that
 requires unanimous decision-making from contributors, so far it's leaning
 towards Reorder Buffers and Tomasulo as a good, clean fit.  In part that