what does the atmega uc do during every clock cycle?

I'd like to understand what really happens inside the core when it runs some code. I've found something but not much about that. I wonder if someone here can point me in the right direction.

I'd like to better understand what happens at every clock cycle, how does the program memory work, how is data treated, data flow basics, how the ALU uses data from memory and/or from code... I am pretty shure all of this has already been summarized in the past since the atmega ucontrollers have been used as an educational tool for so long.

But I really can't find much :-( well, maybe "too much" to be exact, Atmel's datasheets are more than complete, but they really treat specifications in a not-"educational way". It's more like a compilation of data and facts than a learning tool.

Maybe there's something aimed more at teaching than simply at enumerating how this stuff work. Any hint?

I don't think there's much that's specific to AVR chips on your list.

Try widening your google searches to more general CPUs, look for graphical cpu simulators, etc.

fungus: I don't think there's much that's specific to AVR chips on your list. Try widening your google searches to more general CPUs, look for graphical cpu simulators, etc.

Evidently I was not clear enough. I'm sorry.

I don't want to broaden my search at all. I don't want to find more generic dissertations about microcontroller architectures, there's way too much out there. I'd like to understand more specifically how the AVR micro-controllers (mainly the atmega family) work instead. And I'm mainly interested (at the moment) on how the CPU works during each clock cycle, how it retrieves instructions from program memory, how it reads/writes data memory, how/when program-counter/ALU/IO-Ports are handled.

I'm going to read some more generic textx about harvard architecture machines too of course, but I'd really like to get to the AVR specifics and get a grip on what's truely going on.

I know Atmel's datasheets are precious in this regard, and I keep reading them through. It's just that they're not meant to be used as a teaching tool, so they lack that teaching approach I'm looking for.

robitabu:

fungus:
I don’t think there’s much that’s specific to AVR chips on your list.
Try widening your google searches to more general CPUs, look for graphical cpu simulators, etc.

Evidently I was not clear enough. I’m sorry.

I don’t want to broaden my search at all. I don’t want to find more generic dissertations about microcontroller architectures, there’s way too much out there. I’d like to understand more specifically how the AVR micro-controllers (mainly the atmega family) work instead.

Yeah, general knowledge sucks!

What you’re after probably falls under “industrial secrets”, ie. it’s not going to be on a web site somewhere.

fungus: Yeah, general knowledge sucks!

Mmhh.... well, that was not what I meant. Whatever.

robitabu:

fungus:
Yeah, general knowledge sucks!

Mmhh… well, that was not what I meant. Whatever.

Well…a lot of what you’ll be doing will be inferring. For that you need general knowledge about CPUs.

@robitabu:

Not an unreasonable question and an admirable quest ... essentially it boils down to a chip architectural question. In Atmel Studio 6, you could use the simulator to ferret out many of the specific, especially ports. Some assembly language guides/books for the AVR line may also reveal specifics. But, since the AVR is RISC, the job of understanding is basically tied to the instruction set.

ATmel publishes http://www.atmel.com/Images/doc0856.pdf which provides the 8-bit instruction set listing. This is a register-level document and you will need to reference the block diagram of the 328 here: http://www.mouser.com/new/atmel/atmelatmega328/

What would be nice is a 328 version of the 6502 visual simulator: http://www.visual6502.org/JSSim/

Ray

I think section 7 of the datasheet describes pretty well what happens. You really need a computer architecture book to delve into it deeper.

CrossRoads: I think section 7 of the datasheet describes pretty well what happens.

That's it, that's the point! Section 7 is the topic, the way it's exposed in the datasheet is the limit (to me, at least) I want to overcome.

E.g. A statement like "In a typical ALU operation, two operands are output from the Register File, the operation is executed, and the result is stored back in the Register File – in one clock cycle." does not make clear if each and every clock cycle simply does that and that only. It's misleading to someone who doesn't know how it really works in the first place. It's a correct statement, of course, but not much educational :-( Every chapter that follows up is filled with precious and complete informations about every detail of the chip, but the way it's exposed makes the task of learning how it really works a bit daunting.

And yes, of course, I'm learning AVR assembly on the way, that's what I'm doing in my spare time. I'd really like to get more confortable with programming assembly. That's why I'd like to clear my mind about the inner workings of the cpu core.

mrburnette: ...essentially it boils down to a chip architectural question.

Right, and I'd like to be specific on the atmega family.

Some assembly language guides/books for the AVR line may also reveal specifics.

Do you reckon "Atmel AVR Microcontroller Primer: Programming and Interfacing" of Barrett and Pack, "AVR, an introductory course" of J.Morton or "AVR Mikrocontroller Praxis" of Volpe and P.Volpe are good readings in this regard?

And yes, of course, I'm learning AVR assembly on the way, that's what I'm doing in my spare time. I'd really like to get more confortable with programming assembly. That's why I'd like to clear my mind about the inner workings of the cpu core.

