introduction
Audio conforming to the audiocodec97 protocol (ab97, a digital audio processing protocol proposed by Intel) is widely used not only for personal computer sound cards, but also for audio solutions for personal information terminal equipment soc (such as int el pxa250). The audio controller designed in this paper provides a digital audio interface for the dsp core. While introducing the structure of the audio controller, the paper emphasizes the coordinated transmission of data between the core and the kernel, and gives a method for functional testing of the audio controller based on fpga implementation of the soc kernel simulation environment.
The structure and principle of the audio controller
The ac97 system consists of two parts: audio codec and audio controller. Among them, the audio code *** implements a/d, d/a conversion, sound processing and other functions, and the audio controller is the digital interface between the soc kernel and the audio code ***, which is responsible for controlling the data and audio data strings / And, / string conversion and transmission.
Performance
The audio controller of this design complies with the ac97 specification v2.3, and its main indicators are as follows: support for dual-channel recording and playback; support for fixed sampling rate (48khz) and variable sampling rate recording and playback; 20-bit wide 16-layer deep pcm audio data fifo; Support power saving mode; support interrupt, dma and polling to achieve data exchange with the kernel or memory.
The main structure of the audio controller that constitutes the structure is shown in Figure 1. The kernel/memory and audio controller interfaces (core/memory, ctrlinterface) connect the audio controller to the kernel or memory. Cs is the chip select signal, wr and rd are read and write enable, addr (16 bit wide) is the port address of the audio controller, din and dout (both 32 bits wide) are the input and output data on the bus, irq And dmareq are interrupts and dma requests, respectively. The main module (ac97 ctrl master) is responsible for the audio data (control) between the audio controller (ac97controller-p.htm" target="_blank"title="controller source and pdf" controller) and the kernel or memory (dma mode). And the status register group (control&statusregs) data and the audio code *** (ac97 codec) internal register data parallel data transmission, synchronized by the main clock clk. The control module (powerctrl) can start the power saving mode, also synchronized by the main clock clk .
Figure 1 The main structure of the audio controller
The four sets of fifo are used to store pcm audio data, which are 20 bits wide and 16 layers deep, so they can support up to 20 bits wide resolution. When the fifo is full or empty, an interrupt or dma request can be issued. Audio code *** internal register read and write buffer (codecreg write / readbuf, referred to as crbuf) is two 32-bit registers. The write buffer can buffer the control word ready to be written to the internal register of the audio program, and can issue an interrupt request when it is empty; the read buffer can buffer the status word that has been read from the audio program internal register, which is full. An interrupt request can be issued. The control and status register set contains eight 32-bit registers. The main functions of the general control register are system cold start and warm start; the general status register reflects the audio edit status; other register functions include configuring the pcm input and output channels. , configuration and generation of interrupts or dma requests. The auxiliary module (ac97ctrlslave) implements serial transmission and reception of an ac-link data frame between the audio controller and the audio code. The output data (sdata_out) is synchronized by the edge on the secondary clock bit_clk, and the input data (sdata_in) is synchronized by the edge of the bit_clk.
working principle
The dsp kernel obtains the audio editing status and the audio editing mode by reading and writing the audio controller csrs respectively; buffering the pcm audio data during audio recording and playback by reading and writing fifo; reading and writing crbuf Get the audio code *** internal register status and set the audio code *** internal register parameters. The following is an example of the main steps in audio playback to introduce the working principle of the audio controller.
(1) write full pcm left channel output fifo;
(2) write full pcm right channel output fifo;
(3) Polling audio code *** Ready (codec ready) signal is valid;
(4) Read the 26h register of the audio code *** to determine if d/a is ready;
(5) Allow crbuf to generate an interrupt request;
(6) Write 0 to the 02h register of the audio code *** to minimize the main volume attenuation;
(7) Wait for crbuf to generate an interrupt, respond to the interrupt and write 0 to the 18h register of the audio editor, so that the pcm output volume attenuation is minimized;
(8) Wait for crbuf to generate an interrupt, respond to the interrupt and write 1 to the 2ah register of the audio code ***, that is, play the audio at a variable sampling rate;
(9) Wait for crbuf to generate an interrupt, respond to the interrupt and write 5622 (hexadecimal) to the 2ch register of the audio code ***, that is, play the audio at the sampling rate of 22.05khz;
(10) Allow the full left interrupt of the pcm left channel fifo;
(11) Set the fixed or variable rate transmission of the left and right channels of the pcm, and start playing the audio;
(12) Waiting for the pcm code in fifo to transfer 16 layers and issue an interrupt request;
(13) determine whether it is the pcm left channel fifo to issue an interrupt request, and if so, write 16 layers of pcm left channel data;
(14) determine whether the pcm right channel fifo issues an interrupt request, and if so, writes 16 layers of pcm right channel fifo data;
(15) If the pcm data in the memory is read, the playback ends, otherwise return to step 12 to continue playback.
The composition and principle of the soc simulation environment
It can be seen from the working principle of the audio controller that each step is performed under the control of the dsp kernel. Therefore, in the function verification of the audio controller, not only to ensure its own logic is correct, but also to ensure that the data transmission with the kernel is correct, thus facilitating the integration of the audio controller and the kernel. It is proposed to approximate the real core through the component soc kernel simulation environment, and test the designed audio controller in this simulation environment.
The composition of the simulation environment
The hardware of the soc kernel emulation environment is based on xilinx's microblaze multimedia development board technology board, and its core is vertexii fpga. National Semiconductor's ac97 codeclm4549 is also integrated on the board and comes with linein/out, headphones and jacks. You can test the audio recording and playback effects through these jacks, and you can also debug some key signals through the test points on the board. The composition of the soc kernel simulation environment is shown in Figure 2.
Figure 2 The composition of the soc kernel simulation environment
The core emulation module (core sim) is the core of the soc kernel emulation environment. It is downloaded to the vertex iifpga in the rtl code to simulate the dsp core's single-cycle instructions. It can read and write memory and access the audio controller (including reading and writing fifo, crbuf, and Csrs), responds to and handles interrupt requests or dma requests. Where din_ram is a 32-bit memory data input bus; din_ctrl is a 32-bit audio controller data input bus; dout is a 32-bit data output bus; irq is an audio controller interrupt request; dmareq is an audio controller dma request; rst is an audio control The device is asynchronously reset.
The block memory module is a single-port memory implemented by block memory in vertex iifpga. This memory has the same timing as the regular sram and can simulate a maximum 126kb on-chip sram. This type of static memory can be generated by calling coregenerator in the xilinx integrated development environment (ise). If you use the memory diagramtor tool to generate cgf and coe files (block memory configuration files), you can assign initial values ​​to the block memory while downloading the bit file for fpga. Based on the powerful function of fpga, the pcm audio code extracted from the personal computer can be downloaded into the block memory, and then transferred to the audio editor through the audio controller under the control of the kernel simulation module. This implements audio playback.
The clock generation module (clockgenerator) can issue three clocks of 27mhz, 54mhz and 108mhz, and generates an audio controller asynchronous reset signal rst. The crystal oscillator on the microblaze development board emits a square wave signal of 27mhz and 50mhz with a duty ratio of 1:1 as the input of the clock generation module. The digital phase-locked loop hard core module (clockgen.v and clockgen.ucf) can be used to output multiple times. The frequency clock (108mhz for this design) and the asynchronous reset signal rst. Ac97ctrl is the audio controller logic downloaded to vertex ii fpga in rtl format. Ac97 codec is the lm4549 ac97 codec chip from nationalsemiconductor.
The implementation principle of the kernel simulation module
The rtl code simulates the instruction execution level in the middle, which is the level at which the audio controller and the kernel directly interact with each other. According to the behavior and interface characteristics of the dsp core at the instruction execution level, the interface and internal signals of the kernel analog module can be flexibly changed (by changing the rtl code) to form different simulation environments. Test whether the operation of the audio controller and the core is stable in the new simulation environment. If the result is not satisfactory, the design of the audio controller should be changed. This allows the characteristics of the audio controller to be optimally coordinated with the core.
Playback example based on soc kernel simulation environment
An example of playing audio based on the soc kernel emulation environment is given below. The audio comes from the utopiawindows start.wav (153kb, 16-bit mono wave file) in the winnt/media directory after the initial installation of the windows2000 operating system. The pcm audio code in the file is extracted and downloaded to the block memory of vertexii. The audio controller controls the audio editing work in the soc kernel emulation environment. Connect the headphones to the headphone jack of the microblaze development board. You can hear the audio signal for nearly 3 seconds, which is basically the same as the sound of the original audio file. The audio analysis software audiocity is used to analyze the audio playback effect. The original audio source is slightly different from the audio played by the development board for the following three reasons. (1) The starting point of the recording of the computer sound card is different from the starting point of the original audio; (2) Since the maximum capacity of the block memory is 126 kb, the recorded waveform file only intercepts the first 2/3 parts of the original file (153 kb). (3) After the sound is played by the soc kernel simulation environment, the audio obtained by the computer sound card recording is inevitably different from the original audio. The first and second factors cause the deviation of the two waveforms in the direction of the time axis, and the factor 3 causes the deviation in the direction of the amplitude axis. Despite these differences, it is entirely clear that in the soc kernel emulation environment, the designed audio controller logic is functioning correctly and can work in coordination with the kernel.
to sum up
In this paper, according to the structure of the designed audio controller, the idea and implementation method of building the soc kernel simulation environment to test the audio controller are introduced in detail. Based on this simulation environment, not only can the effect and performance of the actual recording and playback of the audio controller be tested, but more importantly, the degree of coordination with the kernel can be reflected in time. This avoids the drawback of designing the audio controller in isolation, regardless of its coordination with the soc system, and significantly improves the efficiency of the later integrated soc system.
Audio conforming to the audiocodec97 protocol (ab97, a digital audio processing protocol proposed by Intel) is widely used not only for personal computer sound cards, but also for audio solutions for personal information terminal equipment soc (such as int el pxa250). The audio controller designed in this paper provides a digital audio interface for the dsp core. While introducing the structure of the audio controller, the paper emphasizes the coordinated transmission of data between the core and the kernel, and gives a method for functional testing of the audio controller based on fpga implementation of the soc kernel simulation environment.
The structure and principle of the audio controller
The ac97 system consists of two parts: audio codec and audio controller. Among them, the audio code *** implements a/d, d/a conversion, sound processing and other functions, and the audio controller is the digital interface between the soc kernel and the audio code ***, which is responsible for controlling the data and audio data strings / And, / string conversion and transmission.
Performance
The audio controller of this design complies with the ac97 specification v2.3, and its main indicators are as follows: support for dual-channel recording and playback; support for fixed sampling rate (48khz) and variable sampling rate recording and playback; 20-bit wide 16-layer deep pcm audio data fifo; Support power saving mode; support interrupt, dma and polling to achieve data exchange with the kernel or memory.
The main structure of the audio controller that constitutes the structure is shown in Figure 1. The kernel/memory and audio controller interfaces (core/memory, ctrlinterface) connect the audio controller to the kernel or memory. Cs is the chip select signal, wr and rd are read and write enable, addr (16 bit wide) is the port address of the audio controller, din and dout (both 32 bits wide) are the input and output data on the bus, irq And dmareq are interrupts and dma requests, respectively. The main module (ac97 ctrl master) is responsible for the audio data (control) between the audio controller (ac97controller-p.htm" target="_blank"title="controller source and pdf" controller) and the kernel or memory (dma mode). And the status register group (control&statusregs) data and the audio code *** (ac97 codec) internal register data parallel data transmission, synchronized by the main clock clk. The control module (powerctrl) can start the power saving mode, also synchronized by the main clock clk .
Figure 1 The main structure of the audio controller
The four sets of fifo are used to store pcm audio data, which are 20 bits wide and 16 layers deep, so they can support up to 20 bits wide resolution. When the fifo is full or empty, an interrupt or dma request can be issued. Audio code *** internal register read and write buffer (codecreg write / readbuf, referred to as crbuf) is two 32-bit registers. The write buffer can buffer the control word ready to be written to the internal register of the audio program, and can issue an interrupt request when it is empty; the read buffer can buffer the status word that has been read from the audio program internal register, which is full. An interrupt request can be issued. The control and status register set contains eight 32-bit registers. The main functions of the general control register are system cold start and warm start; the general status register reflects the audio edit status; other register functions include configuring the pcm input and output channels. , configuration and generation of interrupts or dma requests. The auxiliary module (ac97ctrlslave) implements serial transmission and reception of an ac-link data frame between the audio controller and the audio code. The output data (sdata_out) is synchronized by the edge on the secondary clock bit_clk, and the input data (sdata_in) is synchronized by the edge of the bit_clk.
working principle
The dsp kernel obtains the audio editing status and the audio editing mode by reading and writing the audio controller csrs respectively; buffering the pcm audio data during audio recording and playback by reading and writing fifo; reading and writing crbuf Get the audio code *** internal register status and set the audio code *** internal register parameters. The following is an example of the main steps in audio playback to introduce the working principle of the audio controller.
(1) write full pcm left channel output fifo;
(2) write full pcm right channel output fifo;
(3) Polling audio code *** Ready (codec ready) signal is valid;
(4) Read the 26h register of the audio code *** to determine if d/a is ready;
(5) Allow crbuf to generate an interrupt request;
(6) Write 0 to the 02h register of the audio code *** to minimize the main volume attenuation;
(7) Wait for crbuf to generate an interrupt, respond to the interrupt and write 0 to the 18h register of the audio editor, so that the pcm output volume attenuation is minimized;
(8) Wait for crbuf to generate an interrupt, respond to the interrupt and write 1 to the 2ah register of the audio code ***, that is, play the audio at a variable sampling rate;
(9) Wait for crbuf to generate an interrupt, respond to the interrupt and write 5622 (hexadecimal) to the 2ch register of the audio code ***, that is, play the audio at the sampling rate of 22.05khz;
(10) Allow the full left interrupt of the pcm left channel fifo;
(11) Set the fixed or variable rate transmission of the left and right channels of the pcm, and start playing the audio;
(12) Waiting for the pcm code in fifo to transfer 16 layers and issue an interrupt request;
(13) determine whether it is the pcm left channel fifo to issue an interrupt request, and if so, write 16 layers of pcm left channel data;
(14) determine whether the pcm right channel fifo issues an interrupt request, and if so, writes 16 layers of pcm right channel fifo data;
(15) If the pcm data in the memory is read, the playback ends, otherwise return to step 12 to continue playback.
The composition and principle of the soc simulation environment
It can be seen from the working principle of the audio controller that each step is performed under the control of the dsp kernel. Therefore, in the function verification of the audio controller, not only to ensure its own logic is correct, but also to ensure that the data transmission with the kernel is correct, thus facilitating the integration of the audio controller and the kernel. It is proposed to approximate the real core through the component soc kernel simulation environment, and test the designed audio controller in this simulation environment.
The composition of the simulation environment
The hardware of the soc kernel emulation environment is based on xilinx's microblaze multimedia development board technology board, and its core is vertexii fpga. National Semiconductor's ac97 codeclm4549 is also integrated on the board and comes with linein/out, headphones and jacks. You can test the audio recording and playback effects through these jacks, and you can also debug some key signals through the test points on the board. The composition of the soc kernel simulation environment is shown in Figure 2.
Figure 2 The composition of the soc kernel simulation environment
The core emulation module (core sim) is the core of the soc kernel emulation environment. It is downloaded to the vertex iifpga in the rtl code to simulate the dsp core's single-cycle instructions. It can read and write memory and access the audio controller (including reading and writing fifo, crbuf, and Csrs), responds to and handles interrupt requests or dma requests. Where din_ram is a 32-bit memory data input bus; din_ctrl is a 32-bit audio controller data input bus; dout is a 32-bit data output bus; irq is an audio controller interrupt request; dmareq is an audio controller dma request; rst is an audio control The device is asynchronously reset.
The block memory module is a single-port memory implemented by block memory in vertex iifpga. This memory has the same timing as the regular sram and can simulate a maximum 126kb on-chip sram. This type of static memory can be generated by calling coregenerator in the xilinx integrated development environment (ise). If you use the memory diagramtor tool to generate cgf and coe files (block memory configuration files), you can assign initial values ​​to the block memory while downloading the bit file for fpga. Based on the powerful function of fpga, the pcm audio code extracted from the personal computer can be downloaded into the block memory, and then transferred to the audio editor through the audio controller under the control of the kernel simulation module. This implements audio playback.
The clock generation module (clockgenerator) can issue three clocks of 27mhz, 54mhz and 108mhz, and generates an audio controller asynchronous reset signal rst. The crystal oscillator on the microblaze development board emits a square wave signal of 27mhz and 50mhz with a duty ratio of 1:1 as the input of the clock generation module. The digital phase-locked loop hard core module (clockgen.v and clockgen.ucf) can be used to output multiple times. The frequency clock (108mhz for this design) and the asynchronous reset signal rst. Ac97ctrl is the audio controller logic downloaded to vertex ii fpga in rtl format. Ac97 codec is the lm4549 ac97 codec chip from nationalsemiconductor.
The implementation principle of the kernel simulation module
The rtl code simulates the instruction execution level in the middle, which is the level at which the audio controller and the kernel directly interact with each other. According to the behavior and interface characteristics of the dsp core at the instruction execution level, the interface and internal signals of the kernel analog module can be flexibly changed (by changing the rtl code) to form different simulation environments. Test whether the operation of the audio controller and the core is stable in the new simulation environment. If the result is not satisfactory, the design of the audio controller should be changed. This allows the characteristics of the audio controller to be optimally coordinated with the core.
Playback example based on soc kernel simulation environment
An example of playing audio based on the soc kernel emulation environment is given below. The audio comes from the utopiawindows start.wav (153kb, 16-bit mono wave file) in the winnt/media directory after the initial installation of the windows2000 operating system. The pcm audio code in the file is extracted and downloaded to the block memory of vertexii. The audio controller controls the audio editing work in the soc kernel emulation environment. Connect the headphones to the headphone jack of the microblaze development board. You can hear the audio signal for nearly 3 seconds, which is basically the same as the sound of the original audio file. The audio analysis software audiocity is used to analyze the audio playback effect. The original audio source is slightly different from the audio played by the development board for the following three reasons. (1) The starting point of the recording of the computer sound card is different from the starting point of the original audio; (2) Since the maximum capacity of the block memory is 126 kb, the recorded waveform file only intercepts the first 2/3 parts of the original file (153 kb). (3) After the sound is played by the soc kernel simulation environment, the audio obtained by the computer sound card recording is inevitably different from the original audio. The first and second factors cause the deviation of the two waveforms in the direction of the time axis, and the factor 3 causes the deviation in the direction of the amplitude axis. Despite these differences, it is entirely clear that in the soc kernel emulation environment, the designed audio controller logic is functioning correctly and can work in coordination with the kernel.
to sum up
In this paper, according to the structure of the designed audio controller, the idea and implementation method of building the soc kernel simulation environment to test the audio controller are introduced in detail. Based on this simulation environment, not only can the effect and performance of the actual recording and playback of the audio controller be tested, but more importantly, the degree of coordination with the kernel can be reflected in time. This avoids the drawback of designing the audio controller in isolation, regardless of its coordination with the soc system, and significantly improves the efficiency of the later integrated soc system.
Incremental Encoder is commonly used, and Absolute Encoder is used if there are strict requirements on position and zero position. Servo system should be analyzed in detail, depending on the application situation. Commonly used incremental encoder for speed measurement, which can be used for infinite accumulation measurement; Absolute encoder is used for position measurement, and the position is unique (single or multiple turns). Finally, it depends on the application situation and the purpose and requirements to be realized.
Incremental Linear Encoders,Linear Optical Encoder,Linear Position Encoder,Encoder Bearing Tester
Yuheng Optics Co., Ltd.(Changchun) , https://www.yhencoder.com