Skip to main content

Your New Microprocessor Design Steps

 Hello Dear Reader,

Here in this post, I will give an idea about how we can design microprocessors from the scratch as per the requirement.
When designing a new microprocessor or microcontroller unit, there are a few general steps that can be followed to make the process flow more logically. These few steps can be further sub-divided into smaller tasks that can be tackled more easily. The general steps to designing a new microprocessor are:
  1. Determine the capabilities the new processor should have.
  2. Layout the datapath to handle the necessary capabilities.
  3. Define the machine code instruction format (ISA).
  4. Construct the necessary logic to control the datapath.
Let's see each in details:

Determine Machine Capabilities:

Before you start to design a new processor element, it is important to first ask why you are designing it at all. What new thing will your processor do those existing processors cannot? Keep in mind that it is always less expensive to utilize an existing chip than to design and manufacture a new one. 
Some questions to start:
  1. Is this chip an embedded chip, a general-purpose chip, or a different type entirely? 
  2. What, if any, are the limitations in terms of resources, price, power, or speed? 
With that in mind, we need to ask what our chip will do: 
  1. Does it have integer, floating-point, or fixed-point arithmetic, or a combination of all three? 
  2. Does it have scalar or vector operation abilities? 
  3. Is it self-contained, or must it interface with a number of external peripherals? 
  4. Will, it support interrupts? If so, How much interrupt latency is tolerable? How much interrupt-response jitter is tolerable? 

We also need to ask ourselves whether the machine will support a wide array of instructions, or if it will have a limited set of instructions. More instructions make the design more difficult, but make programming and using the chip easier. On the other hand, having fewer instructions is easier to design, but can be harder and more costly to program. 
Layout the basic arithmetic operations you want your chip to have: 
  • Addition/Subtraction 
  • Multiplication 
  • Division 
  • Shifting and Rotating  
  • Logical Operations: AND, OR, XOR, NOR, NOT, etc.
List other capabilities that your machine has: 
  • Unconditional jumps 
  • Conditional Jumps (and what conditions?) 
  • Stack operations (Push, pop) 

Once we know what our chip is supposed to do, it is easier to lay out the framework for our datapath

Design the Datapath:

Right off the bat, we need to determine what ALU architecture that our processor will use:
  • Accumulator 
  • Stack 
  • Register 
  • A combination of the above 3 

This decision, more than any other, is going to have the largest effect on your final design. Do not proceed in the design process until you have made this decision. Once you have your ALU architecture, you create your memory element (stack or register file), and you can lay out your ALU.

Create ISA:

Once we have our basic datapath, we can start to design our ISA. There are a few things that we need to consider: 
  1. Is this processor RISC, CISC, or VLIW? 
  2. How long is a machine word? 
  3. How do you deal with immediate values? What kinds of instructions can accept immediate values? 

Once we have our machine code basics, we frequently need to determine whether our processor will be compatible with higher-level languages. Specifically, are there any instructions that can be used for function call and return? Determining the length of the instruction word in a RISC is a very important matter and one that is worth a considerable amount of thought. For additional flexibility, you can utilize a variable-length instruction set instead like most CISC machines at the expense of additional and more complicated instruction decode logic. If the instruction word is too long, programmers will be able to fit fewer instructions into memory. If the instruction word is too small, there will not be enough room for all the necessary information. On a desktop PC with several megabytes or even gigabytes of RAM, large instruction words are not a big problem. On an embedded system, however, with limited program ROM, the length of the instruction word will have a direct effect on the size of potential programs, and the usefulness of the chips. Each instruction should have an associated opcode, and typically the length of the opcode field should be constant for all instructions, to reduce the complexity of the decoder. The length of the opcode field will directly impact the number of distinct instructions that can be implemented. if the opcode field is too small, you won't have enough room to designate all your instructions. If your opcode is too large, you will be wasting precious bits in your instruction word. Some instructions will need to be larger than others. For instance, instructions that deal with an immediate value, a memory location, or a jump address are typically larger than instructions that only deal with registers. Instructions that deal only with registers, therefore, will have additional space left over that can be used as an extension to the opcode field.

Example: MIPS R-Type

In the MIPS architecture, instructions that only deal with registers are called R-type instructions. With 32 registers, a register address is only 5 bits wide. The MIPS opcode is 6 bits wide. With the opcode and the three register addresses (two source and 1 destination register), an R-type instruction only uses 21 out of the 32 bits available. The additional 11 bits are broken into two additional fields: Shamt, a 5-bit immediate value that controls the amount of places shifted by a shift or rotate instruction, and Func. Func is a 6-bit field that contains additional information about R-Type instructions. Because of the availability of the Func field, all R-Type instructions share an opcode of 0.

Instruction Set Design:

Picking a particular set of instructions is often more an art than a science. Historically there have been different perspectives on what makes a "good" instruction set. 
  • The early CISC years focused on making instruction sets that expert assembly language programmers enjoyed programming -- "../code density" was a common metric. 
  • the early RISC years focused on making instruction sets that ran a few benchmark programs in C, when compiled with relatively primitive compilers, really, really fast -- "cycles per instruction", and later "instructions per cycle" was recognized as an important part of achieving low "time to run the benchmark". 
  • The rise of multitasking operating systems (and shared-memory parallel processors) lead to the discovery of non-blocking synchronization and the instructions necessary to support it. 
  • CPUs dedicated to a single application (ASICs or FPGAs) led to the idea of customizing the CPU for one particular application 
  • The rise of viruses and other malware led to the recognition of the Popek and Goldberg virtualization requirements
