## 3 Prototyping of the Proposed CAPT Framework
### Original Implementation  
Considering that the diagnosing tasks are activated when the interested signals are segmented and pre-processed, the proposed CAPT detector is prototyped as a slave IP core, allowing a master module to invoke it at any time. In order to facilitate the updating of the network parameters, parameter ports are designed. Moreover, the data ports should be parallelizable, allowing parallelizing the computing by accessing multiple data sets simultaneously. The final interface protocol is shown in Table 1. It includes a group of logical control signals (_CLK_, _RST_, _START_, _DONE_, _IDLE_, _READY_, and _RETURN_) and the data ports (\(x\_*\), _W1\(\_*\), _W2\(\_*\), \(B\) and _ETA_). The parameter ports are implemented in the classical memory protocol, allowing the core to access the external memory with an index when needed. \(x\_*\) is the utterance sample to be diagnosed, and its size is determined by the sampling precision of the system. In the case of this paper, we set \(\overline{n}\) as 14, allowing a sampling frequency of \(2^{\overline{n}}=16384\) Hz. \(W1\_*\) and \(W2\_*\) are the parameter matrices of the first and second layers of the proposed framework, respectively. The size of \(W2\_*\) is set as \(2^{6}=64\), and \(W1\_*\) is therefore a \(2^{\overline{n}+6}=1048579\)-element array, which can cover the 35 phonemes in the case of this paper. If desired, the data and parameter ports can be expanded to accelerate the processing speed by communicating parallelly. \(B\) is the bias value of the second layer. _ETA_ is the threshold value of the decision cycle. If the diagnosis result is positive, _RETURN_ output _true_, otherwise _false_ when negative. Algorithm 2 shows the Matlab pseudocode of the proposed CAPT implementation. Because Matlab provides a vector-available programming environment, the target behavior can be efficiently described. The algorithm's behavior starts the diagnostic processing after parameter initializations. Lines 2 and 4 correspond to the regression operations of the first and second layers (see (2) and (3)), whereas Lines 3 and 5 correspond to the ReLU and sigmoid active functions. The final decision is made in Line 6. The operator \"\(\times\)\" returns a matrix whose elements are the products of the corresponding elements of the two input matrices. Next, we transform the algorithm behavior from Matlab into C++ code via the source-to-source compiler Matlab Coder. For the reason that C++ is only available for scalar variables and operations, the matrix computations in Matlab are mapped into loops line by line. The pseudocode of the generated C++ behavior is shown in Algorithm 3. The first nest loop (Lines 2-8) computes the PLS regressions (see (2)) with the help of a newly-allocated register. The second loop with a \"if\" body (Lines 9-15) corresponds to the ReLU function. Lines 17-20 compute the SVM regressions (see (3)). Here, the buffer of the first loop is reused to save the hardware sources. Line 21 is the sigmoid function, and the decision is made within Lines 22-26. Figure 2: VHLS based SW/HW co-design flow: the full- and dotted-line blocks represent the automatic and manual development cycles, respectively. From this point, we can start to synthesize the C++ code down to the register level through the HLS process. HLS extracts the source code as a control-and-datapath flow graph (CDFG) [51] and then represents it as a finite state machine (FSM) [52]. Figure 3 shows the diagram of the extracted FSM, in which each node is a state including a series of subsequent operations, and the arrows are the operating orders. \(L*\) is the line number of Algorithm 3. As presented in [44], this method allows us to formally implement it at RTL in a standardized way.