diff --git a/doc/contributing/hw/comportability/README.md b/doc/contributing/hw/comportability/README.md
index a997f18..f89ae1c 100644
--- a/doc/contributing/hw/comportability/README.md
+++ b/doc/contributing/hw/comportability/README.md
@@ -484,7 +484,7 @@
 The waveform below shows the timing of the event occurrence, its latched value, and the clearing by the processor.
 More details follow.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'Clock',             wave: 'p.............' },
@@ -502,7 +502,7 @@
     tock: 0
   },
 }
-{{< /wavejson >}}
+```
 
 ### Status Type Interrupt
 
@@ -512,7 +512,7 @@
 The status type interrupts do not drop the interrupt lines until the cause signals are dropped by the processor or hardware logic
 SW is responsible to mask the interrupts if they want to process the interrupt in a deferred way.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'Clock',                  wave: 'p.............' },
@@ -530,8 +530,7 @@
     tock: 0
   },
 }
-{{< /wavejson >}}
-
+```
 
 ### Interrupts per module
 
diff --git a/hw/ip/adc_ctrl/README.md b/hw/ip/adc_ctrl/README.md
index 4ebcd1b..477b86b 100644
--- a/hw/ip/adc_ctrl/README.md
+++ b/hw/ip/adc_ctrl/README.md
@@ -156,7 +156,7 @@
 Since there is no request sample signal between the controller and the ADC, the ADC takes a new sample when `adc_o.channel_sel` is changed from 0 to a valid channel.
 To take a new sample then, the controller actively sets `adc_o.channel_sel` to 0, before setting it to another valid channel.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     {node: '.a..b........', phase:0.2},
@@ -168,7 +168,7 @@
   ],
   edge: [  'a<->b wakeup time',   ]
 }
-{{< /wavejson >}}
+```
 
 # Programmers Guide
 
diff --git a/hw/ip/aes/README.md b/hw/ip/aes/README.md
index 077b910..899eae1 100644
--- a/hw/ip/aes/README.md
+++ b/hw/ip/aes/README.md
@@ -277,7 +277,7 @@
 
 The timing diagram below visualizes this process.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     {    name: 'clk',       wave: 'p........|.......'},
@@ -298,7 +298,7 @@
     ]
   ]
 }
-{{< /wavejson >}}
+```
 
 The AES unit is configured to do decryption (`Config op` = DECRYPT).
 Once the new key has been provided via the control and status registers (top), this new key is loaded into the Full Key register (`key_full` = K0-3) and the KEM starts performing encryption (`KEM op`=ENCRYPT).
diff --git a/hw/ip/csrng/README.md b/hw/ip/csrng/README.md
index 981fae1..14868f2 100644
--- a/hw/ip/csrng/README.md
+++ b/hw/ip/csrng/README.md
@@ -444,7 +444,7 @@
 
 ##### Application Interface: Instantiate Request
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'             , wave: 'p...............|.....'},
    {name: 'csrng_req_valid' , wave: '01............0.|.....'},
@@ -453,11 +453,12 @@
    {name: 'csrng_rsp_ack'   , wave: '0...............|.10..'},
    {name: 'csrng_rsp_sts'   , wave: 'x...............|.5x..', data: ['ok']},
  {},
-]}{{< /wavejson >}}
+]}
+```
 
 ##### Application Interface:  Reseed Request
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'             , wave: 'p...............|.....'},
    {name: 'csrng_req_valid' , wave: '01............0.|.....'},
@@ -466,11 +467,12 @@
    {name: 'csrng_rsp_ack'   , wave: '0...............|.10..'},
    {name: 'csrng_rsp_sts'   , wave: 'x...............|.5x..', data: ['ok']},
  {},
-]}{{< /wavejson >}}
+]}
+```
 
 ##### Application Interface:  Generate Request
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'              , wave: 'p...|...|....|....|...'},
    {name: 'csrng_req_valid'  , wave: '010.|...|....|....|...'},
@@ -483,11 +485,11 @@
    {name: 'genbits_bus'      , wave: '0...|.40|.4.0|.40.|...', data: ['bits0','bits1','bits2']},
    {name: 'genbits_ready'    , wave: '1...|...|0.1.|........'},
 ]}
-{{< /wavejson >}}
+```
 
 ##### Application Interface:  Update Request
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'             , wave: 'p...............|.....'},
    {name: 'csrng_req_valid' , wave: '01............0.|.....'},
@@ -496,11 +498,12 @@
    {name: 'csrng_rsp_ack'   , wave: '0...............|.10..'},
    {name: 'csrng_rsp_sts'   , wave: 'x...............|.5x..', data: ['ok']},
  {},
-]}{{< /wavejson >}}
+]}
+```
 
 ##### Application Interface:  Uninstantiate Request
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'             , wave: 'p...............|.....'},
    {name: 'csrng_req_valid' , wave: '010.............|.....'},
@@ -509,14 +512,15 @@
    {name: 'csrng_rsp_ack'   , wave: '0...............|.10..'},
    {name: 'csrng_rsp_sts'   , wave: 'x...............|.5x..', data: ['ok']},
  {},
-]}{{< /wavejson >}}
+]}
+```
 
 
 ##### Entropy Source Hardware Interface
 The following waveform shows an example of how the entropy source hardware interface works.
 
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'           , wave: 'p...|.........|.......'},
    {name: 'es_req'        , wave: '0..1|..01.0..1|.....0.'},
@@ -525,7 +529,7 @@
    {name: 'es_fips'       , wave: '0...|....10...|....10.'},
 ]}
 ]}
-{{< /wavejson >}}
+```
 
 ### Interrupts
 
diff --git a/hw/ip/edn/README.md b/hw/ip/edn/README.md
index 625080d..d48764a 100644
--- a/hw/ip/edn/README.md
+++ b/hw/ip/edn/README.md
@@ -228,7 +228,7 @@
 This example shows the case where the boot-time mode in the ENTROPY_SRC block is enabled.
 This example also shows the case where the next request will change the prior data by popping the data FIFO.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'           , wave: 'p...|...........|......'},
    {name: 'edn_enable'    , wave: '01..|...........|......'},
@@ -237,7 +237,8 @@
    {name: 'edn_bus[31:0]' , wave: '0...|3....3.....|3.....', data: ['es0','es1','es2']},
    {name: 'edn_fips'      , wave: '0...|...........|......'},
  {},
-]}{{< /wavejson >}}
+]}
+```
 
 # Programmers Guide
 
diff --git a/hw/ip/entropy_src/README.md b/hw/ip/entropy_src/README.md
index 560b4af0..3808306 100644
--- a/hw/ip/entropy_src/README.md
+++ b/hw/ip/entropy_src/README.md
@@ -254,7 +254,7 @@
 The following waveform shows an example of how the entropy source hardware interface works, which is much like a FIFO.
 
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'           , wave: 'p...|.........|.......'},
    {name: 'es_req'        , wave: '0..1|..01.0..1|.....0.'},
@@ -262,21 +262,21 @@
    {name: 'es_bus[383:0]' , wave: '0...|.30.30...|....30.', data: ['es0','es1','es2']},
    {name: 'es_fips'       , wave: '0...|....10...|....10.'},
 ]}
-{{< /wavejson >}}
+```
 
 
 ### PTRNG Hardware Interface
 The following waveform shows an example of what the PTRNG timing looks like.
 
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'clk'             , wave: 'p.|......|......|......'},
    {name: 'rng_enable'      , wave: '01|......|......|......'},
    {name: 'rng_valid'       , wave: '0.|..10..|..10..|..10..'},
    {name: 'rng_b'           , wave: 'x.|..3...|..4...|..5.....', data: ['es0','es1','es2']},
 ]}
-{{< /wavejson >}}
+```
 
 ### Repetition Count Test
 The following waveform shows how a sampling of a data pattern will be tested by the Repetition Count test.
@@ -284,7 +284,7 @@
 This NIST test is intended to signal a catastrophic failure with the PTRNG noise source.
 
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'rng_valid'      , wave: 'p...............'},
   ['rng bits',
@@ -304,7 +304,7 @@
    text:'Repetition Count Test',
    tick:0,
   },}
-{{< /wavejson >}}
+```
 
 ### Adaptive Proportion Test
 This NIST-defined test is intended to detect statistical bias in the raw entropy data.