Build Control Logic:

Once we have our datapath and our ISA, we can start to construct the logic of our primary control unit. These units are typically implemented as finite state machines, and we can try to map the ISA to the control unit in a logical way. 

Design the address path:

If a simple virtual physical address path is adequate for your CPU, you can skip this section. Most processors have a very simple address path -- address bits come from the PC or some other programmer-visible register, or directly from some instruction, and they are directly applied to the address bus. Many general-purpose processors have a more complex address path: user-level programs run as if they have a simple address path, but the physical address applied to the address bus is significantly different than the programmer-visible address. If your CPU needs to do this, then you need something to translate user-visible addresses to physical address -- either design the CPU to connect to some off-chip bank register or MMU (such as the 8722 MMU or the 68851 MMU) or design in an on-chip bank register or MMU. 

You may want to do this in order to:
  •  support various debug tools that trap on reads or writes to selected addresses.  
  • allow access to more RAM (wider physical address) than the user-level address seems to support (banking) 
  • support many different programs all in different physical RAM locations, even though they were all compiled to run at location 0x300. 
  • allow a program to successfully read and write a large block of data using normal LOAD and STORE instructions as if it were all in RAM, even though the machine doesn't have that much RAM (paging with virtual memory) 
  • support a "protected" supervisor-level system that can run buggy or malicious user-level code in an isolated sandbox at full speed without damaging other user-level programs or the supervisor system itself -- Popek and Goldberg virtualization, W xor X memory protection, etc. 
  • or some combination of the above.

Verify the design:

People who design a CPU often spend more time on functional verification than all other steps combined.

After your ASIC Microprocessor is ready to sell your customers and make your organization profitable because you are not selling only design but also make a constant commitment towards renovation to your design as per raise demands from the markets.



Comments

  1. What a great post keep it up

    ReplyDelete
  2. any reference sites from which we can pickup new project ideas

    ReplyDelete
  3. Best short summary for designing new microprocessor thanks and keep it up

    ReplyDelete
  4. An integrated circuit can be a collection of many transistors arranged to do many functions besides processing. It can be digital or analog or even mixed. within digital and analog functions there can be thousands of applications. how to extract gold from electronics without chemicals

    ReplyDelete

Post a Comment

Popular posts from this blog

Electronic Engineer at Thinture Technologies Pvt. Ltd

Hello Dear Readers, Currently, at Thinture Technologies Pvt. Ltd vacancy for Electronic Engineer role. Thinture Technologies Pvt. Ltd. is a vehicle control systems manufacturer, with a primary focus on road speed limitation and GPS-based tracking systems. All of our products are designed in-house from basic circuit designing to firmware, algorithm to PCB designing, online software platforms to mechanical assembly drawings, and standard operating procedures for aftermarket usage. Role Description: This is a full-time on-site role for an Electronic Engineer located in Bengaluru. The Electronic Engineer will be responsible for the day-to-day tasks associated with electronic engineering, including electronics, electrical engineering, circuit design, testing, and more. Qualifications: Strong electronic engineering skills Sound knowledge of circuit design and electrical engineering Experience with electronics testing and quality assurance Proficient in using software tools for schematic capt

R&D Intern (Electronics Engineering) at Greaves Electric Mobility

Hello Dear Readers, Currently, at Greaves Electric Mobility vacancy for an R&D Intern (Electronics Engineering) role. At Greaves Electric Mobility, we build products and solutions that are designed to democratize smart and sustainable mobility and do our bit to heal the Planet. Backed by the 164 year engineering legacy of Greaves, our portfolio of electric two and three wheelers are made in India at manufacturing sites across Tamil Nadu, Telangana and Uttar Pradesh. Key Responsibilities: Collaborate with experienced engineers in the research and development of electric mobility technologies. Participate in the design, prototyping, and testing of electronic and electrical systems for electric vehicles. Contribute to the analysis and improvement of automotive electrical systems, ensuring compliance with industry standards. Assist in troubleshooting and problem-solving activities related to electric vehicle components. Stay updated on the latest advancements in the electric mobility s

Hardware Design Engineer at TSC Tech Labs

  Hello Dear Readers, Currently, at TSC Tech Labs  vacancy for a Hardware Design Engineer role. Company Description: TSC Tech Labs is a Space and Defence Startup based in Bengaluru. The company has a legacy of developing three Satellites with Space Heritage and holds five active Defence Contracts with the Indian Navy. Role Description: This is a Senior Hardware Design Engineer role and is a full-time on-site position located in Bengaluru. The Senior Hardware Design Engineer will be responsible for designing and developing electronics hardware, circuit design, hardware architecture and hardware development for satellite and defense systems. Responsibilities: Review and understand electrical schematic designs Perform design reviews with other team members Perform layout design based on these schematic designs, complying with product requirements Close collaboration with other project members (system, mechanical, hardware, and firmware engineers, etc.) Prepare PCB/PCBA production document