Forums

Help on different types of emulators

Started by DSP-novice January 22, 2004
Can someone send me a link or name of books where I can find some
useful understanding of the topic EMULATORS. I am kind of unsure if I
do understand how they work and I have seen people use the terms
pretty loosely.
 JTAG Emulators, PCI based Emulators, In-circuit Emulators, etc...
etc..

 What do they do in terms of writing a DSP code, with relation to the
target board. How does running the code on emulator memory help a
programmer?? What are key differences between a Debugger and a
Emulator.
 
 I would appreciate any help on this regard.
"DSP-novice" <apu_4_U@hotmail.com> wrote in message
news:47045fc8.0401220637.1a73b881@posting.google.com...
> Can someone send me a link or name of books where I can find some > useful understanding of the topic EMULATORS. I am kind of unsure if I > do understand how they work and I have seen people use the terms > pretty loosely. > JTAG Emulators, PCI based Emulators, In-circuit Emulators, etc... > etc..
I don't think you'll find this in any book...perhaps some well written app note or white paper (I've never seen one on this).
> What do they do in terms of writing a DSP code, with relation to the > target board. > How does running the code on emulator memory help a > programmer?? What are key differences between a Debugger and a > Emulator.
To understand this, you have to depart from the usage model of writing software for PCs. A target board typically has a DSP (or any microprocessor). It probably also has some non-volatile memory to store the code. Typically, on power-up, this code is loaded into the processor (booting) and then it starts running the program you've written. It's pretty slow and painful to repeatedly write code, compile, link and generate some kind of eeprom hex file. Burn it into the eeprom, stick it on the board and see if your program does what it is supposed to. You can't read variables, set breakpoints...nothing. So God invented emulators. These are typically a scheme for you to interface with the DSP and your PC so that you can interact with the DSP, load and debug your programs. A JTAG emulator (most of them are of this type these days) uses the JTAG capabilities of the DSP to get the current state of the DSP as well as control its execution with minimal impact on your program. (read up on the JTAG standard to learn more if you like). A JTAG emulator will involve some kind of 'pod' that plugs into your target board's JTAG connector and on the other end of the cable will end up in a board. Now this board can be a PCI, USB, ISA etc type. This largely determines how the PC talks to this emulator board. The Debugger is the software that interfaces to the emulator board and in turn to your target board from the PC. It also typically interfaces with your IDE if you have one. The debugger software allows you to connect to the target board, download programs that you have compiled and linked, set breakpoints, etc. Usually debuggers will also come with a 'simulator' - this allows you to run your programs, set breakpoints etc in a simulated environment on the PC without any emulator or target connections. Hope that clears things up a bit. Cheers Bhaskar
> > I would appreciate any help on this regard.
"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:bup3c9$k8m9o$1@ID-82263.news.uni-berlin.de...
> "DSP-novice" <apu_4_U@hotmail.com> wrote in message > news:47045fc8.0401220637.1a73b881@posting.google.com... > > Can someone send me a link or name of books where I can find some > > useful understanding of the topic EMULATORS. I am kind of unsure if I > > do understand how they work and I have seen people use the terms > > pretty loosely. > > JTAG Emulators, PCI based Emulators, In-circuit Emulators, etc... > > etc.. > > I don't think you'll find this in any book...perhaps some well written app > note or white paper (I've never seen one on this). > > > What do they do in terms of writing a DSP code, with relation to the > > target board. > > How does running the code on emulator memory help a > > programmer?? What are key differences between a Debugger and a > > Emulator. > > To understand this, you have to depart from the usage model of writing > software for PCs. > A target board typically has a DSP (or any microprocessor). It probably
also
> has some non-volatile memory to store the code. Typically, on power-up,
this
> code is loaded into the processor (booting) and then it starts running the > program you've written. > It's pretty slow and painful to repeatedly write code, compile, link and > generate some kind of eeprom hex file. Burn it into the eeprom, stick it
on
> the board and see if your program does what it is supposed to. You can't > read variables, set breakpoints...nothing. > > So God invented emulators. These are typically a scheme for you to
interface
> with the DSP and your PC so that you can interact with the DSP, load and > debug your programs. A JTAG emulator (most of them are of this type these > days) uses the JTAG capabilities of the DSP to get the current state of
the
> DSP as well as control its execution with minimal impact on your program. > (read up on the JTAG standard to learn more if you like). > A JTAG emulator will involve some kind of 'pod' that plugs into your
target
> board's JTAG connector and on the other end of the cable will end up in a > board. Now this board can be a PCI, USB, ISA etc type. This largely > determines how the PC talks to this emulator board. > > The Debugger is the software that interfaces to the emulator board and in > turn to your target board from the PC. It also typically interfaces with > your IDE if you have one. The debugger software allows you to connect to
the
> target board, download programs that you have compiled and linked, set > breakpoints, etc. > Usually debuggers will also come with a 'simulator' - this allows you to
run
> your programs, set breakpoints etc in a simulated environment on the PC > without any emulator or target connections.
Bhaskar, I bought an evaluation board recently but haven't worked with it yet. I figured it was time to add to the scope of things I really understood and writing code for embedded processors is something I've not done. But, the folks working for me at times were very good at it. And, I knew that we had a disconnect in terminology but didn't ever need to investigate it - so it remained a nagging curiosity. I always thought that "emulator" in the embedded world usage was a misnomer in the sense that an emulator in the olden days was more like the "simulator" you describe - it was software that would run on one machine to emulate the instructions of another. I once wrote the framework for an emulator of an IBM 360 that would run on a UNIVAC 1108. The framework figured out how to use the machine instructions of the UNIVAC in order to emulate the exact operations / results of the 360 - including storage of instructions and data of course. I've always wanted to understand the embedded tools better. So, what I got from the first part of your description was that an "emulator" in this context means a combination of hardware and software that emulates the eprom and its communication with the embedded processor. So one could emulate a boot and other eprom reads. Rather than emulating the processor itself, it's emulating some of the periphery. Is that reasonable so far? Then, you got off on debugger software and "emulator board" and lost me. Can you further illuminate please? Thanks, Fred
Fred Marshall wrote:
> I've always wanted to understand the embedded tools better. So, what I got > from the first part of your description was that an "emulator" in this > context means a combination of hardware and software that emulates the eprom > and its communication with the embedded processor. So one could emulate a > boot and other eprom reads. Rather than emulating the processor itself, > it's emulating some of the periphery. Is that reasonable so far?
No, although those types of emulators do exist - they're called ROM emulators, or "romulators." They only emulate ROMs - not CPUs.
> > Then, you got off on debugger software and "emulator board" and lost me. > Can you further illuminate please?
An emulator allows you to get inside the processor. You can examine/modify the internal registers and memory. You can single step through a program. You can set break points. In the ADI toolset (and probably others), the simulator and emulator GUIs are identical. They APPEAR to do exactly the same thing. But on the emulator, you're actually connected to the target hardware. The code runs _at_speed_. The emulator can read an A/D and toggle a flag. And when you do those things, it has a real effect. In a simulator, it has no effect or - if you're lucky - a simulated effect. You can use an emulator to test/debug your peripherals. In the olden days, an emulator was a chunk-o-hardware that would mimic the CPU, but with visibility. It plugged into the CPU's socket. Sometimes chip manufacturers would make versions of their chips with a different bond-out, so emulator makers could put them into emulators. These days, those capabilities are available via the JTAG port. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 I'm a man. But I can change. If I have to. I guess. - Red Green
"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:dbCdndMLctakg43dRVn-vw@centurytel.net...
> > "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message > news:bup3c9$k8m9o$1@ID-82263.news.uni-berlin.de... > > "DSP-novice" <apu_4_U@hotmail.com> wrote in message > > news:47045fc8.0401220637.1a73b881@posting.google.com... > > > Can someone send me a link or name of books where I can find some > > > useful understanding of the topic EMULATORS. I am kind of unsure if I > > > do understand how they work and I have seen people use the terms > > > pretty loosely. > > > JTAG Emulators, PCI based Emulators, In-circuit Emulators, etc... > > > etc.. > > > > I don't think you'll find this in any book...perhaps some well written
app
> > note or white paper (I've never seen one on this). > > > > > What do they do in terms of writing a DSP code, with relation to the > > > target board. > > > How does running the code on emulator memory help a > > > programmer?? What are key differences between a Debugger and a > > > Emulator. > > > > To understand this, you have to depart from the usage model of writing > > software for PCs. > > A target board typically has a DSP (or any microprocessor). It probably > also > > has some non-volatile memory to store the code. Typically, on power-up, > this > > code is loaded into the processor (booting) and then it starts running
the
> > program you've written. > > It's pretty slow and painful to repeatedly write code, compile, link and > > generate some kind of eeprom hex file. Burn it into the eeprom, stick it > on > > the board and see if your program does what it is supposed to. You can't > > read variables, set breakpoints...nothing. > > > > So God invented emulators. These are typically a scheme for you to > interface > > with the DSP and your PC so that you can interact with the DSP, load and > > debug your programs. A JTAG emulator (most of them are of this type
these
> > days) uses the JTAG capabilities of the DSP to get the current state of > the > > DSP as well as control its execution with minimal impact on your
program.
> > (read up on the JTAG standard to learn more if you like). > > A JTAG emulator will involve some kind of 'pod' that plugs into your > target > > board's JTAG connector and on the other end of the cable will end up in
a
> > board. Now this board can be a PCI, USB, ISA etc type. This largely > > determines how the PC talks to this emulator board. > > > > The Debugger is the software that interfaces to the emulator board and
in
> > turn to your target board from the PC. It also typically interfaces with > > your IDE if you have one. The debugger software allows you to connect to > the > > target board, download programs that you have compiled and linked, set > > breakpoints, etc. > > Usually debuggers will also come with a 'simulator' - this allows you to > run > > your programs, set breakpoints etc in a simulated environment on the PC > > without any emulator or target connections. > > Bhaskar, > > I bought an evaluation board recently but haven't worked with it yet. I > figured it was time to add to the scope of things I really understood and > writing code for embedded processors is something I've not done. But, the > folks working for me at times were very good at it. And, I knew that we
had
> a disconnect in terminology but didn't ever need to investigate it - so it > remained a nagging curiosity. > > I always thought that "emulator" in the embedded world usage was a
misnomer
> in the sense that an emulator in the olden days was more like the > "simulator" you describe - it was software that would run on one machine
to If one didn't know that a simulator existed, then yes, I'd be confused by the word 'emulator' in this context. Knowing that a simulator exists, doesn't make the situation totally comfortable for me, but it makes it more digestable I guess ('debugger hardware' is probably too long and I can't think of anything else that comes close).
> emulate the instructions of another. I once wrote the framework for an > emulator of an IBM 360 that would run on a UNIVAC 1108. The framework > figured out how to use the machine instructions of the UNIVAC in order to > emulate the exact operations / results of the 360 - including storage of > instructions and data of course. > > I've always wanted to understand the embedded tools better. So, what I
got
> from the first part of your description was that an "emulator" in this > context means a combination of hardware and software that emulates the
eprom
> and its communication with the embedded processor. So one could emulate a > boot and other eprom reads.
No - the emulator cannot really 'emulate' the eprom interaction at a hardware level. I have to qualify further comments by saying that it refers to JTAG emulators. There are JTAG 'commands' that allow the emulator to non-intrusively read/write data, send processor specific commands that halt or start the core, etc. So when the emulator is connected to the DSP it takes control of the DSP using the JTAG port. So when you have debugger software on the PC and it's 'connected' to the DSP using the emulator, the debugger essentially controls the DSP directly using this JTAG port. So a typical use scenario would be to open the debugger software, make sure it is using the emulator to connect to the target DSP. Then start debugging programs by first 'loading' your program. The debugger software then takes your program and then using the emulator software driver, talks to the emulator board which in turn sends JTAG commands to the DSP to allow a program to be loaded into it's internal memory (this process is different from what happens during booting since the bootloaded never comes into the picture). The debugger can also read all the DSP registers and memory, so now you can open windows that show the Disassembly, DSP registers, etc. When you 'run' the program from the debugger, JTAG commands are sent to make the DSP core start executing. JTAG also allows you to set breakpoints at a certain line of code...so when that line is reached the debugger receives JTAG signals to indicate program has stopped and it then queries for the current state of the DSP and displays it on your debugger. So essentially, the DSP's JTAG port is key to all of this. The emulator (board + driver) allows a higher level software (debugger) to take control of the DSP using JTAG. Hope that makes things a little more clear. I may have oversimplified some aspects, but hopefully didn't say anything grossly wrong. Mike Rosing, who posts on comp.dsp, works for a company (or does he own it?) that makes debuggers for the ADI Sharcs. They don't really talk about an emulator as a separate thing...it's part of their debugger tool. I'm sure Mike can add to what I've said (if necessary ;-)). Cheers Bhaskar
> Rather than emulating the processor itself, > it's emulating some of the periphery. Is that reasonable so far? > > Then, you got off on debugger software and "emulator board" and lost me. > Can you further illuminate please? > > Thanks, > > Fred > >
Bhaskar Thiagarajan wrote:

   ...