@@ -318,7 +318,7 @@
 The following waveform shows how a sampling of a data pattern will be tested by the Adaptive Proportion test.
 In this example, the sum is taken over all RNG lines (i.e., {{#regref entropy_src.CONF.THRESHOLD_SCOPE }} is True).
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'rng_valid'      , wave: 'p...............'},
   ['rng bits',
@@ -334,14 +334,14 @@
    text:'Adaptive Proportion Test',
    tick:0,
   },}
-{{< /wavejson >}}
+```
 
 ### Bucket Test
 The following waveform shows how a sampling of a data pattern will be tested by the Bucket test.
 Operating on all four bit streams, this test will identify the symbol and sort it into bin counters, or "buckets".
 This test is intended to find bias with a symbol or symbols.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'rng_valid'      , wave: 'p...............'},
   ['rng bits',
@@ -363,7 +363,7 @@
    text:'Bucket Test',
    tick:0,
   },}
-{{< /wavejson >}}
+```
 
 ### Markov Test
 The following waveform shows how a sampling of a data pattern will be tested by the Markov test.
@@ -382,7 +382,7 @@
 Like the Adaptive Proportion test, the Markov Test can be computed either cumulatively (summing the results over all RNG lines) or on a per-line basis.
 In this example, the RNG lines are scored individually (i.e., {{#regref entropy_src.CONF.THRESHOLD_SCOPE }} is False).
 
-{{< wavejson >}}
+```wavejson
 {signal: [
    {name: 'rng_valid'      , wave: 'p...............'},
   ['rng bits',
@@ -400,7 +400,7 @@
    text:'Markov Test',
    tick:0,
   },}
-{{< /wavejson >}}
+```
 
 
 # Programmers Guide
diff --git a/hw/ip/flash_ctrl/README.md b/hw/ip/flash_ctrl/README.md
index eed7aa3..90f512f 100644
--- a/hw/ip/flash_ctrl/README.md
+++ b/hw/ip/flash_ctrl/README.md
@@ -689,7 +689,7 @@
 As host reads are usually tied to host execution upstream, additional latency can severely harm performance and is not desired.
 The expected waveform from the perspective of the physical controller is shown below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',           wave: 'p..............'},
   {name: 'rst_ni',          wave: '0.1............'},
@@ -699,7 +699,7 @@
   {name: 'host_req_done_o', wave: '0...10..1110...'},
   {name: 'host_rdata_o',    wave: 'x...4x..444x...',data: ['Dat0', 'Dat1', 'Dat2', 'Dat3']},
 ]}
-{{< /wavejson >}}
+```
 
 The `host_req_done_o` is always single cycle pulsed and upstream logic is expected to always accept and correctly handle the return.
 The same cycle the return data is posted a new command / address can be accepted.
@@ -712,7 +712,7 @@
 Once the done is seen, the controller then transitions to the next read operation.
 The expected waveform from the perspective of the physical controller is shown below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                 wave: 'p..............'},
   {name: 'rst_ni',                wave: '0.1............'},
@@ -722,7 +722,7 @@
   {name: 'flash_ctrl_o.rd_done',  wave: '0....10.10...10'},
   {name: 'flash_ctrl_o.rdata',    wave: 'x....4x.4x...4x', data: ['Dat0', 'Dat1', 'Dat2']},
 ]}
-{{< /wavejson >}}
+```
 
 ### Controller Program
 
@@ -730,7 +730,7 @@
 The protocol controller will hold the request, address and data lines until the programming is complete.
 The expected waveform from the perspective of the physical controller is shown below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                  wave: 'p..............'},
   {name: 'rst_ni',                 wave: '0.1............'},
@@ -740,7 +740,7 @@
   {name: 'flash_ctrl_o.prog_data', wave: 'x..4..4..x.4..x', data: ['Dat0', 'Dat1', 'Dat2']},
   {name: 'flash_ctrl_o.prog_done', wave: '0....10.10...10'},
 ]}
-{{< /wavejson >}}
+```
 
 # Programmers Guide
 
diff --git a/hw/ip/i2c/README.md b/hw/ip/i2c/README.md
index 7a525a6..8682cb5 100644
--- a/hw/ip/i2c/README.md
+++ b/hw/ip/i2c/README.md
@@ -303,7 +303,7 @@
 However the target device must assert SCL low before the start of the SCL pulse.
 If SCL is pulled low during an SCL pulse which has already started, this interruption of the SCL pulse will be registered as an exception by the I2C core, which will then assert the `scl_interference` interrupt.
 
-{{<wavejson>}}
+```wavejson
 {signal: [
   {name: 'Clock', wave: 'p.....|.......|......'},
   {name: 'SCL Host Driver', wave: '0.z..0|.z....0|..z.x.'},
@@ -312,13 +312,13 @@
   {name: 'scl_interference', wave: '0.....|.......|....1.'},
 ],
   head: {text: 'SCL pulses: Normal SCL pulse (Cycle 3),  SCL pulse with clock stretching (cycle 11), and SCL interference (interrupted SCL pulse)',tick:1}}
-{{</wavejson>}}
+```
 
 
 Though normal clock stretching does not count as SCL interference, if the module detects that a target device has held SCL low and stretched the any given SCL cycle for more than {{#regref i2c.TIMEOUT_CTRL.VAL }} clock ticks this will cause the stretch timeout interrupt to be asserted.
 This interrupt is suppressed, however, if {{#regref i2c.TIMEOUT_CTRL.EN }} is deasserted low.
 
-{{<wavejson>}}
+```wavejson
 {signal: [
   {name: 'Clock', wave: 'p............'},
   {name: 'SCL Host Driver', wave: '0..z.......x.'},
@@ -330,7 +330,7 @@
   {name: 'scl_timeout', wave: '0..........1.'},
 ],
   head: {text: 'SCL Timeout Example',tick:-3}}
-{{</wavejson>}}
+```
 
 Except for START and STOP symbols, the I2C specification requires that the SDA signal remains constant whenever SCL is high.
 The `sda_unstable` interrupt is asserted if, when receiving data or acknowledgement pulse, the value of the SDA signal does not remain constant over the duration of the SCL pulse.
diff --git a/hw/ip/keymgr/README.md b/hw/ip/keymgr/README.md
index 9bd7bcf..84dd787 100644
--- a/hw/ip/keymgr/README.md
+++ b/hw/ip/keymgr/README.md
@@ -404,7 +404,7 @@
 
 See diagram below for an example transfer:
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'kmac_data_o.valid',     wave: '01...........|....0..'},
   {name: 'kmac_data_i.ready',     wave: '1...0..101...|.......'},
@@ -415,7 +415,7 @@
   {name: 'kmac_data_i.digest*',   wave: 'x..................3x'},
   ],
 }
-{{< /wavejson >}}
+```
 
 ### Sideload Keys
 
@@ -441,7 +441,7 @@
 During the duration of the operation, the key is valid and shows the internal key state.
 Once the operation is complete, it falls back to the sideload key state, which is invalid in this case.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'u_sideload_ctrl.u_kmac_key.key_o.valid',     wave: '0................'},
   {name: 'u_sideload_ctrl.u_kmac_key.key_o.key_share', wave: 'x................'},
@@ -452,13 +452,13 @@
   {name: 'kmac_key_o.key_share*',                      wave: 'x....3.....x.....'},
   ],
 }
-{{< /wavejson >}}
+```
 
 The following diagram illustrates an example when there is a valid key in the KMAC sideload registers and an operation is called.
 During the duration of the operation, the key is valid and shows the internal key state.
 Once the operation is complete, it falls back to the sideload key state, which is valid and contains a different value.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'u_sideload_ctrl.u_kmac_key.key_o.valid',     wave: '01...............'},
   {name: 'u_sideload_ctrl.u_kmac_key.key_o.key_share', wave: 'x4...............'},
@@ -469,7 +469,7 @@
   {name: 'kmac_key_o.key_share*',                      wave: 'x4...3.....4.....'},
   ],
 }
-{{< /wavejson >}}
+```
 
 
 ### Software Binding
diff --git a/hw/ip/otp_ctrl/README.md b/hw/ip/otp_ctrl/README.md
index 87898b0..7000147 100644
--- a/hw/ip/otp_ctrl/README.md
+++ b/hw/ip/otp_ctrl/README.md
@@ -353,7 +353,7 @@
 Some of these qualifier signals (`lc_dft_en_i`, `lc_creator_seed_sw_rw_en_i`, `lc_seed_hw_rd_en_i` and `lc_escalate_en_i`) are fed back to the OTP controller in order to ungate testing logic to the OTP macro; enable SW write access to the `SECRET2` partition; enable hardware read access to the root key in the `SECRET2` partition; or to push the OTP controller into escalation state.
 
 A possible sequence for the signals described is illustrated below.
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                           wave: 'p.................'},
   {name: 'otp_lc_data_o.valid',             wave: '0.|...|.1.|...|...'},