And that is a very good way to understand how the cpu core hardware actually works. While C/C++ is a pretty low level high level language, it still insulates one somewhat from understanding how the ALU, status bits, register control, etc actually work together.

I was able to learn computers in the 70s from being a hardware field service engineer on minicomputer systems where we were trained to repair CPUs at the chip replacement level when the chips were small and medium scale TTL chips. I wasn't much interested in learning software at the time (just wrote a few machine language programs) but that background did help me a lot when I finally did get interested in learning some programming decades later.

Lefty

As a start point, you might be interested in the Security Now podcast's series on "how computers work."

Steve Gibson starts at the beginning with transistors, moves up to gates, and then into the logical blocks of a CPU. It gives an excellent foundation for reading a higher-level document like a datasheet, which isn't meant to be an educational tool.

It starts with this episode and I think goes on for a couple: http://twit.tv/sn233

If Audio isn't your thing, Steve has every episode transcribed (by a person).

@robitabu

Do you reckon "Atmel AVR Microcontroller Primer: Programming and Interfacing" of Barrett and Pack, "AVR, an introductory course" of J.Morton or "AVR Mikrocontroller Praxis" of Volpe and P.Volpe are good readings in this regard?

I simply do not know. I grew up in the 6800 and 6502 days and did a considerable amount of assembler before doing Intel 8080. Terminology just is absorbed from data sheet to data sheet. Which is to say, "In a typical ALU operation, two operands are output from the Register File, the operation is executed, and the result is stored back in the Register File – in one clock cycle." makes perfect sense to me.

My recommendation is to download ATmel Studio and make use of freely available Internet resources. In this regard, Google is your friend. Ex: www.avr-asm-download.de/beginner_en.pdf

You may also wish to join AVRfreaks http://www.avrfreaks.net

Just give yourself some time to absorb the terminology... Many of us ol' timers have been at thus stuff for a long, long time and still are learning. Ray

I think this is a deep topic that requires a lot of background knowledge to really grasp. You have electronics (do you understand how a transistor works, for example?), you have general ALU architecture theory (if you read texts on the Harvard architecture, you will know a good deal about how the AVR specifically works), understanding assembly language is crucial, as the raw instructions determine the status of the ALU in any given clock cycle... So yeah, many disciplines all interacting in a complex way. Don't expect to be able to read a page of high-level overview and have it "click" -- this kind of thing takes time. Just be patient and absorb what you can. You'll get it.

robitabu:
E.g. A statement like “In a typical ALU operation, two operands are output from the Register File, the operation is executed, and the result is stored back in the Register File – in one clock cycle.” does not make clear if each and every clock cycle simply does that and that only. It’s misleading to someone who doesn’t know how it really works in the first place. It’s a correct statement, of course, but not much educational :frowning:

Yes, and the education needed would be one in computer hardware engineering, which is not found in a few books or in any number of datasheets. You’re asking the wrong question, education proceeds from the general to the specific and you want to start with the specifics for a particular processor. Those likely are just not available anyway, I’d bet that those details are Atmel proprietary.

There really is little reason to understand that level of specifics for Atmel MCUs unless you are a hardware engineer for Atmel. On the other hand, once educated in the general concepts and principles of the field, the question about the ATmega will evaporate because with the proper education you will realize that those specific details really don’t much matter and you will know enough to be comfortable with what’s going on inside the ATmega or any other processor.

You probably wanted to hear none of that. Your quest for knowledge is admirable but you need to reframe your thinking. I really hope this helps.

PS: The short (and flip) answer to the question is fetch & execute, fetch & execute, fetch … :smiley:

I'd like to be specific on the atmega family.

As someone said, you can't, because the details are secret. For your first effort, it would be extremely helpful if you were looking at an architecture that was fully documented. It would also be helpful if you were looking at an older style of processor where the architecture was laid out to be easily understood by humans, instead of just easily implementable in silicon. You know - fixed position/size fields for opcode, source, and destination; less aliasing of "special" addresses, etc. Atmel, IMO, does a particularly poor job of describing the functional architecture of their architecture (compared to some other vendors who do a better job with that, but a worse job describing how it should be used.) (For example, the fact that peripherals and RAM are in the same address space is understated.)

