Code Generation From MATLAB – Simulink Models

Nowadays, computational tools are indispensable in the design of electronic circuits due to the increase in complexity of electronic circuits and the need to manage large amounts of related data to design. The development of new methodologies and tools has become a strategic area in the development of new technologies, in particular the development of CAD (Computer Aided Design) tools. CAD tools can be best understood as design information management systems, along with the creation of graphic based input and simulations of the designs are created. These simulations can be used, shared, published, republished and reused in different formats, scales and levels of detail.


Introduction
Nowadays, computational tools are indispensable in the design of electronic circuits due to the increase in complexity of electronic circuits and the need to manage large amounts of related data to design. The development of new methodologies and tools has become a strategic area in the development of new technologies, in particular the development of CAD (Computer Aided Design) tools. CAD tools can be best understood as design information management systems, along with the creation of graphic based input and simulations of the designs are created. These simulations can be used, shared, published, republished and reused in different formats, scales and levels of detail.
But with so many studies involving different methodologies and computational tools, in [1], it was proposed to form a classification model for design and tools at the Electronic System Level (ESL) of design abstraction. This chapter details the characteristics and approaches that differ between computational tools of design, for modeling at level hardware and software. Figure 1 illustrates the design flow in different levels of abstraction. The design flow, called the Double Roof Model, is considered by [1] as an extended version of the Y diagram presented by [2] [3]. However, there are still problems of incompatibility between designs the tools and this identifies a number of weaknesses. Figure 1 shows the process of designing the top-down methodology in an ideal way. The left side corresponds to the process of software creation, while the right side corresponds to the process of hardware creation. Each side is divided into different levels of abstraction, e.g., Task and Instruction (software) or Components and Logic (hardware). There is a common level of abstraction, named ESL. In this level, we cannot distinguish between hardware and software. At each level, we can run a synthesis step (continuous vertical arrow) and the specification is transformed into an implementation. Horizontal dotted arrows indicate the steps which we can change the models of individual elements in the implementation directly to the next level of abstraction (lower level abstraction). In this chapter, we present a methodology for ESL designs based in four computational tools. The first one is the SF 2 HDL tool (Stateflow to Hardware Description Language or transition states table). The SF 2 HDL has the ability to convert models of finite state machine (FSM) in Stateflow / Simulink in a corresponding description in VHDL, Verilog or even a text file with a state transition table. The descriptions in the VHDL and Verilog languages are generated at the behavioral abstraction level for the finite state machine. The second computational tool, called MS 2 SV (MATLAB / Simulink to SystemVision), is able to generate descriptions in VHDL-AMS from models described in Simulink and all of model structure design for simulation in SystemVision environment from Mentor Graphics. The descriptions are generated in VHDL-AMS since even in the standard Simulink toolbox. there are many components with different signal representations of a purely digital representation. The third computational tool developed, called BD 2 XML (Block Diagram to XML), is able to generate a textual representation of the architecture of this model in XML markup language, also from models described in Simulink. XML was chosen for its applicability and it can be used as object code by other tools. The fourth and last computational tool described works together with BD 2 XML and it is similar to SF 2 HDL. The tool, called SF 2 XML (Stateflow to XML), is able to capture the relevant information in the Stateflow file and generate a corresponding description in XML. The file resulting from the conversion is according to the standard of XML structure called SCXML (StateChart XML) proposed by the W3C [4].
For acceptance in the community of software development, maintainability and practicality, we chose to develop the translation environment using an object-oriented approach. For robustness, the C++language was chosen. With C++ language is possible create linear and nonlinear data structure, and languages like Java, it is not possible do it. In our tools, we used liner lists to store dynamically the data in memory. Thus, C++language is a better choice for programming language. Another reason for this choice, it is the common features between methods were coupled to objects, so there was created a logical interaction with low representational gap.
As case study designs, the digital-to-analog converters (DAC) design was used to explain the MS 2 SV and BD 2 XML. Data converters are circuits that transform a given representation to another. The ADC (analog to digital converter) is used to convert analog signals to digital data. The digital to analogue converter works in the opposite manner to the ADC, converting digital data input to analogue signal output proportional to value of input digital.
Considering the DAC operation, n binary input bits (which can be considered as representing the binary code of a decimal value) are received and there are 2 n possible combinations of binary input. There is also an additional input to the circuit design that is used as a reference signal, represented by V ref and the reference is a voltage level, which is used to determine the maximum value that converter can generate on its output. The analog value is generated by the weighted sum of n inputs, multiplied by the reference voltage. Inputs are weighted according to magnitude of each bit, where n is the magnitude of input bit, x is total number of inputs, and b is DAC input value contained in the bit of n magnitude, where b n ∈ {0,1}, as described in: Using Equation (1), the analogue output voltage from the data converter is obtained by multiplying the result of Equation (1) by the reference voltage to obtain: There are several methods possible to implement the DAC operation (i.e., there are several different DAC design architectures possible). One common method used is R/2R ladder circuit, where only two values for resistors in circuit are used (R and 2R), and output current depends on positions of switches that are controlled by inputs [5].
To explain the use of SF 2 HDL and SF 2 XML, we used a HDB3 (High Density Bipolar 3) finite state machine [6]. HDB3 line code, which is a technique for detecting synchronism with bipolar signaling, and it has been used over the years in digital systems. A finite state machine can be represented by state diagrams. State diagrams are used to graphically represent a state transition functions set. Having an input event set, the output event set and the next state set can be determined.
There are also several other forms to represent finite state machine that differ slightly and have different semantic. The State Transition Where, f is a state transition function. The value of output M(t) is obtained through of two ways: or, where, g is an output function.
A finite state machine with properties described in Equations (3) and (4) is called Moore model and a machine described by equations (3) and (5) is called Mealy model [7].
To illustrate the state transition diagram, Figure 3 shows a state transition diagram of HDB3 code line, in hexadecimal representation as proposed in [6]. The encoder needed three parts of memory to store and to identify four successive 0. After this, it was necessary to use a flipflop to store the polarity of the pulse (0 for+or 1 for-), and finally other flip-flop to store the polarity of the violation. The encoder requests a minimum of 25=32 states. The state 00 represents the initial state of the machine, and the two pairs of state 07 and 0F (in the left) and 1F and 17 (in the right) represent the description AMI, what causes the alternate code between +1 and-1 [6].

