[Libre-soc-bugs] [Bug 393] Hook up augmented-Wishbone Memory Bus to LDSTCompUnit (via PortInterface)

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=393

--- Comment #21 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
michael i created a file soc/experiment/pi2ls.py which contains this:

"""
    PortInterface                LoadStoreUnitInterface

    is_ld_i/1                    x_ld_i
    is_st_i/1                    x_st_i

    data_len/4                   x_mask/16  (translate using LenExpand)

    busy_o/1                     most likely to be x_busy_o
    go_die_i/1                   rst?
    addr.data/48                 x_addr_i[4:] (x_addr_i[:4] goes into
LenExpand)
    addr.ok/1                    probably x_valid_i & ~x_stall_i

    addr_ok_o/1                  no equivalent.  *might* work using x_stall_i
    addr_exc_o/2(?)              m_load_err_o and m_store_err_o

    ld.data/64                   m_ld_data_o
    ld.ok/1                      probably implicit, when x_busy drops low
    st.data/64                   x_st_data_i
    st.ok/1                      probably kinda redundant, set to x_st_i
"""

it shows the mapping between PI and LSUI, as best as i can determine,
and also shows where LenExpand gets used.  from TestMemoryPortInterface:

            # set up LenExpander with the LD len and lower bits of addr
            lsbaddr, msbaddr = self.splitaddr(ldport.addr.data)
            comb += lenexp.len_i.eq(ldport.data_len)
            comb += lenexp.addr_i.eq(lsbaddr)

and then this should do the trick:

            comb += lsui.x_mask_i.eq(lenexp.exp_o)

btw TestMemoryPortInterface is done as a FSM because, given that it represents
PortInterface, it has to do the 3 things: offer, exchange, complete.

so this is why there is the "adrok_l" latch, because that is kept LOW to
indicate the "offer" phase is still being negotiated.  once "adrok_l" goes
HI this indicates a move into "exchange" phase of the Contract.

* "complete" is represented by reset_l.

the "offer" part the bit where we have to fudge things for a while: still have
that
"address ok / not-ok" phase however return fake answers ("yes address is always
ok")

or, if you actually want to make it "work", check the size of the TestMemory,
and if the address is out of range of the size of the TestMemory, actually
set addr_exc_o to 1!

-- 
You are receiving this mail because:
You are on the CC list for the bug.