On Thu, Mar 29, 2012 at 5:21 AM, Ouabache Designworks <[email protected]> wrote: > Ruben, > > The or1200_monitor.v really doesn't "handle" anything. It can detect when > the cpu enters certain states and can pass that info back to the simulation > but it doesn't affect the hardware. > > Passing information back to the sim is a lot trickier. You might be hitting > a issue where your write is not aligned with a clock edge and it is > overwritten at the next edge. Or you could > be trying to write the registers during the same time that the software is > trying to update them. > > It is very tempting and easy to access other parts of the simulation via > software links it is also somewhat limiting. Yes your sim will work fine but > when you get silicon back there is no > way that you can run that sim on real silicon and get the same response. You > are better off taking the time to add a gpio device and pass all your info > through that. Yes it does take more > time up front but you will be able to run that same test on real silicon and > it will behave exactly as it did in the simulation.
Hi John You're right on the issues here. This is something I've never done with or1200_monitor.v (get values back into the sim) and there are certain hazards, such as dealing with an event-driven simulation and knowing exactly when to inject the value to the hardware model so it won't get overwritten. I also agree with the idea of having some mechanism to debug the CPU hardware in silicon (FPGA or ASIC) to allow comparison of execution traces and the like. I think the OR1K spec provides some mechanisms (eg. cycle counter in the performance counters unit), we just don't implement or use them. The "l.nop" trick for simulation is nice but isn't immediately implementable in silicon, so I'm all in favour of discussion of some system which would allow us to achieve a similar function in a synthesised design. It would be very handy to help verify functionality in silicon, or even gatelevel simulation. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
