The process of prototyping an ASIC with an FPGA (updated)

The process of prototyping and validating ASIC using FPGA reference:http://xilinx.eetrend.com/d6-xilinx/article/2018-10/13736.html

Given the complexity of chip design, the steps and processes involved in successfully designing a chip are becoming more complex, and the amount of money required is multiplied, and the cycle and cost of a typical chip development project is as follows

Can be seen before the chip manufacturing, a lot of energy will be spent on the RTL code verification work, the other software related development work, also will be in front of the chip to get started, these 2 aspects need to use the FPGA prototype to simulate the behavior of the chip, to help hardware development and software developers to work together to improve work efficiency.

FPGA prototype in the digital chip design, the basic is essential, the reason is very obvious, compared with the simulator, or accelerator and so on to run the simulation, the speed of the FPGA, closer to the real chip, can cooperate with software developers to develop the underlying software. Of course, the FPGA prototype as the chip of the double, there are many restrictions, such as scale constraints, speed limits, power constraints, structural constraints, etc., in the use of FPGA prototype as a substitute for the chip, need to make corresponding changes in order to complete the corresponding functions, and even some features can not be overwritten.

If we compare the resources in the FPGA that can be mapped to Asics, we can get a table like this.

The above table shows that, in addition to ordinary RTL logic and basic ports, and other similar storage clock DSP, and so on, it is best to do manual modification to map, the ASIC design to convert to FPGA more reliable.

To make an FPGA prototype of an ASIC, you need to approximate the steps,

1 FPGA selection

2 make the board or purchase the prototype board.

3 Converting an ASIC design transformation into an FPGA

4 Debug Start FPGA prototype

5 loading software co-operation

6 hardware and software system verification

Follow these steps to discuss the following:

The first is the FPGA selection problem, before the selection, of course, the ASIC design needs to be generally understood, including the following aspects:

Some of the dimensions that are most concerned with the selection problem:

1 capacity including pure logical capacity, storage capacity, DSP unit capacity These

2 built-in IP including clock, storage control, CPU and so on hard core

3 Interface Common interface and dedicated high-speed interface

4 the speed at which the speed resource occupancy rate is around 50% is generally used to evaluate the prototype

The capacity of pure logical capacity, which is the combination circuit and trigger in ASIC, can be directly converted to the resources in FPGA.

For example, the Xilinx V7 2000T has 2.4M FF, roughly corresponding to the ASIC 2 input and non-gate 10M gates, if the usage rate according to 50%, probably placed 5M logic gate no problem.

Built-in memory, can achieve 21M single-and dual-port RAM,ROM,FIFO, and so on, if the ASIC uses a little more storage, you can also use the Lut to implement some of the storage, instead of block RAM.

If more multiplication is used, you can also map the implementation of DSP devices in the FPGA, the specific types of FPGA contains how many devices, you can refer to the Xilinx documentation.

For the built-in IP, the first thing to consider is the clock module MMCM, the general FPGA will have several to dozens of clock modules, such as the following table 2000T contains 24 CMTs, which is 24 PLL and MMCM, each set of PLL and MMCM can be a clock domain clock frequency multiplier. The general ASIC will contain multiple clock domains, each of which requires at least one CMTS to operate the clock, which can be used to choose which FPGA device to use.

To select an FPGA with an arm hard core to emulate an arm core in an ASIC, you need to select the Zynq series. The logic of self-study in the system is attached to the bus via Axi, which of course does not necessarily make the FPGA fully consistent with the system in the ASIC, but as a circle, the following is the capacity of some FPGAs with arm cores and the corresponding IP conditions

For the limitations of the interface, the general number of ordinary FPGA interface is large enough, will not become a bottleneck, mainly in the ASIC required by the specific interface, in the FPGA can be satisfied, many times these specific interfaces require external PHY to complete the corresponding functions.

There are many factors that affect the final speed of the FPGA, including code style, specific design, resource occupancy, FPGA model, etc., so this needs to be completed in the RTL Code basic framework, through the tool synthesis to obtain a approximate value, so as an ASIC prototype, as far as possible to choose the speed of fast FPGA.

Through the above qualification, the basic can choose which FPGA model to use, but may be the ASIC resources occupy too much, any one can not fit, there are 2 ways to solve. One is that the blocks are verified separately, and of course this is extremely risky and cannot directly validate the final system.

In addition, the use of multi-chip FPGA to get the prototype, which involves the functional division of different FPGA problems, this is more cumbersome and difficult things, the FPGA circuit design, and ASIC to FPGA code conversion, there are quite a number of new problems.

The 2nd step is Seihan, this need to consider the aspect is also quite a lot, such as signal integrity, power problems, clock problems, scalability, etc., I do not have direct experience, there is no way to unfold. Of course, the need for multiple FPGA verification Board, the general strength of the team, may not be able to handle, so choose to spend money to buy peace, direct selection of similar haps such a verification system, may be more reliable.

The 3rd step is that the ASIC is designed to be loaded into the FPGA. This requires modifications to the original ASIC-oriented code.

For general pure RTL logic, the available results can be synthesized in the ASIC and FPGA, but the devices in the following table need to be modified

The pad in the chip, usually the hard core given by Fab factory, has input and output, drive up and down control and so on. When converting to an FPGA, it is common to use the assign substitution in the example, and the. Xdc or. v Specifies the pull-down, etc.

