[Libre-soc-dev] [OpenPOWER-HDL-Cores] microwatt dcache potential bug (overlap r0 and r1)

lkcl luke.leighton at gmail.com
Fri Jan 14 22:25:07 GMT 2022



On January 14, 2022 9:46:41 PM UTC, Paul Mackerras <paulus at ozlabs.org> wrote:

>> * dcache is currently *still processing r1.state=RELOAD_WAIT_ACK*,
>>   r1.full is *ZERO*, and yet it gets asked to process the incoming
>>   "std" operation.
>
>In this situation, the incoming store request should get put into
>r1.req 

i'm seeing that [in dcache.py]

> and then processed once the state machine gets back to IDLE
>state. 

this is what's not happening: it looks like it's getting processed immediately even whilst r1.state != IDLE. i have no idea why... yet.

did a 10min video btw https://m.youtube.com/watch?v=_Q8J10nBGeo

> In the VHDL, the variable 'req' represents a multiplexer that
>selects between r1.req (the stored request) and a request constructed
>from req_op, ra, r0.req, etc.

yes, ditto, dcache.py is a literal line-for-line translation of dcache.vhdl.  mostly.

>  This enables the state machine to
>handle either a request that has just arrived, or one that came in
>previously while the state machine was busy.  It's like a 1-entry
>FIFO (but with 0 latency in the empty case).

got it.  i have a req as well, what with dcache.py being a direct translation.  nmigen does not have the concept of VHDL "variables", though: instead the rules for combinatorial assignment are followed [last assigner "wins" and *all* uses even ones in earlier HDL use that last combinatorially-assigned value]

[this made the translation of the PLRU to nmigen parteeecularly hairy :) i had to create multiple signals with new names each time inside the loop. works great: is just hard to understand]

>> now, whether this is a bug in the porting of dcache.vhdl to dcache.py
>> or whether it's a bug in the original i honestly couldn't say.
>
>I haven't looked at your dcache.py translation.  Is it accessible
>somewhere? (not that I'm much good at python...)

:) the names have [not] been changed, to protect the innocent...
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/dcache.py;h=9f6ba0d4edf9fb67cd0f19e48946487e095b395b;hb=refs/heads/ldst_misalign

comb is combinatorial, sync is DFFs.  should be fairly self explanatory, what with the names being the same. mentally ignore the word "with" before anything and it's readable

>The VHDL certainly is designed to be able to handle a store coming in
>while r1.full = 0 and the state machine is in RELOAD_WAIT_ACK state.

hmm then i need to look at that closely.

l.



More information about the Libre-soc-dev mailing list