(no commit message)

diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn
index 17d6392c64e7ae5792e1b96722bc9f14a084a1b0..43bec717a5497244e35902a56abe65b9e888068f 100644 (file)
--- a/openpower/sv/16_bit_compressed.mdwn
+++ b/openpower/sv/16_bit_compressed.mdwn
@@ -820,7 +820,7 @@ Pseudocode:
     # and back transitions left to implementor
     # (or for someone else to add)
 
-## Phase 2 Compressed (16bit decoding)
+### Phase 2: Compressed mode
 
 At this phase, knowing that the length is 16bit and the mode is either 10b or 16b, further analysis is required to determine if the 16bit.immediate encoding is active, and so on.  This is a fully combinatorial block that **at no time** steps outside of the strict bounds already determined by Phase 1.
 
@@ -833,7 +833,11 @@ At this phase, knowing that the length is 16bit and the mode is either 10b or 16
             decode_16bit_nonimmed_mode(insn)
 
 From this point onwards each of the decode_xx functions perform straightforward combinatorial decoding of the 16 bits of "insn".  In sone cases this involves further analysis of bit 1, in some cases (Cmaj.m = 0b010.1) even further deep-dive decoding is required (CR ops).  *All* of it is entirely combinatorial and at **no time** involves changing of, or interaction with, or disruption of, the Phase 1 determination of Length+Mode (that has *already taken place* in an earlier decoding pipeline time-schedule)
-  
+
+### Phase 2: v3.0B mode
+
+Standard v3.0B decoders are deployed.  Absolutely no interaction occurs with any 16 bit decoders or state.  Absolutely no interaction with the earlier Phase 1 decoding occurs.  Absolutely no interaction occurs whatsoever (assuming an implementation that does not perform macro-op fusion) between other multi-issued v3.0B instructions being decoded in parallel at this time.
+ 
 ## Demo of encoding that's backward-compatible with PowerISA v3.1 in both LE and BE mode
 
 [[demo]]