From: Luke Kenneth Casson Leighton Date: Fri, 27 Apr 2018 03:46:55 +0000 (+0100) Subject: clarify X-Git-Tag: convert-csv-opcode-to-binary~5450 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=3ebe82ec5a6bb2f32306efe7109e245fa320e8b3;p=libreriscv.git clarify --- diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index eb91163f0..d96c5eeaf 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -316,8 +316,8 @@ On this latter point, it was observed that MISA already switches out entire sets of instructions (interacts at the "decode" phase). The difference between what MISA does and the mvendor/march-id WARL idea is that whilst MISA only switches instruction decoding on (or off), the WARL idea -*redirects* encoding, to *different* engines, fortunately in a deliberately -mutually-exclusive fashion. +*redirects* encoding, effectively to *different* simultaneous engines, +fortunately in a deliberately mutually-exclusive fashion. Implementations would therefore, in each Extension (assuming one separate "decode" engine per Extension), simply have an extra (mutually-exclusively @@ -325,8 +325,8 @@ enabled) wire in the AND gate for any given binary encoding, and in this way there would actually be very little impact on the latency. The assumption here is that there are not dozens of Extensions vying for the same binary encoding (at which point the Fabless Semi Company has other much more -pressing issues to deal with that make resolving encoding conflicts trivial -by comparison). +pressing issues to deal with that make resolving binary encoding conflicts +trivial by comparison). Also pointed out was that in certain cases pipeline stalls could be introduced during the switching phase, if needed, just as they may be needed for