@@ -375,7 +375,7 @@
   {},
   {name: 'lc_escalate_en_i',                wave: '0.|...|...|...|.5.'},
 ]}
-{{< /wavejson >}}
+```
 
 Note that the `otp_lc_data_o.valid` signal is only asserted after the `LIFE_CYCLE`, `SECRET0` and `SECRET2` partitions have successfully initialized, since the life cycle collateral contains information from all three partitions.
 The `otp_lc_data_o.test_tokens_valid` and `otp_lc_data_o.rma_token_valid` signals are multibit valid signals indicating whether the corresponding tokens are valid.
@@ -386,7 +386,7 @@
 
 In order to perform life cycle state transitions, the life cycle controller can present the new value of the life cycle state and counter via the programming interface as shown below:
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                          wave: 'p.......'},
   {name: 'lc_otp_program_i.req',           wave: '01.|..0.'},
@@ -395,7 +395,7 @@
   {name: 'lc_otp_program_o.ack',           wave: '0..|.10.'},
   {name: 'lc_otp_program_o.err',           wave: '0..|.40.'},
 ]}
-{{< /wavejson >}}
+```
 
 The request must remain asserted until the life cycle controller has responded.
 An error is fatal and indicates that the OTP programming operation has failed.
@@ -420,7 +420,7 @@
 
 The keys can be requested as illustrated below:
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                      wave: 'p...........'},
   {name: 'flash_otp_key_i.data_req',   wave: '01.|..0.|...'},
@@ -430,7 +430,7 @@
   {name: 'flash_otp_key_o.key',        wave: '0..|.30.|.40'},
   {name: 'flash_otp_key_o.seed_valid', wave: '0..|.10.|.10'},
 ]}
-{{< /wavejson >}}
+```
 
 The keys are derived from the FLASH_DATA_KEY_SEED and FLASH_ADDR_KEY_SEED values stored in the `SECRET1` partition using the [scrambling primitive](#scrambling-datapath).
 If the key seeds have not yet been provisioned, the keys are derived from all-zero constants, and the `flash_otp_key_o.seed_valid` signal will be set to 0 in the response.
@@ -451,7 +451,7 @@
 Finally, the OTP controller returns a fresh ephemeral key via the response channels (`sram_otp_key_o[*]`, `otbn_otp_key_o`), which complete the req / ack handshake.
 The wave diagram below illustrates this process for the OTBN scrambling device.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                     wave: 'p.......'},
   {name: 'otbn_otp_key_i.req',        wave: '01.|..0.'},
@@ -460,7 +460,7 @@
   {name: 'otbn_otp_key_o.key',        wave: '0..|.30.'},
   {name: 'otbn_otp_key_o.seed_valid', wave: '0..|.10.'},
 ]}
-{{< /wavejson >}}
+```
 
 If the key seeds have not yet been provisioned, the keys are derived from all-zero constants, and the `*.seed_valid` signal will be set to 0 in the response.
 It should be noted that this mechanism requires the EDN and entropy distribution network to be operational, and a key derivation request will block if they are not.
@@ -649,7 +649,7 @@
 Arbitration at transaction level is implemented similarly to cycle-based arbitration, with the difference that the grant signals remain asserted until the requestor deasserts the request (thereby releasing the arbiter, which acts as a mutex in this case).
 This is behavior illustrated in the example below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                  wave: 'p............'},
   {name: 'part_scrmbl_mtx_req[0]', wave: '01....0.1....'},
@@ -660,7 +660,7 @@
   {name: 'part_scrmbl_mtx_gnt[1]', wave: '0.....1..0...'},
   {name: 'part_scrmbl_mtx_gnt[2]', wave: '0........1.0.'},
 ]}
-{{< /wavejson >}}
+```
 
 ### Primitive Wrapper and FPGA Emulation
 
@@ -725,7 +725,7 @@
 The latency from accepting a command to returning a response depends on the underlying OTP IP and is typically larger than 10 cycles.
 The returned values depend on the command type and whether an error occurred or not.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',    wave: 'p.............' },
@@ -750,7 +750,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Note that the open source OTP controller allows up to two outstanding OTP commands, meaning that it is permissible to acknowledge an incoming command and start working on it while the results of the last command are still in the process of being output (e.g., due to an output register stage).
 
diff --git a/hw/ip/pattgen/README.md b/hw/ip/pattgen/README.md
index b763f03..f3d15b6 100644
--- a/hw/ip/pattgen/README.md
+++ b/hw/ip/pattgen/README.md
@@ -107,7 +107,7 @@
 A one in the polarity bit inverts the `pcl` clock so that it starts high and `pda` transitions on the rising edge.
 The following waveform illustrates the effect of the `POLARITY` bit.
 Here both channels are configured for simultaneous pattern generation, but the two channels are configured for opposite polarity.
-{{<wavejson>}}
+```wavejson
 {signal: [
   {name: 'CTRL.ENABLE_CH0', wave: 'lh......'},
   {name: 'CTRL.POLARITY_CH0 (default: low)', wave: '0.......'},
@@ -118,7 +118,7 @@
   {name: 'pda1_tx', wave: 'x5.5.5.5', data: 'DATA[0] DATA[1] DATA[2]'},
 ],
   head: {text: 'Effect of the Polarity Registers',tick:0}}
-{{</wavejson>}}
+```
 
 1. Program the length of seed pattern using the length field, {{#regref pattgen.SIZE.LEN_CH0 }}.
 Note that since the allowed seed length ranges from 1-64, the value of this field should be one less than the pattern length.
diff --git a/hw/ip/prim/doc/prim_clock_gp_mux2.md b/hw/ip/prim/doc/prim_clock_gp_mux2.md
index 460d8b8..b73a288 100644
--- a/hw/ip/prim/doc/prim_clock_gp_mux2.md
+++ b/hw/ip/prim/doc/prim_clock_gp_mux2.md
@@ -4,23 +4,23 @@
 `prim_clock_gp_mux2` is a two input clock mux that protects a glitch. When a current clock source is switched to the next clock source where two clocks are totally unrelated, a glitch can be generated as follows.
 
 ### Glitch
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk0_i',           wave: 'L.H....L....H....L....H....'},
   {name: 'clk1_i',           wave: 'L.H.L.H.L.H.L.H.L.H.L.H.L.H'},
   {name: 'sel_i',            wave: '0............1.............'},
   {name: 'clk_o',            wave: 'L.H....L....HLH.L.H.L.H.L.H'},
  ]}
-{{< /wavejson >}}
+```
 
 This glitch free clock mux can avoid glitch by placing two parallel synchronizers connected to each other. 1st flop and 2nd flop are triggered by positive edge and negative edge respectively to protect metastability on the sel_i signal. The following waveform shows the result.
 
 ### Glitch Free
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk0_i',           wave: 'L.H....L....H....L....H....'},
   {name: 'clk1_i',           wave: 'L.H.L.H.L.H.L.H.L.H.L.H.L.H'},
   {name: 'sel_i',            wave: '0............1.............'},
   {name: 'clk_o',            wave: 'L.H....L....H....LH.L.H.L.H'},
  ]}
-{{< /wavejson >}}
+```
diff --git a/hw/ip/prim/doc/prim_flash.md b/hw/ip/prim/doc/prim_flash.md
index a187d9d..b5073e3 100644
--- a/hw/ip/prim/doc/prim_flash.md
+++ b/hw/ip/prim/doc/prim_flash.md
@@ -90,7 +90,7 @@
 The following are examples for read, program and erase transactions.
 
 ### Read
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',     wave: 'p.................'},
   {name: 'rd_i',      wave: '011..0.1..0.......'},
@@ -99,10 +99,10 @@
   {name: 'done_o',    wave: '0....10...10....10'},
   {name: 'rd_data_o', wave: 'x....2x...2x....2x'},
 ]}
-{{< /wavejson >}}
+```
 
 ### Program
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',       wave: 'p................'},
   {name: 'prog_i',      wave: '011...0.1....0...'},
@@ -112,17 +112,17 @@
   {name: 'ack_o',       wave: '010..10.....10...'},
   {name: 'done_o',      wave: '0..............10'},
 ]}