So for each clock cycle, you have an instruction in the instruction decode buffer, and one in the instruction prefetch register (or it will be there "soon.") Some of the bits specify the source, which can be one of the registers, or a RAM location. RAM locations can the instruction decode buffer itself ("immediate" addressing) (or maybe that's more like a register address?), or RAM pointed to by the instruction decode register (IO instructions), or RAM pointed to by the prefetch register ("direct addressing"), or RAM pointed to by the various index registers in the CPU. Some of the bits specify the destination, which is similar but has somewhat fewer possibilities. The destination is also the source of the 2nd operand, for two-operand instructions. The destination can also be the PC (jmp), or it can get discarded (Compare instruction.) More of the bits tell the ALU what it's supposed to do with the two 8-bit quantities. See a SN74181 datasheet for an approximation of what's available. Probably on the next clock edge, the output of the ALU would get written to the destination. (rising edge: fetch operands. High: wait for results to stabalize. Falling edge: write results. Or something like that.) Also store the flag bits from the ALU in the status register.

Obviously, 16-bit operations, stack operations, multiply, and other instructions would be handled a bit differently. Immediate addressing only gets to access half the registers as the destination. And a bunch of other complications.

This is all much easier to grasp on something like a PDP11, where the PC and SP are just ordinary registers, and there haven't been any "optimizations" done to squeeze 32 registers into 4bits of identifier in the instruction. (or make everything happen in "one clock cycle"; it's really useful to think of multiple phases of each instruction taking "as long as needed", and letting the HW designer figure out how to make that happen in half a clock cycle. You can probably find a good description somewhere of what an 8051 does with each of the 12 clocks that make up ONE instruction "cycle" in THAT architecture. Or the 4 clocks of an 8080. etc.)

westfw: This is all much easier to grasp on something like a PDP11, where the PC and SP are just ordinary registers, and there haven't been any "optimizations" done to squeeze 32 registers into 4bits of identifier in the instruction. (or make everything happen in "one clock cycle"; it's really useful to think of multiple phases of each instruction taking "as long as needed", and letting the HW designer figure out how to make that happen in half a clock cycle. You can probably find a good description somewhere of what an 8051 does with each of the 12 clocks that make up ONE instruction "cycle" in THAT architecture. Or the 4 clocks of an 8080. etc.)

I'll look into that, it may prove usefull.

Btw, if someone is familiar with Bell Labs' Cardiac ( http://www.scientificsonline.com/cardiac-illustrated-computation-aid.html ) it will be clear what I have in mind when talking about "educational approach".

The PDP11 goes back a few years ... I think I read somewhere that the prototype was built with wirewrap!

That got me wondering about what really lies behind the OPs original question. It would be possible to build a "microprocessor" on a large breadboard using discrete chips - that's how it used to be done.

At a very basic level all computers work by responding to patterns of bits. If the pattern is xxxx they do one thing (perhaps move a byte from RAM to somewhere else) and if the pattern is yyyy they do something else (perhaps add one byte to another byte).

You can simulate pieces of this using individual logic chips - for example a couple of 8-bit latches could store two bytes and some AND, OR, XOR, NOT gates (I haven't thought out the details) could be configured to add the two values.

I suspect if the OP studies some very simple Assembler programming what is going on will be much clearer as the Assembler instructions represent 1 for 1 the actions within the microprocessor.

And, as someone else said, the general principles are the same across a range of different microprocessors. If you understand how a PIC works you will know most of how an Atmel processor works. And, more importantly, if you know how any one of them works you will be better placed to appreciate the differences.

...R

Robin2:
The PDP11 goes back a few years …
I think I read somewhere that the prototype was built with wirewrap!

I wouldn’t be surprised. The first mainframe I worked with was build with wirewrap and it wasn’t a prototype! Well, no more so than anything else back then :smiley:

One way to really get in touch with things on the level that I think the OP wants would be to design and build your own CPU from small-scale TTL chips. One example at http://www.homebrewcpu.com/

Robin2: The PDP11 goes back a few years ... I think I read somewhere that the prototype was built with wirewrap!

That got me wondering about what really lies behind the OPs original question. It would be possible to build a "microprocessor" on a large breadboard using discrete chips - that's how it used to be done.

At a very basic level all computers work by responding to patterns of bits. If the pattern is xxxx they do one thing (perhaps move a byte from RAM to somewhere else) and if the pattern is yyyy they do something else (perhaps add one byte to another byte).

You can simulate pieces of this using individual logic chips - for example a couple of 8-bit latches could store two bytes and some AND, OR, XOR, NOT gates (I haven't thought out the details) could be configured to add the two values.

I suspect if the OP studies some very simple Assembler programming what is going on will be much clearer as the Assembler instructions represent 1 for 1 the actions within the microprocessor.

And, as someone else said, the general principles are the same across a range of different microprocessors. If you understand how a PIC works you will know most of how an Atmel processor works. And, more importantly, if you know how any one of them works you will be better placed to appreciate the differences.

...R

Basically true but there are still pretty significant differences between some CPU/Microcontrollers implementation, such as:

Harvard Vs Von Newman design, memory usage is fundamentally different.

RISC (single clock cycle per instructions) Vs CISC (multiple clock cycles per instruction) which takes a pretty drastic different tradeoff in hardware performance Vs instruction complexity.

Lefty