Related research
Project-level electronic systems, also known as ESL (Electronic System Level), require much effort designer. The first work to classify the steps involved in system design at a high level of abstraction [2] subsequently refined to a more current [1] and [3]. Some studies deal with design optimization or minimization, for example the work in paper [8]. This work explored the computational complexity of logic minimization problem on two levels for digital circuit designs. In [9] was developed a genetic algorithm for synthesis of multicore architectures. The target system was an implementation of Petri net. In [10] was presented a method of re-engineering the FSM by rebuilding it with a different topology, but with equivalent functionality. The method is mainly concerned with power consumption of the finite state machine and uses a genetic algorithm to find the best solution. This approach facilitates the process of synthesis for optimal implementations of the system.
The representation of electronic systems by means of the FSM facilitates verification of the system and formal methodologies can be developed to assist in the synthesis process. In [11] was presented a tool capable to translate a FSM described in the VHDL. The focus of the work was modeling and the verification. In [12] was developed a conceptual mathematical model for automatic checking of the FSM by observing the outputs of this particular FSM, allowing checking faulty behavior.
Hardware description languages (HDLs) are widely used in the design of electronic systems and also represent a major means for simulation and project documentation. In [13] was developed an algorithm for automatic generation of analog circuit models for modeling faults in the circuit at a high level. In [14] was developed a methodology for implementing FFT (Fast Fourier Transform) processors in reprogrammable devices using VHDL. In [15] was developed the architecture for implementing a SPICE (Simulation Program with Integrated Circuit Emphasis) simulator using an FPGA (Field Programmable Gate Array) In [16] the authors proposed a simulator for the VHDL-AMS (Analog and Mixed Signal) language developed in the MATLAB environment. The tool was compared with others simulators available commercially. Another example that can be cited is the tool called SF2VHD, presented in [17]. That tool is capable to translate hierarchical models of finite states machine, modeled in the Stateflow environment, in a code corresponding structural VHDL.
In the work described in [18] was developed a tool called Sim2HDL, which accomplishes the automatic translation of Simulink models in a hardware description language in the attempt to drastically reduce the project time. The generated language can be VHDL or Verilog, at a behavioral level description, and the system can be implemented in FPGAs using commercial synthesizers.
Some commercial modeling tools incorporate the translation need for different forms of modeling. An example is a MATLAB C Compiler tool, developed by Mathworks. That tool translates programs written in MATLAB for a corresponding program in the C language. The functionality and main advantages of these tools are described in [19].
In [20] was proposed an approach to automatic synthesis of additional decoders. The method attempts to find and remove cases where there are no equivalent decoders. To discover all decoders that can exist simultaneously, an algorithm based on functional dependency has also been proposed. To select the correct decoder another algorithm is used to infer formula of each decoder precondition.
In [21] was developed a framework for the synthesis of electronic systems at a high level based on abstract finite state machines. The framework called synASM is capable of generating a CDFG (Control Data Flow Graph) from hardware descriptions based on C language. The authors extended the definitions of abstract state machines to support the parallelism and timing. After generating the CDFG extended, it was possible the automatic generation of optimizable hardware descriptions in VHDL and implementation in a FPGA.
In [22] was presented a complete approach decoder for communication systems. The modelling was based on finite state machines and the method was capable of identifying whether decode exists or not, by observing the input sequence and output of encoder. [23] presented a method of representation and synthesis of Boolean expressions recursively. The method performs a sequence of operations with denial implications using two memristors. With the method, it was proved that it was possible to reduce the number of necessary implications for the expression representation and inference using multiple inputs can reduce the computation of memristor implementation.
In [24] was proposed an algorithm for identifying flowcharts structure. Twelve structures were identified and then the algorithm was used to generate the code flowchart identified using recursion. The technologies and algorithms were used in an integrated development platform. [25] presented an approach of output bit selection based on counter for output response compaction in test systems observable. The hardware implementation requires only a counter and a multiplexer. Thus, the complexity was reduced and the control area was simplified. Furthermore, a change in the ATPG (Automatic Test Pattern Generation) tool was not required. Two output selection algorithms have been developed in several operations which counters can be employed.
In [26] was discussed some work and the importance of developing CAD tools for the synthesis and design of systems and multi-core architectures, highlighting the importance of multi-core optimized and efficient resource allocation. [27] presented revised performance measures of some data type converters ADC (Analog-to-Digital Converter), such as SNR (Signal to Noise Ratio), SINAD (Signal to Noise Ratio and Distortion), SFDR (Spurious free Dynamic Range), THD (Total Harmonic Distortion) and ENOB (Effective Number of Bits). These metrics were analyzed with the case study of an ideal 14-bit converter in MATLAB and a converter with 12bit commercial manufactured by Analog Devices.
In [28] was presented a methodology for genetic optimization based on VHDL-AMS for Fuzzy Logic controllers. The fuzzy logic controller was used for modeling work in automotive systems in mixed physical domain. A genetic algorithm was developed and simulated in SystemVision environment, is employed in the generation of rough fuzzy sets.