-{{< /wavejson >}}
+```
 
 ### Erase
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',     wave: 'p................'},
   {name: '*_erase_i', wave: '01.0.........1.0.'},
   {name: 'ack_o',     wave: '0.10..........10.'},
   {name: 'done_o',    wave: '0.....10.........'},
 ]}
-{{< /wavejson >}}
+```
 
 ## Initialization
 
@@ -150,7 +150,7 @@
 When the erase suspend completes, the flash wrapper circuitry also asserts `done` for the ongoing erase transaction to ensure all hardware gracefully completes.
 
 The following is an example diagram
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_i',                wave: 'p................'},
   {name: 'pg_erase_i',           wave: '01.0..............'},
@@ -159,7 +159,7 @@
   {name: 'done_o',               wave: '0............10..'},
  ]
   }
-{{< /wavejson >}}
+```
 
 ## Error Interrupt
 The `flash_err_o` is a level interrupt indication, that is asserted whenever an error event occurs in one of the Flash banks.
diff --git a/hw/ip/prim/doc/prim_packer.md b/hw/ip/prim/doc/prim_packer.md
index f870315..97297ac 100644
--- a/hw/ip/prim/doc/prim_packer.md
+++ b/hw/ip/prim/doc/prim_packer.md
@@ -59,7 +59,7 @@
 data and send outgoing data to the `data_o` port.
 
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'valid_i',      wave: '01.01......0.'},
   { name: 'data_i[3:0]',  wave: 'x==x===.===x.', data:'0h 1h 2h 3h 4h 5h 6h 7h'},
@@ -78,7 +78,7 @@
     tick: ['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18    ']
   }
 }
-{{< /wavejson >}}
+```
 
 The above waveform shows the case of InW := 4 and OutW := 6. After the first
 transaction, `prim_packer` has `0h` in the storage. When the second `valid_i`
diff --git a/hw/ip/prim/doc/prim_xoshiro256pp.md b/hw/ip/prim/doc/prim_xoshiro256pp.md
index 2d76852..50beef4 100644
--- a/hw/ip/prim/doc/prim_xoshiro256pp.md
+++ b/hw/ip/prim/doc/prim_xoshiro256pp.md
@@ -61,7 +61,7 @@
 The state is internally updated in every clock cycle whenever the enable signal `xoshiro_en_i` is raised.
 The timing diagram below visualizes this process.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     {name: 'clk', wave: 'p......|....'},
@@ -71,4 +71,4 @@
     {name: 'state', wave: 'x.3..45|678.', data: 'Seed'}
   ]
 }
-{{< /wavejson >}}
+```
diff --git a/hw/ip/pwm/README.md b/hw/ip/pwm/README.md
index 9bc1f17..8a5af96 100644
--- a/hw/ip/pwm/README.md
+++ b/hw/ip/pwm/README.md
@@ -136,7 +136,8 @@
 
 The following figure illustrates the effect of the clock divider register.  Note that changes to {{#regref pwm.CFG.CLK_DIV }} or {{#regref pwm.CFG.DC_RESN }} only take effect when {{#regref pwm.CFG.CNTR_EN }} is disabled.
 
-{{< wavejson >}}{signal: [
+```wavejson
+{signal: [
   {name: 'core_clk_i', wave: 'p..............|..........'},
   {name: 'sync(CFG.CNTR_EN)', wave: '0.1............|01........'},
   {name: 'sync(CFG.CLK_DIV)', wave: '2....4.........|..2.......', data: '2 4 4'},
@@ -148,7 +149,7 @@
   {name: 'beat_end', wave: '0....10.10.10.1|0.....10..'}],
   config:{skin:'narrow'}
 }
-{{< /wavejson >}}
+```
 
 ### PWM Comparators and Pulse Generation.
 
@@ -178,7 +179,7 @@
 The following figure illustrates the effect of the {{#regref pwm.PWM_PARAM_0.PHASE_DELAY_0 }} register and `duty_cycle`.
 Note that this figure shows two channels, 0 and 1, where the second channel has a significant phase delay, such that the output pulse is high when `phase_ctr` overflows to zero.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'core_clk_i', wave: 'p.....|....|......'},
   {name: 'CFG.CLK_DIV', wave: '2.....|....|......', data: '0'},
@@ -198,7 +199,7 @@
   ],
  config:{skin:'narrow'}
 }
-{{< /wavejson >}}
+```
 
 Changes to {{#regref pwm.PWM_EN.EN_0 }} bit have no effect on the *timing* of the pulses, as the `phase_ctr` is common to all channels.
 Enabling {{#regref pwm.PWM_EN.EN_0 }}, or changing {{#regref pwm.PWM_PARAM_0.PHASE_DELAY_0 }} is acceptable while the PWM channel is enabled.
@@ -245,7 +246,7 @@
 In heartbeat mode the duty cycle gradually transitions from {{#regref pwm.DUTY_CYCLE_0.A_0 }} to {{#regref pwm.DUTY_CYCLE_0.B_0 }} and back in a series of small steps.
 
 An example of this process is illustrated in the following waveform.
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'Pulse Cycle', wave: '2222222222222222222',
    data: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]},
@@ -259,7 +260,7 @@
 ],
  config:{skin:'narrow'}
 }
-{{< /wavejson >}}
+```
 
 The sequence starts with {{#regref pwm.BLINK_PARAM_0.X_0 }}+1 pulses at {{#regref pwm.DUTY_CYCLE_0.A_0 }}.
 The duty cycle then increases by {{#regref pwm.BLINK_PARAM_0.Y_0 }}+1 units, and {{#regref pwm.BLINK_PARAM_0.X_0 }}+1 more pulses are generated at the new duty cycle.
diff --git a/hw/ip/rom_ctrl/README.md b/hw/ip/rom_ctrl/README.md
index 9b36654..92307e5 100644
--- a/hw/ip/rom_ctrl/README.md
+++ b/hw/ip/rom_ctrl/README.md
@@ -54,7 +54,7 @@
 The keystream value for address 12 is denoted `k12`.
 The unscrambled ROM data for (logical) address 12 is denoted `d12`.
 
-{{<wavejson>}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p....', period: 2},
   {name: 'req', wave: '0.1...0...'},
@@ -65,7 +65,7 @@
   {name: 'rdata + ecc', wave: 'x...3.4.x.', data: ['d12', 'd34']},
   {name: 'rvalid', wave: '0...1...0.'},
 ]}
-{{</wavejson>}}
+```
 
 The `prim_prince` primitive and the two substitution-permutation networks are all parameterised by "keys".
 For `rom_ctrl`, these keys are global randomised netlist constants: they are assumed to be difficult to recover, but aren't considered secret data.
diff --git a/hw/ip/spi_device/README.md b/hw/ip/spi_device/README.md
index a1895a6..841e5f9 100644
--- a/hw/ip/spi_device/README.md
+++ b/hw/ip/spi_device/README.md
@@ -200,7 +200,7 @@
 showing the beginning and end of the transfer). Configurability for active
 edges, polarities, and bit orders are described later.
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'CSB',  wave: '10.........|....1.'},
   { name: 'SCK',  wave: '0.p........|....l.'},
@@ -215,7 +215,7 @@
     tick: ['-2 -1 0 1 2 3 4 5 6 7 8 9 60 61 62 63     ']
   }
 }
-{{< /wavejson >}}
+```
 
 
 ### Defining "Firmware Operation Mode"
@@ -563,7 +563,7 @@
 
 ![Command Filtering logic in Passthrough mode](./doc/passthrough-filter.svg)
 
-{{<wavejson>}}
+```wavejson
 { signal: [
   { name: 'CSb_in',  wave: '10.........|....1.'},
   { name: 'SCK_in',  wave: '0.p........|....l.'},
@@ -582,7 +582,7 @@
     tick: ['-2 -1 0 n-1 n+' ]
   }
 }
-{{</wavejson>}}
+```
 
 The passthrough logic filters the command based on the 256 bit of {{#regref spi_device.CMD_FILTER_0 }} CSR.
 Each bit corresponds to each opcode.
@@ -708,7 +708,7 @@
 module registers bits [7:1] and combines them with the SDI signal directly to
 form the input to RXFIFO. This is detailed in the waveform below.
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'CSB', wave: '10.||...|..1'},
   { name: 'SCK', wave: '0.p||...|..l', node:'......b' },
@@ -722,7 +722,7 @@
     tick: ['-2 -1 0 1 . 30 31 32 33 n-1 n n+1 n+2 '],
   },
 }
-{{< /wavejson >}}
+```
 
 As shown above, the RXFIFO write request signal (`RX_WEN`) is asserted when
 BitCount reaches 0h. Bitcount is reset by CSB asynchronously, returning to 7h
