missed camelcase in ls012

diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn
index 4282384f1b8d255695136440b67bee04b58d7360..a381f5ffa3ee9976555f4d305379e88903350049 100644 (file)
--- a/openpower/sv/rfc/ls012.mdwn
+++ b/openpower/sv/rfc/ls012.mdwn
@@ -140,7 +140,7 @@ These without question have to go in EXT0xx.  Future extended variants,
 bringing even more powerful capabilities, can be followed up later with
 EXT1xx prefixed variants, which is not possible if placed in EXT2xx.
 *Only `svstep` is actually Vectorizeable*, all other Management
-instructions are UnVectorizeable.  PO1-Prefixed examples include
+instructions are Unvectorizeable.  PO1-Prefixed examples include
 adding psvshape in order to support both Inner and Outer Product Matrix
 Schedules, by providing the option to directly reverse the order of the
 triple loops.  Outer is used for standard Matrix Multiply (on top of a
@@ -188,7 +188,7 @@ specialist.
 Found at [[sv/av_opcodes]] these do not require Saturated variants
 because Saturation is added via [[sv/svp64]] (Vector Prefixing) and
 via [[sv/svp64-single]] Scalar Prefixing. This is important to note for
-Opcode Allocation because placing these operations in the UnVectorizeable
+Opcode Allocation because placing these operations in the Unvectorizeable
 areas would irredeemably damage their value.  Unlike PackedSIMD ISAs
 the actual number of AV Opcodes is remarkably small once the usual
 cascading-option-multipliers (SIMD width, bitwidth, saturation,
@@ -737,7 +737,7 @@ The key to headings and sections are as follows:
   is **mutually exclusively incompatible** with Vectorization.
 * **group** - the Primary Opcode Group recommended for this instruction.
   Options are EXT0xx (EXT000-EXT063), EXT1xx and EXT2xx.  A third area
-  (UnVectorizeable),
+  (Unvectorizeable),
   EXT3xx, was available in an early Draft RFC but has been made "RESERVED"
   instead.  see [[sv/po9_encoding]].
 * **Level** - Compliancy Subset and Simple-V Level. `SFFS` indicates "mandatory"