Previous journal: | Next journal: |
---|---|
0216-2024-08-23.md | 0218-2024-10-05.md |
- I verified my prior (and otherwise incomplete) documentation and setup of my raybox-zero (RBZ) CI2311 test jig, and started making the documentation a part of the main raybox-zero repo -- in particular, see: https://github.com/algofoogle/raybox-zero/blob/main/game/doc/CI2311.md
- A drawback of RBZ CI2311 is that it requires the Caravel CPU to be clocked at about 50MHz in order to be able to bit-bang frame POV updates fast enough (from UART data) for a smooth update rate from a host PC. An advantage though is that RBZ is independently clocked from an external clock source, so it can be run at (say) 25MHz or 30MHz to suit the required VGA sync, while the Caravel CPU can be run faster.
- NOTE: I should make simple adapter PCBs or wire looms for connecting the 3 RBZ test boards
- Internally, RGB444 with DAC? Optionally also "palettes" or other data in the spare SPI io3 pin
- Wishbone reads/writes as alternative to LA
- More debug functions & features via LA
- Multiple instances with different implementations for characterizing
- gpouts
- Half-VINF (only upper or lower VINF). Likewise: Extended up/down leak range
- External clock, or user_clock2
- Game map in CUP memory
- Memory banking
- Proper COLUMN rendering in framebuffer RAM instead of JIT ROW rendering -- but this wouldn't work with SPI texture ROM unless it was cached in RAM too.
- Use Caravel's SPI passthrough port ("flash2" on
IO[37:36,11:8]
) to allow for Flash ROM rewriting via HKSPI. - Texture flip options: X and/or Y
- Output internal reset signal as ext. pin to help debug sync
- Option to advance px/py along vplane axes instead of universally
- Image over/under-lay
- SPI interfaces share data lines and just use separate CSBs, or single interface accepting both POV & register data.
- "Immediate" register updates
- IRQs with optional "next line distance override" -- ISR in local memory?
Assuming the eval board has no firmware programmed, the power-on state of all the GPIOs should be as USER INPUTs.
Plugging the board in, the power and gpio LEDs (D4 and D3) are lit, though not brightly.
The chip slowly warms up. Is this a bad sign?
Setup... see below, but also notes in 0206 re permanently mapping FTDI devices in Ubuntu.
git clone https://github.com/efabless/caravel_board
cd caravel_board
### SET UP VENV, then...
source .venv/bin/activate
pip install pyftdi
pip install pyserial
pip install pyusb
pip install setuptools
cd firmware/gf180/util
python3 caravel_hkdebug.py
It reveals this, which is good:
Caravel data:
mfg = 0456
product = 20
project ID = 1801dc4f
project ID = f23b8018
I assume all the Caravel registers are the same on GFMPW-1 as they are on Caravel v6.0 (MPW6+).
Decoding registers:
reg 0x08 = b'02' reg_hkspi_pll_ena DLL disabled
reg 0x09 = b'01' reg_hkspi_pll_bypass Bypass enabled; pass ext. clk
reg 0x0a = b'00' reg_hkspi_irq No action
reg 0x0b = b'00' reg_hkspi_reset No action
reg 0x0c = b'00' reg_hkspi_trap ??
reg 0x0d = b'ff' reg_hkspi_pll_trim[7:0] ...
reg 0x0e = b'ef' reg_hkspi_pll_trim[15:8] ...
reg 0x0f = b'ff' reg_hkspi_pll_trim[23:16] ...
reg 0x10 = b'03' reg_hkspi_pll_trim[25:24] ...trim is 0x03ffefff
reg 0x11 = b'12' reg_hkspi_pll_source 010_010 = div-2 for both
reg 0x12 = b'04' reg_hkspi_pll_divider mul-4
xclk looks like a very stable 10MHz at maybe just over 5V. Scope says about 5.1-5.2V.
Enable GPIO[15:14]
clock output per this, but note one difference is that on GFMPW-1, the GPIO modes have different bitfields, and their register power-on states are (starting at register 0x1d,0x1e):
0 0x0009 GPIO_MODE_MGMT_STD_BIDIRECTIONAL
1 0x0009 GPIO_MODE_MGMT_STD_BIDIRECTIONAL
2 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
3 0x0087 GPIO_MODE_MGMT_STD_INPUT_PULLUP **
4 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
5 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
6 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
7 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
8 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
9 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
10 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
11 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
12 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
13 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
14 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
15 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
16 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
17 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
18 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
19 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
20 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
21 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
22 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
23 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
24 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
25 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
26 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
27 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
28 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
29 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
30 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
31 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
32 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
33 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
34 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
35 0x0007 GPIO_MODE_MGMT_STD_INPUT_NOPULL
36 0x0009 GPIO_MODE_MGMT_STD_BIDIRECTIONAL
37 0x0009 GPIO_MODE_MGMT_STD_BIDIRECTIONAL
- Reg 0x1B: Write 6 (enable output for both clocks)
- Reg 0x39,0x3A: Write 0,0xb (GPIO_MODE_MGMT_STD_OUTPUT)
- Reg 0x3B,0x3C: Ditto
- Reg 0x13: Write 1 (push GPIO config to activate)
- Observe 6.5V (??) 10MHz output on GPIO14, with ~16ns slew and 20ns lag? -- Oh, it was bad grounding on one probe.
NOTE: GPIO 'state' registers had these values in them:
0x69 00
0x6a 80
0x6b 00
0x6c 30
0x6d 10