Difference between revisions of "Protocol decoder:Parallel"
Uwe Hermann (talk | contribs) m |
(catch up with recent decoder features) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 10: | Line 10: | ||
| output = parallel | | output = parallel | ||
| probes = — | | probes = — | ||
| optional_probes = CLK, D0- | | optional_probes = CLK, D0-D15, RST | ||
| options = clock_edge, reset_polarity, wordsize, endianness | |||
}} | }} | ||
The '''parallel''' protocol decoder can decode synchronous parallel buses with various number of data bits/probes and | The '''parallel''' protocol decoder can decode (synchronous or asynchronous) parallel buses with various number of data bits/probes, an optional clock, and an optional select/enable/reset line. | ||
== Hardware == | == Hardware == | ||
There's a lot of hardware (ICs, connectors) that uses various kinds of sync or async parallel protocols. | |||
Generally there are a number of data lines (e.g. 8 or 16) and (in the synchronous case) a clock line. Memory buses may also involve a select or enable or clear/reset signal. | |||
== Protocol == | == Protocol == | ||
Data lines get sampled on the falling, or rising, or either clock edge. When no clock signal is provided, data values are updated on any change on any of the data lines (which can be perceived as noisy depending on the input data). Not connected data lines are assumed to be at logical low level, which allows to inspect "wide" buses with a few probes. | |||
An optional reset signal can pause the interpretation of the data lines, and/or improve synchronization to input data streams. This typical use case can extract data values from parallel busses (memory addresses, data bits, including multiplexed transfer). | |||
Another non-obvious use case is the extraction of (clocked) serial data by means of the "words" extraction across a given number of bus cycles. Not only can the parallel decoder double as an alternative to single wire SPI, it can also deal with arbitrary bit counts that need not align with byte boundaries. | |||
<gallery> | |||
File:Parallel-sqi-io4.png|<small>SQI (multi-I/O SPI communication) decoding</small> | |||
</gallery> | |||
== Resources == | == Resources == | ||
Latest revision as of 21:18, 11 November 2020
 | |
| Name | Parallel |
|---|---|
| Description | Generic parallel synchronous bus |
| Status | supported |
| License | GPLv2+ |
| Source code | decoders/parallel |
| Input | logic |
| Output | parallel |
| Probes | — |
| Optional probes | CLK, D0-D15, RST |
| Options | clock_edge, reset_polarity, wordsize, endianness |
The parallel protocol decoder can decode (synchronous or asynchronous) parallel buses with various number of data bits/probes, an optional clock, and an optional select/enable/reset line.
Hardware
There's a lot of hardware (ICs, connectors) that uses various kinds of sync or async parallel protocols.
Generally there are a number of data lines (e.g. 8 or 16) and (in the synchronous case) a clock line. Memory buses may also involve a select or enable or clear/reset signal.
Protocol
Data lines get sampled on the falling, or rising, or either clock edge. When no clock signal is provided, data values are updated on any change on any of the data lines (which can be perceived as noisy depending on the input data). Not connected data lines are assumed to be at logical low level, which allows to inspect "wide" buses with a few probes.
An optional reset signal can pause the interpretation of the data lines, and/or improve synchronization to input data streams. This typical use case can extract data values from parallel busses (memory addresses, data bits, including multiplexed transfer).
Another non-obvious use case is the extraction of (clocked) serial data by means of the "words" extraction across a given number of bus cycles. Not only can the parallel decoder double as an alternative to single wire SPI, it can also deal with arbitrary bit counts that need not align with byte boundaries.
SQI (multi-I/O SPI communication) decoding
