top of page

SYNTHESIS AT THE REGISTER TRANSFER LEVEL (RTL)

HLS & RTL Technology | High Level Synthesis | Synthesis at the Register Transfer Level (RTL)

Two Concepts in RTL Design

 Before we look at the results of the RTL design, we will demonstrate two concepts that we used in Data path design. As you know, we can look at any digital system as a composition of the Control unit and Operational unit (Data path) – see Fig. 1. A Data path contains such regular blocks as memories, registers, ALUs, counters, coders, encoders, multiplexers, demultiplexers, etc. A Control unit produces a sequence of control signals that force the implementation of microoperations in the Data path.

Digital system as a composition of Control unit and Data path

Figure 1. Digital system as a composition of Control unit and Data path

As a rule, designers include cloud (non-regular) circuits in the Data path as well. In Fig. 2 we have a very simple fragment of the Data path with two registers R1, R2, and a cloud circuit.

 

Suppose that the digital system transfers information from register R1 to register R2 at different times and with various conditions. Designers often use a cloud circuit to realize some Boolean function, and the output of this circuit is the signal for the transfer. So, this circuit defines when and under which logic conditions the transfer of information from R1 to R2 takes place.

Fig2_Element of DP with a cloud circuit.

Figure 2. The element of the Data path with a cloud circuit

The folder System contains the first stage of RTL design. At this stage, Synthagate implements our optimizing design methodology, using the construction of connection graphs, lists of parallel microoperations, and graphs of incompatibility. You can read about that in the book "High Level Synthesis of Digital Systems" available on Amazon as an ebook and paperback.

​

Since Synthagate designs the "naked" Data path and doesn't contains cloud circuits (read about that in the same book), it is enough to construct MUXes and Direct connections and connect them with corresponding inputs and outputs of Data path components. Synthagate creates MUXes and Direct connections separately for each length of signals. What is essential – Synthagate did not divide buses by an address bus and a data bus. It allows us to increase the speed of a digital system.

​

Files Funcmi_t4b.mux and Funcmi_t16b.mux in folder System contain MUXes and direct connections for signals with four, and sixteen bits. Fig.3 explains MUX3 presented in this folder. The numbers 12x16 in the title of this MUX means that it has twelve 16bit inputs. 

Fig3a_Mux3.png
Fig3b_Mux3.PNG

Figure 3. 16-bit MUX7 as a picture (a) and as part of file Funcmi_t16b.mux (b)

In the file, constructed by Synthagate (Fig. 3,b) we have five columns:
 

  • The first column contains outputs and inputs of MUX.

  • The second column contains the number of appearances of input signals in different microoperations.

  • The third column is equal to the code at the input of the ctr. The input number in the next (fourth) column is equal to this code.

  • The fifth column contains the component reachable with the corresponding code at the input ctr. I wrote the same information above the input arrows in Fig. 3,a.
     

The direct connections (they don't need MUXes) are in the same file together with MUXes(Fig. 4).

DIRECT CONNECTIONS:

SOURCES

alu16_1_out

br

​

ext_out

m0[m0_address]

TARGETS

tempReg16_1

bor[bor_adr]

br1

outr

 m0[m0_address]

ir1

Figure 4. 16-bit direct connections

From the direct connections:
 

  • the output of alu16_1_out is connected directly with the input of tempReg16_1;

  • the output of br is connected directly with the inputs of bor[bor_adr], br1 and outr;

  • the output of external system ext_out is connected directly with the input of m0[m0_address];

  • the output of m0[m0_address] is connected directly with the input ir1.
     

Synthagate constructed Muxes in XML too. 16-bit MUXes in XML are in the file Funcmi_t16b-mux.xml. Compare this file with the file Funcmi_t16b.mux.

To design the VHDL code of Data path, Synthagate automatically creates External Specifications (file ExtSpec.xml in folder Spec). This file contains inputs and outputs of the Data path, which are inputs and outputs of the Processor (lines 16 – 22). This file also includes the types and names of each component used in the design. In this design, we have Muxes (lines 7 – 10), rs_flip-flops (lines 45 – 56), registers (lines 57 – 70), the block of registers (bor lines 71 – 81) counter (lines 82 – 92), comparators (lines 93 – 103) and ALU (lines 104 – 114). Signals and instances of Altera memory core are written as the external component in rows 31 – 42. The name of the clock signal in Altera memory is the clock, but in Synthagate – clk. It is the reason that we have an assignment 

​

clock:=clk

in line 25.

​

In folder RTL, Synthagate generates VHDL codes for 11 components of the Data path listed in file components.vhd: four MUXes, one ALU (Arithmetic Logic Unit), one counter, one register, one RS flip-flop, one comparator, one BoR and one Altera memory. At the last step of the Data path design, Synthagate automatically instantiates these components in the Data path (file dp.vhd in folder RTL). At the bottom of this file, you will find that it contains 213 lines and 19 components instantiated in the Data path. This number of components is more than the number of VHDL files in folder RTL because some components are used several times.

​

Synthagate automatically creates the RTL code of the Control unit (file Structm.vhd). Its input signals are feedbacks from the Data path and some inputs of the digital system. Its outputs are signals of microoperations, implemented in the Data path, and some outputs of the designed system. The Control unit is a Finite State Machine with 36 states and 797 lines.

It may seem to you that it is not convenient to work with so large FSM, especially when searching for errors during the simulation. But if a designer begins the design from RTL, instead of the design of one large FSM, they construct several small interconnected FSMs. But if a designer starts the design from ASMs, they will never use VHDL or SystemC codes to fix mistakes in design. He will use ASMs, which are very simple. Besides, each connection of two FSMs will require at least one clock, which can drastically slow down the designed system.

​

At the last stage, Synthagate creates the top-level (file top.vhd) automatically combining two components – the Control unit and the Data path. The entity of this file contains inputs and outputs of the designed system. Its architecture has two components – Control unit (Structm) and Data path (dp), signals connecting these components, and instantiations of these two components (u1_fsm and u2_dp). 

bottom of page