Hello everyone ,
Am i brainless to ask those questions ? or they have been processed ?
Because since i'm asking for help there is no answers .
This time i just want to know if it's possible to profile an application in
full system with arm as architecture using gprof ?
Thanks
--
*Cordialement*
Dear All,
I am running a full-system ARM simulation
(aarch-system-2014-10/vmlinux.aarch32.ll_20131205.0-gem5).
I intend to flush the L1 and L2 caches in my device driver.
For the L1 cache, I succeed without any problem, but for the L2 cache when
I use *outer_clean_range()*, nothing happens, and w
Hi Erfan,
The cache management instructions are currently not implemented. It would be a
great addition though. The only related instruction that is currently supported
is dzcva. If you’re interested in filling in the blanks I’m sure there are
plenty people willing to help out.
All devices in
Dear Andreas,
Thank you very much for the info,
Best,
On Mon, May 4, 2015 at 3:43 PM, Andreas Hansson
wrote:
> Hi Erfan,
>
> The cache management instructions are currently not implemented. It
> would be a great addition though. The only related instruction that is
> currently supported is d
Hello All,
I am simulating an ARM O3 multi-core system with private L1 cache and a
Shared L2 cache.
I am investigating the MSHR contention in the L2 cache. If cache has no
free MSHRs, this Marks the access path of the cache as blocked and also
sets the blocked flag in the slave interface.This mean
Hi Prathap,
The most sensible place to implement the arbitration is indeed in the crossbar
which is conceptually part of the L2 cache. By default the crossbar uses
First-Come First-Served, but you can change with not too much coding. The
tricky bit in this case is to base the selection on MSHRs
Hi Andreas,
Thanks for your reply. I am trying to figure out how to implement this
based on your inputs. Can you also please point out the data structures
which maintains the queue in cross bar.?
Thanks,
Prathap
On Mon, May 4, 2015 at 4:04 PM, Andreas Hansson
wrote:
> Hi Prathap,
>
> The mos
Hi Prathap,
Check retryWaiting in Xbar. There we choose the port to go next when one or
more ports had to wait. If you want to implement what you suggest you also have
to perform a check in recvTimingReq to not just see if the layer is busy, but
also check if the port asking is within budget.
Thanks Andreas.
On Mon, May 4, 2015 at 5:11 PM, Andreas Hansson
wrote:
> Hi Prathap,
>
> Check retryWaiting in Xbar. There we choose the port to go next when one
> or more ports had to wait. If you want to implement what you suggest you
> also have to perform a check in recvTimingReq to not ju
