0161-2023-10-17.md

17 Oct 2023

Previous journal:	Next journal:
0160-2023-10-16.md	0162-2023-10-20.md

Continue raybox-zero update for chipIgnite

NOTE: This day was a blitz, so the notes below are much less organised than I'd normally try to make them. Please bear with me :)

Accomplishments

• top_ew_algofoogle
• Started writing Tip 2310C: Checks to do on final chipIgnite submission
• Gave a presentation (private for now; ask if you want access) on 2023-10-19 to the Z2A weekly meeting about raybox-zero. I made a quick demo video that I used in the presentation.
• Basic SPI reading for wall textures in raybox-zero: Single SPI, just reads 1-bit colour (into green channel) for now, 64 bits total. Builds address from wall ID (0..4, but actual ID is -1 so that wall 1 is actually at address 0), side (0/1), and slice (0..63). It works!

Next steps

• Try to finish core raybox-zero design including:
  • External texture loading with QSPI
  • Debug mux logic in TOP
• Solder up another flash ROM chip and write some image data to it, with different colour plane modes we can test.
• Do some more hardens
• Try testing TOP on FPGA
• Provide GDS, LEF, and spec doco to Ellen et al.
• Watch videos on sky130 DAC design, consider grabbing someone else's DAC design (Harald Pretl?) -- also, do one analog pin as direct R2R DAC, another with analog (simple BiCMOS) mux, another with a simple OpAmp or other amplifier??
• Find and include Caravel SoC block diagram
• Include my own pinout doco inc. QFN-64, TT, breakout mapping

Notes

• Spoke with Ellen, Pawel, Matt about chipIgnite. Might have to drop analog DAC goal.
• If I can't get analog working, then make sure there is a LA 'mode' or debug control or whatever that can just select what 3 digital outputs we want: RGB111? G3?
• The host controller could update textures in an SPI PSRAM by double-buffering it, i.e. for the portion of each line where raybox-zero is not mastering the Texture SPI memory, and for the whole of VBLANK, write new texture data into a second memory region, and then send an SPI signal to raybox-zero at the end of the frame to say "flip this texture MSB now".
• de0nano wrapper for raybox-zero does NOT wire up reg SPI!
• Testing with Verilator sim could be tricky because:
  • We might need a higher TB to encapsulate top_ew_algofoogle and wire up spiflash. This could change a lot of the C++ code.
  • Verilator might not handle the negedge clocking (SCLK-is-inverted-CLK) very well, or at least not with the way my 'tick' code is written so far. Or maybe it will work just fine, automatically??
• If for some reason we get VERY few IOs, the bare minimum target could be:
  • Larger area for more internal memory, and optionally 32x32 texture(s) with option for doubling. Shift-shading.
  • Write to internal memory via LA only.
  • These bare minimum external IOs:
    • Analog: 1 DAC out: greyscale.
    • CLK (unless it can be done internally)
    • HSYNC
    • VSYNC
    • ...those 4 are enough to produce a video display.
    • Either of HSYNC or VSYNC could also be used to mux a debug output.
• Which version of OL1 should I be using?
• Can gating CLK (e.g. via ena) muck up CTS?
• Do we need extra LA wires to inspect the state of vectors? This can be a good way to debug whether the view is loaded properly.
• Do we need a 'burst' output signal IF we use a SYNC pin as debug output (if constrained on outputs), so that it's easier to find the start of a frame or other measurable point?
• Share my design with the team soon, or at least a diagram of its outer structure.
• EW dedicated pins needed:
  • Pawel needs 6 analog, no digital
  • Ellen needs 2 analog
  • Ellen needs 10 digital that can't be muxed
  • This totals 18... out of 30, there are only 12 left.
  • Ellen needs 8 digital that CAN be muxed??
  • I've worked out that my ideal external pin count is 3 analog and 10 digital. This includes CLK:
    • If 12 was still the hard limit, then maybe CLK can be internal (where would it come from? I think it can come from the Caravel PLL/DLL)
    • Otherwise, I could drop the debug pin and let the LA switch it on either of the SYNC pins.
