| one potential option would be to modify opal such that multiple pseq's (defined in system/pseq.C) write to the same copy of ruby. You'd have to add some disambiguation logic to know which requests were from where (after they were returned from ruby), but that wouldn't be too hard. Also it would likely need to make sure you can only do one memory request per cycle. To really make things work right you'd want the pseqs to use a "fair" scheme for selecting who has priority on issuing a memory request.
However, I don't really know why you'd want a shared L1... Opal already supports multi-threading, so I can't think of where it would be advantageous/feasible.
Phil On Nov 25, 2009, at 1:56 AM, csm wrote:
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}