doc: framebuffer example
[litex.git] / doc / fhdl.rst
1 The FHDL layer
2 ##############
3
4 The Fragmented Hardware Description Language (FHDL) is the lowest layer of Migen. It consists of a formal system to describe signals, and combinatorial and synchronous statements operating on them. The formal system itself is low level and close to the synthesizable subset of Verilog, and we then rely on Python algorithms to build complex structures by combining FHDL elements and encapsulating them in "fragments".
5 The FHDL module also contains a back-end to produce synthesizable Verilog, and some basic analysis functions. It would be possible to develop a VHDL back-end as well, though more difficult than for Verilog - we are "cheating" a bit now as Verilog provides most of the FHDL semantics.
6
7 FHDL differs from MyHDL [myhdl]_ in fundamental ways. MyHDL follows the event-driven paradigm of traditional HDLs (see :ref:`background`) while FHDL separates the code into combinatorial statements, synchronous statements, and reset values. In MyHDL, the logic is described directly in the Python AST. The converter to Verilog or VHDL then examines the Python AST and recognizes a subset of Python that it translates into V*HDL statements. This seriously impedes the capability of MyHDL to generate logic procedurally. With FHDL, you manipulate a custom AST from Python, and you can more easily design algorithms that operate on it.
8
9 .. [myhdl] http://www.myhdl.org
10
11 FHDL is made of several elements, which are briefly explained below.
12
13 Expressions
14 ***********
15
16 .. _bv:
17
18 Bit vector (BV)
19 ===============
20 The bit vector (BV) object defines if a constant or signal is signed or unsigned, and how many bits it has. This is useful e.g. to:
21
22 * Determine when to perform sign extension (FHDL uses the same rules as Verilog).
23 * Determine the size of registers.
24 * Determine how many bits should be used by each value in concatenations.
25
26 Constant
27 ========
28 This object should be self-explanatory. All constant objects contain a BV object and a value. If no BV object is specified, one will be made up using the following rules:
29
30 * If the value is positive, the BV is unsigned and has the minimum number of bits needed to represent the constant's value in the canonical base-2 system.
31 * If the value is negative, the BV is signed, and has the minimum number of bits needed to represent the constant's value in the canonical two's complement, base-2 system.
32
33 Signal
34 ======
35 The signal object represents a value that is expected to change in the circuit. It does exactly what Verilog's "wire" and "reg" and VHDL's "signal" and "variable" do.
36
37 The main point of the signal object is that it is identified by its Python ID (as returned by the :py:func:`id` function), and nothing else. It is the responsibility of the V*HDL back-end to establish an injective mapping between Python IDs and the V*HDL namespace. It should perform name mangling to ensure this. The consequence of this is that signal objects can safely become members of arbitrary Python classes, or be passed as parameters to functions or methods that generate logic involving them.
38
39 The properties of a signal object are:
40
41 * A bit vector description
42 * A name, used as a hint for the V*HDL back-end name mangler.
43 * A boolean "variable". If true, the signal will behave like a VHDL variable, or a Verilog reg that uses blocking assignment. This parameter only has an effect when the signal's value is modified in a synchronous statement.
44 * The signal's reset value. It must be an integer, and defaults to 0. When the signal's value is modified with a synchronous statement, the reset value is the initialization value of the associated register. When the signal is assigned to in a conditional combinatorial statement (``If`` or ``Case``), the reset value is the value that the signal has when no condition that causes the signal to be driven is verified. This enforces the absence of latches in designs. If the signal is permanently driven using a combinatorial statement, the reset value has no effect.
45
46 The sole purpose of the name property is to make the generated V*HDL code easier to understand and debug. From a purely functional point of view, it is perfectly OK to have several signals with the same name property. The back-end will generate a unique name for each object. If no name property is specified, Migen will analyze the code that created the signal object, and try to extract the variable or member name from there. For example, the following statements will create one or several signals named "bar": ::
47
48 bar = Signal()
49 self.bar = Signal()
50 self.baz.bar = Signal()
51 bar = [Signal() for x in range(42)]
52
53 In case of conflicts, Migen tries first to resolve the situation by prefixing the identifiers with names from the class and module hierarchy that created them. If the conflict persists (which can be the case if two signal objects are created with the same name in the same context), it will ultimately add number suffixes.
54
55 Operators
56 =========
57 Operators are represented by the ``_Operator`` object, which generally should not be used directly. Instead, most FHDL objects overload the usual Python logic and arithmetic operators, which allows a much lighter syntax to be used. For example, the expression: ::
58
59 a * b + c
60
61 is equivalent to::
62
63 _Operator("+", [_Operator("*", [a, b]), c])
64
65 Slices
66 ======
67 Likewise, slices are represented by the ``_Slice`` object, which often should not be used in favor of the Python slice operation [x:y]. Implicit indices using the forms [x], [x:] and [:y] are supported. Beware! Slices work like Python slices, not like VHDL or Verilog slices. The first bound is the index of the LSB and is inclusive. The second bound is the index of MSB and is exclusive. In V*HDL, bounds are MSB:LSB and both are inclusive.
68
69 Concatenations
70 ==============
71 Concatenations are done using the ``Cat`` object. To make the syntax lighter, its constructor takes a variable number of arguments, which are the signals to be concatenated together (you can use the Python "*" operator to pass a list instead).
72 To be consistent with slices, the first signal is connected to the bits with the lowest indices in the result. This is the opposite of the way the "{}" construct works in Verilog.
73
74 Replications
75 ============
76 The ``Replicate`` object represents the equivalent of {count{expression}} in Verilog.
77
78 Statements
79 **********
80
81 Assignment
82 ==========
83 Assignments are represented with the ``_Assign`` object. Since using it directly would result in a cluttered syntax, the preferred technique for assignments is to use the ``eq()`` method provided by objects that can have a value assigned to them. They are signals, and their combinations with the slice and concatenation operators.
84 As an example, the statement: ::
85
86 a[0].eq(b)
87
88 is equivalent to: ::
89
90 _Assign(_Slice(a, 0, 1), b)
91
92 If
93 ==
94 The ``If`` object takes a first parameter which must be an expression (combination of the ``Constant``, ``Signal``, ``_Operator``, ``_Slice``, etc. objects) representing the condition, then a variable number of parameters representing the statements (``_Assign``, ``If``, ``Case``, etc. objects) to be executed when the condition is verified.
95
96 The ``If`` object defines a ``Else()`` method, which when called defines the statements to be executed when the condition is not true. Those statements are passed as parameters to the variadic method.
97
98 For convenience, there is also a ``Elif()`` method.
99
100 Example: ::
101
102 If(tx_count16 == 0,
103 tx_bitcount.eq(tx_bitcount + 1),
104 If(tx_bitcount == 8,
105 self.tx.eq(1)
106 ).Elif(tx_bitcount == 9,
107 self.tx.eq(1),
108 tx_busy.eq(0)
109 ).Else(
110 self.tx.eq(tx_reg[0]),
111 tx_reg.eq(Cat(tx_reg[1:], 0))
112 )
113 )
114
115 Case
116 ====
117 The ``Case`` object constructor takes as first parameter the expression to be tested, then a variable number of lists describing the various cases.
118
119 Each list contains an expression (typically a constant) describing the value to be matched, followed by the statements to be executed when there is a match. The head of the list can be the an instance of the ``Default`` object.
120
121 Arrays
122 ======
123 The ``Array`` object represents lists of other objects that can be indexed by FHDL expressions. It is explicitely possible to:
124
125 * nest ``Array`` objects to create multidimensional tables.
126 * list any Python object in a ``Array`` as long as every expression appearing in a fragment ultimately evaluates to a ``Signal`` for all possible values of the indices. This allows the creation of lists of structured data.
127 * use expressions involving ``Array`` objects in both directions (assignment and reading).
128
129 For example, this creates a 4x4 matrix of 1-bit signals: ::
130
131 my_2d_array = Array(Array(Signal() for a in range(4)) for b in range(4))
132
133 You can then read the matrix with (``x`` and ``y`` being 2-bit signals): ::
134
135 out.eq(my_2d_array[x][y])
136
137 and write it with: ::
138
139 my_2d_array[x][y].eq(inp)
140
141 Since they have no direct equivalent in Verilog, ``Array`` objects are lowered into multiplexers and conditional statements before the actual conversion takes place. Such lowering happens automatically without any user intervention.
142
143 Special elements
144 ****************
145
146 Instances
147 =========
148 Instance objects represent the parametrized instantiation of a V*HDL module, and the connection of its ports to FHDL signals. They are useful in a number of cases:
149
150 * Reusing legacy or third-party V*HDL code.
151 * Using special FPGA features (DCM, ICAP, ...).
152 * Implementing logic that cannot be expressed with FHDL (asynchronous circuits, ...).
153 * Breaking down a Migen system into multiple sub-systems, possibly using different clock domains.
154
155 The properties of the instance object are:
156
157 * The type of the instance (i.e. name of the instantiated module).
158 * A list of output ports of the instantiated module. Each element of the list is a pair containing a string, which is the name of the module's port, and either an existing signal (on which the port will be connected to) or a BV (which will cause the creation of a new signal).
159 * A list of input ports (likewise).
160 * A list of (name, value) pairs for the parameters ("generics" in VHDL) of the module.
161 * The name of the clock port of the module (if any). If this is specified, the port will be connected to the system clock.
162 * The name of the reset port of the module (likewise).
163 * The name of the instance (can be mangled like signal names).
164
165 Memories
166 ========
167 Memories (on-chip SRAM) are supported using a mechanism similar to instances.
168
169 A memory object has the following parameters:
170
171 * The width, which is the number of bits in each word.
172 * The depth, which represents the number of words in the memory.
173 * An optional list of integers used to initialize the memory.
174 * A list of port descriptions.
175
176 Each port description contains:
177
178 * The address signal (mandatory).
179 * The data read signal (mandatory).
180 * The write enable signal (optional). If the port is using masked writes, the width of the write enable signal should match the number of sub-words.
181 * The data write signal (iff there is a write enable signal).
182 * Whether reads are synchronous (default) or asynchronous.
183 * The read enable port (optional, ignored for asynchronous ports).
184 * The write granularity (default 0), which defines the number of bits in each sub-word. If it is set to 0, the port is using whole-word writes only and the width of the write enable signal must be 1. This parameter is ignored if there is no write enable signal.
185 * The mode of the port (default ``WRITE_FIRST``, ignored for asynchronous ports). It can be:
186
187 * ``READ_FIRST``: during a write, the previous value is read.
188 * ``WRITE_FIRST``: the written value is returned.
189 * ``NO_CHANGE``: the data read signal keeps its previous value on a write.
190
191 Migen generates behavioural V*HDL code that should be compatible with all simulators and, if the number of ports is <= 2, most FPGA synthesizers. If a specific code is needed, the memory generator function can be overriden using the ``memory_handler`` parameter of the conversion function.
192
193 Fragments
194 *********
195 A "fragment" is a unit of logic, which is composed of:
196
197 * A list of combinatorial statements.
198 * A list of synchronous statements.
199 * A list of instances.
200 * A list of memories.
201 * A list of simulation functions (see :ref:`simulating`).
202
203 Fragments can reference arbitrary signals, including signals that are referenced in other fragments. Fragments can be combined using the "+" operator, which returns a new fragment containing the concatenation of each pair of lists.
204
205 Fragments can be passed to the back-end for conversion to Verilog.
206
207 By convention, classes that generate logic implement a method called ``get_fragment``. When called, this method builds a new fragment implementing the desired functionality of the class, and returns it. This convention allows fragments to be built automatically by combining the fragments from all relevant objects in the local scope, by using the autofragment module.
208
209 Conversion for synthesis
210 ************************
211
212 Any FHDL fragment (except, of course, its simulation functions) can be converted into synthesizable Verilog HDL. This is accomplished by using the ``convert`` function in the ``verilog`` module.
213
214 Migen does not provide support for any specific synthesis tools or ASIC/FPGA technologies. Users must run themselves the generated code through the appropriate tool flow for hardware implementation.