• Caravel 38 mprj_io pins:
  • First 8 should be reserved for general system functions (SoC and housekeeping)
  • Which pins can be dedicated analog?
  • I seem to recall that a small number support reduced IO config options...? Maybe because it was related to analog?
  • WLCSP pins -- which of these support analog??

    IO	Pin	Name	Description
    mprj_io[0]	D7	JTAG	JTAG system access
    mprj_io[1]	E9	SDO	Housekeeping SPI
    mprj_io[2]	F9	SDI	Housekeeping SPI
    mprj_io[3]	E8	CSB	Housekeeping SPI
    mprj_io[4]	F8	SCK	Housekeeping SPI
    mprj_io[5]	E7	ser_rx	SoC UART?
    mprj_io[6]	F7	ser_tx	SoC UART?
    mprj_io[7]	E5	irq	External interrupt - MIGHT be usable?
    mprj_io[8]	F5	flash2_csb	User area QSPI (DDR maybe??)
    mprj_io[9]	E4	flash2_sck	User area QSPI (DDR maybe??)
    mprj_io[10]	F4	flash2_io[0]	User area QSPI (DDR maybe??)
    mprj_io[11]	E3	flash2_io[1]	User area QSPI (DDR maybe??)
    mprj_io[12]	F3	-
    mprj_io[13]	D3	-
    mprj_io[14]	E2	-
    mprj_io[15]	F1	-
    mprj_io[16]	E1	-
    mprj_io[17]	D2	-
    mprj_io[18]	D1	-
    mprj_io[19]	C1	-
    mprj_io[20]	C2	-
    mprj_io[21]	B1	-
    mprj_io[22]	B2	-
    mprj_io[23]	A1	-
    mprj_io[24]	C3	-
    mprj_io[25]	A3	-
    mprj_io[26]	B4	-
    mprj_io[27]	A4	-
    mprj_io[28]	B5	-
    mprj_io[29]	A5	-
    mprj_io[30]	B6	-
    mprj_io[31]	A6	-
    mprj_io[32]	A7	-
    mprj_io[33]	C8	-
    mprj_io[34]	B8	-
    mprj_io[35]	A8	-
    mprj_io[36]	B9	-
    mprj_io[37]	A9	-

  • NOTE: There are 22 other pins which include Soc/shared clock, flash SPI (for SoC XIP from external flash ROM), power, etc.
• Expect that our digital IOs will be similar to what Matt's done for prior group submissions, where there is a mux and tristating for all key signals. Exception will probably be analog and LA pins.
• Could use single-wire UART (RX) to send data to the design, if not via SoC? How will the outside world talk to the SoC to tell it to send data to the design via LA SPI? SoC already has a UART? mprj_io[6:5] are {ser_tx, ser_rx}
• Should in/out (inout) ports actually just be oeb+in+out triples?
• I recall Matt's group submission wrapper was setting stuff explicitly to Z. Do we need to do that too?
• Should top_ew_algofoogle be moved into its own top-level dir called caravel or ew or something?
• Will another wrapper be needed that standardises pin names for muxing/sharing/caravel/analog/LA pins? One thing that comes to mind is that we need to have a way to specify oebs for ALL pins...?
• Will digital RGB (24-bit) be part of top_ew_algofoogle, or will the DAC be a macro within it?
• How are we going to test/sim this thing?
  • Simple version:
    • Check the example CUP/UPW counter IO project.
    • Check what I did for solo_squash.
    • Write firmware for SoC to do basic design control.
    • Put my design inside caravel.
    • Wire up the WHOLE thing and run thru cocotb and get waveform...
    • ...and/or try Verilated version too.

yosys (logs/synthesis/1-synthesis.log) does at least report missing drivers as warnings:

19.6. Executing CHECK pass (checking for obvious problems).
Checking module top_ew_algofoogle...
Warning: Wire top_ew_algofoogle.\tex_sclk is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [3] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [2] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [1] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [0] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [3] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [2] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [1] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [0] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_csb is used but has no driver.
Warning: Wire top_ew_algofoogle.\debug is used but has no driver.
Warning: Wire top_ew_algofoogle.\rbzero.pov.i_inc_py is used but has no driver.
Found and reported 12 problems.

Last one is quite real: rbzero.pov.i_inc_py is used but has no driver -- I accidentally doubled up i_inc_px in instantiation port list! Why wasn't this reported as an error instead?

Later on:

37. Executing CHECK pass (checking for obvious problems).
Checking module top_ew_algofoogle...
Warning: Wire top_ew_algofoogle.\vsync_n is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_sclk is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [3] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [2] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [1] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_out [0] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [3] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [2] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [1] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_oeb [0] is used but has no driver.
Warning: Wire top_ew_algofoogle.\tex_csb is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [23] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [22] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [21] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [20] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [19] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [18] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [17] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [16] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [15] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [14] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [13] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [12] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [11] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [10] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [9] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [8] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [7] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [6] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [5] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [4] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [3] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [2] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [1] is used but has no driver.
Warning: Wire top_ew_algofoogle.\rgb [0] is used but has no driver.
Warning: Wire top_ew_algofoogle.\hsync_n is used but has no driver.
Warning: Wire top_ew_algofoogle.\debug is used but has no driver.
Found and reported 37 problems.

These ones are a bit strange. All 24 RGB bits are reported, but they are external ports... and they DO have drivers...? Same goes for hsync_n and vsync_n.