1 |
4 |
jondawson |
===============================
|
2 |
|
|
Reference Manual
|
3 |
|
|
===============================
|
4 |
|
|
|
5 |
|
|
Download
|
6 |
|
|
========
|
7 |
|
|
|
8 |
|
|
You can download the
|
9 |
|
|
`source `_
|
10 |
|
|
from the
|
11 |
|
|
`Git Hub `_
|
12 |
|
|
homepage. Alternatively clone the project using git::
|
13 |
|
|
|
14 |
|
|
~$ git clone https://github.com/dawsonjon/Chips-2.0.git
|
15 |
|
|
|
16 |
|
|
|
17 |
|
|
Install
|
18 |
|
|
=======
|
19 |
|
|
|
20 |
|
|
1. First `install Python `_. You need *Python* 2.6 or later, but not *Python* 3.
|
21 |
|
|
2. In the Linux console, or the Windows command line (you will need
|
22 |
|
|
administrator privileges)::
|
23 |
|
|
|
24 |
|
|
~$ cd Chips-2.0
|
25 |
|
|
~$ python setup.py install
|
26 |
|
|
|
27 |
|
|
Icarus Verilog
|
28 |
|
|
==============
|
29 |
|
|
|
30 |
|
|
This example uses the `Icarus Verilog `_
|
31 |
|
|
simulator, you will need this installed in your command path to follow this
|
32 |
|
|
tutorial.
|
33 |
|
|
|
34 |
|
|
C Components
|
35 |
|
|
============
|
36 |
|
|
|
37 |
|
|
This section of the manual describes the subset of the C language that is available in *Chips*.
|
38 |
|
|
|
39 |
|
|
Types
|
40 |
|
|
-----
|
41 |
|
|
|
42 |
|
|
The following types are available in chips:
|
43 |
|
|
|
44 |
|
|
+ `char`
|
45 |
|
|
+ `int`
|
46 |
|
|
+ `long`
|
47 |
|
|
+ `unsigned char`
|
48 |
|
|
+ `unsigned int`
|
49 |
|
|
+ `unsigned long`
|
50 |
|
|
+ `float`
|
51 |
|
|
|
52 |
|
|
A `char` is at least 8 bits wide. An `int` is at least 16 bits wide. A `long`
|
53 |
|
|
is at least 32 bits wide.
|
54 |
|
|
|
55 |
|
|
The `float` type is implemented as an IEEE 754 single precision floating point
|
56 |
|
|
number.
|
57 |
|
|
|
58 |
|
|
At present, `long long`, `float` and `double` have not been implemented, but I
|
59 |
|
|
plan to add support for these types in a later release.
|
60 |
|
|
|
61 |
|
|
single dimensional arrays, `char[]`, `int[]` and `long[]` are supported, but
|
62 |
|
|
multidimensional arrays are not yet supported.
|
63 |
|
|
|
64 |
|
|
`struct` s are supported, you can define arrays of `struct` s, and `struct` s
|
65 |
|
|
may contain arrays.
|
66 |
|
|
|
67 |
|
|
`struct` s cannot yet be passed to a function or returned from a function.
|
68 |
|
|
|
69 |
|
|
Arrays may be passed (by reference) to functions.
|
70 |
|
|
|
71 |
|
|
Pointers are not supported, and neither is dynamic memory allocation. This is a
|
72 |
|
|
deliberate decision with low memory FPGAs in mind, and probably won't be
|
73 |
|
|
supported in future releases.
|
74 |
|
|
|
75 |
|
|
Functions
|
76 |
|
|
---------
|
77 |
|
|
|
78 |
|
|
Functions are supported. They may be nested, but may not be recursive. Only a
|
79 |
|
|
fixed number of arguments is supported, optional arguments are not permitted.
|
80 |
|
|
|
81 |
|
|
Control Structures
|
82 |
|
|
------------------
|
83 |
|
|
|
84 |
|
|
The following control structures are supported:
|
85 |
|
|
|
86 |
|
|
+ if/else statements
|
87 |
|
|
+ while loop
|
88 |
|
|
+ for loop
|
89 |
|
|
+ break/continue statements
|
90 |
|
|
+ switch/case statements
|
91 |
|
|
|
92 |
|
|
Operators
|
93 |
|
|
---------
|
94 |
|
|
|
95 |
|
|
The following operators are supported, in order of preference:
|
96 |
|
|
|
97 |
|
|
+ `()`
|
98 |
|
|
+ `~` `-` `!` `sizeof` (unary operators)
|
99 |
|
|
+ `*` `/` `%`
|
100 |
|
|
+ `+` `-`
|
101 |
|
|
+ `<<` `>>`
|
102 |
|
|
+ `<` `>` `<=` `>=`
|
103 |
|
|
+ `==` `!=`
|
104 |
|
|
+ `&`
|
105 |
|
|
+ '^`
|
106 |
|
|
+ `|`
|
107 |
|
|
+ `&&`
|
108 |
|
|
+ `||`
|
109 |
|
|
+ \`? : `
|
110 |
|
|
|
111 |
|
|
|
112 |
|
|
Stream I/O
|
113 |
|
|
----------
|
114 |
|
|
|
115 |
|
|
The language has been extended to allow components to communicate by sending
|
116 |
|
|
data through streams.
|
117 |
|
|
|
118 |
|
|
Stream I/O is achieved by calling built-in functions with special names.
|
119 |
|
|
Functions that start with the name `input` or `output` are interpreted as "read
|
120 |
|
|
from input", or "write to output".
|
121 |
|
|
|
122 |
|
|
.. code-block:: c
|
123 |
|
|
|
124 |
|
|
int temp;
|
125 |
|
|
temp = input_spam(); //reads from an input called spam
|
126 |
|
|
temp = input_eggs(); //reads from an input called eggs
|
127 |
|
|
output_fish(temp); //writes to an output called fish
|
128 |
|
|
|
129 |
|
|
Reading or writing from inputs and outputs causes program execution to block
|
130 |
|
|
until data is available. If you don't want to commit yourself to reading and
|
131 |
|
|
input and blocking execution, you can check if data is ready.
|
132 |
|
|
|
133 |
|
|
.. code-block:: c
|
134 |
|
|
|
135 |
|
|
int temp;
|
136 |
|
|
if(ready_spam()){
|
137 |
|
|
temp = input_spam();
|
138 |
|
|
}
|
139 |
|
|
|
140 |
|
|
There is no equivalent function to check if an output is ready to receive data,
|
141 |
|
|
this could cause deadlocks if both the sending and receiving end were waiting
|
142 |
|
|
for one another.
|
143 |
|
|
|
144 |
|
|
Timed Waits
|
145 |
|
|
-----------
|
146 |
|
|
|
147 |
|
|
Timed waits can be achieved using the built-in `wait-clocks` function. The
|
148 |
|
|
wait_clocks function accepts a single argument, the numbers of clock cycles to
|
149 |
|
|
wait.
|
150 |
|
|
|
151 |
|
|
.. code-block:: c
|
152 |
|
|
|
153 |
|
|
wait_clocks(100); //wait for 1 us with 100MHz clock
|
154 |
|
|
|
155 |
|
|
|
156 |
|
|
Debug and Test
|
157 |
|
|
--------------
|
158 |
|
|
|
159 |
|
|
The built in `report` function displays the value of an expression in the
|
160 |
|
|
simulation console. This will have no effect in a synthesised design.
|
161 |
|
|
|
162 |
|
|
.. code-block:: c
|
163 |
|
|
|
164 |
|
|
int temp = 4;
|
165 |
|
|
report(temp); //prints 4 to console
|
166 |
|
|
report(10); //prints 10 to the console
|
167 |
|
|
|
168 |
|
|
|
169 |
|
|
The built in function assert causes a simulation error if it is passed a zero
|
170 |
|
|
value. The assert function has no effect in a synthesised design.
|
171 |
|
|
|
172 |
|
|
.. code-block:: c
|
173 |
|
|
|
174 |
|
|
int temp = 5;
|
175 |
|
|
assert(temp); //does not cause an error
|
176 |
|
|
int temp = 0;
|
177 |
|
|
assert(temp); //will cause a simulation error
|
178 |
|
|
assert(2+2==5); //will cause a simulation error
|
179 |
|
|
|
180 |
|
|
In simulation, you can write values to a file using the built-in `file_write`
|
181 |
|
|
function. The first argument is the value to write, and the second argument is
|
182 |
|
|
the file to write to. The file will be overwritten when the simulation starts,
|
183 |
|
|
and subsequent calls will append a new vale to the end of the file. Each value
|
184 |
|
|
will appear in decimal format on a separate line. A file write has no effect in
|
185 |
|
|
a synthesised design.
|
186 |
|
|
|
187 |
|
|
.. code-block:: c
|
188 |
|
|
|
189 |
|
|
file_write(1, "simulation_log.txt");
|
190 |
|
|
file_write(2, "simulation_log.txt");
|
191 |
|
|
file_write(3, "simulation_log.txt");
|
192 |
|
|
file_write(4, "simulation_log.txt");
|
193 |
|
|
|
194 |
|
|
You can also read values from a file during simulation. A simulation error will
|
195 |
|
|
occur if there are no more value in the file.
|
196 |
|
|
|
197 |
|
|
.. code-block:: c
|
198 |
|
|
|
199 |
|
|
assert(file_read("simulation_log.txt") == 1);
|
200 |
|
|
assert(file_read("simulation_log.txt") == 2);
|
201 |
|
|
assert(file_read("simulation_log.txt") == 3);
|
202 |
|
|
assert(file_read("simulation_log.txt") == 4);
|
203 |
|
|
|
204 |
|
|
|
205 |
|
|
C Preprocessor
|
206 |
|
|
--------------
|
207 |
|
|
|
208 |
|
|
The C preprocessor currently has only limited capabilities, and currently only
|
209 |
|
|
the `#include` feature is supported.
|
210 |
|
|
|
211 |
|
|
Built in Libraries
|
212 |
|
|
==================
|
213 |
|
|
|
214 |
|
|
The C standard library is not supported. The intention is to provide a build-in
|
215 |
|
|
library with some basic utilities appropriate for FPGA design. At present
|
216 |
|
|
`print.h` is the only library provided.
|
217 |
|
|
|
218 |
|
|
print.h
|
219 |
|
|
-------
|
220 |
|
|
|
221 |
|
|
The `print_string` function prints a null terminated string to standard output.
|
222 |
|
|
|
223 |
|
|
.. code-block:: c
|
224 |
|
|
|
225 |
|
|
void print_string(char string[])
|
226 |
|
|
|
227 |
|
|
The `print_decimal` function prints a number in decimal to standard output.
|
228 |
|
|
|
229 |
|
|
.. code-block:: c
|
230 |
|
|
|
231 |
|
|
void print_decimal(int value)
|
232 |
|
|
|
233 |
|
|
The `print_hex` function prints a number in hexadecimal format to standard output.
|
234 |
|
|
|
235 |
|
|
.. code-block:: c
|
236 |
|
|
|
237 |
|
|
void print_hex(int value)
|
238 |
|
|
|
239 |
|
|
To provide most flexibility, the definition of standard_output is left to the
|
240 |
|
|
user, it could be a serial port, an LCD display, or perhaps a telnet session.
|
241 |
|
|
To define standard output, a function `stdout_put_char` function must be
|
242 |
|
|
defined before including print.h.
|
243 |
|
|
|
244 |
|
|
.. code-block:: c
|
245 |
|
|
|
246 |
|
|
void stdout_put_char(char value){
|
247 |
|
|
output_rs232_tx(value);
|
248 |
|
|
}
|
249 |
|
|
|
250 |
|
|
#include
|
251 |
|
|
|
252 |
|
|
print_string("Hello World!\n"); //Hello World
|
253 |
|
|
print_decimal(12345); //12345
|
254 |
|
|
print_hex(127); //0x7f
|
255 |
|
|
|
256 |
|
|
c2verilog
|
257 |
|
|
---------
|
258 |
|
|
|
259 |
|
|
For simple designs with only one C component, the simplest way to generate Verilog is by using the c2verilog utility.
|
260 |
|
|
The utility accepts C files as input, and generates Verilog files as output.
|
261 |
|
|
|
262 |
|
|
::
|
263 |
|
|
|
264 |
|
|
~$ c2verilog input_file.c
|
265 |
|
|
|
266 |
|
|
You may automatically compile the output using Icarus Verilog by adding the
|
267 |
|
|
`iverilog` option. You may also run the Icarus Verilog simulation using the
|
268 |
|
|
`run` option.
|
269 |
|
|
|
270 |
|
|
::
|
271 |
|
|
|
272 |
|
|
~$ c2verilog iverilog run input_file.c
|
273 |
|
|
|
274 |
|
|
You can also influence the way the Verilog is generated. By default, a low area
|
275 |
|
|
solution is implemented. If you can specify a design optimised for speed using
|
276 |
|
|
the `speed` option.
|
277 |
|
|
|
278 |
|
|
Python API
|
279 |
|
|
==========
|
280 |
|
|
|
281 |
|
|
The C language provides the ability to define components. The Python API
|
282 |
|
|
provides the ability to build systems from C components.
|
283 |
|
|
|
284 |
|
|
To use the Python API, you must import it.
|
285 |
|
|
|
286 |
|
|
.. code-block:: python
|
287 |
|
|
|
288 |
|
|
from chips.api.api import *
|
289 |
|
|
|
290 |
|
|
Chip
|
291 |
|
|
----
|
292 |
|
|
|
293 |
|
|
Once you have imported the Python API, you can define a chip. A chip is a
|
294 |
|
|
canvas to which you can add inputs outputs, components and wires. When you
|
295 |
|
|
create a chips all you need to give it is a name.
|
296 |
|
|
|
297 |
|
|
.. code-block:: python
|
298 |
|
|
|
299 |
|
|
mychip = Chip("mychip")
|
300 |
|
|
|
301 |
|
|
Wire
|
302 |
|
|
----
|
303 |
|
|
|
304 |
|
|
You can create `Input`, `Output` and `Wires` objects. A `Wire` is a point to point connection, a stream, that connects an output from one component to the input of another. A `Wire` can only have one source of data, and one data sink. When you create a `Wire`, you must tell it which `Chip` it belongs to:
|
305 |
|
|
|
306 |
|
|
.. code-block:: python
|
307 |
|
|
|
308 |
|
|
wire_a = Wire(mychip)
|
309 |
|
|
wire_b = Wire(mychip)
|
310 |
|
|
|
311 |
|
|
Input
|
312 |
|
|
-----
|
313 |
|
|
|
314 |
|
|
An `Input` takes data from outside the `Chip`, and feeds it into the input of a
|
315 |
|
|
`Component`. When you create an `Input`, you need to specify the `Chip` it
|
316 |
|
|
belongs to, and the name it will be given.
|
317 |
|
|
|
318 |
|
|
.. code-block:: python
|
319 |
|
|
|
320 |
|
|
input_a = Input(mychip, "A")
|
321 |
|
|
input_b = Input(mychip, "B")
|
322 |
|
|
input_c = Input(mychip, "C")
|
323 |
|
|
input_d = Input(mychip, "D")
|
324 |
|
|
|
325 |
|
|
Output
|
326 |
|
|
------
|
327 |
|
|
|
328 |
|
|
An `Output` takes data from a `Component` output, and sends it outside the
|
329 |
|
|
`Chip`. When you create an `Output` you must tell it which `Chip` it belongs
|
330 |
|
|
to, and the name it will be given.
|
331 |
|
|
|
332 |
|
|
Component
|
333 |
|
|
---------
|
334 |
|
|
|
335 |
|
|
From Python, you can import a C component by specifying the file where it is
|
336 |
|
|
defined. When you import a C component it will be compiled.
|
337 |
|
|
|
338 |
|
|
The C file adder.c defines a two input adder.
|
339 |
|
|
|
340 |
|
|
.. code-block:: python
|
341 |
|
|
|
342 |
|
|
//adder.c
|
343 |
|
|
|
344 |
|
|
void adder(){
|
345 |
|
|
while(1){
|
346 |
|
|
output_z(input_a() + input_b());
|
347 |
|
|
}
|
348 |
|
|
}
|
349 |
|
|
|
350 |
|
|
.. code-block:: python
|
351 |
|
|
|
352 |
|
|
adder = Component("source/adder.c")
|
353 |
|
|
|
354 |
|
|
Instances
|
355 |
|
|
---------
|
356 |
|
|
|
357 |
|
|
You can make many instances of a component by "calling" the component. Each
|
358 |
|
|
time you make an instance, you must specify the `Chip` it belongs to, and
|
359 |
|
|
connect up the inputs and outputs of the `Component`.
|
360 |
|
|
|
361 |
|
|
.. code-block:: python
|
362 |
|
|
|
363 |
|
|
adder(mychip,
|
364 |
|
|
inputs = {"a" : input_a, "b" : input_b},
|
365 |
|
|
outputs = {"z" : wire_a})
|
366 |
|
|
|
367 |
|
|
adder(mychip,
|
368 |
|
|
inputs = {"a" : input_c, "b" : input_d},
|
369 |
|
|
outputs = {"z" : wire_b})
|
370 |
|
|
|
371 |
|
|
adder(mychip,
|
372 |
|
|
inputs = {"a" : wire_a, "b" : wire_b},
|
373 |
|
|
outputs = {"z" : output_z})
|
374 |
|
|
|
375 |
|
|
A diagrammatic representation of the `Chip` is shown below.
|
376 |
|
|
|
377 |
|
|
::
|
378 |
|
|
|
379 |
|
|
+-------+ +-------+
|
380 |
|
|
| adder | | adder |
|
381 |
|
|
A =====> >=======> >=====> Z
|
382 |
|
|
B =====> | | |
|
383 |
|
|
+-------+ | |
|
384 |
|
|
| |
|
385 |
|
|
+-------+ | |
|
386 |
|
|
| adder | | |
|
387 |
|
|
C =====> >=======> |
|
388 |
|
|
D =====> | | |
|
389 |
|
|
+-------+ +-------+
|
390 |
|
|
|
391 |
|
|
Code Generation
|
392 |
|
|
---------------
|
393 |
|
|
|
394 |
|
|
You can generate synthesisable Verilog code for your chip
|
395 |
|
|
using the `generate_verilog` method.
|
396 |
|
|
|
397 |
|
|
.. code-block:: python
|
398 |
|
|
|
399 |
|
|
mychip.generate_verilog()
|
400 |
|
|
|
401 |
|
|
You can also generate a matching testbench using the `generate_testbench`
|
402 |
|
|
method. You can also specify the simulation run time in clock cycles.
|
403 |
|
|
|
404 |
|
|
.. code-block:: python
|
405 |
|
|
|
406 |
|
|
mychip.generate_testbench(1000) #1000 clocks
|
407 |
|
|
|
408 |
|
|
To compile the design in Icarus Verilog, use the `compile_iverilog` method. You
|
409 |
|
|
can also run the code directly if you pass `True` to the `compile_iverilog`
|
410 |
|
|
function.
|
411 |
|
|
|
412 |
|
|
.. code-block:: python
|
413 |
|
|
|
414 |
|
|
mychip.compile_iverilog(True)
|
415 |
|
|
|
416 |
|
|
|
417 |
|
|
Physical Interface
|
418 |
|
|
==================
|
419 |
|
|
|
420 |
|
|
`Input`, `Output` and `Wire` objects within a chip are implemented using a
|
421 |
|
|
synchronous interconnect bus. The details of the interconnect bus are described
|
422 |
|
|
here. This section will be of most use to developers who want to integrate a
|
423 |
|
|
*Chips* design into a larger design, or to generate an HDL wrapper to support a
|
424 |
|
|
*Chips* design in new hardware.
|
425 |
|
|
|
426 |
|
|
::
|
427 |
|
|
|
428 |
|
|
rst >-o-----------------------------+
|
429 |
|
|
clk >-+-o-------------------------+ |
|
430 |
|
|
| | | |
|
431 |
|
|
| | +-----------+ | | +--------------+
|
432 |
|
|
| | | TX | | | | RX |
|
433 |
|
|
| +---> | | +-----> |
|
434 |
|
|
+-----> | +-------> |
|
435 |
|
|
| | | |
|
436 |
|
|
| | | |
|
437 |
|
|
| out >=================> in |
|
438 |
|
|
| | _stb | |
|
439 |
|
|
| out >-----------------> in |
|
440 |
|
|
| | _ack | |
|
441 |
|
|
| in <-----------------< out |
|
442 |
|
|
| | | |
|
443 |
|
|
+-----------+ +--------------+
|
444 |
|
|
|
445 |
|
|
Global Signals
|
446 |
|
|
--------------
|
447 |
|
|
|
448 |
|
|
+------+-----------+------+-------------+
|
449 |
|
|
| Name | Direction | Type | Description |
|
450 |
|
|
+------+-----------+------+-------------+
|
451 |
|
|
| clk | input | bit | Clock |
|
452 |
|
|
+------+-----------+------+-------------+
|
453 |
|
|
| rst | input | bit | Reset |
|
454 |
|
|
+------+-----------+------+-------------+
|
455 |
|
|
|
456 |
|
|
|
457 |
|
|
Interconnect Signals
|
458 |
|
|
--------------------
|
459 |
|
|
|
460 |
|
|
+----------------+-----------+------+-----------------------------------------------------------+
|
461 |
|
|
| Name | Direction | Type | Description |
|
462 |
|
|
+----------------+-----------+------+-----------------------------------------------------------+
|
463 |
|
|
| | TX to RX | bus | Payload Data |
|
464 |
|
|
+----------------+-----------+------+-----------------------------------------------------------+
|
465 |
|
|
| _stb | TX to RX | bit | '1' indicates that payload data is valid and TX is ready. |
|
466 |
|
|
+----------------+-----------+------+-----------------------------------------------------------+
|
467 |
|
|
| _ack | TX to RX | bit | '1' indicates that RX is ready. |
|
468 |
|
|
+----------------+-----------+------+-----------------------------------------------------------+
|
469 |
|
|
|
470 |
|
|
|
471 |
|
|
Interconnect Bus Transaction
|
472 |
|
|
----------------------------
|
473 |
|
|
|
474 |
|
|
1. Both transmitter and receiver **shall** be synchronised to the 0 to 1 transition of `clk`.
|
475 |
|
|
#. If `rst` is set to 1, upon the 0 to 1 transition of `clk` the transmitter **shall** terminate any active bus transaction and set `_stb` to 0.
|
476 |
|
|
#. If `rst` is set to 1, upon the 0 to 1 transition of `clk` the receiver **shall** terminate any active bus transaction and set `_ack` to 0.
|
477 |
|
|
#. If `rst` is set to 0, normal operation **shall** commence.
|
478 |
|
|
#. The transmitter **may** insert wait states on the bus by setting `_stb` to 0.
|
479 |
|
|
#. The transmitter **shall** set `_stb` to 1 to signify that data is valid.
|
480 |
|
|
#. Once `_stb` has been set to 1, it **shall** remain at 1 until the transaction completes.
|
481 |
|
|
#. The transmitter **shall** ensure that `` contains valid data for the entire period that `_stb` is 1.
|
482 |
|
|
#. The transmitter **may** set `` to any value when `_stb` is 0.
|
483 |
|
|
#. The receiver **may** insert wait states on the bus by setting `_ack` to 0.
|
484 |
|
|
#. The receiver **shall** set `_ack` to 1 to signify that it is ready to receive data.
|
485 |
|
|
#. Once `_ack` has been set to 1, it **shall** remain at 1 until the transaction completes.
|
486 |
|
|
#. Whenever `_stb` is 1 and `_ack` are 1, a bus transaction **shall** complete on the following 0 to 1 transition of `clk`.
|
487 |
|
|
#. Both the transmitter and receiver **may** commence a new transaction without inserting any wait states.
|
488 |
|
|
#. The receiver **may** delay a transaction by inserting wait states until the transmitter indicates that data is available.
|
489 |
|
|
#. The transmitter **shall** not delay a transaction by inserting wait states until the receiver is ready to accept data. Deadlock would occur if both the transmitter and receiver delayed a transaction until the other was ready.
|
490 |
|
|
|
491 |
|
|
::
|
492 |
|
|
|
493 |
|
|
rst ______________________________________________________________
|
494 |
|
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
495 |
|
|
clk _| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
|
496 |
|
|
_____ _______ ________________________________________________
|
497 |
|
|
_____X_VALID_X________________________________________________
|
498 |
|
|
_______
|
499 |
|
|
_stb _____| |________________________________________________
|
500 |
|
|
___
|
501 |
|
|
_ack _________| |________________________________________________
|
502 |
|
|
|
503 |
|
|
^^^^ RX adds wait states
|
504 |
|
|
|
505 |
|
|
^^^^ Data transfers
|
506 |
|
|
|
507 |
|
|
rst ______________________________________________________________
|
508 |
|
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
509 |
|
|
clk _| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
|
510 |
|
|
_____ _______ ________________________________________________
|
511 |
|
|
_____X_VALID_X________________________________________________
|
512 |
|
|
___
|
513 |
|
|
_stb _________| |________________________________________________
|
514 |
|
|
_______
|
515 |
|
|
_ack _____| |________________________________________________
|
516 |
|
|
|
517 |
|
|
|
518 |
|
|
^^^^ TX adds wait states
|
519 |
|
|
|
520 |
|
|
^^^^ Data transfers
|
521 |
|
|
|
522 |
|
|
|
523 |
|
|
rst ______________________________________________________________
|
524 |
|
|
__ __ __ __ __ __ __ __ __ __ _
|
525 |
|
|
clk _| |__| |__| |__| |__| |__| |__| |__| |__| |__| |_|
|
526 |
|
|
|
527 |
|
|
_______ ___________ _____ _____ ______________________________
|
528 |
|
|
_______X_D0________X_D1__X_D2__X______________________________
|
529 |
|
|
_________________
|
530 |
|
|
_stb _____________| |______________________________
|
531 |
|
|
_______________________
|
532 |
|
|
_ack _______| |______________________________
|
533 |
|
|
|
534 |
|
|
^^^^ TX adds wait states
|
535 |
|
|
|
536 |
|
|
^^^^ Data transfers
|
537 |
|
|
|
538 |
|
|
^^^^ stb and ack needn't return to 0 between data words
|
539 |
|
|
|
540 |
|
|
..
|
541 |
|
|
|
542 |
|
|
|