Working of IN CIRCUIT EMULATORS(ICE)-help me understand it plz...

Dear all, My understanding of ICE are that they are typically CPU emulators,I mean that when you want to hook or spy into the CPU bus cycles and inspect whats happening in the bus level,ICEs are used.AFAIK,ICEs are hardwares which contain a processor for the real target board you are going to emulate with.Basically it contains a pod and a bus which will help me to connect my ICE to real target.So as far as the connection is concerned,I will replace the cpu of the target board with ICE's CPU.So ICE has a inbuilt software which will show me up whats going on in bus level. So My understanding is target hardware's CPU is getting replaced with ICE's CPU. First of all I would like to know whether my understanding is correct regarding ICE and its connections?

Some of my colleagues are saying that,ICE's dont typically completely replace the target processor,as I have understood ,rather it will be working in Master/Slave mode where ICE's processor will be master and my target processor will be slave,and in effect the master ICE will control whats going on in the slave.

Are my colleagues correct or me?

I would like to learn more about ICE's.Any help will be great doing. Can anyone explain me this or else point me to a good links which will help me to understand working of ICE's in embedded projects...

Looking farward for all your replys and advanced thanks for the same, regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

The ICE's that I have used (68HC11 & H8/530) have (IIRC) had CPU emulators on the board. This is typically going to be required so that you can inspect register values and also inspect/change memory locations without upsetting the state of the 'processor' whilst it is between instructions. You also need to be able to halt internal timers etc whilst debugging.

Also, some processors don't like being halted (having their clocks stopped).

Having said that, I can imagine some processor architectures would lend themselves to being used in an ICE without requiring a CPU emulator. Motorola Coldfire, for example, supports 'hardware' debugging in-circuit via its BDM interface. I'm sure others offer similar capabilities that would lend themselves to some sort of ICE arrangment.

So, you're probably both right!

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|     |   with less resistance!"
Reply to
Mark McDougall

Typically a classic ICE has its own CPU onboard, and that replaces the emulated CPU. Most of the lines from the emulation CPU are fed directly into the board under test, with a few signal lines such as read and write processed so that the ICE CPU can perform reads and writes to local memories on the ICE itself. This is used both to simulate target memory, allow the CPU to do things like load a program into target memory, read internal registers, etc.

A lot of ICEs require that the CPU on the target be vacant, and probally replaced with a special pin socket or similar. The ICEs that allow the CPU to remain in system are activating a signal pin on the board's CPU that tells it to disable itself.

Other solutions, like JTAG, that call themselves ICEs, are not really ICEs, they are just using the name.

ICEs in general fell out of favor, because their increased pin capacitence and timing problems cause the emulated system to be less stable. JTAG style solutions work much better.

Reply to
Scott Moore

It depends. What CPU? first ICE do not let you inspect the bus. That would be a logic analyzer. It allows you to pause the CPU and look at registers and memory. Some replace the CPU with a bondout. Others disable the CPU on board and use the PODs CPU. Other connect to the CPU via a special serial port on the chip. (usually JTAG) Never bit bang without one.

Reply to
Neil Kurzman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.