Chip design is mainly divided into two blocks of analog and digital, and each block is divided into front-end and back-end, I think most of the students on this is certainly very clear, the following digital circuit to talk about some of the things chip design.
When it comes to digital chips, you can not ignore FPGA. This is a programmable digital circuit. The goal of digital circuit design is to make these functions into our own dedicated ASIC / SoC so that regardless of the area, cost or security can be guaranteed.
In terms of flow, the general steps of digital chip design are system and function definition, RTL implementation verification, synthesis and testability design, ATPG simulation, timing analysis to automatic layout and routing (APR) until the delivery of the fab’s GDS netlist.
This process is iterative, and for different types of chips, such as pure digital ASICs or mixed-signal circuits and system-on-chips (SoCs), the approach and implementation flow may vary at each step. Some of the main issues are discussed below in terms of these basic processes step by step.
System design is mainly concerned with functional definition and architecture design, the configuration of bus architecture, module design, distribution of data flow, and clock design. The bus includes a series of factors such as communication between modules, between modules and MCU cores, between external hosts and chips, or testing needs, etc. The clock involves the planning of data flow, communication interface or internal MCU clocking conventions, process conditions, power consumption, and other factors. Modules need to be clearly interfaced and defined.
In the system level design, especially in many mixed digital-analog circuits or circuits with special requirements for power consumption, there is also a voltage domain design, different modules, functional modules and interfaces may need to set different voltages according to process conditions, power requirements.
Both the clock, or voltage, can be controlled by the switch to achieve the power consumption requirements, the clock is relatively simple to implement, in most circuits can be implemented in this clock control. Voltage control is generally implemented on larger chips with an integrated power management chip, but the future trend is that even without a power management chip, voltage gating needs to be taken into account.
In the SoC system design, an important link is the selection of the MCU core, now commonly used core is generally ARM, the older ARM7, ARM9 and other series. The newer is the three series Cortex -A , R, M, the specific purpose is not described in detail. According to the need to set, generally do not need to do hardware people know too much about its instruction set. Generally, people who do hardware do not need to know much about its instruction set. We need to understand its bus interface, data bus, instruction bus, as well as the design of the storage system, generally need to arrange ROM, RAM as instruction and data memory, respectively. Because ROM is not changeable, generally also need to join the flash as a patch program written to, may also need external memory or DMA controller to increase the external storage space. Address allocation is done according to functional needs, and there are many tools such as synopsys’ DesignKits to generate external bus code and perform address allocation.
After the first step of system and function definition, the implementation is RTL, which is a special tool language for describing hardware circuits, including Verilog and VHDL. Timing logic is physically composed of registers that are controlled by a clock. The registers represent data or control signals in the circuit that are driven by the flow of the clock. Combinational logic is a block of circuitry that is not controlled by a clock. Combinational logic as the name implies generates some logic results directly through the combination of some signals.
RTL design, a major problem is the asynchronous design issues, asynchronous data processing according to the different circumstances. The simplest for asynchronous level signals, you can add 2 levels of registers directly in the new clock domain to isolate, to avoid the occurrence of indeterminate state. For bus processing or pulse processing, a synchronous module is required. Synchronization module is generally refers to the need to handshake signal, that is, the first level of the clock to tell the sampling of the clock – the signal. The second clock to sample again, pick up and then tell the first level of the clock.
There is a situation that the first level of the clock is too fast, causing the second level is too late to pass the signal. It is necessary to join the FIFO as isolation. The design of this FIFO involves the read-write address judgment, write full or read empty need to be processed accordingly. Read-write address judgment can only be carried out in one of the clock domain, which itself involves the processing of asynchronous signals. Generally solve with Grema, or some places can directly determine the address high. The purpose of these methods is not to let the address in the comparison of the time instability.
RTL design, the design of the clock itself should also pay attention to the issue. We try to put the clock generation circuit in one piece, mainly from the perspective of the integrated DFT to consider, so that these clocks unified management and constraints. Clock division, switching should also be specifically handled, otherwise it is easy to generate burrs and other things.
There are many other issues that need attention in RTL design, such as synthesizability, and the need to take into account the area of the circuit, as well as the response speed, etc. These issues are the basic issues of RTL coding. After the code is written, what needs to be done is verification work, the following talk about this aspect of things.
Chip verification generally has these levels, one is the RTL level or Netlist ( pre or post PR with SDF). This is also the general sense of the chip verification work, one is the FPGA level, also RTL, but download to the FPGA. With the help of the hardware environment, you can also directly do application experiments.
Chip verification workload in the chip design occupies most of the time and effort, no matter which verification, you need to build a testbench, verification platform from the software structure to simulate the working environment of the chip. There is both a clear connectivity structure and the unstructured functions or task packages needed to complete these tests. The chip under test in the testbench is RTL level, and the test vector or the applied stimulus can be verilog/VHDL, the HDL language itself has a relatively complete behavior level description function, and can meet most of the testbench construction and test stimulus generation. Of course, we face more complex design, or the pursuit of more efficient, and can also use other compiler-compatible. We can also use other compiler-compatible languages, such as C/C++, SC, SV, etc., for more complex designs or for higher efficiency.
Obviously, the test stimulus is time-sensitive and flows sequentially into and out of the chip, and the non-circuit description language and functions used are almost indistinguishable from software, so verification is increasingly using software techniques such as object-oriented programming, SystemVerilog, Specman E, etc.
In the verification system, the memory model and the code file in text format are generally used, and the general implementation is to read the file into the memory model directly through the system read-in instruction. (Some simulation tools can be imported directly through options, similar to SDF files, such as the tool nscim).
Emulators can directly write out the log of instruction execution for debug purposes, but there are now more advanced ways to verify complex SoCs, such as the Codelink tool, which builds on the original emulator and establishes a relationship between the MCU and the HDL circuitry already in software, making it easier to debug by displaying waveforms and links to firmware source code.
