[Libre-soc-bugs] [Bug 762] Peripheral Pin Muxing Development

[bugzilla-daemon at libre-soc.org]

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

--- Comment #27 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #26)
> replace with:
> 
>   93         comb += wb_rd_data.eq(Cat(*rd_multi))
>   94         for i in range(len(bus.sel)):
>                   sync += rd_multi[i].eq(0)
Yes! Thanks for the simplification.

> NO.  again, you are creating a 2-clock situation where bus.we will
> be ***INVALID*** at the time new_transaction is raised.
> ...
> the entirety of the wishbone transaction is
> ***ONLY VALID AT THE CYCLE IT OCCURS***
> 
> look again at the WB4 specification PDF.  how on earth can the specification
> be complied with if new_transaction is raised to indicate "please only read
> wb.we on the **NEXT** cycle"??
> ...
> yes it has taken me at least one year to fully understand this, you are
> not alone in getting it wrong.  it is an absolute pig.
Yes, after you explanation and re-reading the spec, it makes sense.
Thanks for drilling it in!

Given that the intermediate signals are now combinatorial, the reading/writing
of GPIO reg's can be done in the cycle where the slave detects the master's
transaction. No "new_transaction" signals anymore.

https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=70a9e00ebc3873399d36cfd45a555121dc9ce8ef

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