clarification ideas update

diff --git a/updates/020_2019aug28_intriguing_ideas.mdwn b/updates/020_2019aug28_intriguing_ideas.mdwn
index fb2b9339c0ecf034e9426811b9b75614ea697577..90699d94e2a6b8b9d104a367e1d7bc1337a3984b 100644 (file)
--- a/updates/020_2019aug28_intriguing_ideas.mdwn
+++ b/updates/020_2019aug28_intriguing_ideas.mdwn
@@ -67,8 +67,10 @@ just to meet Libre criteria, but to meet the long tail of innovation in
 3D and kick start some real innovation.
 These were the challenges discussed at the upcoming first
 [meetup](https://www.meetup.com/Bay-Area-RISC-V-Meetup/events/264231095/)
-at Western Digital's Milpitas HQ. Experts in 3D at the Meetup were really
-enthusiastic and praised this approach.
+at Western Digital's Milpitas HQ. Experts at the Meetup, from the 3D
+Industry who have worked for decades for ATI, NVIDIA and Intel, were
+really enthusiastic and praised this approach, saying that it was exactly
+the kind of shakeup the 3D Industry needs.
 
 # Reconfigureable Pipelines
 
@@ -84,15 +86,17 @@ results. This is termed a "pipeline".  Actually it's more like an
 escalator.
 
 The problem comes when you want to vary the clock speed. This is desirable
-because if the pipeline is long and the clock rate is slow, the latency
+because if the pipeline is long and the clock rate is slow, clearly the latency
 (completion time of an instruction) is also long.
 
 Conversely, if the pipeline is short (large numbers of gates connected
 together) then as mentioned above, this can inherently limit the maximum
-frequency that the processor could run at.
+frequency that the processor could run at, because due to the "ripple" effect
+in each pipeline stage, a longer chain of gates clearly has to have a longer
+time to stabilise.
 
 What if there was a solution which allowed *both* options? What if you
-could actually reconfigure tge pipeline to be shorter or longer?
+could actually reconfigure the pipeline to be shorter or longer?
 
 It turns out that by using what is termed "transparent latches" that it
 is possible to do precisely that.  The advantages are enormous and were
@@ -102,21 +106,28 @@ Earlier in
 [this thread](https://groups.google.com/d/msg/comp.arch/fcq-GLQqvas/SY2F9Hd8AQAJ),
 someone kindly pointed out that IBM published
 papers on the technique.  Basically, the latches normally present in the
-pipeline have a combinatorial "bypass" in the form of a Mux. The output
-is dynamically selected from either the input *or* the input after it
-has been put through a flip-flop. The flip-flop basically stores (and
-delays) its input for one clock cycle.
+pipeline have an additional combinatorial "bypass" in the form of a
+Mux. The output is dynamically selected from either the input *or* the
+input after it has been put through a flip-flop. The flip-flop basically
+stores (and delays) its input for one clock cycle, or it can be bypassed
+i.e. just be another part of that "ripple" effect mentioned earlier.
 
 By putting these transparent latches on every other combinatorial stage
 in the processing chain, the length of the pipeline may be halved, such
 that when the clock rate is also halved the *instruction completion time
 remains the same*.
 
-Normally if the processor speed were lowered it would have an adverse
-impact on instruction latency.
+As described earlier, normally if the processor speed were lowered it
+would have an adverse impact on instruction latency.  With the transparent
+latches bypassed and with plenty of time to stabilise at the lower speed,
+two back-to-back stages now comprise a *single* pipeline stage, and thus,
+even if the processor speed is halved,
+*so is the length of the overall pipeline* and thus the instruction
+completion time remains the same.
 
 It's a fantastic idea that will allow us to reconfigure the processor
-to reach a 1.5ghz clock rate for high performance bursts.
+either to reach a 1.5ghz clock rate for high performance bursts, or to
+run at 800mhz in reduced power mode.
 
 # NLNet Funding proposals.