You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/SpinalHDL/Libraries/Pipeline/introduction.rst
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,13 +186,13 @@ You can access its arbitration via :
186
186
- Description
187
187
* - ``node.valid``
188
188
- RW
189
-
- Is the signal which specifies if a transaction is present on the node. It is driven by the upstream. Once asserted, it must only be de-asserted the cycle after which either both valid and ready or node.cancel are high. valid must not depend on ready.
189
+
- Is the signal which specifies if a transaction is present on the node. It is driven by the upstream. Once asserted, it must only be de-asserted the cycle after which either both ``valid`` and ``ready`` or ``node.cancel`` are high. ``valid`` must not depend on ``ready``.
190
190
* - ``node.ready``
191
191
- RW
192
-
- Is the signal which specifies if the node's transaction can proceed downstream. It is driven by the downstream to create backpressure. The signal has no meaning when there is no transaction (node.valid being deasserted)
192
+
- Is the signal which specifies if the node's transaction can proceed downstream. It is driven by the downstream to create backpressure. The signal has no meaning when there is no transaction (``node.valid`` being deasserted).
193
193
* - ``node.cancel``
194
194
- RW
195
-
- Is the signal which specifies if the node's transaction in being canceled from the pipeline. It is driven by the downstream. The signal has no meaning when there is no transaction (node.valid being deasserted)
195
+
- Is the signal which specifies if the node's transaction in being canceled from the pipeline. It is driven by the downstream. The signal has no meaning when there is no transaction (``node.valid`` being deasserted)
196
196
* - ``node.isValid``
197
197
- RO
198
198
- ``node.valid``'s read only accessor
@@ -204,15 +204,15 @@ You can access its arbitration via :
204
204
- ``node.cancel``'s read only accessor
205
205
* - ``node.isFiring``
206
206
- RO
207
-
- True when the node transaction is successfully moving further (valid && ready && !cancel). Useful to commit state changes.
207
+
- ``True`` when the node transaction is successfully moving further (``valid && ready && !cancel``). Useful to commit state changes.
208
208
* - ``node.isMoving``
209
209
- RO
210
-
- True when the node transaction will not be present anymore on the node (starting from the next cycle),
210
+
- ``True`` when the node transaction will not be present anymore on the node (starting from the next cycle),
211
211
either because downstream is ready to take the transaction,
212
-
or because the transaction is canceled from the pipeline. (``valid && (ready || cancel)``). Useful to "reset" states.
212
+
or because the transaction is canceled from the pipeline (``valid && (ready || cancel)``). Useful to "reset" states.
213
213
* - ``node.isCanceling``
214
214
- RO
215
-
- True when the node transaction is being canceled. Meaning that it will not appear anywhere in the pipeline in future cycles.
215
+
- True when the node transaction is being cleaned up. Meaning that it will not appear anywhere in the pipeline in future cycles. It is equivalent to ``isValid && isCancel``.
216
216
217
217
Note that the ``node.valid``/``node.ready`` signals follows the same conventions than
Copy file name to clipboardExpand all lines: source/SpinalHDL/Libraries/stream.rst
+43-7Lines changed: 43 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,6 +113,10 @@ Functions
113
113
- Return True when a transaction is stall on the bus (valid && ! ready)
114
114
- Bool
115
115
-
116
+
* - x.isFree
117
+
- Return True when the bus isn't stuck with a transaction (!isStall)
118
+
- Bool
119
+
-
116
120
* - x.queue(size:Int)
117
121
- Return a Stream connected to x through a FIFO
118
122
- Stream[T]
@@ -219,20 +223,47 @@ On each stream you can call the .queue(size) to get a buffered stream. But you c
219
223
myFifo.io.push << streamA
220
224
myFifo.io.pop >> streamB
221
225
226
+
227
+
Mandatory parameters:
228
+
222
229
.. list-table::
223
230
:header-rows: 1
224
231
:widths: 1 1 2
225
232
226
-
* - parameter name
233
+
* - Name
227
234
- Type
228
235
- Description
229
236
* - dataType
230
237
- T
231
238
- Payload data type
232
239
* - depth
233
240
- Int
234
-
- Size of the memory used to store elements
241
+
- Number of element stored in the fifo, Note that if ``withAsyncRead==false``, then one extra transaction can be stored.
242
+
243
+
Optional parameters:
235
244
245
+
.. list-table::
246
+
:header-rows: 1
247
+
:widths: 1 1 2
248
+
249
+
* - Name
250
+
- Default
251
+
- Description
252
+
* - withAsyncRead
253
+
- ``false``
254
+
- Read the memory using asynchronous read port (ex distributed ram). If false, add 1 cycle latency.
255
+
* - withBypass
256
+
- ``false``
257
+
- Bypass the push port to the pop port when the fifo is empty.If false, add 1 cycle latency. Only available if ``withAsyncRead == true``.
258
+
* - forFMax
259
+
- ``false``
260
+
- Tune the design to get the maximal clock frequency.
261
+
* - useVec
262
+
- ``false``
263
+
- Use an ``Vec`` of register instead of a Mem to store the content
264
+
* - initPayload
265
+
- ``None``
266
+
- A ``=> Option[T]`` function that return a value to init the ``Vec`` register, only meaningful when ``useVec == true``
236
267
237
268
.. list-table::
238
269
:header-rows: 1
@@ -420,10 +451,10 @@ When you have multiple Streams and you want to arbitrate them to drive a single
420
451
.. code-block:: scala
421
452
422
453
val streamA, streamB, streamC = Stream(Bits(8 bits))
423
-
val arbitredABC = StreamArbiterFactory.roundRobin.onArgs(streamA, streamB, streamC)
454
+
val arbiteredABC = StreamArbiterFactory.roundRobin.onArgs(streamA, streamB, streamC)
424
455
425
456
val streamD, streamE, streamF = Stream(Bits(8 bits))
426
-
val arbitredDEF = StreamArbiterFactory.lowerFirst.noLock.onArgs(streamD, streamE, streamF)
457
+
val arbiteredDEF = StreamArbiterFactory.lowerFirst.noLock.onArgs(streamD, streamE, streamF)
427
458
428
459
.. list-table::
429
460
:header-rows: 1
@@ -490,7 +521,7 @@ all output streams have processed each item regardlessly.
490
521
.. code-block:: scala
491
522
492
523
val inputStream = Stream(Bits(8 bits))
493
-
val (outputstream1, outputstream2) = StreamFork2(inputStream, synchronous=false)
524
+
val (outputStream1, outputStream2) = StreamFork2(inputStream, synchronous=false)
494
525
495
526
or
496
527
@@ -558,11 +589,16 @@ The ``count`` is captured and registered each time inputStream fires for an indi
558
589
val extender = StreamTransactionExtender(inputStream, outputStream, count) {
559
590
// id, is the 0-based index of total output transfers so far in the current input transaction.
560
591
// last, is the last transfer indication, same as the last signal for extender.
561
-
// the returned payload is allowed to be modified only based on id and last signals, other translation should be done outside of this.
592
+
// the returned payload is allowed to be modified only based on id and last signals, other
593
+
// translation should be done outside of this.
562
594
(id, payload, last) => payload
563
595
}
564
596
565
-
This ``extender`` provides several status signals, such as ``working``, ``last``, ``done`` where ``working`` means there is one input transfer accepted and in-progress, ``last`` indicates the last output transfer is prepared and waiting to complete, ``done`` become valid represents the last output transfer is fireing and making the current input transaction process complete and ready to start another transaction.
597
+
This ``extender`` provides several status signals, such as ``working``, ``last``, ``done`` where
598
+
``working`` means there is one input transfer accepted and in-progress, ``last`` indicates the last
599
+
output transfer is prepared and waiting to complete, ``done`` become valid represents the last
600
+
output transfer is firing and making the current input transaction process complete and ready to
0 commit comments