Generation code methodology of SF 2 HDL
The SF 2 HDL is a computational tool capable to convert a state transition diagram into a hardware description language description. This diagram is described in the Stateflow environment [29]. The Stateflow is toolbox inside Simulink is used to simulate finite state machines in different contexts. The SF 2 HDL tool is a simplified graphical interface that allows the user to select between generate (i) an input file to be processed by TABELA program and (ii) a.vhd file with a behavioral VHDL description obtained directly from state transition diagram.
The TABELA program was developed for synthesize of a finite state machine and was implemented in Pascal language by researchers from UNICAMP [7] (Universidade Estadual de Campinas-Brazil). The program generates combinational functions that implement the finite machine described by state transition table. The transition functions and output functions are minimized and the cost of minimization using minterms and maxterms [7]. The transitions are specified on table form using one line per state transition, so: present state, next state, input, output. The description end is represented by notation "-100". Figure 4 shows the standard file for TABELA program input.
The states, the inputs and outputs must be in decimal notation. The finite state machines can be completely or incompletely specified.   Thus, from all the information found in the.mdl (Simulink file) file, it is possible to determine the present state, the next state, the input and output of the finite state machine. According to the structure of each file, all the information is grouped and then is generated the input file for TABELA program and/or the corresponding behavioral VHDL. Figure 6 presents the functional diagram of SF 2 HDL program with all necessary steps to perform the translation, as previously reviewed. SF 2 HDL initially reads the file containing finite state machine, simulated in the S program finds the state machine structure and it makes a temporary storage of this location list for all states is generated and through the transition locations is generated conditions for the inputs and outputs. When the user selects to generate the input file the need to choose what type of memory element (flip-flop) will be used in the generat must be put manually by the user. Figure 7 shows the class diagram of SF 2 HDL. The SF 2 HDL was built with many inher are two objects to store the structure found in the .mdl file; the state information distinction is considered because the differences between a Mealy machine and Moor (3), (4) and (5). SF 2 HDL is capable of recognizing which machine is used in the mode read the .mdl file and to save this information. The misc has some operations used  SF 2 HDL initially reads the file containing finite state machine, simulated in the Stateflow environment. Then, the program finds the state machine structure and it makes a temporary storage of this information. After that, the state location list for all states is generated and through the transition locations is generated a transitions list, identifying the conditions for the inputs and outputs. When the user selects to generate the input file for the TABELA program, there is the need to choose what type of memory element (flip-flop) will be used in the generated file. The memory element type must be put manually by the user. Figure 7 shows the class diagram of SF 2 HDL. The SF 2 HDL was built with many inheritances between the classes. There are two objects to store the structure found in the.mdl file; the state information and transition information. This distinction is considered because the differences between a Mealy machine and Moore machine described in Equations (3), (4) and (5). SF 2 HDL is capable of recognizing which machine is used in the model. The fsm object is responsible to read the.mdl file and to save this information. The misc has some operations used many times during running of SF 2 HDL. The create_files object is responsible to create the file that was chosen by user, as illustrate in Figure 7. As SF 2 HDL can create three files at the same time, the main class call the create_files more than once, if it is the case.

