|
Message
From: mphan@n...
Date: Thu, 26 Jun 2003 17:51:44 -0100
Subject: Re: [openrisc] Cache Line Fill
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
> > > > >
> > > > >
> > > >
> > >
> >
> >
>
|
 |
Browse
