1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
===
[I] Setup del HPS y SDRAM
===
Luego de agregar el HPS a Platform Designer hay que ejecutar un script Tcl para
que Quartus agarre la config correcta de impedancias y más magia. Si se
sintetiza sin más acción entonces pasa esto:
Error (174068): Output buffer atom "platform:plat|platform_hps_0:hps_0|platform_hps_0_hps_io:hps_io|platform_hps_0_hps_io_border:border|hps_sdram:hps_sdram_inst|hps_sdram_p0:p0|hps_sdram_p0_acv_hard_memphy:umemphy|hps_sdram_p0_acv_hard_io_pads:uio_pads|hps_sdram_p0_altdqdqs:dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev:altdq_dqs2_inst|obuf_os_bar_0" has port "PARALLELTERMINATIONCONTROL[8]" connected, but does not use calibrated on-chip termination
Foro: <https://community.intel.com/t5/Programmable-Devices/Build-HPS-Hardware/td-p/219711>
Tools > Tcl Scripts. There navigate through your QSys project, synthesis >
submodules folders, and there you should find a script whose name ends with
pin_assignments.tcl . Select that script, run it and try and compile the
project again
Nota: es *_pin_assignments.tcl y no ningún otro
===
[II] Emulación de Avalon
===
Para las señales fuera del top que C++ escribe, por ejemplo en tb/platform.sv,
se necesita /*verilator public_flat_rw @(negedge clk_clk)*/ en vez de
/*verilator public*/ (la última igual se usa para señales que C++ lee). Poner
lo segundo en una señal `s` hace que `assign a = s;` no tenga ningún efecto,
lo cual es difícil de depurar.
https://github.com/verilator/verilator/issues/2262
===
[III] MSEL, uboot y fpga2sdram
===
Solamente cambiar MSEL a 01010, convertir a rbf en Quartus y tratar de programar
desde uboot resulta en esto:
SOCFPGA_CYCLONE5 # fpga load 0 ${fpgadata} ${fpgadatasize}
altera_load: Failed with error code -4
Hay que setear un modo en opciones de Quartus para que esto sirva. También puse
el MSEL en 00000 por si acaso.
El manual dice que 00000 corresponde a FPPx16
https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Altera-Cyclone-V-development-board-FPGA-problem-error-code-4/m-p/103855
Ahora pasa una de cuatro cosas con `mw 0xFFC2505C 0xA` (apply en registro staticcfg):
1. Hard-lock
2. Data abort
3. Prefetch abort
4. Como 1/10 veces parece servir
Sin apply la flag de done se queda levantada por siempre al tocar memoria.
Hice de cero varias partes del Platform en Platform Designer, también desactivé
MPU events en hps_0 y cambié el data width de fpga2sdram de 64 a 256 bits. Todo
sigue igual.
Si omito la instrucción que toca applycfg algo sirve. Escribir ya sirve
(confirmado con dd if=/dev/mem en HPS). Leer crashea el HPS tal como predice
zangman.
Shintel al rescate:
https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/embedded/2016/how-and-when-can-i-enable-the-fpga2sdram-bridge-on-cyclone-v-soc.html?utm_source=Altera&utm_medium=newsletter&utm_campaign=FACTS&utm_content=NA_how_can_i_enable_KI_15_08_2016
Bug exacto:
https://forum.rocketboards.org/t/fpga-to-sdram-cyclone-v-can-write-but-cannot-read/2796
Errata:
https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge
El problema parece ser uno de dos:
- Me faltan las señales de burst
- uboot está en RAM cuando se toca applycfg
Para lo segundo, errata dice que:
Altera has provided the capability to set the configuration bit in step three
with a macro command in their (and Critical Link's) u-Boot port. This is
accomplished by copying a small routine to on-chip RAM that disables caches and
asserts the APPLYCFG bit and then returns operation to the typical DDR space.
No sé donde putas está esa macro, así que voy a escribir mi propia:
Info sobre OCRAM (on-chip RAM): https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#sfo1410068453374.html#sfo1410068453374
sdram_staticcfg_applycfg:
dmb
dsb
isb
mov r0, #0x505c
movt r0, #0xffc2
mov r1, #0xa
str r1, [r0]
dmb
dsb
mov r0, #0
bx lr
Trivial. Esto solucionó todo.
===
[IV] Minimizando ciclos y evitando una Fmax asquerosa
===
Para este punto ya tengo semi-pipeline ((pre)fetch, decode, exec con máquina de
estados multiciclo en exec), register file (duplicado para tener dos read
ports), ALU, shifter, branches, condiciones y todas las instrucciones de
procesamiento de datos. También simuladores de Avalon y VGA.
En este momento necesitamos block memory real (no construida con lógica) para el
archivo de registros. El problema es que al ser memoria síncrona existe un ciclo
intermedio entre leer y recibir la lectura. Esto es absolutamente inaceptable. Hay
dos grandes dilemas:
- La altsyncram no está calzando con el diseño
- La Fmax se está yendo directo al caño (antes iba por como 120MHz, hoy tocó
piso con ~30MHz), principalmente por culpa de esa memoria y también que el
shifter está en serie con la ALU.
Traté de hacer un workaround con @(negedge clk) para operaciones de register
file. Esto arregla las cosas en Verilator pero reduce la Fmax a la mitad (!!!!)
en la cuarta esencia. Algunas Fmax:
- ~30MHz con @(negedge clk)
- ~60MHz con @(posedge clk) (claramente no sirve pero da una idea)
- 75.57MHz si quito el shifter del todo
También sospecho que es buena idea ponerle su propioo reloj a platform para que no
estorbe, pero para eso necesito un clock crossing bridge y una PLL.
El operand forwarding también está destruyendo todo, luego del cambio del
shifter todos los top failling paths se nota que vienen de eso. Lo voy a
cambiar por stalls artificiales. Subió a 105MHz con esto.
La limitante ahora parecen ser los bloques M10K de register file. Luego de
reacomodar la relación shifter-ALU (rediseño grande) hay Fmax = 102.99MHz con
el Slow 1100mV 0C Model. Reemplazando el register file con un registro dummy
obtengo 108.52MHz. Hay una ruta crítica entre cycles.pc y psr.flags.
Principales causas identificadas:
- Los M10K limitan a no más de 110MHz por alguna razón
- Lógica combinacional para seleccionar entre PC y file_rd_value
- Entradas combinacionales de ALU en cycles, esto llega hasta psr.flags
Voy a seguir con esto después.
===
[V] Port de U-Boot
===
Lo útil empieza en l[ineas 2108 y 3086 del README.
===
[VI] Ejecución de Qsys (Platform Designer) de manera OS-agnóstica
===
EL problema de NullPointerExceptions de AWT al abrir QSys en sistemas non-NixOS,
es por configuración de fonts. Ver este caso:
<https://discourse.nixos.org/t/fonts-in-nix-installed-packages-on-a-non-nixos-system/5871/7>
La soloución es usar home-manager o utilizar:
export LOCALE_ARCHIVE="${pkgs.glibcLocales}/lib/locale/locale-archive"
export FONTCONFIG_FILE="${pkgs.fontconfig.out}/etc/fonts/fonts.conf"
|