@@ -736,7 +736,7 @@
 change of SDO value at the negative edge of SCK. SDO_OE is controlled by the
 CSB signal. If CSB goes to high, SDO is returned to High-Z state.
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'CSB',      wave:'10.||...|..1'},
   { name: 'SCK',      wave:'0...p.|.|...|l' , node:'.............a', period:0.5},
@@ -752,7 +752,7 @@
     tick: ['-2 -1 0 1 . 30 31 32 33 n-1 n n+1 n+2 '],
   },
 }
-{{< /wavejson >}}
+```
 
 Note that in the SPI mode 3 configuration ({{#regref spi_device.CFG.CPOL }}=1, {{#regref spi_device.CFG.CPHA }}=1), the
 logic isn't able to pop the entry from the TX async FIFO after the last bit
diff --git a/hw/ip/spi_host/README.md b/hw/ip/spi_host/README.md
index ae9a7dc..ce41303 100644
--- a/hw/ip/spi_host/README.md
+++ b/hw/ip/spi_host/README.md
@@ -82,7 +82,7 @@
 In order to support these fastest data rates, the SPI_HOST IP offers a modified "Full-cycle" (FULLCYC = 1) timing mode where data can be sampled a *full* cycle after the target device asserts data on the SD bus.
 This full cycle mode has no effect on any of the signals transmitted, only on the timing of the sampling of the incoming signals.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i", wave: "p.................."},
   {name: "SCK (CPOL=0)", wave: "0.1010101010101010."},
@@ -107,7 +107,7 @@
   foot: {
   }
 }
-{{< /wavejson >}}
+```
 
 As mentioned earlier, the SD[0] and SD[1] lines are unidirectional in Standard SPI mode.
 On the other hand in the faster Dual- or Quad-modes, all data lines are bidirectional, and in Quad mode the number of data lines increases to four.
@@ -122,7 +122,7 @@
 Likewise, software-provided data is only transmitted in the first two segments.
 The SPI_HOST command interface allows the user to specify any number of command segments to build larger, more complex transactions.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i",        wave: "p................................"},
   {name: "SCK (CPOL=0)", wave: "0.101010101010101010101010101010."},
@@ -142,7 +142,7 @@
   text: "Example Quad SPI transaction: 1 byte TX (Single), 1 byte (Quad), 3 dummy cycles and 1 RX byte with CPHA=0"
   },
 }
-{{< /wavejson >}}
+```
 
 For even faster transfer rates, some flash chips support double transfer rate (DTR) variations to the SPI protocol wherein the device receives and transmits fresh data on *both* the leading and trailing edge.
 This IP only supports single transfer rate (STR), *not* DTR.
@@ -198,7 +198,7 @@
 Therefore such a command can be thought of as consisting of two separate segments, the first segment being TX Only and the second segment being RX only, as shown in the following figure.
 Breaking the command up this way potentially simplifies the job of writing software for this type of command.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i",          wave: "p....................|.............."},
   {name: "SCK (CPOL=0)",   wave: "0.1010101010101010101|01010101010101"},
@@ -211,7 +211,7 @@
   ],
  foot: {text: "Standard SPI example: Flash Read command with 24-bit address, consisting of one TX and one RX segment"}
 }
-{{< /wavejson >}}
+```
 
 In addition to the TX, RX or Bidirectional modes, many SPI commands require periods where neither the host or device are transmitting data.
 For instance, many flash devices define a Fast Read command in which the host must insert a number of "dummy clocks" between the last address byte and the first data byte from the device.
@@ -221,7 +221,7 @@
 - 8 dummy clocks
 - N bytes RX Only for read data response
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i",          wave: "p....................|.............................."},
   {name: "SCK (CPOL=0)",   wave: "0.1010101010101010101|010101010101010101010101010101"},
@@ -234,7 +234,7 @@
   ],
  foot: {text: "Standard SPI example: Fast read command (instruction code 0xb) with 24-bit address, consisting of three segments, one TX, 8 dummy clocks and one RX segment"}
 }
-{{< /wavejson >}}
+```
 
 For standard mode-commands, segments simplify the IO process by identifying which bus cycles have useful RX or TX data.
 In such cases it is not strictly necessary to the manage the impedance of the SD[0] and SD[1] lines.
@@ -321,7 +321,7 @@
 - T<sub>TRAIL</sub>: The minimum time between the last trailing edge of SCK and the following rising edge of CSB.
 This time delay is a half SCK cycle by default but can be extended to as long as eight SCK cycles by setting the {{#regref spi_host.CONFIGOPTS.CSNTRAIL }} register.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "SCK",  wave: "l....1010|10........"},
   {name: "CSB", wave: "10.......|.....1...0", node: ".A...B.....C...D...E"}
@@ -339,7 +339,7 @@
           "&#xd7;(CLKDIV+1)"]
   }
 }
-{{< /wavejson >}}
+```
 
 These settings are all minimum bounds, and delays in the FSM implementation may create more margin in each of these timing constraints.
 