> Hope that makes things a little more clear. I may have oversimplified some > aspects, but hopefully didn't say anything grossly wrong. > Mike Rosing, who posts on comp.dsp, works for a company (or does he own it?) > that makes debuggers for the ADI Sharcs. They don't really talk about an > emulator as a separate thing...it's part of their debugger tool. I'm sure > Mike can add to what I've said (if necessary ;-)). > > Cheers > Bhaskar >
Confusion arises because "emulator" has two meanings: 1) A program that runs on one computer and emulates another. Basically, an interpreter that uses a particular computer's machine code as its instructions. (I have a Z-80 emulator that runs on my GHz pentium. No real Z-80 ever computed so fast!) 2) A hardware device that emulates a processor chip at its pins, a so-called in-circuit emulator, or ICE. On old processors, a cable plugs into the processor socket. Nowadays, the JTAG interface allows the actual processor to run. (And, with BGAs and such, a good thing, too!) Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
"Jerry Avins" <jya@ieee.org> wrote in message
news:40102fa7$0$3058$61fed72c@news.rcn.com...
> Confusion arises because "emulator" has two meanings: > [...]
But those are the same meaning, precisely. Both your ICE and your software emulator are emulating a CPU. The guy who first said "JTAG emulator" obviously had the wrong-headed idea that "emulator" meant "debugging tool" in general. It's really too bad that the terminology stuck. JTAG would be so much easier to learn if it had been called a "boundary scanner", "JTAG scanner", or "test point scanner" instead.
Matt Timmermans wrote:

