Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua <yimmanuel3@gatech.edu>]

> * when the core's executing instructions, we can start writing more
> comprehensive unit tests.
> * when the scoreboard is added, we re-run those unit tests.  if they
> work, chances are scoreboard is functional.
> * when that's added, we add multi-issue.  exactly the same same thing
> again: run the unit tests.

I completely support this approach.

>  if that takes several minutes to do (minerva takes a *minute*
> to compile to verilog), tough luck.

Minerva took 8 seconds to compile on my Mac…

> a higher level that then *ALSO* has a unit test, this type of approach
> is *EXACTLY* the kind of thing that will give investors a high degree
> of confidence that we will be a safe bet.

Exactly! I plan to mention this in my pitch deck.
My mentor has been helpful in getting the meat of the ideas out of my head.

Also, I’m fiddling around with the Minerva cache.
Not quite sure about a few things:

	1. Why are there s1 and s2 inputs? What does 1 vs 2 mean?
	https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L43 <https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L43>

	2. Why does s1_stall switch the memory read ports addresses from s1_addr to s2_addr?
	https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L141 <https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L141>
	
I reached out to Jean Paul from lambda concepts about this.
Once I figure out exactly how Minerva core works - I’ll write a 
tiny unit bench for it. Hopefully this would be helpful in modifying
it for our needs.


Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev