What Are The Synthesis Tools In Vlsi System Design

Synthesis Tool

Hardware Description Languages

Sarah L. Harris , David Harris , in Digital Design and Computer Architecture, 2022

4.6 Finite State Machines

Recall that a finite state machine (FSM) consists of a state register and two blocks of combinational logic to compute the next state and the output given the current state and the input, as was shown in Figure 3.22. HDL descriptions of state machines are correspondingly divided into three parts to model the state register, the next state logic, and the output logic.

HDL Example 4.30 describes the divide-by-3 FSM from Section 3.4.2. It provides an asynchronous reset to initialize the FSM. The state register uses the ordinary idiom for flip-flops. The next state and output logic blocks are combinational.

HDL Example 4.30

DIvide-By-3 Finite State Machine

SystemVerilog

module divideby3FSM(input logic clk,

input logic reset,

output logic y);

typedef enum logic [1:0] {S0, S1, S2} statetype;

statetype state, nextstate;

// state register

always_ff @(posedge clk, posedge reset)

if (reset) state <= S0;

else state <= nextstate;

// next state logic

always_comb

case (state)

S0: nextstate = S1;

S1: nextstate = S2;

S2: nextstate = S0;

default: nextstate = S0;

endcase

// output logic

assign y = (state = = S0);

endmodule

The typedef statement defines statetype to be a two-bit logic value with three possibilities: S0, S1, or S2. state and nextstate are statetype signals.

The enumerated encodings default to numerical order: S0 = 00, S1 = 01, and S2 = 10. The encodings can be explicitly set by the user; however, the synthesis tool views them as suggestions, not requirements. For example, the following snippet encodes the states as 3-bit one-hot values:

