At the High level we used functional ASM because this ASM represents the functional (High level) behavior of the design system, we don’t have an architecture or Data Path. In this ASM, inputs and outputs of  units in each assignment were used as variables and we did not have a real structure of system. Look that in details at our site here.  

To explain the difference between functional representation and structural representation (between the High level and RTL in our context) we will use a very simple structure in Fig. 1. In this figure, we have sources s0, … , s3 and targets (receivers) t0, …, t4 (disregard target t5 for now, we will use it later). Only for simplicity, you can think about these sources and targets as registers.

Let us suppose that we should send information from each source to each target except t5. Of course, we can connect each source with each target directly but the cost of such connection is very high. So, we use here a multiplexer (MUX) with four inputs. To send information from any input to the output of MUX we should supply 2-bit vector (control signal), corresponding to the input, to ctr_mux. Suppose that the control signal is equal to the input number, so for in0, the signal at ctr_mux is equal to 00, for in101 etc. sgdfhfgfg

1. Our simpliest structure

We will discuss several examples in Fig. 2. In the first example, source s2 transfers information to target t3. At the functional level, the description is very simple and clear: t3 := s2. At the structural level, to pass information from input in2 to the output of MUX, ctr_mux should get control signal 10. To write information from the output of MUX to the target t3 the signal enable of t3 should be equal to 1: t3_en := ′1′.

2. Examples of descriptions at the functional and structural levels

In the second example, we send the same information from one source s3 to two targets t1 and t2. The control signal of MUX must be equal to 11 and two enable signals, equal to 1, will write information into t1 and t2. However, if we should pass information from several sources to several outputs at the same time, we need several MUXes because one MUX transfers only one input to its output. To put it more precisely, we need as many MUXes as the number of sources we wish to pass simultaneously.

One of the targets t5 in our structure is connected only with one source, i.e. it can get information only from s0. We call such a connection a direct connection. In example 3 in Fig. 2 to send information from s0 to t5 it is sufficient to supply enable signal to this target: t5_en := ′1′.

In the fourth example we have two simultaneous transfers – the first through the direct connection: t5 := s0, and the second – through the indirect connection: t4 := s1. Since only one indirect transfer takes place in this example, one MUX is sufficient in such a case.

Any digital system is usually regarded as a composition of Control unit and Operational unit (Data Path) – see Fig. 3. Data path contains such regular blocks as memory, registers, ALU, counters, coders, encoders, multiplexers, demultiplexers etc. A control unit produces a sequence of control signals that force implementation of microoperations in data path. Sometimes designers include cloud (non-regular) circuits in data path as well. In Fig. 4 we have a fragment of data path with two registers R1, R2 and a cloud circuit.

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

Suppose that in the Data path there are transfers from R1 to R2 at different times with different 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 information from R1 to R2 takes place.

Figure 4. Element of Data path with a cloud circuit

One of the main concepts in our design methodology is the construction of “naked data path. Naked data path doesn’t contain any cloud circuits, only standard regular units with their inputs and outputs. Such units can be predesigned or even taken from libraries. We leave all check-ups of conditions to control unit. We can afford this because we know how to design very complicated FSM with hardly any constraints on their size, that is, the number of inputs, outputs and states. We will try to show that such design and its verification are very simple. Moreover, we formalized a design of the digital system with naked data path and Synthagate implements that automatically.

The main goal of Data path design is to construct indirect (MUXes) and direct connections. Synthagate begins from the Functional Asm table.This table is constructed from the Functional Asm (Funcmi.gsa and Funcmi.txt). FunctionL Asm table contains four columns:  

  1. Yt - the number of microinstruction (operator);
  2. yn1, yn2, ... - the numbers of microoperatioms in Yt;
  3. the length of microoperation;
  4. microoperation.

There are two classes of microoperations in this table. The first one presents the transfer information from the output of one unit of Data path (source) to the input of another unit of Data path (target), for  example, relem:=nelem,  ext_in:=m2[m2_address], m1[m1_address]:=ext_out, rwrite2m2:=cnt_m2, etc. Two units take part in such microoperations. The lengths of these microoperations are written in the third column of the table of Functional ASM. The microoperations from the second class, such as codcomplete:=1, mac1:=0, cnt:=cnt+1, bitcnt:=0  etc. are executed in one operational unit. They are marked by 0 in the same column. Synthagate begins with microoperations from the first class marked by nonzero numbers in the Funtional ASM table. For each length of assignment Synthagate constructs sequentially the Connection graph, minimized List of parallel microoperations and the Graph of incompatibility. After the coloring of the Graph of incompatibility Synthagate immediately designs MUXes and direct connections. you wil be able to read more about that in the book by Samary Baranov "High Level Synthesis". It will be published at the end of 2017.

The main goal of Data path design is the construction of indirect (MUXes) and direct connections. Synthagate constructs MUXes automatically in two forms – as a text file (look at 8bits MUXes for our example here) and a file in XML (look at 8bits MUXes for our example 8bit MuxesXML).

Automatic generation of components. Synthagate automatically generates VHDL codes for components of Data Path. You can find them in folder RTL in the example of the full design of Codec. In our example, Synthagate have constructed the following components:

components.vhd; alu_8bit.vhd;

countero_ps_4bit.vhd; alu_16bit.vhd;

countero_ps_8bit.vhd; countero_ps_16bit.vhd;

counter_pm_16bit.vhd; counter_ps_16bit.vhd;

mux_3x1.vhd; mux_2x7.vhd;

mux_3x8.vhd; mux_3x16.vhd;

mux_5x4.vhd; mux_8x8.vhd;

mux_12x8.vhd; reg_1bit.vhd;

reg_7bit.vhd; reg_8bit.vhd;

reg_8bit_2en.vhd; reg_16bit.vhd;

ram65536x8.vhd; rsff.vhd;

g_comp.vhd; g_comp_alu.vhd.

To construct Data path in VHDL Synthagate uses external specifications ExtSpec.xml prepared automatically by program ExtSpecBuilder. At the last step of Data Path design Synthagate automatically instantiates these components in the Data Path Dp.vhd. If a designer would like to use some “exotic” components or predesigned IP cores, he must put their RTL codes in folder Components before the design. Later these components will be included in the library of automatically generated units. In our example we used core memory from Altera Ram65536x8.vhd.