{"id":23621,"date":"2025-04-18T20:40:36","date_gmt":"2025-04-18T20:40:36","guid":{"rendered":"https:\/\/liquidinstruments.com\/?p=23621"},"modified":"2025-08-29T04:40:49","modified_gmt":"2025-08-29T04:40:49","slug":"using-ip-cores-in-mcc","status":"publish","type":"post","link":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/","title":{"rendered":"Using IP cores for faster customization in Moku Cloud Compile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

[vc_row][vc_column]\n

\n
\n \n
\n
\n \n

This white paper outlines how to use IP cores in Moku Cloud Compile<\/a>, including eight precompiled IP cores for common signal processing functions and custom AMD Vivado IP core integration. Each core is described with usage examples and test setups using Moku hardware. The document also guides users through uploading custom IPs.<\/p>\n\n <\/div>\n <\/div>\n

\n Explore Moku Cloud Compile<\/span><\/a>\n Configure Moku:Pro<\/span><\/a>\n \n \n <\/div>\n <\/div>\n <\/div>[\/vc_column][\/vc_row][vc_column][\/vc_column][vc_column_text css=””]<\/p>\n

Introduction<\/span><\/span> <\/span><\/h2>\n

Moku Cloud Compile is a powerful tool available on Moku devices. Moku FPGA-based test and measurement devices allow users to deploy custom VHDL and Verilog code to the hardware. With Moku Cloud Compile, you can extend and customize instrument functionality by integrating your own designs with existing instruments to create new capabilities made possible by Moku\u2019s unique Instrument-on-Chip architecture.<\/span> <\/span><\/p>\n

Moku Cloud Compile offers eight precompiled IP cores optimized for arithmetic, filtering, waveform generation, and correlation analysis, compatible with all Moku devices. These cores are ready to instantiate and simplify common digital signal processing tasks. <\/span>Users can also import their own IP cores created in AMD Vivado by uploading <\/span>.xci<\/span><\/b> files, enabling seamless integration of custom hardware blocks into Moku Cloud Compile designs.<\/span> <\/span><\/p>\n

This document outlines the in\/out ports, functionality, and example usage of each IP core, and provides guidance on building and testing custom designs using <\/span>Multi-Instrument Mode<\/span><\/a>. Together, these features make Moku Cloud Compile a more powerful platform for both rapid prototyping and advanced signal processing applications.<\/span> <\/span><\/p>\n

Eight pre<\/span>compiled IP cores<\/span><\/span> <\/span><\/h2>\n

This section descri<\/span>bes<\/span> the eight pre<\/span>compiled IP cores<\/span> listed in Table 1<\/span>, detailing their input and output port specifications and functionalit<\/span>y<\/span>. <\/span>Example<\/span> use cases are provided for each core. Owing to their native integration within the M<\/span>oku Cloud Compile<\/span> backend, these IP cores can be instantiated directly within user designs, thereby streamlining the development process and reducing implementation overhead.<\/span><\/span> <\/span><\/p>\n

Table <\/span><\/span>1<\/span><\/span><\/span>: <\/span>The names and descriptions of the eight precompiled IP cores.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n
No.<\/span> <\/span><\/td>\nIP core name<\/span> <\/span><\/td>\nDescription<\/span> <\/span><\/td>\n<\/tr>\n
1<\/span> <\/span><\/td>\nAddSubtract_16<\/span> <\/span><\/td>\nDynamically reconfigurable adder\/subtractor module.<\/span> <\/span><\/td>\n<\/tr>\n
2<\/span> <\/span><\/td>\nCIC_Dec_3Ordx8<\/span> <\/span><\/td>\nCascaded Integrator-Comb (CIC) decimator with a decimation factor of 8 and filter order of 3.<\/span> <\/span><\/td>\n<\/tr>\n
3<\/span> <\/span><\/td>\nCordic_Translate_16<\/span> <\/span><\/td>\nConverter that transforms 16-bit real and imaginary inputs into amplitude and phase outputs.<\/span> <\/span><\/td>\n<\/tr>\n
4<\/span> <\/span><\/td>\nCounter_32<\/span> <\/span><\/td>\n32-bit counter supporting up\/down counting with synchronous clear functionality.<\/span> <\/span><\/td>\n<\/tr>\n
5<\/span> <\/span><\/td>\nSineGen_48<\/span> <\/span><\/td>\nSine and cosine waveform generator with a 48-bit frequency step resolution.<\/span> <\/span><\/td>\n<\/tr>\n
6<\/span> <\/span><\/td>\nFIR_Filter_7coef<\/span> <\/span><\/td>\nFull-rate FIR low-pass filter with fixed coefficients.<\/span> <\/span><\/td>\n<\/tr>\n
7<\/span> <\/span><\/td>\nFFT_1024<\/span> <\/span><\/td>\n1,024-point fast Fourier transform (FFT) block with selectable forward or inverse transform.<\/span> <\/span><\/td>\n<\/tr>\n
8<\/span> <\/span><\/td>\nFFT_65536<\/span> <\/span><\/td>\n65,536-point fast Fourier transform (FFT) block with selectable forward or inverse transform and configurable output scaling.<\/span> <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

1. <\/span><\/span>AddSubtract_16<\/span><\/span> <\/span><\/h2>\n

The <\/span><\/span>AddSubtract_16<\/span><\/span> module implements a dynamically configurable arithmetic unit capable of performing either addition or subtraction on two signed 16-bit inputs. Its operation is governed by the following logic:<\/span><\/span><\/p>\n

 <\/p>\n

$latex S =left{ begin{array}{rl}
\nA + B text{(add: HIGH)} \\
\nA – B text{(add: LOW)}
\nend{array} right.$<\/p>\n

The input and output ports of the <\/span><\/span>AddSubtract_16<\/span><\/span> core are detailed in Table 2.<\/span> Both input buses (A and B) and the output (S) are treated as signed 16-bit integers (int16). The arithmetic operation is controlled by the <\/span><\/span>add<\/span><\/span> signal, while the <\/span><\/span>ce<\/span><\/span> (clock enable) signal enables or disables the <\/span><\/span>clock<\/span><\/span> of the <\/span>module. When <\/span><\/span>ce<\/span><\/span> is held high, the module remains continuously active.<\/span><\/span> <\/span><\/p>\n

Table 2: Port definitions for the AddSubtract_16 module, detailing its input and output signal interfaces.<\/p>\n\n\n\n\n\n\n\n\n\n
\n

Name<\/p>\n<\/td>\n

Direction<\/td>\nDescription<\/td>\n<\/tr>\n
A[15:0]<\/td>\nInput<\/td>\nInput A bus.<\/td>\n<\/tr>\n
B[15:0]<\/td>\nInput<\/td>\nInput B bus.<\/td>\n<\/tr>\n
clk<\/td>\nInput<\/td>\nClock signal, rising edge.<\/td>\n<\/tr>\n
add<\/td>\nInput<\/td>\nControls the operation performed by AddSubtract_16.<\/p>\n

(HIGH = Addition, LOW=subtraction)<\/td>\n<\/tr>\n

ce<\/td>\nInput<\/td>\nActive-HIGH clock enable. Set to constant high.<\/td>\n<\/tr>\n
S[15:0]<\/td>\nOutput<\/td>\nOutput bus.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Code 1 provides a VHDL example demonstrating<\/span> how to instantiate<\/span> the module and control using the 0th bit<\/span> (least significant bit, LSB)<\/span> of Control0. <\/span>The Multi-Instrument Mode configuration is illustrated in Figure 1. Test results shown in Figures 2 and 3,<\/span> conducted using <\/span>Moku hardware<\/span>,<\/span> confirm correct subtraction and addition behavior under varying signal conditions.<\/span><\/span> <\/span><\/span><\/p>\n

 <\/p>\n

Code <\/span><\/span>1<\/span><\/span><\/span>: <\/span>The VHDL example demonstrates the instantiation of the AddSubtract_16 module, where <\/span>OutputA<\/span> represents the result of either <\/span>InputA<\/span> + <\/span>InputB<\/span> or <\/span>InputA<\/span> – <\/span>InputB<\/span>, depending on the state of the <\/span>LSB<\/span> of the Control0 register.<\/span><\/span> <\/span><\/p>\n

LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioral OF CustomWrapper IS\r\n\r\n\tSIGNAL s_temp : STD_LOGIC_VECTOR(15 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tAddSubtract : AddSubtract_16\r\n\tPORT MAP(\r\n\t\tA => STD_LOGIC_VECTOR(InputA),\r\n\t\tB => STD_LOGIC_VECTOR(InputB),\r\n\t\tclk => clk,\r\n\t\t-- use Control0's 0th bit to control the operation\r\n\t\tadd => Control0(0),\r\n\t\t-- constant high clock enable\r\n\t\tce => '1',\r\n\t\tS => s_temp\r\n\t);\r\n\r\n\tOutputA <= signed(s_temp);\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
\"\"<\/p>\n
Figure <\/span><\/span>1<\/span><\/span><\/span>: <\/span>Test configuration for the AddSubtract_16 using <\/span>M<\/span>ulti-Instrument Mode<\/span>. In this setup, <\/span>InputA<\/span> and <\/span>InputB<\/span> of Moku Cloud Compile <\/span>are internally routed from the outputs of the <\/span>Moku <\/span>Oscilloscope, while the processed output from <\/span>M<\/span>oku Cloud Compile<\/span> is fed back into the Oscillo<\/span>scope.<\/span><\/span><\/p>\n
As shown in Figure 2,<\/span> t<\/span>he two-channel <\/span>embedded <\/span>waveform generators<\/span> in the <\/span>Moku <\/span>Oscilloscope<\/span> are configured to produce a 5<\/span><\/span>\u202f<\/span><\/span>kHz, 500<\/span><\/span>\u202f<\/span><\/span>mV sine wave and a 100<\/span><\/span>\u202f<\/span><\/span>Hz, 5<\/span><\/span>\u202f<\/span><\/span>V<\/span>pp<\/span> ramp signal with 90% <\/span>symmetry<\/span>. With the <\/span>LSB<\/span> of Control0 set to 0, M<\/span>oku Cloud Compile<\/span> operates in subtraction mode. The observed output on the <\/span><\/span>Moku <\/span>Oscilloscope<\/span><\/span><\/a> confirms the expected subtractor behavior.<\/span> Subsequently, <\/span>i<\/span>n Figure 3,<\/span> the <\/span>LSB<\/span> of Control0 is set to 1, configuring M<\/span>oku Cloud Compile<\/span> to perform addition. The resulting output confirms the expected adder functionality.<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>2<\/span><\/span><\/span>: M<\/span>oku Cloud Compile <\/span>outputs subtracted results using two input signals: a 500<\/span><\/span>\u202f<\/span><\/span>mVpp<\/span>, 5<\/span><\/span>\u202f<\/span><\/span>kHz sine wave and a 5<\/span><\/span>\u202f<\/span><\/span>Vpp<\/span>, 100<\/span><\/span>\u202f<\/span><\/span>Hz ramp wave. With Control0(0) set to 0, the system is configured to operate in subtraction mode.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>3<\/span><\/span><\/span>: <\/span>Moku <\/span>Cloud Compile output in response to a 500<\/span><\/span>\u202f<\/span><\/span>mV<\/span>pp<\/span> 5<\/span><\/span>\u202f<\/span><\/span>kHz sine wave and a 5<\/span><\/span>\u202f<\/span><\/span>Vpp<\/span>,<\/span> 100<\/span><\/span>\u202f<\/span><\/span>Hz ramp wave. With Control0(0) set to 1, the system is configured for addition mode.<\/span><\/span> <\/span><\/p>\n
It is important to note that the <\/span><\/span>AddSubtract_16<\/span><\/span> module does not include a carry-out mechanism and may therefore experience overflow during arithmetic operations. Specifically, if the sum of Input A + Input B exceeds the signed 16-bit range \\([-2^{15}, 2^{15}]\\) , the output may exhibit a sign inversion due to overflow.<\/span><\/span><\/span><\/span><\/p>\n
A common method for detecting potential overflow involves monitoring the most significant bit (MSB) of the operands and the result. No overflow occurs if the inputs have opposite signs. However, if both inputs share the same sign and the output sign differs, this typically indicates an overflow condition. While this paper acknowledges the issue, a detailed discussion of overflow detection and mitigation techniques is beyond its current scope.<\/span> <\/span><\/p>\n
The input sources are configured as a 5<\/span>\u202f<\/span>Vpp sine wave and a 5<\/span>\u202f<\/span>V DC signal. Theoretically, this combination should produce an output waveform ranging from 2.5<\/span>\u202f<\/span>V to 7.5<\/span>\u202f<\/span>V. However, the Moku:Go hardware is limited to a \u00b15<\/span>\u202f<\/span>V input\/output range (10<\/span>\u202f<\/span>Vpp). As a result, any portion of the output that exceeds this range will experience a sign inversion due to overflow. This behavior is illustrated in Figure 4, where the portions of the waveform that should lie between 5<\/span>\u202f<\/span>V and 7.5<\/span>\u202f<\/span>V are instead wrapped around and appear between \u22122.5<\/span>\u202f<\/span>V and \u22125<\/span>\u202f<\/span>V.<\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>4<\/span><\/span><\/span>: <\/span>The addition of a 5<\/span><\/span>\u202f<\/span><\/span>Vpp<\/span>, <\/span>1<\/span><\/span>\u202f<\/span><\/span>kHz sine wave and a 5<\/span><\/span>\u202f<\/span><\/span>V DC offset results in observable overflow, as the signal exceeds the <\/span>\u00b1<\/span>5<\/span><\/span>\u202f<\/span><\/span>V input range of the <\/span>Moku:Go<\/span> device. With Control0(0) set to 1, the system operates in addition mode, and a sign inversion in the output confirms the occurrence of overflow.<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
2. CIC_Dec_3Ordx8<\/span><\/h2>\n
The <\/span>CIC_Dec_3Ordx8<\/span> module implements a 3rd-order Cascaded Integrator-Comb (CIC) decimation filter with a fixed decimation rate of 8. CIC filters are widely used in multi-rate systems where a high sampling rate needs to be reduced. The architecture relies solely on adders, subtractors, and delays, making it ideal for hardware-efficient downsampling applications such as digital receivers and lock-in amplifiers.<\/span> <\/span><\/p>\n
The input and output ports of the module are summarized in Table 3, while the implementation details such as latency and filter order are provided in Table 4. The module accepts 16-bit signed input samples and produces 25-bit signed output samples. The input interface provides handshake signals (tvalid, tready) for both input and output channels. The filter updates its output only when valid input is received, and the core is ready.<\/span> <\/span><\/p>\n
Table <\/span><\/span>3<\/span><\/span><\/span>: <\/span>Port descriptions for the <\/span><\/span>CIC_Dec_3Ordx8<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n\n\n
Name<\/span><\/b> <\/span><\/td>\nDirection<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
aclk<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nClock signal, rising edge.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tdata [15:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nTDATA for the Data Input Channel. Carries the unprocessed sample data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nTVALID for the Data Input Channel. Used by the external block to signal that it is able to provide data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nTREADY for the Data Input Channel. Used by the CIC decimator to signal that it is ready to accept data.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tdata [24:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nTDATA for the Data Output Channel. Carries the processed sample data.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tvalid<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\n\n
TVALID for the Data Output Channel. Asserted by the CIC decimator to signal that it is able to provide sample data.<\/span> <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
Table <\/span><\/span>4<\/span><\/span><\/span>: <\/span>Configuration parameters of the <\/span><\/span>CIC_Dec_3Ordx8<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
\n
Component Name<\/span> <\/span><\/p>\n<\/td>\n
CIC_Dec_3Ordx8<\/span> <\/span><\/td>\n<\/tr>\n
Filter Type<\/span> <\/span><\/td>\nDecimation<\/span> <\/span><\/td>\n<\/tr>\n
Number of Stages<\/span> <\/span><\/td>\n3<\/span> <\/span><\/td>\n<\/tr>\n
Differential Delay<\/span> <\/span><\/td>\n1<\/span> <\/span><\/td>\n<\/tr>\n
Rate Supported<\/span> <\/span><\/td>\n8<\/span> <\/span><\/td>\n<\/tr>\n
Input Sample Frequency (MSa\/s)<\/span> <\/span><\/td>\n31.25<\/span> <\/span><\/td>\n<\/tr>\n
Clock Frequency (MHz)<\/span> <\/span><\/td>\n31.25<\/span> <\/span><\/td>\n<\/tr>\n
Input Data Width<\/span> <\/span><\/td>\n16<\/span> <\/span><\/td>\n<\/tr>\n
Output Data Width<\/span> <\/span><\/td>\n25<\/span> <\/span><\/td>\n<\/tr>\n
Latency<\/span> <\/span><\/td>\n\n
15<\/span> <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
In the provided VHDL example<\/span> shown in Code 2<\/span>, input data is written only when the core is ready (<\/span><\/span>s_axis_data_tready<\/span><\/span> is high), and output is captured only when valid data is available (<\/span><\/span>m_axis_data_tvalid<\/span><\/span> is high). The output is scaled by truncating to the most significant 16 bits to maintain consistency with the input dynamic range.<\/span> It is important to note that the valid signal must be asserted, and the output should be updated only when this signal is high. Otherwise, the output may exhibit pulsed or intermittent behavior rather than a continuous stream. This occurs because the <\/span><\/span>CIC_Dec_3Ordx8<\/span><\/span> generates a single valid output sample for every eight clock cycles, in accordance with its decimation factor.<\/span><\/span> <\/span><\/p>\n
Code <\/span><\/span>2<\/span><\/span><\/span>: <\/span>VHDL example demonstrating the instantiation of a CIC decimator with an 8<\/span>x<\/span> decimation factor. The signal <\/span>OutputA<\/span> represents the <\/span>downsampled<\/span> version of the signal <\/span>InputA<\/span>.<\/span><\/span> <\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioral OF CustomWrapper IS\r\n\r\n\tSIGNAL s_axis_data_tready : STD_LOGIC;\r\n\tSIGNAL s_axis_data_tdata : STD_LOGIC_VECTOR(15 DOWNTO 0);\r\n\r\n\tSIGNAL m_axis_data_tvalid : STD_LOGIC;\r\n\tSIGNAL m_axis_data_tdata : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tDecimator : CIC_Dec_3Ordx8\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\ts_axis_data_tdata => s_axis_data_tdata,\r\n\t\ts_axis_data_tvalid => '1', -- always output\r\n\t\ts_axis_data_tready => s_axis_data_tready,\r\n\t\tm_axis_data_tdata => m_axis_data_tdata,\r\n\t\tm_axis_data_tvalid => m_axis_data_tvalid\r\n\t);\r\n\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\t-- update input data when CIC is ready\r\n\t\t\tIF s_axis_data_tready THEN\r\n\t\t\t\ts_axis_data_tdata <= STD_LOGIC_VECTOR(InputA);\r\n\t\t\tELSE\r\n\t\t\t\ts_axis_data_tdata <= (OTHERS => '0');\r\n\t\t\tEND IF;\r\n\r\n\t\t\t-- update Output only when data is valid\r\n\t\t\tIF m_axis_data_tvalid THEN\r\n\t\t\t\t-- Scale data correctly\r\n\t\t\t\tOutputA <= signed(m_axis_data_tdata(24 DOWNTO 9));\r\n\t\t\tEND IF;\r\n\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
A M<\/span>ulti-Instrument Mode<\/span> test setup uses the <\/span><\/span>Moku <\/span>Frequency Response Analyzer<\/span><\/span><\/a> to evaluate the filter\u2019s frequency response is shown in Figure 5. <\/span>The frequency response of the CIC filter is of particular interest, as it characterizes the attenuation of out-of-band signals<\/span> and reflects its effectiveness in suppressing aliasing noise during decimation.<\/span> Measured results<\/span> in Figure 6 and Figure 7<\/span> show good alignment with theoretical expectations, accounting for expected discrepancies due to decimation and interpolation artifacts.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>5<\/span><\/span><\/span>:<\/span><\/span> M<\/span>ulti-Instrument Mode<\/span> test configuration in which the M<\/span>oku Cloud Compile <\/span>output is analyzed using <\/span>the Moku<\/span> Frequency Response Analyzer.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure 6: Frequency response of the CIC_Dec_3Ordx8 IP core as obtained using the Moku Frequency Response Analyzer.<\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>7<\/span><\/span><\/span>: <\/span>Comparison between the simulated and <\/span>implemented<\/span> responses of the <\/span><\/span>CIC_Dec_3Ordx8<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n
3. Cordic_Translate_16<\/span><\/h2>\n
The CORDIC core implements the Coordinate Rotation Digital Computer (CORDIC) algorithm, an iterative method used to compute trigonometric functions and, more generally, to solve equations involving hyperbolic and square root operations. The input and output port descriptions are provided in Table 5. This <\/span>Cordic_Translate_16<\/span> core transforms input signals from their Cartesian representation (real and imaginary components) into their corresponding polar form (amplitude and phase). The total computational latency of the module is 20 clock cycles.<\/span> <\/span><\/p>\n
 <\/p>\n
Table <\/span><\/span>5<\/span><\/span><\/span>: Port definitions of <\/span><\/span>Cordic_Translate_16<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n\n
\n
Name<\/span><\/b> <\/span><\/p>\n<\/td>\n
Direction<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
aclk<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nClock. Active rising edge.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_cartesian_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nHandshake signal for channel S_AXIS_CARTESIAN.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_cartesian_tdata [31:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nDepending on Functional Configuration, this port has one or two subfields.<\/span> <\/span><\/p>\n
X_IN and Y_IN, X_IN is [15:0] and Y_IN is [31:16]. These are the Cartesian operands. <\/span> <\/span><\/p>\n
Each subfield is 16-bit wide. X_IN and Y_IN both have 14 fractional bits and 2 integer bits.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_dout_tvalid<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nHandshake signal for output channel.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_dout_tdata [31:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\n\n
Depending on Functional Configuration this port contains the following subfields. AMPLITUDE_OUT, PHASE_OUT. <\/span> <\/span><\/p>\n
AMPLITUDE_OUT is [15:0] and PHASE_OUT is [31:16].<\/span> <\/span><\/p>\n
Each subfield is 16-bit wide. AMPLITUDE_OUT has 14 fractional bits and 2 integer bits. PHASE_OUT has 13 fractional bits and 3 integer bits with a unit of radians.<\/span> <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
The <\/span><\/span>Cordic_Translate_16<\/span><\/span> IP core can be instantiated using Code 3, which converts the imaginary (<\/span>InputA<\/span>) and real (<\/span>InputB<\/span>) components of a signal into their corresponding amplitude (<\/span>OutputA<\/span>) and phase angle (<\/span>OutputB<\/span>).<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
Code <\/span><\/span>3<\/span><\/span><\/span>: VHDL implementation example demonstrating the instantiation of a <\/span><\/span>Cordic_Translate_16<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioral OF CustomWrapper IS\r\n\r\n\tSIGNAL m_axis_dout_tvalid : STD_LOGIC;\r\n\tSIGNAL tdata_temp : signed(31 DOWNTO 0);\r\n\r\nBEGIN\r\n\tCordic : Cordic_Translate_16\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\t-- input is always valid\r\n\t\ts_axis_cartesian_tvalid => '1',\r\n\t\t-- InputA : imaginary part\r\n\t\t-- InputB : real part\r\n\t\ts_axis_cartesian_tdata => STD_LOGIC_VECTOR(InputA & InputB),\r\n\t\tm_axis_dout_tvalid => m_axis_dout_tvalid,\r\n\t\tm_axis_dout_tdata => tdata_temp\r\n\t);\r\n\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF m_axis_dout_tvalid THEN\r\n\t\t\t\tOutputA <= signed(tdata_temp(15 DOWNTO 0));\r\n\t\t\t\tOutputB <= signed(tdata_temp(31 DOWNTO 16));\r\n\t\t\tEND IF;\r\n\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
The instantiated <\/span>Cordic_Translate_16 <\/span>is tested using the Multi-Instrument Mode setup shown in Figure 8. Moku Cloud Compile InputA (imaginary) and InputB (real) are internally routed from the Moku Oscilloscope outputs to Moku Cloud Compile, which computes the corresponding amplitude and phase outputs. These Moku Cloud Compile outputs are then routed back to the Oscilloscope for visualization and analysis.<\/span> <\/span><\/p>\n
The results are shown in Figure 9. The blue trace reaches a peak value of 3.9288<\/span> V, corresponding to approximately 3.1415 radians. Since the phase output is represented with 13 fractional bits, the resolution is <\/span>2^13 LSBs\/rad. To convert the digital values into physical units, the digital resolution of Moku Cloud Compile must be determined and can be found <\/span>here<\/span><\/a>. Given a digital resolution of 6550.4<\/span> LSBs\/V on Moku:Go, the radian value is calculated as:<\/span><\/p>\n
\\(frac{text{3.9288 V} times text{6550.4 LSBs\/V}}{2^{13}  text{LSBs\/rad}}=text{3.1415 rad}\\)<\/p>\n
Furthermore, the amplitude output increases in magnitude by a factor of approximately 1.1644 due to the accumulation of scaling effects introduced during the 20 iterations performed by the <\/span><\/span>Cordic_Translate_16<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>8<\/span><\/span><\/span>:<\/span> M<\/span>ulti-Instrument Mode<\/span> test setup for testing <\/span><\/span>Cordic_Translate_16<\/span> <\/span>IP core.<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>9<\/span><\/span><\/span>:<\/span> Two <\/span>output<\/span> channels are configured with 100<\/span><\/span>\u202f<\/span><\/span>Hz sine waves at 5<\/span><\/span>\u202f<\/span><\/span>Vpp<\/span> offset by a 90<\/span>\u00b0<\/span> phase shift to emulate a continuously rotating complex vector. <\/span>InputA<\/span> (red trace) represents the amplitude, while <\/span>InputB<\/span> (blue trace) corresponds to the phase. As expected, the amplitude remains constant while the phase increases linearly over time<\/span>, wrapping every 2<\/span><\/span>\ud835\udf0b<\/span><\/span> radians<\/span>.<\/span><\/span> <\/span><\/p>\n
4. Counter_32<\/span><\/h2>\n
The <\/span>Counter_32<\/span> IP core offers counter implementations utilizing lookup tables (LUTs) and single DSP slices. The input and output port functions are described in Table 6. It supports up\/down counting modes with output widths of 32 bits. The counter increments by one on each clock cycle and can be synchronously cleared by pulling the <\/span>SCLR<\/span> signal high.<\/span> <\/span><\/p>\n
Table <\/span><\/span>6<\/span><\/span><\/span>: Port definitions of<\/span><\/span> Counter_32<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n
Name<\/span><\/b> <\/span><\/td>\nDirection<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
CLK<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nRising edge clock signal.<\/span> <\/span><\/td>\n<\/tr>\n
SCLR<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nSynchronous Clear: forces the output to a low state when driven high.<\/span> <\/span><\/td>\n<\/tr>\n
UP<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nControls the count direction on an up\/down counter. Counts up when high, down when low.<\/span> <\/span><\/td>\n<\/tr>\n
Q [31:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\n\n
Counter output. 32-bit wide.<\/span> <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
The example<\/span> in Code 4<\/span> implements two <\/span><\/span>Counter_32<\/span><\/span> functions<\/span>: one configured for bidirectional counting to generate a triangular waveform, and the other for unidirectional counting to produce a sawtooth waveform. Only the least significant 16 bits of the counters are connected to the outputs, as the design operates within a range below 65,536.<\/span><\/span> <\/span><\/span><\/p>\n
Code <\/span><\/span>4<\/span><\/span><\/span>: <\/span>VHDL example instantiating two <\/span><\/span>Counter_32 <\/span><\/span>for triangular and sawtooth waveforms.<\/span><\/span> <\/span><\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioural OF CustomWrapper IS\r\n\r\n\tSIGNAL sclr_triangular : STD_LOGIC;\r\n\tSIGNAL sclr_sawtooth : STD_LOGIC;\r\n\r\n\tSIGNAL up_triangular : STD_LOGIC;\r\n\tSIGNAL up_sawtooth : STD_LOGIC;\r\n\r\n\tSIGNAL q_triangular : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\tSIGNAL q_sawtooth : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\t-- Triangular wave\r\n\tTriangular : Counter_32\r\n\tPORT MAP(\r\n\t\tclk => clk,\r\n\t\t-- synchronous clear\r\n\t\tsclr => sclr_triangular,\r\n\t\tup => up_triangular,\r\n\t\tq => q_triangular\r\n\t);\r\n\tOutputA <= signed(q_triangular(15 DOWNTO 0));\r\n\r\n\t-- Triangular counter configuration\r\n\tPROCESS (clk) IS\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\t\t\t-- reset\r\n\t\t\tIF Control0(0) = '1' THEN\r\n\t\t\t\tsclr_triangular <= '1';\r\n\t\t\t\tup_triangular <= '1';\r\n\t\t\tELSE\r\n\t\t\t\t-- don't clear \r\n\t\t\t\tsclr_triangular <= '0';\r\n\t\t\t\t-- Control1: counter limit\r\n\t\t\t\tIF q_triangular = Control1 THEN\r\n\t\t\t\t\t-- count down\r\n\t\t\t\t\tup_triangular <= '0';\r\n\t\t\t\tELSIF q_triangular = x\"00000000\" THEN\r\n\t\t\t\t\t-- count up\r\n\t\t\t\t\tup_triangular <= '1';\r\n\t\t\t\tELSE\r\n\t\t\t\t\t-- hold\r\n\t\t\t\t\tup_triangular <= up_triangular; END IF; END IF; END IF; END PROCESS; Sawtooth : Counter_32 PORT MAP( clk => clk,\r\n\t\tsclr => sclr_sawtooth, -- synchronous clear\r\n\t\tup => up_sawtooth,\r\n\t\tq => q_sawtooth\r\n\t);\r\n\tOutputB <= signed(q_sawtooth(15 DOWNTO 0));\r\n\r\n\t-- Sawtooth counter configuration\r\n\tPROCESS (clk) IS\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\t\t\t-- reset\r\n\t\t\tIF Control0(0) = '1' THEN\r\n\t\t\t\tsclr_sawtooth <= '1';\r\n\t\t\t\tup_sawtooth <= '1';\r\n\t\t\tELSE\r\n\t\t\t\t-- always count up\r\n\t\t\t\tup_sawtooth <= '1';\r\n\t\t\t\t-- Control2 : counter limit\r\n\t\t\t\tIF q_sawtooth = Control2 THEN\r\n\t\t\t\t\t-- clear\r\n\t\t\t\t\tsclr_sawtooth <= '1';\r\n\t\t\t\tELSE\r\n\t\t\t\t\t-- continue counting\r\n\t\t\t\t\tsclr_sawtooth <= '0';\r\n\t\t\t\tEND IF;\r\n\t\t\tEND IF;\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
The Multi-Instrument Mode configuration is illustrated in Figure 10. The Moku Oscilloscope is employed to visualize the waveforms generated by two <\/span>Counter_32<\/span> modules. Both counters are configured with control values of 6,550 through Control1 and Control2, resulting in a peak output of approximately 1<\/span>\u202f<\/span>V, based on the Moku:Go digital resolution of 6550.4<\/span>\u202f<\/span>LSBs\/V. The LSB of Control0 functions as a reset signal and must be set to high and back to low prior to operation. As expected, the sawtooth waveform has twice the frequency of the triangular waveform, since it counts only upward, while the triangular waveform alternates between upward and downward counting cycles.<\/span> <\/span><\/p>\n
The test results are presented in Figure 11. The red trace represents the triangular waveform, generated by alternating up and down counting. The blue trace corresponds to the sawtooth waveform, which increments continuously and resets upon reaching the configured limit of 6,550.<\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>10<\/span><\/span><\/span>: M<\/span>ulti-Instrument Mode<\/span> configuration for testing <\/span><\/span>Counter_32<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>11<\/span><\/span><\/span>: <\/span>Configuration of M<\/span>oku Cloud Compile<\/span> control registers and corresponding outputs of the two <\/span><\/span>Counter_32<\/span><\/span> modules.<\/span><\/span> <\/span><\/p>\n
5. <\/span>SineGen_48<\/span><\/h2>\n
The <\/span>SineGen_48<\/span> IP core generates high-resolution, low-distortion sine waveforms. Its input and output ports are detailed in Table 7. It accepts a 48-bit frequency step input and produces both 16-bit sine and cosine outputs through a 32-bit output port. This module serves as a sine waveform generator subblock suitable for a range of advanced applications, including phase-locked loops and simultaneous amplitude and frequency modulation (AM and FM).<\/span> <\/span><\/p>\n
Since the <\/span><\/span>SineGen_48<\/span><\/span> IP core<\/span> requires a 48-bit frequency step input, and M<\/span>oku Cloud Compile<\/span> control registers are limited to 32 bits, two registers must be combined to form the full 48-bit input. For example, in Code 5, the least significant 16 bits of Control2 are concatenated with the 32 bits of Control1 to construct the complete frequency control word. The generated output is divided into two 16-bit components, corresponding to the sine and cosine waveforms, which are routed to <\/span>OutputA<\/span> and <\/span>OutputB<\/span>, respectively. Additionally, the most significant 16 bits of the internal phase counter are directed to <\/span>OutputC<\/span>.<\/span><\/span> <\/span><\/p>\n
Code <\/span><\/span>5<\/span><\/span><\/span>: VHDL instantiation example of <\/span><\/span>SineGen_48<\/span><\/span>.<\/span><\/span><\/p>\n
 <\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioural OF CustomWrapper IS\r\n\r\n\tSIGNAL m_axis_data_tvalid : STD_LOGIC;\r\n\tSIGNAL m_axis_phase_tvalid : STD_LOGIC;\r\n\tSIGNAL sine_temp : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\tSIGNAL m_axis_phase_tdata : STD_LOGIC_VECTOR(47 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tSineCosineGen : SineGen_48\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\t-- Use the 0th bit of Control0 to reset this module\r\n\t\taresetn => NOT Control0(0),\r\n\t\t-- input signal is always available\r\n\t\ts_axis_config_tvalid => '1',\r\n\t\t-- 48-bit frequency step\r\n\t\ts_axis_config_tdata => Control2(15 DOWNTO 0) & Control1,\r\n\r\n\t\tm_axis_data_tvalid => m_axis_data_tvalid,\r\n\t\tm_axis_data_tdata => sine_temp,\r\n\r\n\t\tm_axis_phase_tvalid => m_axis_phase_tvalid,\r\n\t\tm_axis_phase_tdata => m_axis_phase_tdata -- 48-bit phase counter output\r\n\t);\r\n\r\n\t-- only output data when data is valid\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF m_axis_data_tvalid THEN\r\n\t\t\t\t-- 32-bit, the most significant 16 bits are sine\r\n\t\t\t\t-- and the least significant 16 bits are cosine\r\n\t\t\t\tOutputA <= signed(sine_temp(15 DOWNTO 0));\r\n\t\t\t\tOutputB <= signed(sine_temp(31 DOWNTO 16));\r\n\t\t\tEND IF;\r\n\r\n\t\t\tIF m_axis_phase_tvalid THEN\r\n\t\t\t\tOutputC <= signed(m_axis_phase_tdata(47 DOWNTO 32));\r\n\t\t\tEND IF;\r\n\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
The <\/span>M<\/span>ulti-Instrument Mode<\/span> configuration for testing the <\/span><\/span>SineGen_48<\/span><\/span> IP core is shown in Figure 12. The frequency step is set to 3.125<\/span><\/span>\u202f<\/span><\/span>kHz by configuring Control1 to 2,374,548,092 and Control2 to 6. The full 48-bit frequency control word is calculated as:<\/span><\/span> <\/span><\/p>\n
\\(text{Frequency step} = text{Control 2} times 2^{32} + text{Control 1} = 2,814,749,767\\)<\/p>\n
And the frequency in the unit of Hz can be calculated as:<\/span><\/span> <\/span><\/p>\n
\\(text{Frequency} = frac{text{clock rate}}{2^{48}}times [text{Control 2} times 2^{32} + text{Control 1}]\\)<\/p>\n
Given that the <\/span>Moku:Go<\/span> clock rate is 31.25 MHz, the output frequency becomes 3.125 kHz.<\/span><\/span> <\/span><\/p>\n
\"\"<\/h2>\n
Figure <\/span><\/span>12<\/span><\/span><\/span>: M<\/span>ulti-Instrument Mode<\/span> configuration for testing <\/span><\/span>SineGen_48<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n
Figure 13 displays the output of the <\/span><\/span>SineGen_48<\/span><\/span> IP core, where Channel A (red) represents the cosine waveform and Channel B (blue) represents the sine waveform. The measured phase difference between the two signals is 90<\/span>\u00b0<\/span>, as expected. Additionally, Figure 14 illustrates the behavior of the phase counter routed to <\/span>OutputC<\/span> of M<\/span>oku Cloud Compile<\/span>. The output shows a continuously increasing ramp, confirming that the phase signal advances at the same frequency as the generated cosine waveform.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>13<\/span><\/span><\/span>: <\/span>Sine and cosine waveforms visualized using the <\/span>Moku <\/span>Oscilloscope. Channel A (red) displays the cosine signal, while Channel B (blue) shows the sine signal. The frequency step is configured with Control1 set to 2,374,548,092 and Control2 set to 6.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>14<\/span><\/span><\/span>: <\/span>The <\/span>Moku <\/span>Oscilloscope inputs are connected to <\/span>OutputA<\/span> and <\/span>OutputC<\/span> of <\/span>Moku Cloud Compile.<\/span> The blue trace represents the most significant 16 bits of the phase counter output.<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
6. <\/span>FIR_Filter_7coef <\/span><\/h2>\n
The <\/span>FIR_Filter_7coef<\/span> IP core operates at the full clock rate with fixed coefficients, offering a resource-efficient solution for users who need to integrate a low-pass filter into their Moku Cloud Compile designs without requiring additional instruments in the Multi-Instrument Mode setup. The filter coefficients are listed in Table 8, and the port definitions are provided in Table 9. <\/span> <\/span><\/p>\n
For applications requiring adjustable coefficients, users can either use the <\/span>Moku FIR Filter Builder<\/span><\/a> or recompile a custom FIR filter IP core by following the guidelines in the <\/span>Customized IP cores<\/span><\/b> section in this paper.<\/span> <\/span><\/p>\n
Table <\/span><\/span>8<\/span><\/span><\/span>: Coefficients <\/span>used in<\/span> <\/span>FIR_Filter_7coef<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Table <\/span><\/span>9<\/span><\/span><\/span>: Port definitions of <\/span><\/span>FIR_Filter_7coef<\/span><\/span>.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n\n\n\n
Name<\/span><\/b> <\/span><\/td>\nDirection<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
aclk<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nRising-edge clock.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntvalid for input data channel. Asserted by external block to indicate data is available for transfer.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntready for input data channel. Asserted by core to indicate core is ready to accept data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tdata [15:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntdata for input data channel. Conveys the data stream to be filtered. See tdata Structure for internal structure<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tvalid<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntvalid for output data channel. Asserted by core to indicate data is available for transfer.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tdata [23:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntdata for the output data channel. This is the filtered data stream. See tdata Structure for internal structure.<\/span> <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The VHDL instantiation of the <\/span><\/span>FIR_Filter_7coef<\/span><\/span> IP core is provided in Code 6. In this example, handshake signals are omitted, as the filter is designed to process continuous input data and produce a continuous output stream. To ensure proper output scaling, the most significant 16 bits of the filter output are routed to <\/span>OutputA<\/span>.<\/span><\/span> <\/span><\/p>\n
This application note examines the implementation of a dual boxcar averager, outlining its core structure, which comprises four single boxcar averagers group<\/p>\n
Code <\/span><\/span>6<\/span><\/span><\/span>: VHDL example of instantiating the <\/span><\/span>FIR_Filter_7coef<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioural OF CustomWrapper IS\r\n\r\n\tSIGNAL FIR_out_temp : STD_LOGIC_VECTOR(23 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tFIR_Filter : FIR_Filter_7coef\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\t-- input data is always valid\r\n\t\ts_axis_data_tvalid => '1',\r\n\t\t-- FIR filter ready to accept data\r\n\t\ts_axis_data_tready => OPEN,\r\n\t\ts_axis_data_tdata => InputA,\r\n\r\n\t\t-- FIR filtered data is available to be transferred \r\n\t\tm_axis_data_tvalid => OPEN,\r\n\t\tm_axis_data_tdata => FIR_out_temp\r\n\t);\r\n\r\n\tOutputA <= signed(FIR_out_temp(23 DOWNTO 8));\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
The <\/span><\/span>FIR_Filter_7coef<\/span><\/span> M<\/span>ulti-Instrument Mode <\/span>test setup is shown in Figure 15. <\/span>The filter response, as measured by the <\/span>Moku <\/span>Frequency Response Analyzer, is presented in Figure 16. A comparison between the simulated response and the measured response is shown in Figure 17.<\/span><\/span> <\/span>\"\"<\/p>\n
Figure <\/span><\/span>15<\/span><\/span><\/span>: M<\/span>ulti-Instrument Mode<\/span> configuration of the <\/span><\/span>FIR_Filter_7coef<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>16<\/span><\/span><\/span>: Frequency response obtained using the <\/span>Moku <\/span>Frequency Response Analyzer.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>17<\/span><\/span><\/span>: <\/span>A comparison between the simulated response based on the <\/span>given FIR <\/span>coefficients and the measured frequency response.<\/span><\/span> <\/span><\/p>\n
7. <\/span>FFT_1024<\/span><\/h2>\n
The Fast Fourier Transform (FFT) IP core implements the Cooley-Tukey algorithm, an efficient technique for computing the Discrete Fourier Transform (DFT). It is well-suited for applications such as large-scale filtering, cross-correlation, and coarse frequency analysis. Table 10 provides the input and output definitions for <\/span>FFT_1024<\/span>. This section presents an example implementation of the FFT core.<\/span> <\/span><\/p>\n
 <\/p>\n
Table 10: Port definitions of the FFT_1024 IP core.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Name<\/span><\/b> <\/span><\/td>\nDirection<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
aclk<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nRising-edge clock.<\/span> <\/span><\/td>\n<\/tr>\n
aresetn<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nActive-Low synchronous clear (optional, always take priority over aclken). A minimum aresetn active pulse of two cycles is required.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tdata[7:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntdata for the Configuration channel. Carries the configuration information: CP_LEN, FWD\/INV, NFFT and SCALE_SCH.<\/span> <\/span><\/p>\n
Only the least significant bit (0th bit) is used to control the FWD\/INV (forward or inverse FFT). Other bits are empty.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntvalid for the Configuration channel. Asserted by the external block to signal that it is able to provide data. <\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntready for the Configuration channel. Asserted by the core to signal that it is ready to accept configuration data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tdata[31:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntdata for the Data Input channel. Carries the unprocessed sample data: real part is [15:0] and imaginary part is [31:16].<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntvalid for the Data Input channel. Used by the external block to signal that it is able to provide data. It can be set as constant high.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntready for the Data Input channel. Used by the core to signal that it is ready to accept data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tlast<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntlast for the Data Input channel. Asserted by the external block on the last sample of the frame. This is not used by the core except to generate the events event_tlast_unexpected and event_tlast_missing events<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tdata[63:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntdata for the Data Output channel. Carries the processed sample data real part is [58:32] and imaginary part is [26:0]. Signals are both signed 27-bit with 15 fractional bits.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tuser[15:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntuser for the Data Output channel. Carries the index of per-sample information.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tvalid<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntvalid for the Data Output channel. Asserted by the core to signal that it is able to provide sample data.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tready<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntready for the Data Output channel. Asserted by the external slave to signal that it is ready to accept data. <\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tlast<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntlast for the Data Output channel. Asserted by the core on the last sample of the frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_frame_started<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core starts to process a new frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_tlast_unexpected<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core sees s_axis_data_tlast High on a data sample that is not the last one in a frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_tlast_missing<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when s_axis_data_tlast is Low on the last data sample of a frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_status_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core tries to write data to the Status channel and it is unable to do so. <\/span> <\/span><\/td>\n<\/tr>\n
event_data_in_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core requests data from the Data Input channel and none is available.<\/span> <\/span><\/td>\n<\/tr>\n
event_data_out_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core tries to write data to the Data Output channel and it is unable to do so. <\/span> <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
The VHDL instantiation of the <\/span>FFT_1024<\/span> IP core is provided in Code 7. Since the input signal is purely real, only the least significant 16 bits of <\/span>s_axis_data_tdata<\/span> are connected to InputA, and the most significant 16 bits of both the real and imaginary components of the FFT output are connected to the inputs of the <\/span>Cordic_Translate_16<\/span> module, which computes the corresponding amplitude and phase.<\/span> <\/span><\/p>\n
In this example, the FFT is configured as a forward Fourier transform through hardcoded settings by setting LSB of <\/span>s_axis_config_tdata<\/span> to high. Event signals are deliberately left unconnected, as they are not utilized in this example. The end of each FFT frame is indicated by the <\/span>m_axis_data_tlast<\/span> signal, upon which the FFT core is reset to prepare for the next processing cycle.<\/span> <\/span><\/p>\n
To account for the 20-cycle processing latency of the <\/span>Cordic_Translate_16<\/span>, the FFT output index (<\/span>m_axis_data_tuser<\/span>) is delayed accordingly. The resulting amplitude, phase, and frequency bin index are routed to OutputA, OutputB, and OutputC, respectively.<\/span> <\/span><\/p>\n
Code <\/span><\/span>7<\/span><\/span><\/span>: <\/span>VHDL example demonstrating the instantiation of the <\/span><\/span>FFT_1024<\/span><\/span> IP core along with the <\/span><\/span>Cordic_Translate_16<\/span><\/span> module, used to convert the FFT output into corresponding amplitude and phase values.<\/span><\/span> <\/span><\/p>\n
LIBRARY IEEE;\r\nUSE IEEE.STD_LOGIC_1164.ALL;\r\nUSE IEEE.NUMERIC_STD.ALL;\r\n\r\nARCHITECTURE Behavioural OF CustomWrapper IS\r\n\r\n\tTYPE array_tuser IS ARRAY (0 TO 19) OF signed(15 DOWNTO 0);\r\n\r\n\tSIGNAL aresetn, aresetn_dly : STD_LOGIC;\r\n\r\n\tSIGNAL s_axis_data_tdata : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\tSIGNAL s_axis_data_tready : STD_LOGIC;\r\n\r\n\tSIGNAL m_axis_data_tlast : STD_LOGIC;\r\n\tSIGNAL m_axis_data_tvalid, m_axis_data_tvalid_dly : STD_LOGIC;\r\n\tSIGNAL m_axis_data_tuser : signed(15 DOWNTO 0);\r\n\tSIGNAL m_axis_data_tuser_dly : array_tuser;\r\n\r\n\tSIGNAL m_axis_dout_tvalid : STD_LOGIC;\r\n\tSIGNAL tdata_temp : signed(31 DOWNTO 0);\r\n\r\n\tSIGNAL im, real : STD_LOGIC_VECTOR(26 DOWNTO 0);\r\n\r\n\tSIGNAL fftdata_temp : STD_LOGIC_VECTOR(63 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tFFT_DUT : FFT_1024\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\taresetn => (NOT reset) AND aresetn AND aresetn_dly,\r\n\t\t-- Forward FFT with the LSB configured as 1\r\n\t\ts_axis_config_tdata => x\"01\",\r\n\t\t-- Config data is always valid\r\n\t\ts_axis_config_tvalid => '1',\r\n\t\t-- Leave config ready signal open\r\n\t\t-- config data is constant\r\n\t\ts_axis_config_tready => OPEN,\r\n\t\t-- Input only has real values\r\n\t\ts_axis_data_tdata => s_axis_data_tdata,\r\n\t\t-- Input data is always valid\r\n\t\ts_axis_data_tvalid => '1',\r\n\t\t-- Data ready logic\r\n\t\ts_axis_data_tready => s_axis_data_tready,\r\n\t\t-- Continuous data stream\r\n\t\t-- don't have last sample\r\n\t\ts_axis_data_tlast => '0',\r\n\r\n\t\t-- Transformed data\r\n\t\tm_axis_data_tdata => fftdata_temp,\r\n\t\t-- FFT frequency index\r\n\t\tm_axis_data_tuser => m_axis_data_tuser,\r\n\t\t-- output is valid\r\n\t\tm_axis_data_tvalid => m_axis_data_tvalid,\r\n\t\t-- Slave device is always ready to accept output\r\n\t\tm_axis_data_tready => '1',\r\n\t\t-- last sample of the frame\r\n\t\tm_axis_data_tlast => m_axis_data_tlast,\r\n\r\n\t\t-- don't care events\r\n\t\tevent_frame_started => OPEN,\r\n\t\tevent_tlast_unexpected => OPEN,\r\n\t\tevent_tlast_missing => OPEN,\r\n\t\tevent_status_channel_halt => OPEN,\r\n\t\tevent_data_in_channel_halt => OPEN,\r\n\t\tevent_data_out_channel_halt => OPEN\r\n\t);\r\n\r\n\t-- only output data when data is valid\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF s_axis_data_tready THEN\r\n\t\t\t\ts_axis_data_tdata <= x\"0000\" & STD_LOGIC_VECTOR(InputA);\r\n\t\t\tEND IF;\r\n\r\n\t\t\tIF m_axis_data_tvalid THEN\r\n\t\t\t\tim <= fftdata_temp(58 DOWNTO 32);\r\n\t\t\t\treal <= fftdata_temp(26 DOWNTO 0);\r\n\t\t\tEND IF;\r\n\t\t\tm_axis_data_tuser_dly <= m_axis_data_tuser & m_axis_data_tuser_dly(0 TO 18);\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\t-- reset process\r\n\t-- reset fft when the tlast is high\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(Clk) THEN\r\n\r\n\t\t\taresetn_dly <= aresetn;\r\n\t\t\tIF m_axis_data_tlast THEN\r\n\t\t\t\taresetn <= '0';\r\n\t\t\tELSE\r\n\t\t\t\taresetn <= '1'; END IF; END IF; END PROCESS; Cordic : Cordic_Translate_16 PORT MAP( aclk => clk,\r\n\t\ts_axis_cartesian_tvalid => m_axis_data_tvalid,\r\n\t\ts_axis_cartesian_tdata => STD_LOGIC_VECTOR(im(26 DOWNTO 11) & real(26 DOWNTO 11)),\r\n\t\tm_axis_dout_tvalid => m_axis_dout_tvalid,\r\n\t\tm_axis_dout_tdata => tdata_temp\r\n\t);\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF m_axis_dout_tvalid THEN\r\n\t\t\t\tOutputA <= signed(tdata_temp(15 DOWNTO 0));\r\n\t\t\t\tOutputB <= signed(tdata_temp(31 DOWNTO 16));\r\n\t\t\t\tOutputC <= signed(m_axis_data_tuser_dly(19));\r\n\t\t\tEND IF;\r\n\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
 <\/p>\n

\nThe Multi-Instrument Mode test configurations and corresponding output signals are shown in Figure 18 and Figure 19. Figure 18 illustrates the measurement setup for the amplitude output from the <\/span>FFT_1024<\/span> and <\/span>Cordic_Translate_16<\/span> IP cores, while Figure 19 shows the configuration for capturing the phase output.<\/span> <\/span><\/p>\n
In Figure 18, two peaks are visible in the amplitude spectrum, one in the positive frequency range and the other in the negative. The index associated with the positive frequency peak corresponds to a timestamp relative to the beginning of the index ramp. Given that the Moku:Go clock operates at 31.25 MHz and the total time span of the index ramp is 32.684 microseconds, the estimated frequency is calculated as:<\/span> <\/span><\/p>\n
\"\"<\/p>\n
\\(text{Frequency} = frac{text{10.531 } mu text{s}}{text{32.684 } mu text{s}} times text{31.25 MHz} = text{10.0689 MHz}\\)<\/p>\n
It is important to note that the 1024-point FFT results in a resolution bandwidth of approximately 0.03 MHz. Therefore, this implementation is suitable for coarse frequency estimation only. For more precise analysis, it is recommended to use the <\/span>Moku Phasemeter<\/span><\/a>.<\/span> <\/span><\/p>\n
Figure 19 displays the phase output in red. The phase appears unstable due to the variability of the FFT analysis window across acquisition cycles. This example serves as a functional demonstration but does not constitute a complete spectrum analyzer, as it lacks essential components such as a windowing function and a superheterodyne block.<\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>18<\/span><\/span><\/span>: M<\/span>ulti-Instrument Mode<\/span> test configuration and amplitude output results for the FFT_1024 IP core. A 10 <\/span>MHz<\/span> sine wave is applied to <\/span>InputA<\/span> of the M<\/span>oku Cloud Compile<\/span> and processed by the <\/span><\/span>FFT_1024<\/span><\/span> module. The resulting amplitude spectrum, displayed on Channel A (red), reveals two peaks corresponding to the positive and negative frequency components of the input signal.<\/span><\/span> <\/span><\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>19<\/span><\/span><\/span>: <\/span>M<\/span>ulti-Instrument Mode<\/span> test configuration and phase response of the <\/span><\/span>FFT_1024<\/span><\/span> IP core. The observed phase response appears unstable due to the random time offset of the FFT analysis window relative to the input signal.<\/span><\/span> <\/span><\/p>\n
8. <\/span>FFT_65536<\/span><\/h2>\n
FFT_65536<\/span> is a variant of <\/span>FFT_1024<\/span>, generated using the same IP core compiler but configured with a larger number of FFT points. Although both cores share the same foundation, <\/span>FFT_65536<\/span> has distinct configuration parameters and output data formats to accommodate the increased point count. Detailed port specifications and updated signal connections are provided in Table 11, with changes highlighted.<\/span> <\/span><\/p>\n
Due to hardware resource limitations, the <\/span>FFT_65536<\/span> IP core is not supported on Moku:Go or Moku:Lab and must be deployed on Moku:Pro.<\/span> <\/span><\/p>\n
 <\/p>\n
Table 11: Ports definitions of FFT_65536 IP core. The parameters different than the FFT_1024 are bolded.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Name<\/span><\/b> <\/span><\/td>\nDirection<\/span><\/b> <\/span><\/td>\nDescription<\/span><\/b> <\/span><\/td>\n<\/tr>\n
aclk<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nRising-edge clock.<\/span> <\/span><\/td>\n<\/tr>\n
aresetn<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\nActive-Low synchronous clear (optional, always take priority over aclken). A minimum aresetn active pulse of two cycles is required.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tdata[39:0]<\/span><\/b> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntdata for the Configuration channel. The 0th bit controls the forward or inverse FFT. And [32:1] is the scale of the output. Other bits are empty.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntvalid for the Configuration channel. <\/span> <\/span><\/td>\n<\/tr>\n
s_axis_config_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntready for the Configuration channel. <\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tdata[31:0]<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntdata for the Data Input channel. Carries the unprocessed sample data: real [15:0] and imaginary [31:16].<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tvalid<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntvalid for the Data Input channel. Set to constant high.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tready<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntready for the Data Input channel. Used by the core to signal that it is ready to accept data.<\/span> <\/span><\/td>\n<\/tr>\n
s_axis_data_tlast<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntlast for the Data Input channel. Asserted by the external master on the last sample of the frame. <\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tdata[31:0]<\/span><\/b> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntdata for the Data Output channel. Carries the processed sample data real [15:0] and imaginary [31:16]. The signal format is signed 16-bit with 15 fractional bits.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tuser[15:0]<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntuser for the Data Output channel. Carries the index of per-sample information.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tvalid<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntvalid for the Data Output channel. Asserted by the core to signal that it is able to provide sample data.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tready<\/span> <\/span><\/td>\nInput<\/span> <\/span><\/td>\ntready for the Data Output channel. Asserted by the external block to signal that it is ready to accept data.<\/span> <\/span><\/td>\n<\/tr>\n
m_axis_data_tlast<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\ntlast for the Data Output channel. Asserted by the core on the last sample of the frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_frame_started<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core starts to process a new frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_tlast_unexpected<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core sees s_axis_data_tlast High on a data sample that is not the last one in a frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_tlast_missing<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when s_axis_data_tlast is Low on the last data sample of a frame.<\/span> <\/span><\/td>\n<\/tr>\n
event_status_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core tries to write data to the Status channel and it is unable to do so. <\/span> <\/span><\/td>\n<\/tr>\n
event_data_in_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core requests data from the Data Input channel and none is available.<\/span> <\/span><\/td>\n<\/tr>\n
event_data_out_channel_halt<\/span> <\/span><\/td>\nOutput<\/span> <\/span><\/td>\nAsserted when the core tries to write data to the Data Output channel and it is unable to do so.<\/span> <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
The VHDL example for instantiating <\/span><\/span>FFT_65536<\/span><\/span> and one <\/span><\/span>Cordic_Translate_16<\/span><\/span> is shown in Code 8. The <\/span>M<\/span>oku Cloud Compile<\/span> outputs include the amplitude and phase spectra of <\/span>InputA<\/span>, along with the frequency index. Additionally, Control0 is used to set the scale parameter, and the LSB of Control1 determines the FFT direction.<\/span><\/span> <\/span><\/p>\n
Code <\/span><\/span>8<\/span><\/span><\/span>: <\/span>VHDL example demonstrating the instantiation of one <\/span><\/span>FFT_65536<\/span><\/span> and one <\/span><\/span>Cordic_Translate_16<\/span><\/span> module.<\/span><\/span> <\/span><\/p>\n
LIBRARY ieee;\r\n\r\nARCHITECTURE Behavioural OF CustomWrapper IS\r\n\r\n\tTYPE array_tuser IS ARRAY (0 TO 19) OF signed(15 DOWNTO 0);\r\n\r\n\tSIGNAL aresetn, aresetn_dly : STD_LOGIC;\r\n\r\n\tSIGNAL s_axis_data_tdata : STD_LOGIC_VECTOR(31 DOWNTO 0);\r\n\tSIGNAL s_axis_data_tready : STD_LOGIC;\r\n\r\n\tSIGNAL m_axis_data_tlast : STD_LOGIC;\r\n\tSIGNAL m_axis_data_tvalid, m_axis_data_tvalid_dly : STD_LOGIC;\r\n\tSIGNAL count_out, m_axis_data_tuser : signed(15 DOWNTO 0);\r\n\tSIGNAL m_axis_data_tuser_dly : array_tuser;\r\n\r\n\tSIGNAL fftdata_temp : signed(31 DOWNTO 0);\r\n\tSIGNAL real, im : signed(15 DOWNTO 0);\r\n\r\n\tSIGNAL m_axis_dout_tvalid : STD_LOGIC;\r\n\tSIGNAL tdata_temp : signed(31 DOWNTO 0);\r\n\r\nBEGIN\r\n\r\n\tFFT_DUT : FFT_65536\r\n\tPORT MAP(\r\n\t\taclk => clk,\r\n\t\t-- aresetn => (not Reset) and FFT_reset and FFT_reset_dly,\r\n\t\taresetn => (NOT reset) AND aresetn AND aresetn_dly,\r\n\t\t-- Control FFT direction with LSB of Control1\r\n\t\t-- and scale of the FFT output with Control0\r\n\t\ts_axis_config_tdata => \"0000000\" & Control0(31 DOWNTO 0) & Control1(0),\r\n\t\t-- Config data is always valid\r\n\t\ts_axis_config_tvalid => '1',\r\n\t\t-- Leave config ready signal open\r\n\t\t-- config data is constant\r\n\t\ts_axis_config_tready => OPEN,\r\n\t\t-- Input only has real values\r\n\t\ts_axis_data_tdata => s_axis_data_tdata,\r\n\t\t-- Input data is always valid\r\n\t\ts_axis_data_tvalid => '1',\r\n\t\t-- Data ready logic\r\n\t\ts_axis_data_tready => s_axis_data_tready,\r\n\t\t-- Continuous data stream\r\n\t\t-- don't have last sample\r\n\t\ts_axis_data_tlast => '0',\r\n\r\n\t\t-- Transformed data\r\n\t\tm_axis_data_tdata => fftdata_temp,\r\n\t\t-- FFT frequency index\r\n\t\tm_axis_data_tuser => m_axis_data_tuser,\r\n\t\t-- output is valid\r\n\t\tm_axis_data_tvalid => m_axis_data_tvalid,\r\n\t\t-- Slave device is always ready to accept output\r\n\t\tm_axis_data_tready => '1',\r\n\t\t-- last sample of the frame\r\n\t\tm_axis_data_tlast => m_axis_data_tlast,\r\n\r\n\t\t-- don't care events\r\n\t\tevent_frame_started => OPEN,\r\n\t\tevent_tlast_unexpected => OPEN,\r\n\t\tevent_tlast_missing => OPEN,\r\n\t\tevent_status_channel_halt => OPEN,\r\n\t\tevent_data_in_channel_halt => OPEN,\r\n\t\tevent_data_out_channel_halt => OPEN\r\n\t);\r\n\r\n\t-- only output data when data is valid\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF s_axis_data_tready THEN\r\n\t\t\t\ts_axis_data_tdata <= x\"0000\" & STD_LOGIC_VECTOR(InputA);\r\n\t\t\tEND IF;\r\n\r\n\t\t\tIF m_axis_data_tvalid THEN\r\n\t\t\t\t-- real part\r\n\t\t\t\treal <= fftdata_temp(15 DOWNTO 0);\r\n\t\t\t\t-- imaginary part\r\n\t\t\t\tim <= fftdata_temp(31 DOWNTO 16);\r\n\t\t\tEND IF;\r\n\t\t\t-- delay 20 clk cycles\r\n\t\t\tm_axis_data_tuser_dly <= m_axis_data_tuser & m_axis_data_tuser_dly(0 TO 18);\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\t-- reset process\r\n\t-- reset fft when the tlast is high\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(Clk) THEN\r\n\r\n\t\t\taresetn_dly <= aresetn;\r\n\t\t\tIF m_axis_data_tlast THEN\r\n\t\t\t\taresetn <= '0';\r\n\t\t\tELSE\r\n\t\t\t\taresetn <= '1'; END IF; END IF; END PROCESS; Cordic : Cordic_Translate_16 PORT MAP( aclk => clk,\r\n\t\ts_axis_cartesian_tvalid => m_axis_data_tvalid,\r\n\t\ts_axis_cartesian_tdata => STD_LOGIC_VECTOR(im & real),\r\n\t\tm_axis_dout_tvalid => m_axis_dout_tvalid,\r\n\t\tm_axis_dout_tdata => tdata_temp\r\n\t);\r\n\tPROCESS (clk)\r\n\tBEGIN\r\n\t\tIF rising_edge(clk) THEN\r\n\r\n\t\t\tIF m_axis_dout_tvalid THEN\r\n\t\t\t\tOutputA <= signed(tdata_temp(15 DOWNTO 0));\r\n\t\t\t\tOutputB <= signed(tdata_temp(31 DOWNTO 16));\r\n\t\t\t\tOutputC <= signed(m_axis_data_tuser_dly(19));\r\n\t\t\tEND IF;\r\n\r\n\t\tEND IF;\r\n\tEND PROCESS;\r\n\r\nEND ARCHITECTURE;<\/code><\/pre>\n
The <\/span>Moku:Pro<\/span> M<\/span>ulti-Instrument Mode<\/span> test configurations are shown in Figure 20. The signal under test is generated by the <\/span>Moku <\/span>Oscilloscope\u2019s built-in waveform generator and routed back to the M<\/span>oku Cloud Compile<\/span> input via the internal digital signal bus. M<\/span>oku <\/span>C<\/span>loud <\/span>C<\/span>ompile<\/span> produces three outputs: <\/span>OutputA<\/span> and <\/span>OutputB<\/span> represent the converted amplitude and phase, while <\/span>OutputC<\/span> corresponds to the frequency index. These outputs are connected to the inputs of the Oscilloscope for monitoring.<\/span><\/span> <\/span>
\n\"\"<\/p>\n
Figure <\/span><\/span>20<\/span><\/span><\/span>: <\/span>Moku:Pro<\/span> <\/span>FFT_65536<\/span><\/span> t<\/span>esting <\/span>M<\/span>ulti-Instrument Mode<\/span> c<\/span>onfigurations<\/span>.<\/span><\/span> <\/span><\/p>\n
The output amplitude and frequency index of <\/span><\/span>FFT_65536<\/span><\/span> are shown in Figure 2<\/span>1<\/span>. Control0 is fine-tuned to prevent signal overflow, and Control1 is set to 1 to perform a forward FFT. It is worth noting that the frequency index appears to flip signs due to the use of a signed 16-bit representation for the 65,536-point FFT, which <\/span>results in an overflow. However, this overflow is harmless, as it effectively distinguishes between negative and positive frequencies. The amplitude channel shows a peak near the 80 MHz frequency index, which corresponds to the 80 MHz input signal from M<\/span>oku <\/span>C<\/span>loud <\/span>C<\/span>ompile<\/span>, given the <\/span>Moku:Pro<\/span> M<\/span>oku Cloud Compile<\/span> clock rate of 312.5 <\/span>MHz.<\/span><\/span> <\/span>
\n\"\"<\/p>\n
\\(text{Frequency} = frac{53.86  mu text{s}}{104.95  mu text{s}} times frac{312.5  text{MHz}}{2} = 80.19  text{MHz}\\)<\/p>\n
\"\"<\/p>\n
Figure <\/span><\/span>21<\/span><\/span><\/span>: <\/span>Test results of the instantiated <\/span><\/span>FFT_65536<\/span><\/span> and its corresponding amplitude spectrum output.<\/span><\/span> <\/span><\/p>\n
Customized IP cores<\/span> <\/span><\/h2>\n
Moku Cloud Compile also allows users to upload custom .xci files that define the configuration of IP cores generated in Vivado. Moku Cloud Compile is capable of parsing these .xci files, loading the corresponding IP cores on the backend, and enabling their instantiation within user designs.<\/span> <\/span>
\nIt is important to note that the .xci files must be generated using Vivado version 2022.2 to ensure compatibility with the Moku Cloud Compile backend. All IP cores supported by Vivado 2022.2 are likewise supported by Moku Cloud Compile. Vivado 2022.2 is available for download from the <\/span>official AMD website<\/span><\/a>. The following section presents an example to illustrate this process.<\/span> <\/span><\/p>\n
1. Create Vivado project:<\/span> <\/span><\/h3>\n
Selecting the correct hardware platform is essential during the project creation process. The target FPGA device must be specified as part of the setup process. Table 12 lists the FPGA platform models for three supported hardware platforms, and an example configuration is illustrated in Figure 22.<\/span> <\/span><\/p>\n
Table 12: The FPGA model numbers of the Moku platforms.<\/p>\n\n\n\n\n\n\n
Platform<\/span><\/b> <\/span><\/td>\nFPGA model<\/span><\/b> <\/span><\/td>\n<\/tr>\n
Moku:Go<\/span> <\/span><\/td>\nxc7z020clg400-1<\/span> <\/span><\/td>\n<\/tr>\n
Moku:Lab<\/span> <\/span><\/td>\nxc7z020clg484-3<\/span> <\/span><\/td>\n<\/tr>\n
Moku:Pro<\/span> <\/span><\/td>\nxczu9egffvc900-2<\/span> <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 
\n\"\"<\/p>\n
Figure <\/span><\/span>22<\/span><\/span><\/span>: <\/span>The project must be created in <\/span>Vivado<\/span> with the appropriate FPGA platform settings. In this example, the <\/span>Moku:Go<\/span> platform is selected as the target device.<\/span><\/span> <\/span><\/p>\n
2. Build an IP core and locate the .xci file<\/span> <\/span><\/h3>\n
A custom IP core can be compiled by following the steps illustrated in Figure 23. First, select <\/span>IP Catalog<\/span><\/b> from the <\/span>Project Manager<\/span><\/b> panel on the left (Step 1). Then, choose the desired IP core from the list in the right panel (Step 2). During configuration, the clock frequency may be required; platform-specific clock rates are provided in Table 13. Once the IP core is configured, it will appear in the <\/span>Sources<\/span><\/b> window (Step 3). The location of the generated .xci file can be found in the <\/span>Source File Properties<\/span><\/b> panel (Step 4).<\/span> <\/span><\/p>\n
Table <\/span><\/span>13<\/span><\/span><\/span>: <\/span>Clock rates of M<\/span>oku <\/span>C<\/span>loud <\/span>C<\/span>ompile<\/span> across different hardware platforms.<\/span><\/span> <\/span><\/p>\n\n\n\n\n\n\n
Platform<\/span><\/b> <\/span><\/td>\nMoku Cloud Compile clock rate (MHz)<\/span><\/b> <\/span><\/td>\n<\/tr>\n
Moku:Go<\/span> <\/span><\/td>\n31.25<\/span> <\/span><\/td>\n<\/tr>\n
Moku:Lab<\/span> <\/span><\/td>\n125<\/span> <\/span><\/td>\n<\/tr>\n
Moku:Pro<\/span> <\/span><\/td>\n\n
312.5<\/span> <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 
\n\"\"<\/p>\n
Figure <\/span><\/span>23<\/span><\/span><\/span>: The process of configuring the IP core.<\/span><\/span> <\/span><\/p>\n
3. Upload .xci file to Moku Cloud Compile and change OUTPUTDIR<\/span> <\/span><\/h3>\n
Once the IP core has been compiled, the .xci file should be uploaded to the <\/span>Moku Cloud Compile web interface<\/span><\/a>. To ensure successful recompilation on the Moku Cloud Compile backend, the <\/span>OUTPUTDIR<\/span><\/b> parameter must be set to “<\/span>..\/output<\/span>“. An example of this process is illustrated in Figure 24.<\/span> <\/span>
\n\"\"<\/p>\n
Figure <\/span><\/span>24<\/span><\/span><\/span>: Upload the .xci file to <\/span>Moku Cloud Compile <\/span>and <\/span>set<\/span> the <\/span><\/span>OUTPUTDIR<\/span><\/span> to <\/span>“<\/span><\/span>..<\/span>\/output<\/span><\/span>“<\/span> to ensure proper compilation.<\/span><\/span> <\/span><\/p>\n
4. Instantiate the IP core in M<\/span>oku Cloud Compile<\/span> and build the design<\/span><\/span> <\/span><\/h3>\n
To instantiate a custom IP core in M<\/span>oku <\/span>C<\/span>loud <\/span>C<\/span>ompile<\/span>, it is essential to understand the port configurations and signal connections. <\/span>Figure 25 illustrates the process of locating the instantiation template.<\/span> Begin by selecting IP Sources, then locate the .<\/span>vho<\/span> and .<\/span>veo<\/span> files, which provide example instantiations. The .<\/span>vho<\/span> file is intended for VHDL, while the .<\/span>veo<\/span> file is used for Verilog.<\/span><\/span> <\/span>
\n\"\"<\/p>\n
Figure <\/span><\/span>25<\/span><\/span><\/span>: Locating the IP core instantiating templates.<\/span><\/span> <\/span><\/p>\n
Next,<\/span> the process of<\/span> instantiat<\/span>ing<\/span> the custom IP core using the templates <\/span>is <\/span>shown in Figure 2<\/span>6<\/span>. This completes the setup, after which the custom IP core can be compiled within M<\/span>oku Cloud Compile<\/span> and the bitstreams <\/span>are<\/span> generated.<\/span><\/span> <\/span>
\n\"\"<\/p>\n
Figure <\/span><\/span>26<\/span><\/span><\/span>:<\/span> Instantiate the IP core within M<\/span>oku Cloud Compile<\/span> and connect its signals to the corresponding ports of the <\/span>CustomWrapper<\/span> module.<\/span><\/span> <\/span><\/p>\n
 <\/p>\n
Verilog support<\/span> <\/span><\/h2>\n
Verilog, like VHDL, is a hardware description language, but it is generally more compact and closely aligned with hardware modeling. <\/span>In contrast to VHDL, where users typically define only the behavior architecture of the CustomWrapper entity, Verilog requires both the declaration and structural definition of the entire CustomWrapper module. This includes explicitly specifying the CustomWrapper ports and internal logic.<\/span> <\/span>
\nThis section provides an example of instantiating the <\/span>AddSubtract_16<\/span> IP core using Verilog, as shown in Code 9. It is important to note that Verilog is <\/span>case-sensitive<\/span><\/b>. Therefore, correct capitalization and consistent naming are essential to avoid synthesis or behavioral errors.<\/span> <\/span><\/p>\n
Code <\/span><\/span>9<\/span><\/span><\/span>: <\/span>Example Verilog implementation demonstrating <\/span>support<\/span> for the <\/span><\/span>AddSubtract_16<\/span><\/span> IP core.<\/span><\/span> <\/span><\/p>\n
module CustomWrapper (\r\n    input wire Clk,\r\n    input wire Reset,\r\n    input wire [31:0] Sync,\r\n\r\n    \/\/ 4 input ports\r\n    input wire signed [15:0] InputA,\r\n    input wire signed [15:0] InputB,\r\n    input wire signed [15:0] InputC,\r\n    input wire signed [15:0] InputD,\r\n\r\n    \/\/ external trigger input port\r\n    input wire ExtTrig,\r\n\r\n    \/\/ 4 output ports\r\n    output wire signed [15:0] OutputA,\r\n    output wire signed [15:0] OutputB,\r\n    output wire signed [15:0] OutputC,\r\n    output wire signed [15:0] OutputD,\r\n\r\n    \/\/ enable\/disable interpolation\r\n    output wire OutputInterpA,\r\n    output wire OutputInterpB,\r\n    output wire OutputInterpC,\r\n    output wire OutputInterpD,\r\n\r\n    \/\/ 16 control registers\r\n    input wire [31:0] Control0,\r\n    input wire [31:0] Control1,\r\n    input wire [31:0] Control2,\r\n    input wire [31:0] Control3,\r\n    input wire [31:0] Control4,\r\n    input wire [31:0] Control5,\r\n    input wire [31:0] Control6,\r\n    input wire [31:0] Control7,\r\n    input wire [31:0] Control8,\r\n    input wire [31:0] Control9,\r\n    input wire [31:0] Control10,\r\n    input wire [31:0] Control11,\r\n    input wire [31:0] Control12,\r\n    input wire [31:0] Control13,\r\n    input wire [31:0] Control14,\r\n    input wire [31:0] Control15\r\n);\r\n  \r\nAddSubtract_16 AddSubtract_DUT (\r\n  .A(InputA),      \/\/ input wire [15 : 0] A\r\n  .B(InputB),      \/\/ input wire [15 : 0] B\r\n  .CLK(Clk),  \/\/ input wire CLK\r\n  .ADD(Control0[0]),  \/\/ input wire ADD\r\n  .CE(1'b1),    \/\/ input wire CE\r\n  .S(OutputA)      \/\/ output wire [15 : 0] S\r\n);\r\n  \r\nendmodule\r\n<\/code><\/pre>\n
After uploading the example Verilog code to M<\/span>oku Cloud Compile,<\/span> the <\/span><\/span>AddSubtract_16<\/span><\/span> module can be compiled successfully, and the corresponding bitstream <\/span>is<\/span> generated<\/span>, as illustrated in Figure 27<\/span>.<\/span><\/span> <\/span>\"\"<\/p>\n
Figure <\/span><\/span>27<\/span><\/span><\/span>: <\/span>M<\/span>oku Cloud Compile<\/span> interface for compiling the <\/span><\/span>AddSubtract_16<\/span><\/span> module and generating bitstreams from Verilog code.<\/span><\/span><\/p>\n
Summary<\/span> <\/span><\/h2>\n
Moku Cloud Compile offers eight precompiled IP cores for signal processing tasks such as arithmetic operations, filtering, waveform generation, and spectral analysis. Each core is described above with detailed port definitions, example VHDL implementations, and test configurations using Multi-Instrument Mode on Moku hardware platforms.<\/span> <\/span>
\nIn addition to built-in cores, users can upload custom IP cores by importing .xci files generated in Vivado 2022.2. Moku Cloud Compile also offers both Verilog and VHDL support. Together, these features enhance Moku Cloud Compile\u2019s capabilities, making it a powerful and flexible platform for rapid development and deployment of FPGA-based digital signal processing solutions.<\/span> <\/span>[\/vc_column_text][vc_row background=”gradient” layout=”vertical” options=”button” media_position=”right” media_type=”” ja_toggle_src=”” zh_toggle_src=”” kr_toggle_src=”” image=”” image_size=”full” aspect_ratio=”auto” max_width=”” center=”” href=”url:https%3A%2F%2Fknowledge.liquidinstruments.com%2F|title:Knowledge%20Base|target:_blank” style=”filled” size=”medium” href_secondary_btn=”” style-secondary=”filled” size-secondary=”medium” en_src=”” ja_src=”” zh_src=”” kr_src=””][\/vc_row][vc_column][\/vc_column]<\/p>\n<\/div>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
[vc_row][vc_column][\/vc_column][\/vc_row][vc_column][\/vc_column][vc_column_text css=””] Introduction  Moku Cloud Compile is a powerful tool available on Moku devices. Moku FPGA-based test and measurement devices allow users to deploy custom VHDL and Verilog code to the hardware. With Moku Cloud Compile, you can extend and customize instrument functionality by integrating your own designs with existing instruments to create new capabilities […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":59,"featured_media":23860,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[92],"tags":[],"class_list":["post-23621","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-white-papers","site-category-moku-cloud-compile","site-category-multi-instrument-mode"],"acf":[],"yoast_head":"\nUsing IP cores for faster customization in Moku Cloud Compile<\/title>\n<meta name=\"description\" content=\"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Using IP cores for faster customization in Moku Cloud Compile\" \/>\n<meta property=\"og:description\" content=\"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations\" \/>\n<meta property=\"og:url\" content=\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\" \/>\n<meta property=\"og:site_name\" content=\"Liquid Instruments\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/LiquidInstruments\/\" \/>\n<meta property=\"article:published_time\" content=\"2025-04-18T20:40:36+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-08-29T04:40:49+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"2560\" \/>\n\t<meta property=\"og:image:height\" content=\"1707\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Noah Monroy\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@liquidinstrmnts\" \/>\n<meta name=\"twitter:site\" content=\"@liquidinstrmnts\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Noah Monroy\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"15 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\"},\"author\":{\"name\":\"Noah Monroy\",\"@id\":\"https:\/\/liquidinstruments.com\/#\/schema\/person\/3e07e87049698dbcb79f8d92a4d30018\"},\"headline\":\"Using IP cores for faster customization in Moku Cloud Compile\",\"datePublished\":\"2025-04-18T20:40:36+00:00\",\"dateModified\":\"2025-08-29T04:40:49+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\"},\"wordCount\":6571,\"publisher\":{\"@id\":\"https:\/\/liquidinstruments.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg\",\"articleSection\":[\"White papers\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\",\"url\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\",\"name\":\"Using IP cores for faster customization in Moku Cloud Compile\",\"isPartOf\":{\"@id\":\"https:\/\/liquidinstruments.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg\",\"datePublished\":\"2025-04-18T20:40:36+00:00\",\"dateModified\":\"2025-08-29T04:40:49+00:00\",\"description\":\"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations\",\"breadcrumb\":{\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage\",\"url\":\"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg\",\"contentUrl\":\"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg\",\"width\":2560,\"height\":1707,\"caption\":\"An engineer using Moku Cloud Compile to deploy custom functions\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/liquidinstruments.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Using IP cores for faster customization in Moku Cloud Compile\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/liquidinstruments.com\/#website\",\"url\":\"https:\/\/liquidinstruments.com\/\",\"name\":\"Liquid Instruments\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/liquidinstruments.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/liquidinstruments.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/liquidinstruments.com\/#organization\",\"name\":\"Liquid Instruments\",\"url\":\"https:\/\/liquidinstruments.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/liquidinstruments.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/i0.wp.com\/liquidinstruments.com\/wp-content\/uploads\/2020\/10\/BrandMark-Preferred-RGB-Color.png?fit=1000%2C924&ssl=1\",\"contentUrl\":\"https:\/\/i0.wp.com\/liquidinstruments.com\/wp-content\/uploads\/2020\/10\/BrandMark-Preferred-RGB-Color.png?fit=1000%2C924&ssl=1\",\"width\":1000,\"height\":924,\"caption\":\"Liquid Instruments\"},\"image\":{\"@id\":\"https:\/\/liquidinstruments.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/LiquidInstruments\/\",\"https:\/\/x.com\/liquidinstrmnts\",\"https:\/\/www.instagram.com\/liquidinstruments\/\",\"https:\/\/www.linkedin.com\/company\/liquidinstruments\/\",\"https:\/\/www.youtube.com\/c\/LiquidInstruments\",\"https:\/\/vimeo.com\/liquidinstruments\"],\"hasMerchantReturnPolicy\":{\"@type\":\"MerchantReturnPolicy\",\"merchantReturnLink\":\"https:\/\/liquidinstruments.com\/support\/warranty-repairs-and-service\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/liquidinstruments.com\/#\/schema\/person\/3e07e87049698dbcb79f8d92a4d30018\",\"name\":\"Noah Monroy\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/liquidinstruments.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c659d7b8514100af4aaaac7dd06c3929df909f5d7eb7fb20be4d16cf26b8cb10?s=96&d=wavatar&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c659d7b8514100af4aaaac7dd06c3929df909f5d7eb7fb20be4d16cf26b8cb10?s=96&d=wavatar&r=g\",\"caption\":\"Noah Monroy\"}}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Using IP cores for faster customization in Moku Cloud Compile","description":"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/","og_locale":"en_US","og_type":"article","og_title":"Using IP cores for faster customization in Moku Cloud Compile","og_description":"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations","og_url":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/","og_site_name":"Liquid Instruments","article_publisher":"https:\/\/www.facebook.com\/LiquidInstruments\/","article_published_time":"2025-04-18T20:40:36+00:00","article_modified_time":"2025-08-29T04:40:49+00:00","og_image":[{"width":2560,"height":1707,"url":"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg","type":"image\/jpeg"}],"author":"Noah Monroy","twitter_card":"summary_large_image","twitter_creator":"@liquidinstrmnts","twitter_site":"@liquidinstrmnts","twitter_misc":{"Written by":"Noah Monroy","Est. reading time":"15 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#article","isPartOf":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/"},"author":{"name":"Noah Monroy","@id":"https:\/\/liquidinstruments.com\/#\/schema\/person\/3e07e87049698dbcb79f8d92a4d30018"},"headline":"Using IP cores for faster customization in Moku Cloud Compile","datePublished":"2025-04-18T20:40:36+00:00","dateModified":"2025-08-29T04:40:49+00:00","mainEntityOfPage":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/"},"wordCount":6571,"publisher":{"@id":"https:\/\/liquidinstruments.com\/#organization"},"image":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage"},"thumbnailUrl":"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg","articleSection":["White papers"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/","url":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/","name":"Using IP cores for faster customization in Moku Cloud Compile","isPartOf":{"@id":"https:\/\/liquidinstruments.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage"},"image":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage"},"thumbnailUrl":"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg","datePublished":"2025-04-18T20:40:36+00:00","dateModified":"2025-08-29T04:40:49+00:00","description":"Discover eight precompiled IP cores to accelerate signal processing tasks, with example implementations and test configurations","breadcrumb":{"@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#primaryimage","url":"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg","contentUrl":"https:\/\/liquidinstruments.com\/wp-content\/uploads\/2025\/04\/3020_LiquidInstruments_118-scaled.jpg","width":2560,"height":1707,"caption":"An engineer using Moku Cloud Compile to deploy custom functions"},{"@type":"BreadcrumbList","@id":"https:\/\/liquidinstruments.com\/white-papers\/using-ip-cores-in-mcc\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/liquidinstruments.com\/"},{"@type":"ListItem","position":2,"name":"Using IP cores for faster customization in Moku Cloud Compile"}]},{"@type":"WebSite","@id":"https:\/\/liquidinstruments.com\/#website","url":"https:\/\/liquidinstruments.com\/","name":"Liquid Instruments","description":"","publisher":{"@id":"https:\/\/liquidinstruments.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/liquidinstruments.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/liquidinstruments.com\/#organization","name":"Liquid Instruments","url":"https:\/\/liquidinstruments.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/liquidinstruments.com\/#\/schema\/logo\/image\/","url":"https:\/\/i0.wp.com\/liquidinstruments.com\/wp-content\/uploads\/2020\/10\/BrandMark-Preferred-RGB-Color.png?fit=1000%2C924&ssl=1","contentUrl":"https:\/\/i0.wp.com\/liquidinstruments.com\/wp-content\/uploads\/2020\/10\/BrandMark-Preferred-RGB-Color.png?fit=1000%2C924&ssl=1","width":1000,"height":924,"caption":"Liquid Instruments"},"image":{"@id":"https:\/\/liquidinstruments.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/LiquidInstruments\/","https:\/\/x.com\/liquidinstrmnts","https:\/\/www.instagram.com\/liquidinstruments\/","https:\/\/www.linkedin.com\/company\/liquidinstruments\/","https:\/\/www.youtube.com\/c\/LiquidInstruments","https:\/\/vimeo.com\/liquidinstruments"],"hasMerchantReturnPolicy":{"@type":"MerchantReturnPolicy","merchantReturnLink":"https:\/\/liquidinstruments.com\/support\/warranty-repairs-and-service\/"}},{"@type":"Person","@id":"https:\/\/liquidinstruments.com\/#\/schema\/person\/3e07e87049698dbcb79f8d92a4d30018","name":"Noah Monroy","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/liquidinstruments.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/c659d7b8514100af4aaaac7dd06c3929df909f5d7eb7fb20be4d16cf26b8cb10?s=96&d=wavatar&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c659d7b8514100af4aaaac7dd06c3929df909f5d7eb7fb20be4d16cf26b8cb10?s=96&d=wavatar&r=g","caption":"Noah Monroy"}}]}},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/posts\/23621","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/users\/59"}],"replies":[{"embeddable":true,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/comments?post=23621"}],"version-history":[{"count":60,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/posts\/23621\/revisions"}],"predecessor-version":[{"id":25561,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/posts\/23621\/revisions\/25561"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/media\/23860"}],"wp:attachment":[{"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/media?parent=23621"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/categories?post=23621"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/liquidinstruments.com\/wp-json\/wp\/v2\/tags?post=23621"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}