M. Harte, Howard

Wishbone LPC Host and Peripheral Bridge

The wishbone bus in the wb_lpc_host block is little endian, 32 bits wide with byte granularity.  The code is written to assume all byte read/write data appears on wbs_dat[7:0].

I believe it should be written such that byte data appears across all 4 byte lanes with appropriate wbs_sel_i values depending on the decode of the bottom 2 address bits (ie an access to address 0xf00b0003 would have wbs_sel_i == 4'b1000, wbs_adr_i == 0xf00b0000, and the data on wbs_dat_i[31:24]).

wishbone byte strobe handling

The wb_lpc_host module doesn't handle the case where no device on the bus responds with a valid sync cycle for 3 clocks (see 4.2.1.9 paragraph 1 in the LPC spec) (ie in LPC_ST_SYNC state and lad_i == 4'b1111.  It looks like the correct action is to force an abort as per 4.2.1.13.

host SYNC error handling

looking in wb_lpc_defines.v the state defines for LPC_ST_P_TAR2 and LPC_ST_WB_RETIRE both have the value 14'h400.

LPC_ST_P_TAR2 and LPC_ST_WB_RETIRE have same value

According to the LPC standard, the peripheral should tri-states the bus and rely on pull-up to keep LAD bus at 1111 during the second turn-around clock.

The LPC peripheral should never drive the BUS during LPC_ST_H_TAR2 state

The LPC peripheral should implement the abort mechanism.
I think that a simple fix in all state (except LPC_ST_IDLE) could do the job:
>case(state)
>   'LPC_ST_XXXX:
>      begin
>         if(lframe_i) begin
>            lad_oe <= 1'b0;
>            state <= `LPC_ST_IDLE;
>         end
>         else begin
>            "actual code"
>         end
>      end

The LPC peripheral doesn't handle "abort" command

Quartus v8.1 is unable to synthesize wb_lpc_periph.v.

It gives the following error (for each lpc_dat_i bit):
Error (10818): Can't infer register for "lpc_dat_i[0]" at
wb_lpc_periph.v(419) because it does not hold its value outside the clock edge

This looks like a Quartus problem, rather than a coding problem!?!

The solution is to move:
            lpc_dat_i <= 32'h00000000;
from the 1st if(~nrst_i) statement (~line 120) into the 2nd (~line 390).

FWIW I actually tried splitting the two 'if' statements into 2 separate 'always' blocks, and got 'unable to resolve multiple drivers for lpc_dat_i'. The above change fixed that problem, and subsequently re-merging back into a single 'always' block worked - well, synthesized - as well.

Quartus v8.1 synthesis problem

The host finishes the first part of TAR. It should follow another cycle of 4'b1111, when no one drives the bus. But the peripheral immediately starts driving the SYNC.

LPC Peripheral illegaly drives the bus during TAR

LPC Spec, ch. 6.4.3 "DMA Request De-assertion":
"...To indicate the last byte of transfer, the peripheral uses a SYNC value of ‘0000b’ (Ready), or ‘1010b’ (Error). These encodings tell the host that this is the last piece of data transferred on a DMA read (host to peripheral), or the byte that follows is the last piece of data transferred on a DMA write (peripheral to host).
When the host sees one of these two encodings, it ends the DMA transfer after this byte and deasserts the DMA request to the 8237 controller. Therefore, if the host indicated a 16 bit transfer, the peripheral can end the transfer after one byte by indicating a SYNC value of ‘0000b’ or ‘1010b’."

RTL-as-a-host does not end a DMA WORD(SIZE=4'b0011) cycle after the peripheral replies with Ready(4'b0000) after the first byte. The host drives and the next byte+TAR, waiting for response, thus hanging the bus.

Browse

Wishbone LPC Host and Peripheral Bridge