Simulation results of HDB3 line code and conversion results
For modeling the state transition diagram on Stateflow environment, some rules must be obeyed, such as the name of the state contained within the symbol should never begin with numeric character (0, 1, 2, 3, 4, 5, 6, 7, 8 or 9), and the condition in the transition to the Mealy model must meet the following syntax: where e represents the variable that will receive input value, t is a variable that represents a discrete time and s is an output variable. The external bracket represents the input condition in the transition from one state to another to obtain an output. The double equal signs (==) represent the verification of a condition and the equal sign alone (=) represents the allocation of value [30].
For proper functionality of the SF 2 HDL program, is necessary that the values in the transition of model in Stateflow environment, both at input and output, are decimal representations. Figure 8 presents the state diagram of HDB3 code on Stateflow environment.
In simulation are used several words with signs and bits from varying sizes. However, it was standardized in using an input word in the simulation of 24 bits being formed by the following bits: 000100110000110101000100. We used this bit stream because with it we can simulate both characteristics of signal encoder, AMI and HDB3, in a real situation. The result of the simulation is presented in the Figure 9.
The TABELA program creates a new file, containing a description of Boolean functions from the circuit already minimized.
Listing 1 was reduced and is shown only important parts of minimization. Each Boolean function in the finite state machine is minimized. As HDB3 has five flip-flops and two output bits, it is possible to see seven functions in Listing 1 (lines 1, 11, 21, 28, 34, 40 and 51). In each function are described the function minterms in decimal, e.g. line 3. The function prime implicants and essentials are shown too, e.g. lines 4-9. And the function cost is shown in lines 10, 20, 27, 33, 39, 50 and 58. The total cost of the circuit is shown in lie 59, for HDB3 case is 95. It is important to highlight that the cost is expressed like sum of product by TABELA.    After the minimization by TABELA was used the TAB2VHDL program [31] which generated VHDL code in RTL (Register Transfer Level) that is shown in Listing 2. The TAB2VHDL is a tool developed by researchers in UNESP (Universidade Estadual Paulista-Brazil) in C language. The only task TAB2VHDL is generated the VHDL code from TABELA output. Listing 2. VHDL code generate by TAB2VHDL program for HDB3 study case. In Listing 2, there is clear distinction in architecture between the flip-flops and the Boolean function to describe the behavior of HDB3. In lines 15-22 are described the flip-flop used (noting that this listing was reduced to presentation in this chapter). Lines 25-31 show the Boolean function of HDB3. This kind of abstraction has better results for synthesis in order to implement the circuit, e.g. in a FPGA (Field Programming Gate Array). The other option is to generate the behavioral VHDL directly without using TABELA program. In Listing 3 is shown the file with behavioral VHDL code generated.  The other option is to generate the behavioral VHDL directly without using TABELA program. In Listing 3 is shown the file with behavioral VHDL code generated.
This description is different between Listing 2 as it is expressed at a behavioral level of abstraction for HDB3. In lines 3 and 4 in the entity, the signal representation is in decimal instead binary. This is a different way that VHDL can support the representation of input and output signals. Lines 14-41 express the behavior of the finite state machine. The reset signal is shown in line 18 and 19 and lines 21-40 show the transitions of HDB3. SF 2 HDL does not use the same label used in Stateflow, such as Figure 8. This case study coincidentally is the same (decimal representation instead hexadecimal), but in other cases then this label will be changed. The last process in description, lines 43-47, describes the update of state by clock signal.
The third description language generated by SF 2 HDL is a behavioral Verilog code [32], which it is shown in Listing 4. In Figure 10 is shown the simulation of behavioral VHDL code generated by SF 2 HDL on Quartus II environment [33], using the same word of data in the simulation as that in the Stateflow environment to verify accuracy and violation of HDB3 code too in the Quartus II.
There is a short delay in output least significant in Figure 10. But the delay does not disrupt the behavioral of the HDB3 encoder. The behavioral VHDL, RTL VHDL and behavioral Verilog codes were synthesized and implemented on the Cyclone II EP2C20F484C7 FPGA. Figure 11 shows the simulation waveform of code generated by TAB2VHDL, i.e., using a RTL VHDL code. This is different from Figure 10 and in Figure 11 is possible to see a stranger behavioral of the code. Possibly this is due to some mistakes in TABELA program as the RTL VHDL is same of the optimization realized by TABELA program. Or even, possibly the results of synthesis of Quartus II. At the moment we do not know the cause of the problem. Figure 12 illustrates the simulation results for behavioral Verilog code. The simulation waveform of Figure 12 is the same waveform in Figure 10, proving that this representation in behavioral Verilog and VHDL, because the level of abstraction in the same too. The synthesis result in FPGA Cyclone II is another equal result. Figure 11. Listing 2. VHDL code generate by TAB2VHDL program for HDB3 study case.
In Listing 2, there is clear distinction in architecture between the flip-flops and the Boolean function to describe the behavior of HDB3. In lines 15-22 are described the flip-flop used (noting that this listing was reduced to presentation in this chapter). Lines 25-31 show the Boolean function of HDB3. This kind of abstraction has better results for synthesis in order to implement the circuit, e.g. in a FPGA (Field Programming Gate Array).
The other option is to generate the behavioral VHDL directly without using TABELA program. In Listing 3 is shown the file with behavioral VHDL code generated.   There is a short delay in output least significant in Figure 10. But the delay does not disrupt the behavioral of the HDB3 encoder. The behavioral VHDL, RTL VHDL and behavioral Verilog codes were synthesized and implemented on the Cyclone II EP2C20F484C7 FPGA. Figure 11 shows the simulation waveform of code generated by TAB2VHDL, i.e., using a RTL VHDL code. This is different from Figure 10 and in Figure 11 is possible to see a stranger behavioral of the code. Possibly this is due to some Listing 4. Behavioral Verilog code generate by SF 2 HDL for HDB3 study case.

Generation code methodology of MS 2 SV
The MS 2 SV is capable to convert a simulation model in Simulink to a description in VHDL-AMS [34]. This time, we used a VHDL-AMS description since the models can use different kinds of signals such as electrical, mechanical, hydraulic, etc. MS 2 SV has two key features: 1. The designer is able to add new components from the Simulink libraries. With this feature, the designer can use different elements previously defined in the standard Simulink libraries.
2. The addition of new Simulink libraries developed by the designer with more complex models, or to change the library named LIB_MS2SV also used in previously paper [36]. This added flexibility is made possible by creating a directory structure and configuration as shown Figure 13. From the root directory bin configuration files are split between configurations of elements from libraries of MATLAB / Simulink (lib directory) and elements of toolbox Simulink (blk directory) subject to translation. The pseudo-code concerning the VHDL-AMS models are also arranged between directories. In the main interface, there is the menu containing the following options: a) Arquivo (File): In this option, there are two possible actions. With the first action, the user selects the Simulink model to be translated. When this action is selected, the status bar appears on the file name to be translated. The second action is a button to end execution of the tool, b) Ferramentas (Tools): In this option, the user is able to select the project location. The process of translation is then initiated. If there are unknown models that the tool is not able to recognize, it will display a message reporting the fact, c) Configuração (Configuration): In this option, there is an action called "Adicionar / Remover Componentes (Add / Remove Components)" and another called "Adicionar / Remover Bibliotecas (Add / Remove Libraries)". These options are used to add / remove elements of toolboxes and Simulink libraries developed by the designer, respectively. If there is not a model configuration to be translated, the tool is not able to recognize it and translate it.
The translation of the model starts with reading a Simulink generated file with an.mdl extension. Initially, a check is made of elements and libraries used in model. If there are no unknown libraries or elements, the translation process starts. The tool stores a list of components in model, the list of connections between these components and other important information for generation of circuit netlist. Then, project structure required for simulation and analysis in SystemVision is generated too [35] [36]. Finally, all descriptions in VHDL-AMS and files for debugging for project needs are generated. Figure 14 shows the functional diagram of the MS 2 SV tool.
If subsystems are used, a VHDL-AMS model for each subsystem used is generated. The MS 2 SV enables the relationship between elements in the same library by creating hierarchical models. Figure 15 represents the class diagram of tool MS 2 SV in a software perspective. All interface layers are represented since some aspects do not change the MS 2 SV functionality. In Figure  15,

