Subject:
Re: RFC: Trace logging in gpsim
From:
Scott Dattalo ####@####.####
Date:
7 Sep 2000 02:26:00 -0000
Message-Id: <Pine.LNX.4.21.0009062051320.8949-100000@tempest2.blackhat.net>
On Wed, 6 Sep 2000, Daniel Christian wrote:
> I think this is a great idea in one form or another.
>
> Personally, I want some kind of scope/logic analyzer functionality. I
> want this to work either in real time or from a saved file. Being able
> to verify serial IO, or I2C, or interrupt response time would be great.
> Dumping things in hex format would be easy to work with without wasting
> too much time on formatting.
>
> The other trace feature that I want is to be able to back step through
> the instruction sequence. I want to be able to set a breakpoint at an
> "abandonAllHope" point, and then back trace to figure out how it got
> there (and why).
One of the early features I had in gpsim was a `step backwards' operation. It's
purpose was for what you just describe. I also envisioned it being used to test
`what-if' scenarios. For example, some times it's difficult to get the program
into a certain state (by manually manipulating registers etc.). So I thought
it'd be useful to set break points at these hard-to-reach states, step
backwards, manipulate something, and then step forwards. Implementing the step
backwards function is fairly easy if all you're simulating is the pic
instruction set. However, when you begin throwing in stimuli, tmr0 and the other
peripherals, it becomes much more difficult. So I abandoned that.
Now, it could be useful to `play back' a log file. In other words, I could see
the gui being fooled into believing that it was simulating a pic when in fact
the trace log is being fed to it instead. This way you could move the cycle
counter to any value and have an instant image of the simulation state. Single
stepping would consist of fetching a cycle's worth of simulation data.
>
> I don't care so much about logging everything as being able to dump the
> log to a file. Of course, this works fine as long as the fixed trace
> buffer is "big enough".
Early on I did some profiling comparing different tracing techniques. I found
that it was faster to trace everything than to make an effort to trace only
certain things. The reason is that the decision takes extra code. The tracing
operation itself turns out to be very fast. It typically goes like this:
inline void register_write (unsigned int address, unsigned int value)
{
trace_buffer[trace_index] = REGISTER_WRITE | (address << 8) | value;
trace_index = (trace_index + 1) & TRACE_BUFFER_MASK;
}
The `inline' option means that the trace `calls' are not really calls. The code
is placed directly inline. In this case the accompanying x86 assembly code is:
/home/scott/gnupic/gpsim/src/trace.h:87
1da: 8b 93 00 00 00 00 movl 0x0(%ebx),%edx
/home/scott/gnupic/gpsim/src/trace.h:88
1e0: 8b 8a 00 40 00 00 movl 0x4000(%edx),%ecx
1e6: 8d 34 8d 00 00 00 00 leal 0x0(,%ecx,4),%esi
1ed: 8b 4f 08 movl 0x8(%edi),%ecx
1f0: c1 e1 08 shll $0x8,%ecx
1f3: 8b 47 04 movl 0x4(%edi),%eax
1f6: 0d 00 00 00 03 orl $0x3000000,%eax
1fb: 09 c8 orl %ecx,%eax
1fd: 89 04 16 movl %eax,(%esi,%edx,1)
/home/scott/gnupic/gpsim/src/trace.h:89
200: 8b 82 00 40 00 00 movl 0x4000(%edx),%eax
206: 40 incl %eax
207: 25 ff 0f 00 00 andl $0xfff,%eax
20c: 89 82 00 40 00 00 movl %eax,0x4000(%edx)
> I modified the trace output to put out one line for every cycle. This
> is far from perfect, but I find it much more readable than the current
> style. I can easily see all the things that happened during that
> cycle. It can get really wide. I better form would break the line and
> indent properly. Let me know if you want the patch.
Sure!
> Would there be a way to extend the trace mechanism? As you add modules,
> you may want a way to catch new internal state.
I've thought about it, but haven't done too much. The LCD module does do some
tracing but it is not too complete.
> One other question. Can gpsim actually handle a multi-processor
> system? The JRKerr servo controllers use two PICs (one for control and
> one just to count the encoders). There are situation where this is just
> what you want to do to get guaranteed response times. Debugging the
> interaction could be tricky unless you could simulate both at the same
> time.
Again, the mulit-processor feature was designed into gpsim at the outset. I've
never made use of it. However, I've been very diligent in not making assumptions
about which pic is being simulated. For example, each register for the pic is a
c++ object. One of the members of this object is a pointer to the cpu to which
the register belongs. As you might imagine, the pointer to the cpu is copied
many times over. But so what. My Linux box has much more memory than a pic!
The problem that needs to be addressed before multiple pics can be simulated is
the way gpsim handles time. I've got a solution, but there hasn't been a need to
invoke it. But the problem basically is that the cycle counter serves as the
time keeper for gpsim. This forces everything in the simulation to conform to
the pic's cycle counter. If you have more than one pic then things start to get
confusing. In fact, I argue that timing any event aynchronous to the pic is
confusing.
The way to get around is to provide another timer based on 'simulated real
time'. I'm envisioning a 64-bit counter with resolution down to 10's of
pico-seconds. 1pS resolution with a 64-bit counter still gives 512 hours of
simulation time. The cycle counter will then be based on this new timer. If two
pics are being simulated, then the one whose cycle counter is scheduled to
increment next will gain control.
Scott
