Connect with us

8051 specification

Discussion in 'General Electronics Discussion' started by vead, Sep 21, 2014.

Scroll to continue with content
  1. vead


    Nov 27, 2011
    I have doubt about 8051 specification
    8 bit microcontroller
    8 bit data
    8 bit instruction
    8 bit decoder
    16 bit program counter

    8 bit data
    If we want to deal with 8 bit data so we use 8 bit

    8 bit instruction
    instruction is 8 bit then we can do 256 operation (and.or.addition ....upto 256)
    if instruction is 16 bit then we can do 64,000 operation

    In 8 bit 8051 microcontroller why we use 8 bit instruction
    Q1 why we cant use 16 bit instruction ?

    8 bit decoder
    8 bit decoder decode 256 instruction
    we can use 5 bit 9 bit 13 bit why we use 8 bit decoder ?

    Last edited: Sep 21, 2014
  2. ketanrd01


    Aug 11, 2014
    basically, it was the first controller which had 8 bit platform. If you have to opt for, there must be some manufacturer making that 16 bit variant of 8051. Also you can opt for any other 16 bit controller as well..

    As for your query on 5,9 or 13 bit decoder...the number needs to be a power of 2.

    The PCounter is of 16 bit since there are 16 address lines... PC stores address of next instruction to be executed and since addresses are of 16 bit, the PC is of 16 bit...........
  3. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    Nov 28, 2011
    The 8051's code (ROM or Flash ROM) bus is 8 bits wide. That means that every instruction must be a multiple of 8 bits in size. For simplicity, the designers decided that every instruction would start with an 8-bit opcode, which is passed to the instruction decoder to determine the type of instruction and the number of operand bytes that will follow, and either 0, 1, or 2 bytes of operand data. This gives a nice clean design where the first byte of an instruction fully defines that instruction, but the instruction only occupies as many bytes as are required to completely specify what the instruction should do.

    This is not entirely true. For many instructions, the 8-bit opcode contains bits that are actually logically part of the operand information. This is done so that commonly used operations can be reduced in size, at the expense of using more initial opcode values to express them. See the INC Rn and AJMP instructions below.

    Here are some examples.

    NOP - encoding 00000000
    INC A - encoding 00000100

    These are single-byte instructions. They have no operand bytes. The total instruction size is 1 byte (8 bits).

    INC Rn - encoding 00001rrr
    MOV A,Rn - encoding 11101rrr
    MOV A,@Ri - encoding 1110011i

    These are single-byte instructions where the operand is specified as part of the opcode. In the first two instructions, three bits in the opcode byte are used to specify which of the eight working registers is to be used. This means that INC Rn actually uses eight of the 256 possible opcode values. This was done because it's a very commonly used instruction and it is important to keep it short (one byte), at the expense of using eight opcode values instead of just one.

    The MOV A,@Ri instruction has only one opcode bit used to specify the register number, so only two registers can be used as pointers for indirection. This is a reasonable compromise because most operations that are performed using indirect access only need two independent pointers.

    AJMP addr11 - encoding aaa00001 aaaaaaaa

    This instruction occupies two bytes, and the operand data is split between the opcode byte and the operand byte. The operand byte contains the bottom eight bits of the target address, and the opcode byte contains the top three bits of it. Together this allows an 11-bit-wide target address to be specified, at the expense of using eight of the 256 possible opcode values.

    ANL A,#data - encoding 01010100 dddddddd
    ANL A,direct - encoding 01010101 aaaaaaaa
    INC direct - encoding 00000101 aaaaaaaa
    JC relative - encoding 01000000 rrrrrrrr
    SETB bit - encoding 11010010 bbbbbbbb

    These are traditional two-byte instructions. The opcode fully defines the instruction, and contains none of the operand information. The second byte contains all of the operand information. These instructions use four different types of operand data.

    dddddddd is an immediate data value, i.e. a constant in the code. aaaaaaaa is an absolute address that specifies a memory location within the first 256 addressable data locations (registers, RAM and SFRs). rrrrrrrr is an 8-bit signed offset for a conditional branch instruction that specifies an address from -128 to +127 relative to the start of the following instruction. bbbbbbbb is a bit-address specification that specifies an individually addressable bit.

    CJNE A,#data,relative - encoding 10110100 dddddddd rrrrrrrr
    JB bit,relative - encoding 00100000 bbbbbbbb rrrrrrrr
    LJMP addr16 - encoding 00000010 hhhhhhhh aaaaaaaa
    MOV direct,#data - encoding 01110101 aaaaaaaa dddddddd
    ORL direct,#data - encoding 01000011 aaaaaaaa dddddddd

    These are assorted three-byte instructions. Each one consists of an 8-bit opcode that fully defines the instruction type, followed by two 8-bit operands of various types. The only exception is LJMP addr16 where the operand is two halves of a 16-bit address that specifies anywhere in the 16-bit-wide code address space as the destination of the jump.

    The 8051's instruction set is actually pretty thorough, well-thought-out, mature, and powerful (for an 8-bit device), especially considering its age. It has instructions to perform nearly every commonly needed operation. If you want to see an instruction set that's simpler to understand, look at the 6502. Apart from its zero-page handling, it is a much more straightforward design. All instructions contain a single opcode byte that fully defines the instruction and contains no operand informaiton, followed by 0, 1 or 2 operand bytes.

    Please read this description thoroughly, study the instruction encodings, and make sure you understand every sentence. There is a lot of information here in a small space. Study the 8051 instruction set to reinforce your understanding of the general ideas I've described here.
    Allen Bong and vead like this.
  4. vead


    Nov 27, 2011
    2 bit microcontroller
    2 bit data
    2bit instruction
    2bit decoder
    4 bit program counter

    I am taking small example to understand
    I am dealing with 2 bit data
    1bit for opcode
    1bit for operand
    I am using 2:1 decoder
    It can address 4 address line
  5. Fish4Fun

    Fish4Fun So long, and Thanks for all the Fish!

    Aug 27, 2013

    I am not certain you have a good working knowledge of what a "processor" actually is.....Since you have previously stated you are attempting to synthesize an 8051 processor in Verilog (an HDL), I think you should spend some time familiarizing yourself with how processors are actualized from standard logic blocks. Verilog and other HDLs are tools to simplify the task of creating complex logic arrays, but before they can be of any use you MUST have a firm grasp on all of the basic logic blocks....Honestly grasping HOW a processor actually works can be a lot to wrap your head around and because it is not fundamentally requisite to understand HOW a processor works to be able to program one even very good code writers frequently don't have a clue how a processor actually works. In the "bad old days" when processors were constructed from logic ICs or even discrete components there was very little separation between "programmers" and "hardware designers" but after this fairly brief period of time, came the advent of VLSI integrated circuits and with it a divergence of software/firmware development and hardware development....To develop hardware it is absolutely essential to understand what firmware/software features need to be available, optimized etc, but being an "expert programmer" is not really required...similarly, to be an expert programmer one must be aware of the platform for which the firmware/software is being developed, but understanding HOW the platform works is not essential.....FPGAs are a "software" tool for Hardware Designer's to develop hardware platforms....the "high-level language" of the FPGAs (HDLs) are compatible with the tools used to create VLSI in some ways things have come full circle....with any given FPGA synthesis a hardware designer is able to synthesize a platform and verify how it will perform with various firmware/software...and in many cases verify that the new design will be compatible with existing software tools....and like "the bad old days", the Hardware Designer must fully understand both the hardware and the software if he/she hopes to improve on existing designs....For instance, the rise of DSPs is largely dependent on modifying existing processor cores to work in parallel with other "sub-processor cores" to achieve specific goals not possible in "single core" some cases the various cores themselves may have upgradeable firmware/software features that make their function(s) "flexible", in other cases a particular core may be dedicated to a particular task with a very limited range of flexibility....for instance a dedicated encryption/decryption "ASIC" or processor might be incorporated such that the only "input" is a "Public Key", an instruction and a data block (presumably to be encrypted/decrypted). In a STB (Set Top Box) designed to decrypt a video stream a highly complex decryption function can be performed in a logic circuit dedicated to performing the function perhaps 4 or 5 orders of magnitude faster than a traditional software/firmware based function might perform the same operation....and achieve this completely asynchronously WRT to primary processing core.....

    blah,blah, blah...the bottom line here is if you want to develop a Verilog Synthesis of an 8051 processor core then you need to get a firm grasp on the logic blocks processors in general are built from and then study the 8051 core itself. It is easy enough to load an 8051 core onto any suitable FPGA .... as previously stated in another thread, most FPGA Dev kits will have a basic 8051 core synthesis in the "example resources".....or at the very least available as an "open source" download....So if "developing your own Verilog Synthesis" is an effort to "learn" about Verilog and FPGAs then I would suggest you approach this learning process by selecting an FPGA dev kit designed to "teach" the basics of FPGA Synthesis development....If the purpose of the 8051 synthesis is to learn about how processor cores are actualized then I would suggest you start by learning about logic blocks and how processor cores are built from them and leave the Verilog/FPGA synthesis alone until you have a firm grasp on the basics.....but that's just me.

    Good Luck!

    Allen Bong, vead and KrisBlueNZ like this.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day