If there is an ASIC gate-level network table, the underlying ASIC instance device can be replaced with the Verilog behavior description, which can be implemented in FPGA synthesis. Other simple cell routines can also be converted in this way.

For memory, it is generally possible to find the Sram,rom in FPGA that is consistent with the ASIC function, which can directly outsource the FPGA mem to change the port name instead of the ASIC mem. Small embedded flash, you can put the FPGA SRAM packet layer logic to imitate.

Other hard-core IPs may need to look for consistent functionality in the FPGA and modify the interface accordingly, effectively connecting to other parts of the ASIC code.

For Bist, the most straightforward approach is to remove, generally does not affect the actual function.

For a variety of gating clocks, frequency multiplier, etc., generally need to do manual modification to the FPGA, using DCM to complete the same behavior as the clock in the chip.

The following are some of the specific issues that will arise in the changes, detailed description.

First we get the structure of the ASIC design, basically as shown, the most outer ring is a variety of pad ring, inside the first chip of various auxiliary functions, including CLK, RST, power, test,debug and so on. Then the actual function of the chip is related to the part, may include some analog circuit, digital circuit including Cpu,mem bus, various logic control and so on. We need to explicitly use the FPGA to verify the prototype, mainly in the digital circuit of those core functions, chip core outside of those auxiliary logic, many of which need to be modified, but also can not be verified. The pad here is generally directly in the FPGA directly to the example of an FPGA PAD containing several assign statements, the CLK RST needs to be adjusted according to the specific power-up sequence, clock resources, the RST function is generally simplified to make a global reset, The crossover and shutdown functions in CLK are implemented in CMT. Power control, which is generally ignored directly in the FPGA, is almost impossible to simulate with various UPF-specified behaviors with FPGAs. Debug test can be retained or removed according to the actual situation, but even if it is maintained, it will not actually be used. The core functionality needs to be changed, usually a variety of internal memory.

Clock gating clocks gating are generally used in ASIC, usually in the CLK module to be instantiated as a gated unit composed of latch and doors, a module of the clock control. These gating units, if directly in the FPGA to instantiate the same logic latch and door, the logic function is no problem. But at this time with the door out of the controlled clock, you can no longer use the FPGA dedicated clock network line, but to walk the common signal network, so that the FPGA can achieve a very poor frequency. In order to rectify this situation, the gating of the registers can be placed on the register side, which is the use of a gated register such as the FDCE in the FPGA. This process can be done manually, but it is cumbersome, and generally the specialized FPGA synthesis tool can do this kind of automatic conversion. For example, use in Vivado (* Gated_clock = "true" *) input clk_a; Calibrate the controlled clock and add the-gated_clock_conversion on integrated option in the script.

Of course, if the need for a controllable clock is not too much, that is, less than the number of BUFGCE in the FPGA, you can directly control the door signal to the BUFGCE controller, the output is to walk the clock network of the gate control signal. If there is bufhce in the FPGA device, more clocks can be gated and more controlled clocks can be obtained.

For a more detailed explanation of FPGA gating clocks, you can refer to the Https://forums.xilinx.com/t5/General-Technical-Discussion/Reg-Clock-gati ...

The integrated constraints that ASIC transforms into FPGA use are basically compatible with SDC and xdc, such as

These can be used directly, of course, in many cases the FPGA is still impossible to run to the ASIC speed, must be slowed down. There is also the need to add constraints on the pin position, type, drive strength, etc. in the FPGA, as well as some comprehensive options

The above is the main part of the ASIC code changes, in the next to the FPGA board debugging, it is best to simulate the changed FPGA code, confirm the function is normal, reduce the workload of the Board debugging.

The 4th step is to start debugging the FPGA prototype.

Before the modified FPGA code is loaded into the debug, it is necessary to ensure that the FPGA board itself is normally available, then if the outsourcing of the Development Board or similar to the Haps verification system, it will save some trouble.

If the FPGA board was developed for the first time, you would need to load one of the simplest FPGA image files, test the power supply of the FPGA, download the connection is available, and then pass several FPGA files for testing to test whether the other devices connected to the FPGA are working properly. General first design of the board, how many will have a variety of problems, such as power supply problems, PIN connection differential signal matching problem, impedance matching, current drive, signal quality and other issues if the board passed the above test, you can think that the circuit hardware design no problem, can be loaded into the FPGA prototype file for testing.

Loading modified FPGA prototype simulation ASIC, generally not a success, general problems can be divided into the following three categories:

1 RTL logic errors, including errors introduced by the original ASIC and the modification process.

2 interface error with external device electrical signal connection error, including voltage mismatch, drive current inconsistent and so on.

3 software Error The MCU is running software that is not properly configured with related features, which is generally difficult to find in simulations because simulations rarely run real software systems.

On-board debugging of FPGA prototypes can be summarized in the following steps.

When the actual running software is loaded, through the FPGA prototype, the software can be tested and modified in the same way as in the actual chip, and the system-level verification work is done. It also goes to step 5.6, which is roughly the same as common embedded software development.

For prototype verification through FPGA, there are recommendations on the following design processes, which are worth reference

The above references are in the content of the Xilinx website, as well as FPMM books.

The process of prototyping an ASIC with an FPGA (updated)