Re: [openrisc] Cache Line Fill

["Damjan Lampret" <lampret@opencores.org>]

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@nimbuswireless.com>
To: <mphan@nimbuswireless.com>; <openrisc@opencores.org>
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
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml