(WIP) Add APB protocol with two DUTs from GitHub (one possibly buggy)

[ngernest]

This PR adds a .prot file for the APB protocol + round-trip tests against two Verilog DUTs obtained from GitHub:

• Impl 1: https://github.com/iammituraj/apb/blob/main/apb_slave.sv
• Impl 2: https://github.com/courageheart/AMBA_APB_SRAM/blob/master/rtl/apb_v3_sram.v
  (This second implementation was found as it is in the artifact for the Stitch paper : https://github.com/Xprotocols-lab/STITCH/blob/b0f5a78ed10d368a3c04baa029318abb8eb6bff6/testsuite/dut/apb_courageheart/patch_file/apb_courageheart.sv)

(Impl 1 passes the round-trip test, Impl 2 appears to have a bug -- discussed below)

Details about how the APB protocol works are in apb.prot, but at a high-level, it works very similar to the other protocols we've looked at so far (AXI-Stream, Wishbone).

To double check that the .prot file is written correctly, this PR also contains .wave files for the example waveforms in the APB spec (https://support.arm.com/documentation/ihi0024/e/), and expect tests for the BI on these .wave forms. (I manually checked the BI output for these .wave files to make sure they correspond with what's discussed in the manual.)

*Possible bug in Impl 2::

If we supply the following transactions to the interpreter:

// ch_apb.tx
reset();
idle();
write(0x00, 0x12345678, ...); 
read(0x00, 0x12345678, ...);
idle();

The interpreter emits the following error:

error: The two expressions did not evaluate to the same value (in transaction `read(0, 305419896, 0, 0)`)
      ┌─ examples/apb/apb.prot:136:15
       │
136 │     assert_eq(DUT.PRDATA, data);
       │               ^^^^^^^^^^^^^^^^ LHS Value: 0, RHS Value: 305419896

This error indicates that during a read transaction, the PRDATA signal (the read data) contains 0, instead of the data that was written in the preceding write transaction (i.e. 0x12345678 = 305419896).

The interpreter terminates immediately when it encounters this error, so to diagnose what was happening, I tried adding a "bogus" read transaction where the output read data is 0 to diagnose what is happening in the waveform, i.e. we provide the following .tx file:

...
write(0x00, 0x12345678, ...); 
read(0x00, 0x00, ...);  // <--- we insert this transaction where the read data is 0 to figure out what is happening
read(0x00, 0x12345678, ...);

In the waveform, we see that in cycle 5, we have PSEL, PENABLE and PREADY all being 1, but PRDATA still contains 0 instead of the data that was previously written 305419896. Appendix A.1 of the APB spec says when PSEL, PENABLE and PREADY are all asserted, PRDATA must be valid (contain semantically meaningful data), and section 3.3.1 ("read transfers with no wait states") says "The Completer (subordinate) must provide the (read) data before the end of the read transfer", so this appears to be a violation of the APB spec. The DUT only drives the read data 305419896 onto PRDATA one cycle afterwards (in cycle 6), but by then, PENABLE has become 0, which indicates the end of the data transfer.

With the same .prot file, round-trip tests for Impl 1 succeed with multiple read/write transactions, so the fact that Impl 2 fails on the interpreter leads me to wonder if this is a bug with Impl 2.

[ekiwi]

I think this is missing one in wave riht after "ethmax"

[ngernest]

Fixed, thanks!