From: Luke Kenneth Casson Leighton Date: Fri, 14 Jun 2019 06:16:28 +0000 (+0100) Subject: add 48bit conflict FAQ X-Git-Tag: convert-csv-opcode-to-binary~4639 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=89e17b88c93b7d8ff5e04e6206989693b995247e;p=libreriscv.git add 48bit conflict FAQ --- diff --git a/isa_conflict_resolution/isamux_isans.mdwn b/isa_conflict_resolution/isamux_isans.mdwn index a9f61f7df..d92f76ac2 100644 --- a/isa_conflict_resolution/isamux_isans.mdwn +++ b/isa_conflict_resolution/isamux_isans.mdwn @@ -121,6 +121,18 @@ first sight not to make any sense. It's complicated in other words! +# Surely it's okay to just tell people to use 48-bit encodings? + +Short answer: it doesn't help resolve conflicts, and costs hardware and +redesigns to do so. Softcores in cost-sensitive embedded applications may +even not actually be able to fit the required 48 bit instruction decode engine +into a (small, ICE40) FPGA. 48-bit instruction decoding is much more complex +than straight 32-bit decoding, requiring a queue. + +Second answer: conflicts can still occur in the (unregulated, custom) 48-bit +space, which *could* be resolved by ISAMUX/ISANS as applied to the *48* bit +space in exactly the same way. And the 64-bit space. + # Why not leave this to individual custom vendors to solve on a case by case basis? The suggestion was raised that a custom extension vendor could create