typedef enum logic [2:0] {S0 = 3'b001, S1 = 3'b010, S2 = 3'b100} statetype;

Notice how a case statement is used to define the state transition table. Because the next state logic should be combinational, a default is necessary, even though the state 2'b11 should never arise.

The output, y, is 1 when the state is S0. The equality comparison a = = b evaluates to 1 if a equals b and 0 otherwise. The inequality comparison a != b does the inverse, evaluating to 1 if a does not equal b.

VHDL

library IEEE; use IEEE.STD_LOGIC_1164.all;

entity divideby3FSM is

port(clk, reset: in STD_LOGIC;

y: out STD_LOGIC);

end;

architecture synth of divideby3FSM is

type statetype is (S0, S1, S2);

signal state, nextstate: statetype;

begin

–– state register

process(clk, reset) begin

if reset then state <= S0;

elsif rising_edge(clk) then

state <= nextstate;

end if;

end process;

–– next state logic

nextstate <= S1 when state = S0 else

S2 when state = S1 else

S0;

–– output logic

y <= '1' when state = S0 else '0';

end;

This example defines a new enumeration data type, statetype, with three possibilities: S0, S1, and S2. state and nextstate are statetype signals. By using an enumeration instead of choosing the state encoding, VHDL frees the synthesizer to explore various state encodings to choose the best one.

In the HDL above, the output, y, is 1 when the state is S0. The inequality comparison uses /=. To produce an output of 1 when the state is anything but S0, change the comparison to state /= S0.

Synthesis tools produce just a block diagram and state transition diagram for state machines; they do not show the logic gates or the inputs and outputs on the arcs and states. Therefore, be careful that you have specified the FSM correctly in your HDL code. The state transition diagram in Figure 4.25 for the divide-by-3 FSM is analogous to the diagram in Figure 3.28(b). The double circle indicates that S0 is the reset state. Gate-level implementations of the divide-by-3 FSM were shown in Section 3.4.2.

Notice that the synthesis tool uses a 3-bit encoding (Q[2:0]) instead of the 2-bit encoding suggested in the SystemVerilog code.

Notice that the states are named with an enumeration data type rather than by referring to them as binary values. This makes the code more readable and easier to change.

If, for some reason, we had wanted the output to be HIGH in states S0 and S1, the output logic would be modified as follows.

SystemVerilog

// output logic

assign y = (state = = S0 | state = = S1);

VHDL

–– output logic

y <= '1' when (state = S0 or state = S1) else '0';

The next two examples describe the snail pattern recognizer FSM from Section 3.4.3. The code shows how to use case and if statements to handle next state and output logic that depend on the inputs as well as the current state. We show both Moore and Mealy modules. In the Moore machine (HDL Example 4.31), the output depends only on the current state, whereas in the Mealy machine (HDL Example 4.32), the output logic depends on both the current state and inputs.

HDL Example 4.31

Pattern Recognizer Moore FSM

SystemVerilog

module patternMoore(input logic clk,

input logic reset,

input logic a,

output logic y);

typedef enum logic [1:0] {S0, S1, S2} statetype;

statetype state, nextstate;

// state register

always_ff @(posedge clk, posedge reset)

if (reset) state <= S0;

else state <= nextstate;

// next state logic

always_comb

case (state)

S0: if (a) nextstate = S0;

else nextstate = S1;

S1: if (a) nextstate = S2;

else nextstate = S1;

S2: if (a) nextstate = S0;

else nextstate = S1;

default: nextstate = S0;

endcase

// output logic

assign y = (state = = S2);

endmodule

Note how nonblocking assignments (<=) are used in the state register to describe sequential logic, whereas blocking assignments (=) are used in the next state logic to describe combinational logic.

VHDL

library IEEE; use IEEE.STD_LOGIC_1164.all;

entity patternMoore is

port(clk, reset: in STD_LOGIC;

a: in STD_LOGIC;

y: out STD_LOGIC);

end;

architecture synth of patternMoore is

type statetype is (S0, S1, S2);

signal state, nextstate: statetype;

begin

–– state register

process(clk, reset) begin

if reset then state <= S0;

elsif rising_edge(clk) then state <= nextstate;

end if;

end process;

–– next state logic

process(all) begin

case state is

when S0 =>

if a then nextstate <= S0;

else nextstate <= S1;

end if;

when S1 =>

if a then nextstate <= S2;

else nextstate <= S1;

end if;

when S2 =>

if a then nextstate <= S0;

else nextstate <= S1;

end if;

when others =>

nextstate <= S0;

end case;

end process;

––output logic

y <= '1' when state = S2 else '0';

end;

HDL Example 4.32

Pattern Recognizer Mealy FSM

SystemVerilog

module patternMealy(input logic clk,

input logic reset,

input logic a,

output logic y);

typedef enum logic {S0, S1} statetype;

statetype state, nextstate;

// state register

always_ff @(posedge clk, posedge reset)

if (reset) state <= S0;

else state <= nextstate;

// next state logic

always_comb

case (state)

S0: if (a) nextstate = S0;

else nextstate = S1;

S1: if (a) nextstate = S0;

else nextstate = S1;

default: nextstate = S0;

endcase

// output logic

assign y = (a & state = = S1);

endmodule

VHDL

library IEEE; use IEEE.STD_LOGIC_1164.all;

entity patternMealy is

port(clk, reset: in STD_LOGIC;

a: in STD_LOGIC;

y: out STD_LOGIC);

end;

architecture synth of patternMealy is

type statetype is (S0, S1);

signal state, nextstate: statetype;

begin

–– state register

process(clk, reset) begin

if reset then state <= S0;

elsif rising_edge(clk) then state <= nextstate;

end if;

end process;

–– next state logic

process(all) begin

case state is

when S0 =>

if a then nextstate <= S0;

else nextstate <= S1;

end if;

when S1 =>

if a then nextstate <= S0;

else nextstate <= S1;

end if;

when others =>

nextstate <= S0;

end case;

end process;

–– output logic

y <= '1' when (a = '1' and state = S1) else '0';

end;

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128200643000040

Hardware Description Languages

Sarah L. Harris , David Money Harris , in Digital Design and Computer Architecture, 2016

4.4.5 Latches

Recall from Section 3.2.2 that a D latch is transparent when the clock is HIGH, allowing data to flow from input to output. The latch becomes opaque when the clock is LOW, retaining its old state. HDL Example 4.21 shows the idiom for a D latch.

HDL Example 4.21

D Latch

SystemVerilog

module latch(input logic clk,

input logic [3:0] d,

output logic [3:0] q);

always_latch

if (clk) q <= d;

endmodule

always_latch is equivalent to always @(clk, d) and is the preferred idiom for describing a latch in SystemVerilog. It evaluates any time clk or d changes. If clk is HIGH, d flows through to q, so this code describes a positive level sensitive latch. Otherwise, q keeps its old value. SystemVerilog can generate a warning if the always_latch block doesn't imply a latch.

VHDL

library IEEE; use IEEE.STD_LOGIC_1164.all;

entity latch is

port(clk: in STD_LOGIC;

d: in STD_LOGIC_VECTOR(3 downto 0);

q: out STD_LOGIC_VECTOR(3 downto 0));

end;

architecture synth of latch is

begin

process(clk, d) begin

if clk = '1' then

q <= d;

end if;

end process;

end;

The sensitivity list contains both clk and d, so the process evaluates anytime clk or d changes. If clk is HIGH, d flows through to q.

Not all synthesis tools support latches well. Unless you know that your tool does support latches and you have a good reason to use them, avoid them and use edge-triggered flip-flops instead. Furthermore, take care that your HDL does not imply any unintended latches, something that is easy to do if you aren't attentive. Many synthesis tools warn you when a latch is created; if you didn't expect one, track down the bug in your HDL. And if you don't know whether you intended to have a latch or not, you are probably approaching HDLs like a programming language and have bigger problems lurking.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128000564000042

Electronic and Firmware Design of the HP DesignJet Drafting Plotter

Alfred Holt MebaneIV, ... Anne P. Kadonaga , in Readings in Hardware/Software Co-Design, 2002

Logic Synthesis

A logic synthesis tool was used extensively for transforming the control logic into the standard cells. The automation of this laborious task not only saved much time during the initial mapping of the logic into a combination of gates but also reduced the number of iterations through the compose-verify-correct loop. The synthesis tool was also used to generate the custom registers, decoders, and multiplexers. This approach was preferred over the use of TTL macro cells ^* because it made it possible to implement only the necessary functions using minimum-area cells. TTL macro cells were used for such blocks as counters, where they could be modified to provide only the necessary functions with the minimum-area cells.

The synthesis tool also offered area-versus-delay optimization capability, but this was of limited use for most blocks because the CMOS34 process is fast relative to the clock frequencies of 16 MHz and 12 MHz. In many cases, setting the area constraint at minimum sufficed. The exceptions were in control blocks where both the rising and falling edges of the clock were used, effectively doubling the frequency, and some critical timing path blocks. For these blocks, the delay constraint was set as needed with some margin. The worst path delay estimates included in the report files were useful in quickly verifying the timing margins at the block level.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781558607026500612

21st European Symposium on Computer Aided Process Engineering

Jan van Schijndel , ... Johan Grievink , in Computer Aided Chemical Engineering, 2011

4 Computational and software engineering aspects

The process synthesis tool has been implemented in AIMMS®, having links to state-of-the-art solvers for major mathematical programming types, e.g., CONOPT & LGO for NLP and BARON for MINLP. The solution of the underlying problem is currently done using CONOPT [ 8]. Currently, a typical problem has 65 degrees of freedom (# variables - # equality constraints). There are some 2100 constraints (equalities and inequalities), of which 650 are nonlinear, with ∼ 6500 non-zeros in the Jacobian matrix. The current model has a limited number of integer choices for which a brute force approach is taken. One of the major challenges in NLP is to initialize all variables in order to get a feasible solution. A sequential modular strategy is followed by initializing the process units in flow sheet ordering after tearing and fixing plant wide recycles. Thereafter the utility network is added to the entire problem.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444537119500845

Design for Synthesis

Peter J. Ashenden , in The Designer's Guide to VHDL (Third Edition), 2008

21.1 Synthesizable Subsets

There are several synthesis tools available from different design automation tool vendors. While many of them perform the same general process, they differ in their command sets and the way in which we specify synthesis constraints. Hence we discuss synthesis tools only in very general terms. More important, synthesis tools differ in the subsets of VHDL that they accept as input. The majority only accept designs described at the register-transfer level and synthesize to circuits composed of gates, flipflops, registers, and other basic components. A small number of behavioral synthesis tools accept designs described at a higher level of abstraction. However, developing behavioral synthesis technology that is usable in practice has proven to be very difficult, so the techniques are not widely adopted. They are most successful in certain specialized application areas, such as digital signal processing.

The disparity between synthesis tools motivated the development of IEEE Standard 1076.6, Standard for VHDL Register Transfer Level Synthesis. The first version of this standard, published in 1999, specified a "level-1" lowest common denominator subset of VHDL that was acceptable to most synthesis tools. The intention was to assist designers in writing models that were portable between synthesis tools and to ensure that the behavior of the synthesized designs matched simulation results.

In 2004, a revision of the standard was published, specifying a level-2 synthesis subset of VHDL. The intention of this subset, as described in the Introduction to the standard, is "to include a maximum subset of VHDL that could be used to describe synthesizable RTL logic." It provides considerably more flexibility in the way models can be written. It is much closer to the subsets now implemented by synthesis tools. Nonetheless, there remains variation among tools, so we need to consult the documentation for any particular tool that we might use to find out what forms of input it accepts.

There are two aspects of synthesis subsets of VHDL. The first is the collection of language features that are included in the subset. This comprises the types that can be used to represent data and the declarations, specifications, and statements that can be included in models. The second aspect is the way in which we write code to represent different hardware elements. The task of a synthesis tool is to analyze a VHDL description and infer what hardware elements are represented and how they are connected. A tool cannot infer hardware from any arbitrarily written VHDL model. Instead, we need to write models in a synthesis style that is recognized by the tool. Style guidelines include templates for process statements from which various kinds of hardware elements can be inferred, and restrictions on the way in which we write and combine statements. We will look at both of these aspects, as specified by the IEEE 1076.6-2004 standard.

One further point to note about synthesis subsets is that they have historically lagged behind revisions of the VHDL standard. As an illustration, the 1999 version of the IEEE 1076.6 standard specified that models use the VHDL-87 version of the language, despite VHDL-93 having been published six years earlier. In 1999, many synthesis tools still only supported VHDL-87; now, VHDL-93 is widely supported. The changes between VHDL-93 and VHDL-2002 were relatively minor, apart from the addition of protected types. Since these are not supported for synthesis, synthesis tools effectively support VHDL-2002. That is the version of the language referenced in IEEE 1076.6-2004. The changes between VHDL-2002 and VHDL-2008 are much more significant. If past experience is an indicator, it may be some time before synthesis vendors implement the changes in their tools. Again, we should consult the documentation for any particular tool to see whether it supports VHDL-2008 features. The notes throughout this book describing differences between earlier versions of VHDL and VHDL-2008 will also be helpful as we write synthesizable models.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780120887859000216

VLSI Signal Processing

Surin Kittitornkun , Yu-Hen Hu , in The Electrical Engineering Handbook, 2005

Architecture-Driven Synthesis

One of the well-known DSP synthesis tools is the Cathedral I/II/III (De Man et al., 1990, 1988; Note et al., 1991). A DSP algorithm is described as a graph with operators as vertices and with arcs representing the flow of data in a language called SILAGE. The bit-true specification of all signal formats is specified up to bit-level including quantization and overflow characteristics. Since Cathedral is characterized as an architecture-driven synthesis tool, it supports the following architectural styles. Each architecture style is categorized by sample rate.

1.: Hard-wired bit serial architecture supported in Cathedral I is suitable to a low-sample rate filter in audio, speech, and telecommunication applications. Because signals are processed bit by bit, least significant bit (LSB) first, the amount of logic is independent of the word length.
2.: Microcoded processors architecture supported by Cathedral II is appropriate for low- to medium-rate algorithms with heavy decision making and intensive computations. Each processor is a dedicated interconnection of bit-parallel execution units controlled by branch controllers (e.g., highly complex, blockoriented DSP algorithms in the audio- to near-video-frequency range).
3.: Bit-sliced multiplexed data paths supported in Cathedral III are suitable to a medium-level image, video, and radar processing ranging 1–10 MHz data rates with irregular and recursive high-speed algorithms. The data path consists of interconnected dedicated application-specific units such as registers, adders, multipliers, and so on.
4.: Regular array architecture, which would be supported in Cathedral IV, is suited for front-end modules of image, video, and radar processing. A regular network of PEs features mostly localized communication and distributed storage. If it is fully pipelined and modular, the array corresponds to the so-called systolic architecture.

In the next subsection, the focus is shifted to a more specific architecture (i.e., the regular array architecture or systolic array mapped from n-level nested Do-loop).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780121709600500670

Co-synthesis and Co-simulation of Control-Dominated Embedded Systems

ALESSANDRO BALBONI , ... DONATELLA SCIUTO , in Readings in Hardware/Software Co-Design, 2002

3.2 Hardware and Interface Synthesis

Concerning the hardware mapping strategy adopted in TOSCA, it should be pointed out that control-oriented specifications cannot easily be managed by classical high-level synthesis approaches involving operators scheduling. In fact, circuit speed estimation is very difficult when dealing with descriptions dominated by conditional functions, where arithmetic operations are typically restricted to a few sums and comparisons (if anyone of them is present at all). During the next stage involving VHDL translation into a generic netlist, technology mapping and logic implementation, any direct relation between functional specification and synthesized implementation is lost. Estimating area is also a very hard task. As a consequence, scheduling operators according to estimated propagation delays cannot be considered a realistic approach. In the previous version of the TOSCA module devoted to hardware mapping, each hardware-bound architectural unit is implemented by generating a finite state machine VHDL description, together with its bus interface [3]. If the starting point is a synchronous model (as those obtained from speedCHART), no additional scheduling step is needed. The VHDL code generator translates the internal representation of each FSM into a VHDL template (block-encapsulated processes) compliant to the guidelines for synthesis enforced by commercial tools such as Mentor Graphics Autologic and Synopsys VHDL Compiler. The data flow graphs modeling conditions and actions are translated into VHDL statements included in the related template. The algorithm adopted is able to produce a very readable description by building expressions whenever possible, instead of basic assignments for each DFG node. Parameters such as the logic types to be used can be customized by the user. In particular cases, such as for instance counters, predefined library components may be preferred to RTL synthesis in order to guarantee an efficient implementation.

However, recently several commercial VHDL behavioral synthesis tools are emerging (Synopsys, Synthesia). This opportunity is particularly valuable to cope with system-level architectural exploration needing fast speed/cost prediction techniques, avoiding as much as possible to move down to the gate-level netlist. The current version of TOSCA is oriented towards a direct compilation of process algebra description into behavioral VHDL, that is becoming the target abstraction level for synthesis. In summary, three different hardware synthesis paths can be applied:

1.: transparent passing of the initial VHDL description to the synthesis tool;
2.: RTL synthesizable VHDL description of the modules such as FSM;
3.: behavioral VHDL descriptions of the hardware-bound modules.

A suitable VHDL generator has been developed, starting from the OCCAMII description stored within the database and building a tree modeling the statements nesting. It produces a set of modules corresponding to the hardware bound architectural units (coprocessors) with their communication interfaces. The VHDL code generator performs a depth-first scan of the tree representing the OCCAMII structure and produces two output files: the first contains the entities declarations with the corresponding behavioral description while the second is a package containing all the procedures necessary to realize the communication among processes.

Since channels are not supported by VHDL, ad hoc fully hardware interface structures covering both buffered and unbuffered communication have been introduced.

In case of hardware-to-hardware communication, the realization of each channel requires the instance of three signals to implement the negotiation process -s_req (send-request), s_data (send-data) and r_ack (receive-ack), that will be used to expand each OCCAMII declaration of channel–CHAN OF TYPE channelName–into the following VHDL code:

signal ChannelName_s_req: boolean: =false;

signal ChannelName_s_data: =0;

signal ChannelName_r_ack: boolean:=false;

These variables are used to generate an handshake mechanism with the semantic defined by the following VHDL code:

if not s_req then

wait until s_req;

else

wait for 0 ns;

end if;

The OCCAMII statements for message passing ChannelName!variable and ChannelName? variable are translated into the following two procedures, respectively:

send_unbuffered (ChannelName_s_req, ChannelName_r_ack, ChannelName_s_data, variable)

recv_unbuffered (ChannelName_s_req, ChannelName_r_ack, ChannelName_s_data, variable)

The unbuffered communication needs an additional pair of signals, full_f (fifo full) and empty_f (fifo empty), modeling the availability of free positions within the FIFO buffer, as input to the sender and the receiver processes, respectively. The VHDL procedure for buffered communication thus becomes:

send_f (ChName_s_req, ChlName_r_ack, ChName_s_data, ChName_full_f, variable)

recv_f (ChName_s_req, ChName_r_ack, ChName_s_data, ChName_empty_f, variable)

In addition to the above procedure, a VHDL process fifo_ChName will be instanced to actually implement the message storage and management unit. This element can be customized according to the desired buffer size (N) and channel type (e.g. INT).

Each entity description of the modules connected via hardware channels contains the declaration of a set of ports corresponding to the signals used to implement the communication protocol.

The hardware side of the hw-to-sw communication has been implemented by studying an additional BUS interface unit to be added to the coprocessor (see Fig. 4). Such a module contains a pair (input and output) of FIFO buffers used to store the messages that processor and coprocessor need to exchange. The entire communication is mastered by the processor which triggers the reading of data from the output queue or the sending of messages to the input queue according to the data flow direction of the original OCCAMII channel. When a message is sent out on the BUS, the coprocessor protocol manager performs a decoding of the BUS address to discover if it has to be processed. A maximum of 255 coprocessors are allowed with at most eight bi- directional channels per each. For each queue, a pair of status registers (in, out) storing the information on FIFO content (e.g. empty) are foreseen, their information can be accessed by the processor communication primitives. In summary, for the target architecture we are considering, the ADDRESS BUS bits have been associated with the following information:

A0… A2	coprocessors or other peripheral selection;
A3	data BUS contains a datum or the status register;
A4	selection of the status register to put on the data bus;
A5…A7	FIFO selection among the possible eight per coprocessor;
A8…A15	coprocessor selection among the possible 255.

The customization of such a scheme onto the MC68000 is straightforward, the only additional control signals to be taken into account are R/W, BUSREQ and MEMREQ. When a software-bound process needs to send a datum to the n-th coprocessor, the software communication procedures will put on A8…A15 the binary encoding of the coprocessor number, on A5…A7 the FIFO identifier corresponding to the channel considered, A0…A2 = 1 to select the coprocessors address space, A3 = 0, R/W = 0 and MEMREQ = BUSREQ = 1. The datum on the data bus will be acquired by the addressed coprocessor and placed within the proper input FIFO queue which is assumed to be sufficiently large to contain all the incoming messages (this is a matter of correct design, not impacting the suitability of the proposed scheme). The hw-to-sw communication takes place in a similar way.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781558607026500363

Proceedings of the 8th International Conference on Foundations of Computer-Aided Process Design

Dimitrios Koufolioulios , ... Antonis Kokossis , in Computer Aided Chemical Engineering, 2014

Abstract

Multi-product biorefineries emerge with the need for novel conceptual process synthesis tools that will simultaneously assess a multitude of new processes and products for being integrated into the complete biorefinery scheme. Energy integration plays a key role in producing sustainable and profitable processes. Direct or indirect process to process integration may allow the inclusion of-otherwise rejected-energy intensive processes into a final biorefinery system. This paper presents an automated two staged Total Site approach combined with economic indicators, for selecting optimal combinations of candidate processes and producing optimal allocation of utilities. The proposed method can further evaluate process modifications and aid design decisions. The applicability of the models is illustrated through a case study involving eight real pilot biorefining processes developed in the course of the European biorefinery research project Biocore (2010).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444634337500766

SpecSyn: An Environment Supporting the Specify-Explore-Refine Paradigm for Hardware/Software System Design

Daniel D. Gajski , ... Jie Gong , in Readings in Hardware/Software Co-Design, 2002

Abstract

System-level design issues are gaining increasing attention, as behavioral synthesis tools and methodologies mature. We present the SpecSyn system-level design environment, which supports the new specify-explore-refine (SER) design paradigm. This three-step approach to design includes precise specification of system functionality, rapid exploration of numerous system-level design options, and refinement of the specification into one reflecting the chosen option. A system-level design option consists of an allocation of system components, such as standard and custom processors, memories, and buses, and a partitioning of functionality among those components. After refinement, the functionality assigned to each component can then be synthesized to hardware or compiled to software. We describe the issues and approaches for each part of the SpecSyn environment The new paradigm and environment are expected to lead to a more than ten times reduction in design time, and our experiments support this expectation.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781558607026500107

"Traditional" Design Flows

Clive Max Maxfield , in FPGAs: Instant Access, 2008

Serial versus Parallel Multiplexers

When creating RTL code, it is useful to understand what your synthesis tool is going to do in certain circumstances. For example, every time you use an if-then-else statement, the result will be a 2:1 multiplexer. This becomes interesting in the case of nested if-then-else statements, which will be synthesized into a priority structure. For example, assume that we have already declared signals Y, A, B, C, D, and SEL (for select) and that we use them to create a nested if-then-else ( Figure 5-20).

As before, the syntax used here is a generic one that doesn't really reflect any of the mainstream languages. In this case, the innermost if-then-else will be the fastest path, while the outermost if-then-else will be the critical signal (in terms of timing). Having said this, in some FPGAs all of the paths through this structure will be faster than using a case statement. Speaking of which, a case statement implementation of the above will result in a 4:1 multiplexer, in which all of the timing paths associated with the inputs will be (relatively) equal (Figure 5-21).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750689748000053