Confusion between Behavior and Program Data Flow in VHDL

I use the textbook “VHDL: Programming Following the Example” of Douglas L. Perry, fourth edition. He gave an example of a data flow programming model on page 4:

Code I:

ENTITY mux IS PORT ( a, b, c, d : IN BIT; s0, s1 : IN BIT; x, : OUT BIT); END mux; ARCHITECTURE dataflow OF mux IS SIGNAL select : INTEGER; BEGIN select <= 0 WHEN s0 = '0' AND s1 = '0' ELSE 1 WHEN s0 = '1' AND s1 = '0' ELSE 2 WHEN s0 = '0' AND s1 = '1' ELSE 3; x <= a AFTER 0.5 NS WHEN select = 0 ELSE b AFTER 0.5 NS WHEN select = 1 ELSE c AFTER 0.5 NS WHEN select = 2 ELSE d AFTER 0.5 NS; END dataflow; 

Now on page 17, Code II

 LIBRARY IEEE; USE IEEE.std_logic_1164.ALL; ENTITY mux4 IS PORT ( i0, i1, i2, i3, a, b : IN std_logic; PORT ( i0, i1, i2, i3, a, q : OUT std_logic); END mux4; ARCHITECTURE mux4 OF mux4 IS SIGNAL sel: INTEGER; BEGIN WITH sel SELECT q <= i0 AFTER 10 ns WHEN 0, q <= i1 AFTER 10 ns WHEN 1, q <= i2 AFTER 10 ns WHEN 2, q <= i3 AFTER 10 ns WHEN 3, q <= 'X' AFTER 10 ns WHEN OTHERS; sel <= 0 WHEN a = '0' AND b = '0' ELSE 1 WHEN a = '1' AND b = '0' ELSE 2 WHEN a = '0' AND b = '1' ELSE 3 WHEN a = '1' AND b = '1' ELSE 4; END mux4; 

It is assumed that this is a behavioral model , according to one textbook. Besides the differences in the variable name, the only significant difference that I see here is that there is an additional statement

 WITH sel SELECT 

in the second case, and slight differences in syntax. This code II is parallel. But from other sources on the Internet (see below), I saw that the behavioral model should be consistent. Whom should I believe?

Now, from some other Internet sources, the definition of these models is as follows:

Behavioral - Circuit is described as an i / o relationship using sequential operators within a process.

Dataflow - a schema is described using parallel operators

San Jose State University

Behavioral - describes how output is derived from inputs using structured statements.

Dataflow - describes how data flows.

-Acron University of Engineering College

Here I do not understand what expressed expressions mean.

there is a process keyword in the behavior level

at the data flow level, there is a parallel operator (<=)


This has been seen on the online forum.

Is a process instruction required for a behavior model?

What is the actual difference between codes I and II? According to the author, they have different models, data flow and behavioral. I do not see how this is possible. What should I believe in?

Finally, in Perry DL, pp. 45, 46:

 LIBRARY IEEE; USE IEEE.std_logic_1164ALL; ENTITY mux IS PORT (i0, i1, i2, i3, a, b : IN std_logic; PORT (q : OUT std_logic); END mux; ARCHITECTURE better OF mux IS BEGIN PROCESS ( i0, i1, i2, i3, a, b ) VARIABLE muxval : INTEGER; BEGIN muxval := 0; IF (a = '1') THEN muxval := muxval + 1; END IF; IF (b = '1') THEN muxval := muxval + 2; END IF; CASE muxval IS WHEN 0 => q <= I0 AFTER 10 ns; WHEN 1 => q <= I1 AFTER 10 ns; WHEN 2 => q <= I2 AFTER 10 ns; WHEN 3 => q <= I3 AFTER 10 ns; WHEN OTHERS => NULL; END CASE; END PROCESS; END better; 

This is a serial version of MUX. According to other definitions, this should be behavioral, but the author does not say this. Could you resolve my confusion regarding these models?

+4
source share
3 answers

Do not look for a mathematically rigorous description of these terms; they are much more complicated than those that may overlap.

"Dataflow" I think it's pretty clear here; it describes the flow of data and describes it in terms of parallel operators. But I would add that each parallel operator is woken up by changes at its inputs and delivers its results; therefore (an important bit :) there is no correspondence between the order of what is happening and the order of elements in the source code. In this regard, it has much in common with functional programming. And both first models are a data stream; in (I) the elements are in a logical order, while (II) is not.

The “behavioral” MUST be clear enough - it simply describes the pattern in terms of its behavior.

But this does not contradict the flow of data at all - although your quote from San Jose is somewhat correct - the behavioral descriptions are usually consistent simply because the consistent paradigm (within the VHDL process) is common and familiar to programmers. However, the behavior of several of these processes interacting with each other is ... a data stream.

Behavioral then is NOT correctly the opposite of data flow. It is more precisely the opposite of RTL (case-transfer level) and structural, which have fairly clear meanings.

The structural description consists of a number of building blocks (gates, multiplexers, whole processors) and the signals connecting them: a text block diagram (possibly automatically generated from a graphic one). Thus, it can be either the lowest level (see Frequent questions here on how to make an adder out of the gate!), Or the highest level (connecting the CPU to the memory, peripherals, etc.).

The RTL description is pretty low; it describes the transfer and operations with data between storage elements (registers) and is common in the process; it is more like assembly language from the (behavioral) program C.

Finally, too many descriptions and too many extraneous details make it difficult to do the right design job. Look at the task in hand, extract its essence and realize it.

The multiplexer selects one of the set of input elements in accordance with the index of the desired element. The most natural form of an index is usually an integer type, rarely including negative indices, and the most natural form of collection in VHDL is ... an array.

So why not write

 ENTITY mux IS PORT ( a, b, c, d : in BIT; sel : in natural range 0 to 3; x : out BIT); END mux; ARCHITECTURE simple OF mux IS SIGNAL values : array (0 to 3) of BIT; BEGIN values <= a & b & c & d; x <= values(sel); -- after 0.5 ns; if you need to model timing! END simple; 

or better, make the "values" the input port ...

+5
source

There is a distinction between behavioral and structural realizations that are not well described in this book. Dataflow may be a poorly applied description for hardware based on who is trying to convey what.

I suspect the following: Spring 2008 Switching and Logic Lab jeg 1 Lab 2 - Behavioral and Streaming VHDL (PDF, 66KB, 12 pages) was provided to overcome the confusion of those readers of the book like you:

Within VHDL, we can describe logic in three different ways. These are three different architectures:

  • Behavioral - Describes how output is derived from inputs using structured statements.

  • Dataflow - describes how data most often comes from inputs to outputs using NOT, AND, and OR operations.

  • Structural - describes how gates are interconnected, similar to a schematic approach.

Dataflow can mean concurrency, while neither behavioral nor structural excludes either sequential or parallel descriptions. All parallel descriptions are converted into sequential processes for VHDL modeling, relying on delta simulation cycles to synchronize assignments of signals simulating concurrency.

There, this design network concept in the simulator, which reflects a design hierarchy, such as a diagram, can be represented by a list of flat networks.

There is good reason to use what is called Dataflow here, because the description of logical behavior with 9 level logic (MVL9, used by the std_logic_1164 package) leads to the propagation of unknown ("X") and uniintialized values ​​("U"). This leads to a closure between behavioral and structural models, without waving your arms around visible values ​​that you cannot reconcile between levels of abstraction, except for the exception. The stimulus and expected results coincide between the behavioral description of the data flow and structural implementation.

From experience, it’s a lot easier to get different levels of abstraction to fit than to hear from a foundry wishing to set aside the first silicone, waiting for you to approve the exceptions for the stimulus that you provided, plus, at least historically, the amount The exceptions you could make on the IC test were pretty limited. You could think of real silicon on the IC tester as a different level of abstraction.

To model different levels of abstraction in VHDL, you basically write a behavior model that behaves more closely to what the structural model will have. A

I found the above PDF by searching the “VHDL data stream” which shows a lot more sources of information.

0
source

Behavioral - describes how inference is derived from inputs using structured statements.

Dataflow - describes how data flows.

-Acron University of Engineering College

A data flow model requires a clear understanding of the data flow (i.e., physical circuitry). However, when using a behavioral model, you only need to pay attention to the basic design behavior. Thus, the behavioral model is easier to understand and maintain. For example, to implement a parallel factor

data flow model

You will need components such as registers, FAUs, multiplexers, etc. And you must implement them yourself. This is terrible, especially if the input numbers are 16-bit or more.

behavioral model

All you need to do is write an expression like this:

 p <= a * b; 

Whether the model is a single data stream or a behavioral one determines how you model the design. Sequential statements or parallel statements? It does not matter.

0
source

Source: https://habr.com/ru/post/1501142/


All Articles