@@ -353,7 +353,7 @@
 Consider a configuration where total idle time (as determined by the {{#regref spi_host.CONFIGOPTS.CLKDIV }} and {{#regref spi_host.CONFIGOPTS.CSNIDLE }} multi-registers) works out to 9 idle clocks for the first device, and 4 clocks for the second device.
 In this scenario then, when swapping from the first device to the second, the SPI_HOST IP will only swap the clock polarity once the first `csb` line, `csb[0]`, has been high for at least 9 clocks, and will continue to hold the second `csb` line, `csb[1]`, high for 4 additional clocks before starting the next transaction.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p..............'},
   ["Requested Config",
@@ -379,7 +379,7 @@
   edge: ["A<->B min. 9 cycles", "C<->D min. 4 cycles"],
   head: {text: "Extended Idle Time During Configuration Changes", tock: 1}
 }
-{{< /wavejson >}}
+```
 
 This additional idle time applies not only when switching between devices but when making any changes to the configuration for most recently used device.
 For instance, even in a SPI_HOST configured for one device, changes to {{#regref spi_host.CONFIGOPTS }}, will trigger this extended idle time behavior to ensure that the change in configuration only occurs in the middle of a long idle period.
@@ -442,7 +442,7 @@
 
 The following figure shows how data appears on the serial data bus when the hardware reads it from {{#regref spi_host.TXDATA }} or writes it to {{#regref spi_host.RXDATA }}.
 
-{{< wavejson >}}
+```wavejson
  {signal: [
   ["ByteOrder=0",
   {name: "SD[0] (host output)", wave: "x22222222222|2222|222|22x", data: ["t[31]", "t[30]", "t[29]", "t[28]", "t[27]", "t[26]", "t[25]", "t[24]", "t[23]","t[22]",
@@ -466,13 +466,13 @@
   text: "Standard SPI, bidirectional segment.  Bits are numbered as they appear in the DATA memory window"
   }
 }
-{{< /wavejson >}}
+```
 
 
 As shown in the following figure, a similar time-ordering scheme applies for Dual- and Quad-mode transfers.
 However many bits of similar significance are packed into multiple parallel SD data lines, with the least significant going to SD[0].
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   ["ByteOrder=0",
   {name: "SD[0]", wave: "x...22334455x...", data: ["d[28]", "d[24]", "d[20]", "d[16]", "d[12]", "d[8]", "d[4]", "d[0]"]},
@@ -494,7 +494,7 @@
   text: "(Bits are numbered as they appear when loaded into DATA memory window)"
   }
 }
-{{< /wavejson >}}
+```
 
 ### Command Length and Alignment in DATA
 
@@ -508,7 +508,7 @@
 In this example, the values `I[31:0]`, `A[31:0]` and `B[31:0]`, have been previously written into {{#regref spi_host.TXDATA }} via firmware, and afterwards one word, `X[31:0]`, is available for reading from {{#regref spi_host.RXDATA }}.
 All data in the waveform is transferred using 32-bit instructions.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "Segment number", wave: "x2.......2.........2.2.x", data: "1 2 3 4"},
   {name: "Speed", wave: "x2.......2.........2.2.x", data: "Standard Quad X Quad"},
@@ -537,7 +537,7 @@
     text: "Command consists of 4 segments, all TX data is written to DATA using 32-bit memory instructions (all bytes enabled)"
   }
 }
-{{< /wavejson >}}
+```
 
 When packing data into the TX FIFO, there are also no restrictions on the alignment of the data written to the {{#regref spi_host.TXDATA }} memory window, as it supports byte-enable signals.
 This means that when copying bytes into {{#regref spi_host.TXDATA }} from unaligned firmware memory addresses, it is possible to use byte or half-word instructions.
@@ -720,7 +720,7 @@
 
 The following waveform illustrates the operation of the Byte Select module, highlighting the effect of the `flush_i` signal (in the first input word), as well as the effect of the byte enable signal (shown in the second word).
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i", wave:           "p............."},
   {name: "word_i[31:0]", wave:    "x2..x2...x....", data: ["32'hBEADCAFE", "32'hDAD5F00D"]},
@@ -736,7 +736,7 @@
   text: "Byte Select Operation"
   }
 }
-{{< /wavejson >}}
+```
 
 ## Byte Merge
 
@@ -756,7 +756,7 @@
 
 Any ByteOrder swapping is performed at the other end of the RX FIFO.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i",        wave: "p.............."},
   {name: "byte_i[7:0]",  wave: "x22222.2....22x", data: ["01", "02", "03", "04", "05", "06", "07", "08"]},
@@ -772,7 +772,7 @@
   text: "Byte Merge Operation"
   }
 }
-{{< /wavejson >}}
+```
 
 ## Shift Register
 
@@ -793,7 +793,7 @@
    - The `rd_ready_o` output informs the FSM whenever all data storage (the RX FIFO plus any intervening buffers) is full and no further data can be acquired.
 - `last_read_i`: When asserted at the same time as `rd_en_i`, this indicates that the current byte is the last of its command segment, and thus the `rx_last_o` signal should be asserted when passing this byte to the Byte Merge block.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: "clk_i",                   wave: "p.........................."},
  [ "External signals",
@@ -828,7 +828,7 @@
   text: "Shift Register During Standard SPI Transaction: Simultaneous Receipt and Transmission of Data."
 },
 }
-{{< /wavejson >}}
+```
 
 The connection from the shift register to the `sd` bus depends on the speed of the current segment.
 - In Standard-mode, only the most significant shift register bit, `sr_q[7]` is connected to the outputs using `sd_o[0]`.
@@ -883,7 +883,7 @@
 
 $$T_\textrm{timeslice} = \frac{T_{\textrm{clk},\textrm{clk}}}{\texttt{clkdiv}+1}.$$
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk',        wave: 'p......................'},
   {name: 'clkdiv',     wave: '2......................', data: "3"},
@@ -896,7 +896,7 @@
  head: {text: "Use of FSM Enable Pulses to Realize Multi-Clock Timeslices", tock: 1},
  foot: { text: "The fsm_en signal is always high in idle states, to allow exit transitions at any time"}
 }
-{{< /wavejson >}}
+```
 
 #### Other Internal Counters
 
@@ -951,7 +951,7 @@
 The `wait_cntr` register resets to {{#regref spi_host.CONFIGOPTS.CSNIDLE }} upon entering this state, and is decremented once per timeslice.
 This state transitions to `Idle` when `wait_cntr` reaches zero.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p...............'},
   {name: 'rst_n', wave: '01..............'},
@@ -962,7 +962,7 @@
 ],
  config: {hscale: 2}
 }
-{{< /wavejson >}}
+```
 
 ### Milestone Signals, Serial Data Lines & Shift Register Control
 
@@ -982,7 +982,7 @@
 The coordination of the milestone signals and the shift register controls are shown in the following waveform.
 Since the milestone signal pulses coincide with *entering* particular FSM states, they are derived from the state register *inputs* (i.e., `state_d`), as opposed to the state register outputs (`state_q`).
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p........................'},
   {name: 'rst_n', wave: '01.......................'},
@@ -1021,7 +1021,7 @@
 head: {text: "Timing Relationship between FSM states, Milestone Signals, and Shift Register controls (with CPHA=0)"},
 foot: {text: "Key: WL=\"WaitLead\", Hi=\"InternalClkHigh\", Lo=\"InternalClkLow\" "}
 }
-{{< /wavejson >}}
+```
 
 When working from a CPHA=0 configuration, the milestone signals are directly controlled by transitions in the FSM state register, as described in the following table.
 
@@ -1049,7 +1049,7 @@
 - the original FSM-driven copy, for use when operating with CPHA=0, and
 - a delayed copy, for use in CPHA=1 operation.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p......................'},
   {name: 'rst_n', wave: '01.....................'},
@@ -1116,7 +1116,7 @@
 head: {text: "Comparison of Milestone Signals in CPHA=0 vs. CPHA=1 configuration (for a dual speed segment)"},
 foot: {text: "Key: WL=\"WaitLead\", Hi=\"InternalClkHigh\", Lo=\"InternalClkLow\", WT=\"WaitTrail\""}
 }
-{{< /wavejson >}}
+```
 
 ### Milestone Signals and Control of the the Bit and Byte Counters
 
@@ -1152,7 +1152,7 @@
 
 The following waveform illustrates how a change in a single {{#regref spi_host.CONFIGOPTS }}, here {{#regref spi_host.CONFIGOPTS.CPOL }}, triggers an entry into the `ConfigSwitch` Idle state, and how the new configuration is applied at the transition from `WaitIdle` to `ConfigSwitch` thereby ensuring ample idle time both before and after the configuration update.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk',                       wave: 'p.................'},
   {name: 'command_i.csid',            wave: '2.................', data: ["0"]},
@@ -1170,7 +1170,7 @@
   head: {text: "Extension of CSB Idle Pulse Due to CPOL Configuration Switch", tock: 1},
   foot: { text: "(Note: Due to the presence of a valid command, the FSM transitions directly from WaitIdle to ConfigSwitch)"}
 }
-{{< /wavejson >}}
+```
 
 ### CSAAT Support
 
@@ -1187,7 +1187,7 @@
 It is different from the `Idle` state though in that during this state the active `csb` is held low.
 When a command segment is received in the `IdleCSBActive` state, it transitions immediately to the `InternalClkLow` state to generate the next `sck` pulse and process the next segment.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk', wave: 'p...........'},
   {name: 'command_ready_o', wave: '0.1....0....'},
@@ -1200,7 +1200,7 @@
   edge: ["A<->B min. 9 cycles", "C<->D min. 4 cycles"],
   head: {text: "Idling While CS Active", tock: 1}
 }
-{{< /wavejson >}}
+```
 
 The following figure shows the complete state transition diagram of for the SPI_HOST FSM.
 
@@ -1328,7 +1328,7 @@
 This is illustrated in the following figure, which depicts a Fast Quad Read I/O command.
 Assuming that `ByteOrder` is set to `1` for Little-Endian devices such as Ibex, byte-swapping will be required for these addresses, otherwise the device will receive the addresses LSB first.
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   {name:"csb", wave:"10........................."},
   {name:"sck", wave:"lnn........................"},
@@ -1348,7 +1348,7 @@
          'L<->M Address', 'N<->O Data'],
 
  foot: {text: "Addresses are transmitted MSB first, and data is returned in order of increasing peripheral byte address."}}
-{{< /wavejson >}}
+```
 
 Byte ordering on the bus can also be managed by writing {{#regref spi_host.TXDATA }} as a sequence of discrete bytes using 8-bit transactions, since partially-filled data-words are always sent in the order they are received.
 
@@ -1453,7 +1453,7 @@
 Such stalls however are a much smaller concern in the RX direction due to the buffering of the Shift Register outputs.
 As shown in the following waveform, even in Quad-mode, this buffer means the shift register can tolerate as many as six clock cycles of temporary back-pressure before creating a stall.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   [ "Shift Register Ports",
   {name: "clk_core_i",                  wave: "p..........................."},
@@ -1470,12 +1470,12 @@
   edge: ["A<->B 6 clocks: No Stall", "C<->D 7 clocks will stall FSM"],
   head: {text: "SPI_HOST Shift Register: Tolerance to Gaps in rx_ready_i", tick:1}
 }
-{{< /wavejson >}}
+```
 
 Even though such long delays are tolerable, it takes some time for shift register to catch up completely and clear the backlog.
 For example, if after a 6-clock delay the shift-register encounters another 4-clock backlog this can also introduce a stall condition, as shown in the waveform below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   ["Shift Register Ports",
   {name: "clk_core_i", wave: "p........................"},
@@ -1492,14 +1492,14 @@
   edge: ["A<->B 1st Gap: 6 clocks", "C<->D 2nd Gap: 4 clocks"],
   head: {text: "SPI_HOST Shift Register: Back-to-back gaps in rx_ready_i", tick:1}
 }