Case study of MS 2 SV and BD 2 XML
The DAC08, AD7524 and AD7528 DAC were chosen to model and simulate to evaluate the proposed methodology. All of them are monolithic data converter with 8 bit resolution used in applications such gain control circuit and stereo audio.

DAC08
DAC08 is a simpler operating model consisting basically of a converter with a resolution of 8 bit parallel input, which performs the digital to analogue conversion. The conversion of digital data into analog is done using the ladder R/2R where the binary inputs control the switching between the current arrival of resistors and current coming directly from the reference voltage.
Based on the specifications found in the datasheet of DAC08 converter [37], it was possible to model it in MATLAB / Simulink. Other details of the implementation on a physical level, such as compatibility with TTL (Transistor-Transistor Logic) and CMOS (Complementary Metal Oxide Semiconductor) technology were not considered since the focus of this work was on modelling at high level of abstraction.
The creation of the R/2R Ladder subsystems involved the use of Equations (1) and (2) in order to adjust the weights of each bit, as shown in Figure 16 [38]. In Figure 16, the Ladder R/2R subsystem was constructed using basic components available in the Simulink libraries. The multiplication between the digital input and weights of each input was made with the "Gain components", the sum with seven "Sum components" of two values and multiplying the result by the reference voltage using "Product component". In this system there are two outputs, the analog signal and the difference between the output and the reference voltage. An aspect that is important to emphasize in the creation of the R/2R ladder model shown in Figure 16 is that there are "Data Type Conversion components". These components are used to change the way representation of the binary signal (logic 0 or 1) for decimal representation (0 V or 1 V) and subsequent multiplication by weight. In MATLAB / Simulink, this component is not necessary. However, in VHDL-AMS, this component becomes important due to different ways of representing a signal in this language (i.e. the signal types used in VHDL and VHDL-AMS).

AD7524
The AD7524 has internally flip-flops of a latch type capable of storing last digital input, and a logic interface capable of controlling reading and storing digital input. The mode selection is controlled by CS B and WR B inputs. When CS B and WR B are at logic low (0) is enabled writing mode, that is, the analog output representing the binary value at input bus DB 0 -DB 7 . But when CS B or WR B assumes a logic high (1), AD7524 is in hold mode, analog output has the value corresponding to last input in DB 0 -DB 7 before WR B or CS B assume logic high. Table 1 shows the relationship of control inputs and selection mode of AD7524 [39].

CS B WR B Selection mode Comments
The output corresponds to activity on the input bus (DB 0 to DB 7 ).

X Hold
The output corresponds to the last valid entry, stored in flip-flops.
X 1 Table 1. Selection mode pins to control the AD7524. Figure 17 represents the buffers used by the AD7524 to store last valid digital input. This component is basically formed by a set of latches and an input common to all latches to enable the output. Figure 18 illustrates the circuit capable to represent a selection mode in Table 1. This circuit is minimum using only three logic gates (two NOTs and one AND) and Figure 19 shows a complete AD7524 with a circuit of selection mode, a latch buffer to store last input and Ladder R/2R.

AD7528
AD7528 is equivalent to two AD7524 converters in a single IC (integrated circuit). The data bus of the AD7528 is also numbered from DB 0 to DB 7     According to the approach described in [40], we created two identical blocks to represent the R/2R ladder, one for the DAC A and one for the DAC B. Similar to the R/2R ladder subsystem of Figure 16, the subsystem of Figure 16 was used twice in the complete system, i.e. one for each block of the AD7528 internal converter (DAC A and DAC B). Figure 20 represents the logic controller responsible for the selection of which internal drive will be chosen and if converter is in hold or write mode representing behaviour described in Table 2. This subsystem is basically formed by simple logic gates available in toolbox of Simulink as basic primitive [38]. Figure 21 shows the complete AD7528 converter model created in MATLAB / Simulink. In each converter, there are two separate outputs, first one is analog output signal generated by the converter and second one is the difference between analog output and reference voltage. Based on [38] and in order to generate a sine wave signal, MATLAB was able to send the signal to each bit according to its magnitude of the pins of the AD7528 with the "From Workspace" component. Subsequently, the outputs were captured and sent back to MATLAB with the "To Workspace" component to generate the graphic simulation. The reference voltage and the pin configuration for each internal converter were created using "Constant" components (pins DACA/DACB, CS B and WR B ). The DACA/DACB pin could have been used to carry out switching between two converters internally creating two different waveforms from one input. However, as the converters are exactly the same, the kind of simulation does not alter the analysis of signal generated.

