Typically, a chip design company (e.g. QUALCOMM) designs a chip and hands it over to a chip manufacturer (e.g. TSMC) for production, commonly known as wafering. The ASIC department of a chip design company is responsible for designing the chip, and the ASIC-designed chip can only go to silicon if it has been fully verified (in this case, it is FPGA (Field Programmable Gate Array) prototyping, which is verified by porting the RTL to the FPGA). Because of the expensive cost of the flow of the chip, if not fully verified to go to the flow of the chip, the chip is found to be problematic after returning, the economic loss is huge. General ASIC will have a special internal verification engineers to do a round of verification, but also let the software engineering to do a round of verification (do chip verification is one of the main work of the software engineers in the chip company, out of a new chip to do a chip verification), are OK before going to flow. In this paper, the smartphone (or smart watch) on the SoC chip as an example to talk about ADSP (audio DSP, ADSP is part of the SoC) on the audio-related hardware verification of which and how to check.
I. Which tests?
1， IPC
Nowadays, smartphones (or smartwatches) are multi-core systems (mainly AP, CP, ADSP, BT, WIFI, GNSS, etc.). The cores need to communicate with each other, so there is IPC (inter-processor communication, inter-core communication). The schematic is shown below:
The essence of IPC is interrupt and ring buffer. one core sends an IPC to another core, that is, it first writes data to the shared ring buffer and then sends an interrupt to the other side. When the other side receives the interrupt, it reads the data from the shared ring buffer, thus completing an inter-core communication. When verifying, we mainly look at whether the interrupt has come or not, and whether the interrupt service program has entered or not. If the interrupt service program does not work as expected, we will check whether the IPC base address and interrupt number are correct.
2， audio DMA & bus
The audio DMA & bus (I2S, PCM, etc.) is the link between the ADSP and the peripheral (codec chip, etc.), i.e., the ADSP and the peripheral collect and play audio data through them. This is illustrated by the blue circle in the figure below:
For audio DMA, the main thing is to configure the descriptor (buffer length (which determines the audio DMA interrupt interval), source address, destination address) and so on. For audio bus, it is mainly to configure the properties of the bus, including left-aligned or right-aligned and how many bits are sampled at a time, etc. When verifying, it is mainly to see whether the audio DMA interrupt has been interrupted or not. When verifying, the main point is to see if the audio DMA interrupt has an equal interval (e.g. 10ms) and if the interrupt service program has been entered. In some scenarios (e.g., playing music through speakers), the whole audio system is driven by this interrupt.
3， memory & cache
Various memories are used in audio, both on-chip (ITCM, DTCM) and off-chip (DDR, SRAM, ROM, etc.). Verifying memory is mainly about whether it can be read or written within the address range, etc. ROM is readable, while others are readable and writable. Off-chip memory can be divided into different functional blocks. Some of it is used for storing code and data, so it should be configured as cacheable to speed up the program execution. Some of them are used as share memory to interact with audio data (e.g., the AP sends audio data to the ADSP in share memory when playing music), and should be configured as uncacheable so that the receiver can get the correct data immediately. Note that the on-chip memory does not need to be configured with the cache attribute.
4, Low power consumption mode
Low power mode (LPM) is to let the ADSP sleep to save power consumption. There are three low power modes, according to the degree of sleep from shallow to deep are CLOCK _GATING, PLL_OFF, POWER_OFF. CLOCK _GATING is to turn off the clock, the degree of sleep is the shallowest, the power consumption is relatively large, PLL_OFF is to turn off the PLL (phase-locked loop), the degree of sleep is second to the middle of power consumption, POWER_OFF is to give the ADSP power down, basically no power consumption. POWER_OFF is to power down the ADSP, basically no power consumption. In POWER_OFF mode, if memory is configured as retention mode, i.e., the ADSP is powered down, but the contents of memory are not lost, the other cores can continue to work when the ADSP is woken up. If memory is configured as shutdown mode, i.e., ADSP is powered down and memory content is lost, other cores wake up ADSP, which is equivalent to reboot ADSP. After the ADSP enters LPM, other cores can wake up the ADSP through IPC or internal TIMER, etc. The test is that the ADSP can be woken up and enter the corresponding interrupt service program.
There are also some platform-related ones, such as TIMER, which I won't go into detail here.
Two, how to check
There are specialized platforms (FPGA-based) for chip verification. We mainly do verification on two platforms, namely Synopsys' HAPS and Cadence's PZ1. Both platforms are very slow, it takes more than 10 minutes to run on HAPS, and more than half an hour on PZ1, so we have to prepare well before running on HAPS to get the desired results, otherwise it will be a waste of time. So before running on the platform to do all kinds of full preparation, run once like a time, get the desired results, otherwise it will be a waste of time.PZ1 relative to the HAPS advantage is that you can catch the waveform. General (such as IPC, etc.) in order to save time can be verified on the HAPS, there are special requirements (such as LPM) to be verified on the PZ1. ASICs that need to be verified on PZ1 will be pointed out. In the HAPS test encountered difficult problems, it is necessary to reproduce the PZ1, and capture the waveform to the ASIC to analyze, to help find the root cause.
Usually the verification requires cooperation between different cores. Here is an example of how to check the IPC between AP and ADSP.
1, AP boots up the ADSP. after the ADSP is up, send an IPC to the ADSP to tell the AP that the ADSP is up.
2, go to the AP to see if it has received the IPC interrupt (read the relevant registers). If not received, the corresponding bit is 0, in this case the probability is that the sender has a problem. If received, the corresponding bit is 1, then go to check whether there is an interrupt service program, if so, it means that the ADSP to the AP's IPC is good. If it does, it means that the IPC from ADSP to AP is good. If it does not enter the interrupt service program, it is very likely that the interrupt number is not correct, and further investigation is needed.
3, ADSP to the AP's IPC check, and then check the AP to the ADSP's IPC. similar to the AP to the ADSP to send an IPC, in the ADSP to see if there is no interrupt received as well as whether there is into the interrupt service program.
After the IPCs in both directions are verified, the interrupts of the AP and ADSP are verified.