1 |
2 |
julius |
CFI Controller IP Core
|
2 |
|
|
======================
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
This core implements a very simple controller that will provide an interface to
|
6 |
|
|
16-bit data-bus flash memories using the common flash interface (CFI).
|
7 |
|
|
|
8 |
|
|
It uses asynchronous communication only, and thus should be configured with the
|
9 |
|
|
cycle counts for write (usually 50ns, so usually roundup(50ns / Tsys_clk) and
|
10 |
|
|
read (usually 85-115 ns - see your part's spec for exact details.) These cycle
|
11 |
|
|
counts are set via paramters to the core, and each read or write access
|
12 |
|
|
performed by the core will ensure the signals are held for this long.
|
13 |
|
|
|
14 |
|
|
== Interface Modes ==
|
15 |
|
|
|
16 |
|
|
Two interface modes are avilable.
|
17 |
|
|
|
18 |
|
|
=== Simple Mode ===
|
19 |
|
|
|
20 |
|
|
First is a very simple interface with the flash bus - essentially each classic
|
21 |
|
|
Wishbone access is mapped onto the flash bus (address is shifted right by 1
|
22 |
|
|
bit.) The only "advanced" feature of this mode, is that 32-bit reads will work,
|
23 |
|
|
that is the controller will perform two reads if a full-word read is requested,
|
24 |
|
|
which means this controller can be used for XIP (execute-in-place) by a
|
25 |
|
|
processor.
|
26 |
|
|
|
27 |
|
|
The functionality is demonstrated in the testbench cfi_ctrl_wb_bench.v
|
28 |
|
|
|
29 |
|
|
This mode appears to be compliant with the basic CFI software drivers available
|
30 |
|
|
under u-boot/Linux. It is the recommended mode if the controller is to be used
|
31 |
|
|
in a system running software such as this. The complexity is handled by the
|
32 |
|
|
driver software, meaning the controller implementation can be simple.
|
33 |
|
|
|
34 |
|
|
=== CFI Engine Mode ===
|
35 |
|
|
|
36 |
|
|
The second is the "CFI engine" mode, which aims to simplify the interface to the
|
37 |
|
|
flash, allowing single-access block unlock, erase and 16/32-bit writes.
|
38 |
|
|
|
39 |
|
|
This engine core can be used standalone (the source file
|
40 |
|
|
rtl/verilog/cfi_ctrl_engine.v) to provide access to a flash part for another FSM
|
41 |
|
|
or may be wrapped in a different bus interface wrapper.
|
42 |
|
|
|
43 |
|
|
The testbench for the standalone engine core is cfi_ctrl_engine_bench.v
|
44 |
|
|
|
45 |
|
|
The engine is provided with a Wishbone wrapper, and the core's capabilities are
|
46 |
|
|
mapped to the Wishbone bus as outlined below.
|
47 |
|
|
|
48 |
|
|
The testbench for the Wishbone-wrapped engine is cfi_ctrl_engine_wb_bench.v
|
49 |
|
|
|
50 |
|
|
==== Commands ====
|
51 |
|
|
|
52 |
|
|
Commands are essentially encoded on the address bus for the core. The following
|
53 |
|
|
is an outline of how this interface works:
|
54 |
|
|
|
55 |
|
|
Basic functionality:
|
56 |
|
|
Bits [27:26] decode the operation.
|
57 |
|
|
2'b00 : read/write to the flash memory
|
58 |
|
|
2'b01 : unlock block
|
59 |
|
|
2'b10 : erase block
|
60 |
|
|
2'b11 : block registers, other flash control features. See below.
|
61 |
|
|
|
62 |
|
|
Therefore:
|
63 |
|
|
Addresses under 0x000_0000 cause direct access to the flash
|
64 |
|
|
Addresses under 0x400_0000 cause the block (addressed in [24:0]) to be unlocked
|
65 |
|
|
Addresses under 0x800_0000 cause the block (addressed in [24:0]) to be erased
|
66 |
|
|
|
67 |
|
|
==== Registers ====
|
68 |
|
|
0xc00_0000 : block status/control register
|
69 |
|
|
bits:
|
70 |
|
|
[0]: r/o : CFI controller busy
|
71 |
|
|
[1]: w/o : clear flash status register
|
72 |
|
|
[2]: w/o : reset flash device and controller
|
73 |
|
|
|
74 |
|
|
0xc00_0004 : flash device status register
|
75 |
|
|
bits
|
76 |
|
|
[7:0] : r/o : flash device status register
|
77 |
|
|
|
78 |
|
|
0xe00_0000 : read device identifier information
|
79 |
|
|
User is able to access the device identifier information such as:
|
80 |
|
|
offset 0x0 : manufacturer code
|
81 |
|
|
offset 0x2 : device id
|
82 |
|
|
offset bba + 0x4 : block (add increments of 128KB block size)
|
83 |
|
|
offset 0xa : read config register
|
84 |
|
|
See CFI docs for further details (shift offset left by 1)
|
85 |
|
|
|
86 |
|
|
0xe01_0000 : CFI query
|
87 |
|
|
User is able to access the CFI query information
|
88 |
|
|
The hex offsets in the CFI spec should be shifted left by one before
|
89 |
|
|
applying to the Wishbone bus.
|
90 |
|
|
|
91 |
|
|
|
92 |
|
|
== Timing ==
|
93 |
|
|
|
94 |
|
|
Set the parameters flash_write_cycles and flash_read_cycles at the top-level to
|
95 |
|
|
ensure that CFI bus timing is met (usually 50ns for write, 85-115ns for read.)
|
96 |
|
|
The single clock going to the core is the clock used to count these accesses.
|
97 |
|
|
|
98 |
|
|
flash_write_cycles is used to count the wlwh (write-low-to-write-high) parameter
|
99 |
|
|
and flash_read_cycles is used to count elqv, or enable-low-data-valid.
|
100 |
|
|
|
101 |
|
|
== Simulations ==
|
102 |
|
|
|
103 |
|
|
The core's 3 configurations come with testbenches under bench/verilog.
|
104 |
|
|
|
105 |
|
|
To run these simulations, install Icarus Verilog (sudo apt-get install verilog)
|
106 |
|
|
, http://iverilog.icarus.com/.
|
107 |
|
|
|
108 |
|
|
from sim/run run "make all" to run all the tests - a VCD for each will be
|
109 |
|
|
automatically generated in sim/out. Or run individual tests with the following:
|
110 |
|
|
|
111 |
|
|
Simple mode controller:
|
112 |
|
|
make cfi_ctrl_wb_bench
|
113 |
|
|
Engine mode controller, generic bus interface:
|
114 |
|
|
make cfi_engine_bench
|
115 |
|
|
Engine mode controller, Wishbone bus interface:
|
116 |
|
|
make cfi_ctrl_engine_wb_bench
|
117 |
|
|
|
118 |
|
|
The model used is in bench/verilog/x28fxxxp30.v
|
119 |
|
|
|
120 |
|
|
= Author =
|
121 |
|
|
Julius Baxter, julius@opencores.org
|