Simulation results of DAC and MS 2 SV conversion results
After construction and simulation in MATLAB / Simulink, the MS 2 SV translates model to the SystemVision environment. The hierarchy structure of model in Simulink was maintained in VHDL-AMS codes and MS 2 SV generated the same configuration of components. The Listing 5 is part of code generated by MS 2 SV using ladder R/2R in Figure 16. The remains VHDL-AMS description is listed in Appendix A.  To perform the simulation, SystemVision was used the same input used in MATLAB / Simulink. Thus was created an input file with the extension.dat. It was created to an additional VHDL-AMS code to read this file and send the signal each bit input to the converters, as listed in Listing 6. 45. ... 46. end architecture arch_Ladder_R2R; Listing 5. Structural VHDL-AMS code generated by MS 2 SV. This VHDL-AMS code in Listing 5 has a structural abstraction. It represent the linkage between the components which it has all DAC system, e.g. lines 34-39 represent the ports for Gain block and the linkage between Sum block in lines 41-46 and Data Type Converter block in lines 26-32. The exactly behavior of components are in internal libraries in SystemVision environment named EDULIB (Educational Library).
To perform the simulation, SystemVision was used the same input used in MATLAB / Simulink. Thus was created an input file with the extension .dat. It was created to an additional VHDL-AMS code to read this file and send the signal each bit input to the converters, as listed in Listing 6.

Listing 6.
Behavioral VHDL code to read the input simulation file.
In Listing 6 was needed to use a library in order to manipulate files (line 4). It was used for a vector to represent the output which was linked to DAC (line 8). After it was built, a process to read the file and put it into output in lines 13-24 is used.
It was used to save the simulation results in SystemVision in another file with the extension.dat so that was possible to analysis the signal generated also in MATLAB, as listed Listing 7.

