I am wondering how this is done because according to me the instructions in general is executed in certain sequence cycles
1-fetch
2-decode
3-execute
Could any one explain to me how the fetch-decode-execute cycles is done for AVR generally.
I mentioning below the part from datasheet .....
Been discussed extensively before. The fetch happens in parallel and it is suspected an internal clock is generated for the read alu write cycle as there is a specification that suggests you don’t vary the clock too fast.
There is, as far as I understand, a very short instruction pipeline. For most basic instructions, it does decode and execute in one instruction. It does, I think, a fetch during the time another instruction is executing.
Jim
Could you tell me the title of the this discussion and under what category it is named ?
That is very identical to what i have thought thanks for this ,but could you explain how it decodes and executes at the same time
Seems it may be one of your previous threads!
I doubt that decode and execute are done in parallel, but rather as a series of micro-ops with an internally generated clock. There’s no magic here.
Why don't you look at a AVR datasheet !
There is a drawing.
I need more explanation, i have a doubt and i am not certain about the idea that i extracted from datasheet ,so i am asking again.
What is it in these drawings you have problems with ?
Notice that there is NO decode step. That is, there is no unique sequential event that can be identified as "decode". This suggests that decoding is handled more in hardware that is/was common for complex instructions sets.
Jim
The link below very likely has more info on the implementation of a (possible) AVR core than you like or care to know.
Description
Microcontroller core compatible with one used in AT mega 103 and written in VHDL. It has the same instruction timing and the same instruction set (with a few exceptions).
Status
The core was tested with several ASM and C programs.
It was implemented in Altera EPF10K50ETC144-3 device and
tested with AVR port of uC/OS-II The Real-Time Kernel, written by Ole Saether.(I used special version of the design with external SRAM for both program and data memories).
Update 22.12.12. Verilog version of the project is uploaded.
Reference:
That is okay and i understood but i didn't think that if we treat with SRAM instruction it will be happened like above image
Now i understand thank you for your explanation but how it will deal with SRAM Will it fetch and decode at the same time ?
Instructions aren't fetched from ram - the AVR is harvard architecture. The general idea of RISC is that the instructions are simple to decode. I'd suggest decode happens as part of the execute cycle.
Atmel / Microchip has never released much info about the internal workings of AVR's.
The PIC16F84 I meddled with a long time ago for a few days mentioned in the datasheet that it has a 4 stage pipeline and a short description of how it works.
I suspect AVR's have something similar and I have 2 hints that support that.
- Most AVR instructions take 1 CPU cycle, but whenever there is a jump it needs an extra cycle.
- When calibrating the RC oscillator the datasheets states you may only do it in small steps. If you adjust the callibration in too big steps the internal state of the AVR (presumably a PLL) may get disrupted.
(data) "fetch" seems to suggest gating a RAM/IO address to be active then pulling the value there to some special holding place where it might be acted upon in a later cycle but AVR/RISC/Harvard is not like this, the bit pattern in the opcode will enable such gating so the value is immediately visible as the other bits activate some binary operation directly on the source.
I am asking about if the instruction doing addition instruction between constant data and data exist in the memory (SRAM)
Details like #17 are not publicized by Microchip / Atmel as far as I know.
Instead of decapping your AVR's and finding a microscope and matching probes you would be far better of with studying the code from opencores.
DO you have a detailed reference to be explained more?
Remember an AVR can't to anything with SRAM , other then load and store. (and that there are AVR without SRAM at all)
All calculations happens on registers, and if it't is with a constant the constant is a part of the opcode. (remember that an AVR have 16 bit opcodes).
Really it helps
Thanks for all.
You should really look at the instructions like :
and that is take from here :
We can see from above that we don't need to do much for this instruction - we've already got the opcode latched from the previous cycle, so we gate the KKKKKKKK onto the ALU A (or B) bus, dddd has the register number then we read/ALU/write. The other immediate instructions will be much the same methinks.
That's nice explanation
More explanation more clearness thank you Kartman
