Re: [openrisc] Cache Line Fill

[mphan@nimbuswireless.com]

Hi Damjan,

I hope you are back from travelling and had a nice one.
Did you check in the changes for "I RAM replacement for I cache" yet?
I am waiting to test it out.

Thanks
Michael Phan


----- Original Message ----- 
From: "Damjan Lampret" <lampret@o... > 
To: <mphan@n... >, 
<openrisc@o... > 
Date: Sat, 7 Jun 2003 00:47:12 -0700 
Subject: Re: [openrisc] Cache Line Fill 

> 
> 
> Michael, 
> 
> I assume you mean the I RAM replacement for I cache? Not yet, for 
> the moment 
> you can use RAM connected to iwb and I'll commit the changes to the 
> cvs next 
> weekend (I'm travelling this weekend until next weekend). 
> 
> regards, 
> Damjan 
> 
> ----- Original Message ----- 
> From: <mphan@n... > 
> To: <mphan@n... >; 
> <openrisc@o... > 
> Sent: Friday, June 06, 2003 11:11 AM 
> Subject: Re: [openrisc] Cache Line Fill 
> 
> 
> > 
> > HI Damjan, 
> > 
> > Just want to touch base with you on this project, "instruction 
> execution 
> > with 0 wait state", did yo have a chane to put the changes 
> into the 
> > CVS so we can download and try them out. 
> > 
> > Thanks in advance 
> > Michael Phan 
> > 
> > 
> > ----- Original Message ----- 
> > From: mphan@n... 
> > To: lampret@o... , openrisc@o... 
> > Date: Tue, 6 May 2003 17:57:54 -0100 
> > Subject: Re: [openrisc] Cache Line Fill 
> > 
> > > 
> > > 
> > > 
> > > Hi Damjan, 
> > > 
> > > Your feedbacks are so precious and helpful to our 
> project. Exactly, 
> > > we 
> > > don't need to use MMU and want to replace the cache with 
> fixed 
> > > memory for instruction execution with 0 wait state. So 
> please put 
> > > your 
> > > changes in the CVS at your convenience so we can try it 
> out and 
> > > measure the performance improvement. Our project needs 
> about 512 
> > KB 
> > > for the cache. 
> > > 
> > > Thousand thanks 
> > > Michael Phan 
> > > 
> > > 
> > > 
> > > ----- Original Message ----- 
> > > From: "Damjan Lampret" <lampret@o... > 
> > > To: <openrisc@o... > 
> > > Date: Mon, 5 May 2003 21:21:38 -0700 
> > > Subject: Re: [openrisc] Cache Line Fill 
> > > 
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message ----- 
> > > > From: <mphan@n... > 
> > > > To: <openrisc@o... > 
> > > > Sent: Thursday, May 01, 2003 3:36 PM 
> > > > Subject: [openrisc] Cache Line Fill 
> > > > 
> > > > 
> > > > > Hi Damjan. 
> > > > > 
> > > > > In the current design of orp_soc, with 
> > > or1200_registered_ouput 
> > > > > supported, a cache line fill takes 8 clocks 
> (2-2-2-2) to 
> > > fetch 
> > > > 4 DWORDs 
> > > > > from the SRAM/FLASH. And a single  DWORD fetch 
> takes 3 
> > > clocks 
> > > > > (including one idle cycle of wb_cyc_o 
> deasserted). 
> > > > > 
> > > > > If we have a very fast internal SRAM, is it 
> possible to 
> > > do a 
> > > > cache line 
> > > > fill 
> > > > > with 4/5 clocks (1/2-1-1-1) by changing the 
> wb_stb logic 
> > > in 
> > > > the 
> > > > > or1200_wb_biu.v and do a single DWORD fetch 
> with 2 
> > > clocks. 
> > > > 
> > > > OR1200 is it is has been used in SoC projects much 
> more 
> > > complxed 
> > > > than 
> > > > orp_soc. In all these projects the memory subsystem 
> takes more 
> > > than 
> > > > 1/2-1-1-1. So the current 2-2-2-2 was fast enough 
> for all 
> > > SoCs. If 
> > > > you 
> > > > however have faster memory subsystem than 
> modification of 
> > > > or1200_wb_biu and 
> > > > possibly IC/DC state machines will be needed. 
> > > > 
> > > > > 
> > > > > My next question is can we increase to cache 
> size to 512 
> > > kB to 
> > > > reside 
> > > > > the whole firmware and execute instructions 
> from it with 
> > > 0 
> > > > wait state. 
> > > > > 
> > > > 
> > > > If you want to use MMUs, then no. This is because 
> MMU's page 
> > > > translation is 
> > > > done at the same time as cache access - virtual page 
> number is 
> > > > translated at 
> > > > the same time as cache hit is determined. Since page 
> size is 
> > > 8KB, 
> > > > largest 
> > > > direct mapped cache can only be 8KB, unless you use 
> several 
> > > ways, 
> > > > or unless 
> > > > cache access takes an additional clock cycle (maybe 
> acceptable 
> > > for 
> > > > data 
> > > > accesses ?). 
> > > > 
> > > > Anyway if you don't need MMU, then your caches sizes 
> are not 
> > > > limited. To 
> > > > increase cache size just add new IC/DC configuration 
> (search 
> > > for 
> > > > "configuration" in or1200_defines.v and when you 
> find IC and 
> > > DC 
> > > > configurations, just add a new size and then enable 
> new 
> > > > configuration). 
> > > > Right now there are configurations for 4KB and 8KB 
> caches. 
> > > > 
> > > > I'm working on one project where similar to your 
> case all code 
> > > > needs to be 
> > > > accessible in 0 wait states. What I plan to do is to 
> replaces 
> > > > caches with 
> > > > fixed memories - basically removing TAG RAMs and 
> making sure 
> > > that 
> > > > the "hit" 
> > > > always happens when accessing certain address range 
> and never 
> > > > happens when 
> > > > accesssing outside of that range. This will 
> effectively 
> > > "change 
> > > > caches into 
> > > > fixed RAMs much like DSP RAMs or similar). 
> > > > If you want these changes, I can put them into the 
> cvs with 
> > > > appropriate 
> > > > defines. But it will take a few days. 
> > > > 
> > > > regards, 
> > > > Damjan 
> > > > 
> > > > > Thanks 
> > > > > 
> > > > > Michael Phan 
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> > 
> 
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml