Re: GDB/mapper cache problems

Hi -


> Alright, I figured the gdb problem. I hadn't connected the gdb yield pins to 
> the yield bus. gdb debugging now seems to work perfectly.

OK.  I believe that the C++ sid configuration engine in sid/main/dynamic
is not well customized yet for the arm family of targets, so you may
encounter a few such problems.

Regarding interleaving the processors, what you are seeing intentional.
The CPU models are parametrized to allow you to trade off speed versus
accuracy.  (Executing N instructions in one CPU before switching context
to the rest of the sim can be significantly faster.)


> I think the second part of my problem where data doesn't seem to reliably
> make its way into the dual port ram is due to mapper cache. 

The mapper cache probably does not relate to this - you probably mean
something other than the little internal TLB in the memory-mapper
component that helps classify incoming read/write addresses.


> How can I cause a particular bus access to poke the yield net? [...]

For example, you could use the hw-glue-bus-probe component: wire up one
instance of it into the bus structure by mapping it at some address;
use its pin outputs to trigger any desired pin-based event in the simulator.


- FChE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA2FzrVZbdDOm/ZT0RAnRLAJ9cjn2GBw9y1m8SGB0kVIQo8w4y1ACggu5J
JmTt4APM2aCisi56P6rNQ1M=
=JzxJ
-----END PGP SIGNATURE-----