17
It was used to save the simulation results in SystemVision in another file with the extension .dat so that was possible to analysis the signal generated also in MATLAB, as listed Listing 7. wait until (relogio'event) and (relogio='1'); 20. end process writying; 21. end architecture behavior; Listing 7. Behavioral VHDL code to write the output simulation file. Listing 7 follow the same logic in Listing 6, using the library to manipulate file (line 4), a real signal to represent the input which was linked to DAC (line 9) and a process to read from input and write the file in lines 16-22. By space limits, the remains VHDL-AMS description for AD7524 and AD7528 are listed in Appendix B and C, respectively. For each case study was used a different reference voltage in simulation: 10V, 8V, 6V and 4V, for DAC08, AD7524, AD7528 A and AD7528 B, respectively. Figure 22 shows the simulation results for 1 second. The different voltages were used to create a better view waveform in Figure 21. However in the SystemVision environment, only 10V was used for all converters and only one waveform is plotted in Figure 21 as all converters presented the same simulation results. In MATLAB / Simulink, the AD7524, AD7528 A and AD7528 B presented noise in output because the delays in flip-flop of type latch.

Listing 7.
Behavioral VHDL code to write the output simulation file.
Listing 7 follow the same logic in Listing 6, using the library to manipulate file (line 4), a real signal to represent the input which was linked to DAC (line 9) and a process to read from input and write the file in lines 16-22. By space limits, the remains VHDL-AMS description for AD7524 and AD7528 are listed in Appendix B and C, respectively.
For each case study was used a different reference voltage in simulation: 10V, 8V, 6V and 4V, for DAC08, AD7524, AD7528 A and AD7528 B, respectively. Figure 22 shows the simulation results for 1 second. The different voltages were used to create a better view waveform in Figure 21. However in the SystemVision environment, only 10V was used for all converters and only one waveform is plotted in Figure 21 as all converters presented the same simulation results. In MATLAB / Simulink, the AD7524, AD7528 A and AD7528 B presented noise in output because the delays in flip-flop of type latch. Another difference noted in Figure 22 is low simulation time in SystemVision environment compared with simulation MATLAB / Simulink. This was due to the way in which VHDL-AMS sees the frequency inside the SystemVision environment which is different to MATLAB / Simulink.

Analysis of simulation in MATLAB / Simulink and VHDL-AMS
To verify the quality of signal generated, it was made an analysis of signal obtained through simulation. This analysis was performed through power spectral analysis of the signal obtained from discrete Fourier transform (DFT). Figure 23 illustrates amplitude spectrum of y(t) for all case studies, in MATLAB / Simulink and VHDL-AMS. The graph was generated using the discrete Fourier transform described as [41]: Code Generation From MATLAB -Simulink Models http://dx.doi.org/10.5772/57575 ( 1)( 1) The DC (Direct Current) level of the signal was extracted through shifting the signal along the y axis at zero. This resulted in a sine wave signal ranging from-5 to 5 for 10V,-4 to 4 for 8V,-3 to 4 for 6V and-2 to 2 for 4V.
The process of conversion digital to analog represents an interpolation between values of samples provided as inputs, for 20001 points. In this case studies are used linear interpolation, which points of adjacent samples are connected by a straight line. The system output x r (t) is given by: At the same time, the system has unity gain and linear phase. Systems with this frequency response features produce an output that is a shift in the time of input [41]. Importantly, this is a pseudo-conversion to analog, as the conversion happens only while V ref is constant.
In Figure 23, it is possible to note difference in AD7524, AD7528 A and AD7528 B because of noise in signal. The signal from DAC08 and AD7524 presented a distortion in sine wave showed in Figure 23 too. At the end, the most perfect signal presented by amplitude spectral was the signal from SystemVision environment.

Generation code methodology of BD 2 XML
The computational tool, called BD 2 XML, is able to read a file block diagram in MATLAB / Simulink and generate a corresponding textual description in XML [42]. A key point of the working methodology is to use a configuration file that allows the user to identify MATLAB / Simulink block to use. This file contains all the blocks readable by the BD 2 XML and the characteristics that are relevant to operation of the blocks. All this information can be extracted by the user from their own MATLAB / Simulink file through the block properties. The file has tokens that are the key point of interpretation. For example, the token & is responsible for the identification of a new block, which has characteristics between the tokens { and }. Since the token # works as a comment in regular language, i.e., every line that has the # is disregarded. If the token # is used before the token & all block is disregarded. Figure 24 illustrates the functional diagram of BD 2 XML. Initially begins the reading of.mdl file in memory. Next is read the configuration file. All of blocks are loaded in memory to compare with the blocks in.mdl file. Only afterwards begins the reading of the.mdl file. Relevant information is inside.mdl file, such as the type of block, values inside the block, linkage between the blocks and some other information is important to create a netlist of circuit. From this point, it is possible to create an XML file with the circuit that can used, and reused in many contexts. BD 2 XML was developed according to class diagram showed in Figure 25. The classes responsible for creating a logical structure in memory are inherited by classes responsible for read the configuration file and the block diagram file of the MATLAB / Simulink. The misc class with routines common to other classes is also inherited by other classes.
Others instances of classes are composition. This facilitates the creation of threads structure in future to speeding of codes performance for generations of multiple objects codes simultaneously. The designer starts the process specifying the diagram which is the target of BD 2 XML.
At first, the configuration file is read into a structure and then the block diagram of the MATLAB / Simulink is read into another structure. A comparison is done block by block to check whether the target block is identifiable. Every block of the configuration file has its own characteristics and the default values for these characteristics. In the case of not being identified in some of the characteristics relevant target block are considered the default values of the configuration file to generate the XML. If any block is not identifiable, XML is generated in the same way discarding that particular block.

Conversion results using AD7528
To demonstrate the BD 2 XML, we used the Ladder R/2R case study in Figure 16. Listing 8 is shown a partial description in XML generated by the BD 2 XML from the Ladder R/2R.
The data blocks are specified by the tag <data type="..." value="..." />. Even in the case of gain, the first tag data specifies the kind of signal is used by the block (line 31), e.g., analog. The next type of data (line 32) specifies the gain value that block has.
In the configuration file, the blocks of gain are represented in accordance with the Listing 9 (lines [11][12][13][14]. The block gain has no specification of input and output ports, because by default a gain always has an input and an output.
The property id is understood as the property name of the tag BasicBlock. Similarly, the entry are specified by the tags <InputPort> and </InputPort>, and property as="target".
If there are subsystems in the block diagram, they are identified by the tags <SubSystem name="..."> and </SubSystem>, according to the Listing 8 (lines 7-22, 23-40 and 51-55). All configuration of the subsystem is between two tags and their description is the same as already explained. Tags to indicate input and output ports of the block diagram are used most commonly in subsystems and they are in accordance with Listing 8 (lines 3-5, 11-13 and 26-28). Tags to represent input ports are specified by <InBlock name="..."> and </InBlock> (lines [3][4][5]. Similarly, the output ports are specified by the tags <OutBlock name="..."> and </ OutBlock> (Listing 8, lines [11][12][13]. In both the tag property name identify the block. Also in either case the tag <data... /> (Listing 8, lines 4 and 8) are of mixed type, since both blocks can be an input or an output of digital and analog blocks.
All the representation was generated with perfection in one complete file containing all the blocks and subsystems. In this case study AD7528, there are five subsystems representing: the block Ladder R/2R A, Ladder R/2R B, Datalatch A, Datalatch B and Control Logic. 21

Generation code methodology of SF 2 XML
The in this section, the tool called SF 2 XML is presented which is capable to capture relevant information in the Stateflow environment and generate a corresponding description in XML [43]. The resulting file conversion is also in accordance with international standards of default file in case the SCXML proposed by W3C [4].
The SF 2 XML has four classes of objects, an object that makes up the logical structure of storage memory at runtime, an object of reading the file MATLAB / Simulink and extraction of relevant information, an object to generate the syntactic and semantic file XML and other objects to make interfacing with the user. The class diagram to SF 2 XML is shown in Figure 26. In this figure, it is possible to see that the only difference between SF 2 XML and SF 2 HDL is the highlighted xml_file object. Similarly, the functional diagram in Figure 5, is the same to SF 2 XM apart from the files generated. SF 2 XML is also able to identify sub-finite state machine, so it has recursive methods for hierarchical finite state machine clustering automatically, which generates a certain economy of code and maintenance. There is this feature inside SF 2 [15][16][17][18][19][20]. Inside these tags are two tags named <OutputPort> and </OutputPort>, that specify the output ports of the block owned by as="source" and indicating which is the block output id="...". The property id is understood as the property name of the tag BasicBlock. Similarly, the entry are specified by the tags <InputPort> and </InputPort>, and property as="target". If there are subsystems in the block diagram, they are identified by the tags <SubSystem name="..."> and </SubSystem>, according to the Listing 8 (lines 7-22, 23-40 and 51-55). All configuration of the subsystem is between two tags and their description is the same as already explained. Tags to indicate input and output ports of the block diagram are used most commonly in subsystems and they are in accordance with Listing 8 (lines 3-5, 11-13 and 26-28). Tags to represent input ports are specified by <InBlock name="..."> and </InBlock> (lines [3][4][5]. Similarly, the output ports are specified by the tags <OutBlock name="..."> and </OutBlock> (Listing 8, lines [11][12][13]. In both the tag property name identify the block. Also in either case the tag <data ... /> (Listing 8, lines 4 and 8) are of mixed type, since both blocks can be an input or an output of digital and analog blocks. All the representation was generated with perfection in one complete file containing all the blocks and subsystems. In this case study AD7528, there are five subsystems representing: the block Ladder R/2R A, Ladder R/2R B, Datalatch A, Datalatch B and Control Logic.

Generation code methodology of SF 2 XML
The in this section, the tool called SF 2 XML is presented which is capable to capture relevant information in the Stateflow environment and generate a corresponding description in XML [43]. The resulting file conversion is also in accordance with international standards of default file in case the SCXML proposed by W3C [4]. The SF 2 XML has four classes of objects, an object that makes up the logical structure of storage memory at runtime, an object of reading the file MATLAB / Simulink and extraction of relevant information, an object to generate the syntactic and semantic file XML and other objects to make interfacing with the user. The class diagram to SF 2 XML is shown in Figure 26. In this figure, it is possible to see that the only difference between SF 2 XML and SF 2 HDL is the highlighted xml_file object. Similarly, the functional diagram in Figure 5, is the same to SF 2 XM apart from the files generated. SF 2 XML is also able to identify sub-finite state machine, so it has recursive methods for hierarchical finite state machine clustering automatically, which generates a certain economy of code and maintenance. There is this feature inside SF 2 HDL too, but a hierarchical FSM can generate instable behavioral in a same file. It could better if SF 2 HDL would generate different files for different finite state machines. SF 2 XML has the follow algorithm, which can be understood for SF 2 HDL: 1) Read the MATLAB / Simulink file and identify the FSM; Listing 9. Representation of the blocks in the configuration file used by BD 2 XML. c. If there is a sub-FSM decrease the level hierarchical and go to step 3(a), otherwise go to step 3(d); d. While there is a state such that is associated with a transition go to step 3(a).

4.
Return the XML file.

Conversion results of HDB3 line code
The tool was able to accurately generate an XML representation corresponding to the diagram shown in Figure 3. Every XML description is according to SCXML specification. Listing 10 below displays the entire description in XML generated by SF 2 XML.  It is important to highlight that states assumed a decimal representation continuously, regardless of whether the state is within another state or not. Line 1 of Listing 10 specifies that it is an XML file, the XML version and encoding used. The tags of lines 2 and 20, specify the start and end of the finite state machine. In line 2 is also specified the version of SCXML used, the name for the XML document (xmlns) and the initial state of the finite state machine (initialstate="0"). The tag <state id="..."> and </state> It is important to highlight that states assumed a decimal representation continuously, regardless of whether the state is within another state or not.
Line 1 of Listing 10 specifies that it is an XML file, the XML version and encoding used. The tags of lines 2 and 20, specify the start and end of the finite state machine. In line 2 is also specified the version of SCXML used, the name for the XML document (xmlns) and the initial state of the finite state machine (initialstate="0"). The tag <state id="..."> and </state> specifies the state and its identifier (lines 3, 12, 13, 18). The tags <transition event="..."> and </transi-tion> to specify a transition that will occur according to a particular event, e.g. " INPUT=1" (line 4). If the transition occurs, the tag <target next="..." /> specifies the next state of the FSM according to its identifier. The tag <assign expr="OUTPUT=..." /> assigns a new value to the output attribute expr. If there are hierarchically nested state, states are chained between the tags <state id="..."> and </state>. However, the initial state is specified by internal tags <initial> and </initial> within a transition indicating to the initial state.

Conclusion
The SF 2 HDL program makes the translation of finite state machine, but it does not perform circuit optimization. Hence, it also needs a translation into a file that serves as input to TABELA program that is able to perform this work.
The SF 2 HDL program does not make optimal state assignment to the state machine as well. Thus, it is necessary to use another tool to do that task. In this way circuit synthesis can be really optimize using all the potentialities of developed tools. Future work will extend this tool to also realize the translation of finite state machines for the structural VHDL and Verilog code.
The use of CAD tools and a top-down methodology is a reality that is present in the most electronic circuit design projects, and the development of new computational tools to aid in project implementation is highly desirable, because the range of CAD tools used introduces incompatibilities that can be time consuming and costly in translating between them. Hence, there is the need for suitable tools to be able to translate models between different representations.
The SF 2 HDL tool was tested in several cases of finite state machines and all have been simulated and synthesized in Quartus II environment and Cyclone II FPGA model EP2C20F484C7, respectively.
For the case study of HDB3 code described in this chapter, SF 2 HDL program was very effective for translation code modeled on Stateflow, a computational low cost, being accurate in VHDL generation code and the input file for TABELA program corresponding with another programs.
Thus, this research generated a tool that allows to the designers to model a finite state machine at high level of abstraction and obtain a corresponding VHDL model which can be synthesized on synthesis tools available commercially. It is also important to say this new translation tools interact with several other tools developed by research group with TABELA program, creating this way a digital synthesis environment.
The MS 2 SV tool proved convenient to use as it allows for the creation of multiple libraries for different projects and also recycle the libraries for use in others projects. This allows a significant savings of time and hence costs.
By analysing power spectral of a discrete-time signal, one can say that the output signals in MATLAB / Simulink and VHDL-AMS are almost identical. This fact allows us to change our vision about the abstraction levels and details in modelling. Even in the same environment (MATLAB / Simulink) we have difference in spectral signal. If the system be simulating in another environment, we will also have different simulations.
The conversion to XML (using BD 2 XML) is convenient because the portability of the language allows a wide applicability of the proposed methodology, e.g., documentation, level synthesis of hardware or software, web publishing, use of XML simulators and as object code for future work. This is the same when using SF 2 XML, which it use a standardized description in SCXML. This point highlights the importance to explore more alternatives and standard methodologies of electronic circuit design. Nevertheless, our methodology and tools need further investigation and analysis to consider the need for the development of larger and more complex systems.