> "Jerry Avins" <jya@ieee.org> wrote in message > news:40102fa7$0$3058$61fed72c@news.rcn.com... > >>Confusion arises because "emulator" has two meanings: >>[...] > > > But those are the same meaning, precisely. Both your ICE and your software > emulator are emulating a CPU. The guy who first said "JTAG emulator" > obviously had the wrong-headed idea that "emulator" meant "debugging tool" > in general. > > It's really too bad that the terminology stuck. JTAG would be so much > easier to learn if it had been called a "boundary scanner", "JTAG scanner", > or "test point scanner" instead.
The same meaning, but not the same thing. There's a difference between a program running on one computer imitating another on the one hand, and a program, a physical connection to external hardware with a link to another computer on the other. When that distinction isn't clear -- to the uninitiated, it won't be without more description than "emulator" -- confusion (literally, the joining of different notions) is inevitable. Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
"Matt Timmermans" <mt0000@sympatico.nospam-remove.ca> wrote in message
news:Yv_Pb.6497$rW5.547351@news20.bellglobal.com...
> "Jerry Avins" <jya@ieee.org> wrote in message > news:40102fa7$0$3058$61fed72c@news.rcn.com... > > Confusion arises because "emulator" has two meanings: > > [...] > > But those are the same meaning, precisely. Both your ICE and your
software
> emulator are emulating a CPU. The guy who first said "JTAG emulator" > obviously had the wrong-headed idea that "emulator" meant "debugging tool" > in general. > > It's really too bad that the terminology stuck. JTAG would be so much > easier to learn if it had been called a "boundary scanner", "JTAG
scanner",
> or "test point scanner" instead.
Well, I've designed chips with boundary scan - and to great advantage I might add - but I'm not sure how much of a connection there is here. That's because JTAG can also mean an interface that's the same as that used for boundary scan but isn't being used for a boundary scan implementation. Isn't that true? I think that's in fact the case here. Oh, I can imagine things but more in the details of implementation. What I was interested in understanding better is what kind of stuff we're talking about and using. I think I get it now. Let me try to parrot back: "An emulator in today's terms most likely means a JTAG emulator which is: - a physical JTAG interface on a board or on a processor chip that allows getting at registers, memory, interrupts, etc. on the real processor - an external software interface that allows one to monitor and control what the processor is doing It can be used as a monitor and it can be used as a debugger." Am I getting close? Fred
Fred Marshall wrote:
> I think I get it now. Let me try to parrot back: > > "An emulator in today's terms most likely means a JTAG emulator which is: > - a physical JTAG interface on a board or on a processor chip that allows > getting at registers, memory, interrupts, etc. on the real processor > - an external software interface that allows one to monitor and control what > the processor is doing > It can be used as a monitor and it can be used as a debugger." > > Am I getting close?
Yup. I'd say you nailed it. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 The problem with the future is that it keeps turning into the present - Hobbes