[libre-riscv-dev] daily kan-ban 07may2020 update

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri May 8 03:26:11 BST 2020


On Friday, May 8, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:

> I attended the OpenPower virtual coffee meeting, there was an interesting
> suggestion to see if we could move to a later tapeout than october, to
> avoid burnout due to deadline crunch.


i've written to Staf to see what is available.  if you recall we have an
agreement to let him use the Oct2020 slot.  so he is "2nd in queue".

there were other ideas to do a simpler processor for that slot.  however
these would likely go to the *back* of the queue (as a new request for that
slot: "3rd in queue").



>
> I also weighed in on nmigen signed/unsigned sign extension/zero
> extension/truncation operators:
> https://github.com/nmigen/nmigen/issues/381


ah as long as they are explicit rules that in no way change current
behavior (like the signed shift one which caused unit tests to inexplicably
fail for no reason right when we do not need the hassle) we're good.



> still slowly getting through the load/store unit stuff, progress may be a
> little slow since I have a bunch of stuff I need to do at home as well.


ok.

remember, address is divided as:

* bits 0 to 3 plus len turned into 16 bit mask
* bit 4 is for odd-even L1 cache bank selection.
* bits 5 thru 11 go through a 2D AddrMatch, as part of the DMs
* bits 12 and above need checking in 1D, *only* in the L0CacheBuffer.

however if you completely ignore *everything* and i mean everything other
than PortInterface (and the prototype L0CacheBuffer) and just do a
comparison on the full bits 5 thru 48 we can add the information from
AddrMatch later.

the task needed really is genuinely much simpler than it seems. estimated
about... 100 lines of code.

l .


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the libre-riscv-dev mailing list