-{{< /wavejson >}}
+```
 
 Delays of 3-clocks or less do not create any internal backlog in the system.
 However, the Byte Merge block can create a 4-clock delay each time it processes a single-byte segment.
 In practice, this is unlikely to cause a problem, as no Quad-SPI Flash transactions require even two back-to-back RX segments.
 However with enough (at least six) consecutive one-byte segments, the accumulated delay can eventually create a stall event on the RX path as well, as seen below.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
  [ "Shift Register Ports",
   {name: "clk_core_i", wave: "p..........................."},
@@ -1518,4 +1518,4 @@
   head: {text: "SPI_HOST Shift Register: Hypothetical RX Congestion Scenario", tick:1},
  foot: {text: "Six back-to-back quad reads 1-byte each, same CSID, CSAAT enabled"}
 }
-{{< /wavejson >}}
+```
diff --git a/hw/ip/sram_ctrl/README.md b/hw/ip/sram_ctrl/README.md
index 4591a03..3ba81dd 100644
--- a/hw/ip/sram_ctrl/README.md
+++ b/hw/ip/sram_ctrl/README.md
@@ -82,7 +82,7 @@
 The key and nonce are made available to the scrambling primitive in the subsequent cycle.
 The wave diagram below illustrates this process.
 
-{{< wavejson >}}
+```wavejson
 {signal: [
   {name: 'clk_otp_i',                 wave: 'p...........'},
   {name: 'sram_otp_key_o.req',        wave: '0.|1.|..0|..'},
@@ -97,7 +97,7 @@
   {name: 'nonce_q',                   wave: '4.|..|...|3.'},
   {name: 'key_seed_valid_q',          wave: '4.|..|...|3.'},
 ]}
-{{< /wavejson >}}
+```
 
 If the key seeds have not yet been provisioned in OTP, the keys are derived from all-zero constants, and the `*.seed_valid` signal will be set to 0 in the response.
 It should be noted that this mechanism requires the CSRNG and entropy distribution network to be operational, and a key derivation request will block if they are not.
diff --git a/hw/ip/tlul/README.md b/hw/ip/tlul/README.md
index 3883359..ae243e3 100644
--- a/hw/ip/tlul/README.md
+++ b/hw/ip/tlul/README.md
@@ -387,7 +387,7 @@
 response, and reads with response. This shows a few transactions, see
 the TileLink specification for more examples.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',      wave: 'p...................' },
@@ -415,9 +415,9 @@
     text: 'six write transactions (four full, two partial) with various req/ready delays, error on I4 response',
     }
 }
-{{< /wavejson >}}
+```
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',    wave: 'p...................' },
@@ -443,7 +443,7 @@
     text: 'six read transactions with various req/ready delays, error on I4 response',
     }
 }
-{{< /wavejson >}}
+```
 
 ## Bus Primitives
 
diff --git a/hw/ip/uart/README.md b/hw/ip/uart/README.md
index feadb76..df6fb88 100644
--- a/hw/ip/uart/README.md
+++ b/hw/ip/uart/README.md
@@ -54,7 +54,7 @@
 even parity bit follows after the data bits. Finally a STOP (**1**) bit
 completes one byte of data transfer.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'Baud Clock',     wave: 'p............'                                                        },
@@ -81,7 +81,7 @@
     tock: -2,
   }
 }
-{{< /wavejson >}}
+```
 
 ### Transmission
 
@@ -127,7 +127,7 @@
 the stop bit will be a bit time later, so this becomes 8/160 or about
 +/- 5%.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'Sample', wave: '', node: '..P............', period: "2" },
@@ -143,7 +143,7 @@
     text: 'Receiver sampling window',
   },
 }
-{{< /wavejson >}}
+```
 
 In practice, the transmitter and receiver will both differ from the
 ideal baud rate. Since the worst case difference for reception is 5%,
@@ -263,7 +263,7 @@
 the frame error will be set at every char-time. Frame errors will continue to
 be reported after a break error.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'Baud Clock',        wave: 'p............'                                                 },
@@ -286,7 +286,7 @@
     tock: -2,
   }
 }
-{{< /wavejson >}}
+```
 
 The effects of the line being low for certain periods are summarized
 in the table:
diff --git a/hw/ip_templates/alert_handler/README.md b/hw/ip_templates/alert_handler/README.md
index f3dfce4..be952d6 100644
--- a/hw/ip_templates/alert_handler/README.md
+++ b/hw/ip_templates/alert_handler/README.md
@@ -206,7 +206,7 @@
 
 The wave pattern below illustrates differential full handshake mechanism.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                wave: 'p...............' },
@@ -232,7 +232,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 The handshake pattern is repeated as long as the alert is true.
 The sender will wait for 2 cycles between handshakes.
@@ -258,7 +258,7 @@
 
 The following wave diagram illustrates a correct ping sequence, viewed from the receiver side:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',              wave: 'p..............' },
@@ -284,7 +284,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 In the unlikely case that a ping request collides with a native alert at the sender side, the native alert is held back until the ping handshake has been completed.
 This slightly delays the transmission of a native alert, but the alert will eventually be signaled.
@@ -307,7 +307,7 @@
 
 Some of these failure patterns are illustrated in the wave diagram below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',               wave: 'p..............' },
@@ -330,7 +330,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Note that if signal integrity failures occur during ping or alert handshaking, it is possible that the protocol state-machines lock up and the alert sender and receiver modules become unresponsive. However, the above mechanisms ensure that this will always trigger either a signal integrity alert or eventually a "pingfail" alert.
 
@@ -338,7 +338,7 @@
 
 Note that there is likely a (small) skew present within each differential pair of the signaling mechanism above. Since these pairs cross clock domain boundaries, it may thus happen that a level change appears in staggered manner after resynchronization, as illustrated below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',   wave: 'p...........' },
@@ -357,7 +357,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 This behavior is permissible, but needs to be accounted for in the protocol logic.
 Further, the skew within the differential pair should be constrained to be smaller than the shortest clock period in the system.
@@ -488,7 +488,7 @@
 The next waveform shows the gathering of alerts of one class until eventually the escalation protocol is engaged.
 In this diagram, two different alerts are shown for class A, and the gathering and escalation configuration values are shown.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                        wave: 'p...................' },
@@ -526,7 +526,7 @@
     tick: 0,
     }
 }
-{{< /wavejson >}}
+```
 
 In this diagram, the first alert triggers an interrupt to class A.
 The assumption is that the processor is wedged or taken over, in which case it does not handle the interrupt.
@@ -537,7 +537,7 @@
 
 The next wave shows a case where an interrupt remains unhandled and hence the interrupt timeout counter triggers escalation.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                       wave: 'p.....................' },
@@ -566,7 +566,7 @@
     tick: 0,
     }
 }
-{{< /wavejson >}}
+```
 
 It should be noted here that the differential escalation signaling protocol distinguishes 'true' escalation conditions from mere pings by encoding them as pulses that are N + 1 cycles long.
 This is reflected in the two wave diagrams above.
@@ -588,7 +588,7 @@
 Further, it acknowledges the receipt of that message by continuously toggling the `esc_rx.resp_p/n` signals as long as the escalation signal is asserted.
 Any failure to respond correctly will trigger a `integ_fail_o` alert, as illustrated below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',             wave: 'p..................' },
@@ -615,7 +615,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Further, any differential signal mismatch on both the `esc_tx_i.esc_p/n` and `esc_rx_i.resp_p/n` lines will trigger an `integ_fail_o` alert.
 Mismatches on `esc_rx_i.resp_p/n` can be directly detected at the sender.
@@ -627,7 +627,7 @@
 
 Some signal integrity failure cases are illustrated in the wave diagram below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',           wave: 'p...........' },
@@ -654,7 +654,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 
 ### Ping Testing of the Escalation Signals
@@ -670,7 +670,7 @@
 
 This mechanism is illustrated below from the viewpoint of the sender module.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',           wave: 'p..............' },
@@ -697,7 +697,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Note that the escalation signal always takes precedence, and the `ping_req_i` will just be acknowledged with `ping_ok_o` in case `esc_req_i` is already asserted.
 An ongoing ping sequence will be aborted immediately.
diff --git a/hw/ip_templates/rv_plic/README.md b/hw/ip_templates/rv_plic/README.md
index 5d03af0..644cd48 100644
--- a/hw/ip_templates/rv_plic/README.md
+++ b/hw/ip_templates/rv_plic/README.md
@@ -118,7 +118,7 @@
 originating interrupt event during the time between claim and complete such that
 `intr_src_i[ID]` will have de-asserted (unless a new interrupt has occurred).
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'clk',           wave: 'p...........' },
   { name: 'intr_src_i[i]', wave: '01....0.1...', node:'.a....e.f...'},
@@ -133,7 +133,7 @@
     tick: 0,
   },
 }
-{{< /wavejson >}}
+```
 
 In the example above an interrupt for source ID `i` is configured as a level
 interrupt and is raised at a, this results in the target being notified of the
