Perhaps with new understandings of quantum mechanics we'll one day exploit the "spooky action at a distance" (Einstein's words) beyond-lightspeed collapse of the quantum wave function to transmit data between the target and ICE infinitely fast.
#100 mhz clock mini zed Pc
Every connector, connection, and PC board track each impose rather significant additional delays as the signal propagates from your target up to the guts of the ICE.Įlectrons move at around 2 nsec per foot in wire. Once the clock rate starts to climb to the crazy levels we're seeing on the horizon the physical size of the system - a pod, a connection via (perhaps) an adapter to your target - becomes large compared to the speed of light. As you're not likely to design an emulator into your product, we emulator vendors design them as instruments you plug into the CPU socket.Īt low speeds there's no problem. An ICE uses quite a bit of electronics that have to be mounted somewhere, somehow. The second characteristic is simply the sad fact that features (breakpoints, trace, and the like) have a cost. Maybe it's getting ready to read one byte from your target. Perhaps the emulator's hardware/firmware is extracting the contents of the registers so you can see these in a window on your terminal.
#100 mhz clock mini zed code
Turn it off, and the CPU can run ICE-specific code that your target never sees.
The emulator does this to access a target resource. Turn it on, and every bus cycle generated by the CPU on the ICE's pod is mirrored to your own electronics. The first is bus isolation: the microprocessor in the ICE is physically separated from your target system by a data bus buffer. This dual identity - intrusive and non-intrusive behavior - comes from two characteristics of the emulator. Perhaps breakpoints are pending or trace is armed these debug features either have no impact on the code, or at least none till they take effect. It's as if the emulator is the world's most expensive microprocessor, running your code exactly as it should. Conversely, a decent ICE runs your code non-intrusively. In other words, you can stop the code and examine the state of every part of the system. The ICE is intrusive, in that it can toggle bits and exercise your memory and I/O independent of the execution of your code. Electronics - a lot of electronics - uses either the same sort of CPU, or a special "bond-out" version, to control your system.Īt reasonable speeds this is probably the best way to get visibility into your code and hardware. Some sort of hardware replaces the CPU in the product you're working on. In real life I run a business that makes emulators, and am left feeling a bit like those poor armourers of old.Īt some point - 100, 200, or surely by 300 Mhz - the tools we have relied on for all these years just won't keep up.Ĭonsider my old favorite, the in-circuit emulator (ICE).
The chip vendors announce in glittering prose their latest masterpiece of silicon speediness, mostly without a comment about how the poor designer should develop code for it. When a group builds a gigantic canon to shoot a man to the moon the armourers all but revolt, complaining that nothing could keep up with this latest technological advance.Įvery time I pick up an electronics magazine I'm reminded of this story. Armorers always operate in a catch-up mode, trying desperately to build something resistant to the newest speedy shell. In "From the Earth to the Moon" Jules Verne painted a wonderful image of the battle between canon manufacturers and armor makers.
#100 mhz clock mini zed free
Here areįor novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. As CPU speeds climb towards infinity, our debugging strategies must change.
0 kommentar(er)
