>> Hi everyone,
>>
>> I have been experimenting with writing a PIC emulator, and was hoping for
>> some advice. I started doing this as a way of demonstrating the power of
>> dynamic compilation. The result is a (currently partially-complete) PIC
>> emulator which I have tested at sustained speeds of around 80 MIPS on my
>> 300MHz computer (and I mean with genuine code downloaded from the
> internet,
>> not code contrived to be gentle to the emulator).
>>
> I assume by this that what you actually mean is that each PIC instruction is
> converted to a sequence of host instructions. That you build a native host
> executable that does not execute a given function per instruction, no call
> or returns.
Yes, the idea is to eliminate as much as possible of the "simulation
framework" code, just leaving the actual translated PIC instructions, the
code for maintaining the correct state of the peripheral and the logging,
breakpoint etc code.

No, I do not build a native host executable, though. I construct the native
code in a buffer in memory and then call the function that I have assembled.
It of course takes time to compile, but can be recompiled quickly enough
(since I don't perform any particularly complex optimizations) that you can
stop the program, alter something (like a breakpoint) and then run it again
with the recompiled code without a noticable delay.

> The thing is, most simulators do hardware specific simulation at every CPU
> cycle. They interleave instruction and hardware simulation. You also need to
> trace instructions as they are processed. You need to provide the user with
> a mechanism where they can run to a break point then check to see what
> events occured that lead to that point. A trace buffer of some kind is
> invaluable. With this you would need to show what changes occured,
> instruction by instruction, so that the user can work his/her way back.
> Again this does not go well with non-stop no-boundry execution.
Yes, I interleave code that does this between the instructions... but most
of it doesn't have to be between *every* instruction. For example there is
no need to record every instruction in the trace buffer - just which
branches were taken (though details of register contents may be required as
well). To give another example, it is often possible to identify places
where an instruction affects the status register, but that result is
definitely not acted upon before it's overwritten by another result. In that
case, I often don't need to bother updating it at all (as long as no
breakpoint comes up the user will never see the temporarily-incorrect status
register value).

>> Incidentally, one particular feature which someone suggested to me was
> that
>> a fast software emulator could easily be linked up to a circuit board as a
>> way of providing in-circuit emulation with all the advantages of running
> it
>> from a PC and without the expense of dedicated ICE hardware. I am very
>> interested by this possibility (has it been done before?) although I
>> recognise that it would be limited by latencies in the data transfer
> between
>> computer and circuit, preventing it from being useful in some applications
>> where precise I/O timing was critical.
>
> not just that, but your simulated processor cycles will have different times
> depending on which instruction is being simulated. If you are going to
> simulate a processor you need to be able to accurately predict timing. It
> cannot run at 100 MIPS in loop A and 90 MIPS in loop B. That would really
> cause you problems.
Yep - but you only need to synchronise on some instructions. As long as you
know you have simulated 1001 instructions since the last time port IO
occurred (or whatever) you know you have to wait until 1001/(clock speed)
secs have elapsed before doing the read (and you might even be able to do
something like dump the trace buffer to disk while you wait...).

> I don't want to put you off. I just think that these are things you should
> consider carefully. Look at specific PIC and consider how you would simulate
> ALL the hardware (e.g. A/D, UART, I2C, EEPROM read/write, PORT B interrupts,
> watchdog). As personal projects go I certainly think it is worth while.

Thanks very much for some very useful suggestions.

Jonny

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body