diff --git a/hw/top_earlgrey/ip/ast/README.md b/hw/top_earlgrey/ip/ast/README.md
index 6ac4c91..8840ae8 100644
--- a/hw/top_earlgrey/ip/ast/README.md
+++ b/hw/top_earlgrey/ip/ast/README.md
@@ -1084,13 +1084,15 @@
 
 7.  Deactivate the ADC by setting 'adc_pd_i' to save power.
 
-{{< wavejson >}} { signal: [ {node: '.a..b........', phase:0.2},
+```wavejson
+{ signal: [ {node: '.a..b........', phase:0.2},
 {name: 'adc_pd_i' , wave: '10|..|.....|....|..1'}, {name:
 'clk_ast_adc_i', wave: 'p.|..|.....|....|...'}, {name:
 'adc_chnsel_i' , wave: '0.|.3|..04.|....|0..'}, {name:
 'adc_d_val_o' , wave: '0.|..|.1.0.|.1..|.0.'}, {name: 'adc_d_o' ,
 wave: 'x.|..|.3.x.|.4..|.x.', data: ['ch0', 'ch1', 'ch1']}, ],
-edge: [ 'a<->b wakeup time', ] } {{< /wavejson >}}
+edge: [ 'a<->b wakeup time', ] }
+```
 
 # Random Number Generator
 
@@ -1102,12 +1104,13 @@
 can be sampled whenever 'rng_val_o' is asserted according to the
 following diagram.
 
-{{< wavejson >}} {signal: [ {name: 'clk' , wave:
+```wavejson
+{signal: [ {name: 'clk' , wave:
 'p.|......|......|......'}, {name: 'rng_enable' , wave:
 '01|......|......|......'}, {name: 'rng_valid' , wave:
 '0.|..10..|..10..|..10..'}, {name: 'rng_b' , wave:
-'x.|..3...|..4...|..5.....', data: ['es0','es1','es2']}, ]} {{<
-/wavejson >}}
+'x.|..3...|..4...|..5.....', data: ['es0','es1','es2']}, ]}
+```
 
 The expected rng_b_o valid output rate is about 50KHz. For more
 information on the RNG interface, please see the [<u>OpenTitan entropy
@@ -1123,7 +1126,8 @@
 interface. Also note that once entropy_req_o is set, it will remain set
 until ack or until reset.
 
-{{< wavejson >}} {signal: [
+```wavejson
+{signal: [
 
 {name: 'clk_ast_es_i' , wave: 'p.|..........'},
 
@@ -1133,7 +1137,8 @@
 
 {name: 'entropy_i' , wave: 'xx|2x.22x222x'},
 
-] } {{< /wavejson >}}
+] }
+```
 
 # Countermeasures and Alerts
 
diff --git a/hw/top_earlgrey/ip_autogen/alert_handler/README.md b/hw/top_earlgrey/ip_autogen/alert_handler/README.md
index f26ed64..8c0411e 100644
--- a/hw/top_earlgrey/ip_autogen/alert_handler/README.md
+++ b/hw/top_earlgrey/ip_autogen/alert_handler/README.md
@@ -206,7 +206,7 @@
 
 The wave pattern below illustrates differential full handshake mechanism.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                wave: 'p...............' },
@@ -232,7 +232,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 The handshake pattern is repeated as long as the alert is true.
 The sender will wait for 2 cycles between handshakes.
@@ -258,7 +258,7 @@
 
 The following wave diagram illustrates a correct ping sequence, viewed from the receiver side:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',              wave: 'p..............' },
@@ -284,7 +284,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 In the unlikely case that a ping request collides with a native alert at the sender side, the native alert is held back until the ping handshake has been completed.
 This slightly delays the transmission of a native alert, but the alert will eventually be signaled.
@@ -307,7 +307,7 @@
 
 Some of these failure patterns are illustrated in the wave diagram below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',               wave: 'p..............' },
@@ -330,7 +330,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Note that if signal integrity failures occur during ping or alert handshaking, it is possible that the protocol state-machines lock up and the alert sender and receiver modules become unresponsive. However, the above mechanisms ensure that this will always trigger either a signal integrity alert or eventually a "pingfail" alert.
 
@@ -338,7 +338,7 @@
 
 Note that there is likely a (small) skew present within each differential pair of the signaling mechanism above. Since these pairs cross clock domain boundaries, it may thus happen that a level change appears in staggered manner after resynchronization, as illustrated below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',   wave: 'p...........' },
@@ -357,7 +357,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 This behavior is permissible, but needs to be accounted for in the protocol logic.
 Further, the skew within the differential pair should be constrained to be smaller than the shortest clock period in the system.
@@ -488,7 +488,7 @@
 The next waveform shows the gathering of alerts of one class until eventually the escalation protocol is engaged.
 In this diagram, two different alerts are shown for class A, and the gathering and escalation configuration values are shown.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                        wave: 'p...................' },
@@ -526,7 +526,7 @@
     tick: 0,
     }
 }
-{{< /wavejson >}}
+```
 
 In this diagram, the first alert triggers an interrupt to class A.
 The assumption is that the processor is wedged or taken over, in which case it does not handle the interrupt.
@@ -537,7 +537,7 @@
 
 The next wave shows a case where an interrupt remains unhandled and hence the interrupt timeout counter triggers escalation.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',                       wave: 'p.....................' },
@@ -566,7 +566,7 @@
     tick: 0,
     }
 }
-{{< /wavejson >}}
+```
 
 It should be noted here that the differential escalation signaling protocol distinguishes 'true' escalation conditions from mere pings by encoding them as pulses that are N + 1 cycles long.
 This is reflected in the two wave diagrams above.
@@ -588,7 +588,7 @@
 Further, it acknowledges the receipt of that message by continuously toggling the `esc_rx.resp_p/n` signals as long as the escalation signal is asserted.
 Any failure to respond correctly will trigger a `integ_fail_o` alert, as illustrated below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',             wave: 'p..................' },
@@ -615,7 +615,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Further, any differential signal mismatch on both the `esc_tx_i.esc_p/n` and `esc_rx_i.resp_p/n` lines will trigger an `integ_fail_o` alert.
 Mismatches on `esc_rx_i.resp_p/n` can be directly detected at the sender.
@@ -627,7 +627,7 @@
 
 Some signal integrity failure cases are illustrated in the wave diagram below:
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',           wave: 'p...........' },
@@ -654,7 +654,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 
 ### Ping Testing of the Escalation Signals
@@ -670,7 +670,7 @@
 
 This mechanism is illustrated below from the viewpoint of the sender module.
 
-{{< wavejson >}}
+```wavejson
 {
   signal: [
     { name: 'clk_i',           wave: 'p..............' },
@@ -697,7 +697,7 @@
     tick: 0,
   }
 }
-{{< /wavejson >}}
+```
 
 Note that the escalation signal always takes precedence, and the `ping_req_i` will just be acknowledged with `ping_ok_o` in case `esc_req_i` is already asserted.
 An ongoing ping sequence will be aborted immediately.
diff --git a/hw/top_earlgrey/ip_autogen/rv_plic/README.md b/hw/top_earlgrey/ip_autogen/rv_plic/README.md
index 1befbfc..72de044 100644
--- a/hw/top_earlgrey/ip_autogen/rv_plic/README.md
+++ b/hw/top_earlgrey/ip_autogen/rv_plic/README.md
@@ -118,7 +118,7 @@
 originating interrupt event during the time between claim and complete such that
 `intr_src_i[ID]` will have de-asserted (unless a new interrupt has occurred).
 
-{{< wavejson >}}
+```wavejson
 { signal: [
   { name: 'clk',           wave: 'p...........' },
   { name: 'intr_src_i[i]', wave: '01....0.1...', node:'.a....e.f...'},
@@ -133,7 +133,7 @@
     tick: 0,
   },
 }
-{{< /wavejson >}}
+```
 
 In the example above an interrupt for source ID `i` is configured as a level
 interrupt and is raised at a, this results in the target being notified of the