Skip to content

Latest commit

 

History

History
62 lines (50 loc) · 4.07 KB

0073-2023-05-03.md

File metadata and controls

62 lines (50 loc) · 4.07 KB

3 May 2023

Previous journal: Next journal:
0072-2023-05-02.md 0074-2023-05-04.md

Raybox

Raybox next steps

  • Camera movement can now be driven by sim, but rotation doesn't work very well.
    • Is this a quantisation/precision problem due to Q12.12? Does Q16.16 fix it?
    • Does slicing the viewplane into 256 steps per side lead to cumulative rounding errors?
    • Can we fix it by using a higher-precision/magnitude camera step and then post-scaling?
    • NOTE: My calculated gOvers are stored as doubles the whole time, so when we draw them onto the SDL screen we're not seeing them as the DUT would see them. Change this to overlay with ACTUAL (fixed-point-converted) values => Test fixed-point in sim instead of doubles.
    • I also have started to notice X/Y axiom glitches when using rotation (i.e. purple columns or holes). May need to look at that saturation logic again.
    • Keep working on FP in raybox-app, too. I think I'm close to having that working.
  • Got an issue where latest version (with fixed map grid boundary glitch) doesn't work properly on FPGA. This could be due to Q12.12, or changed lzc, or other changes that were made to fix the Qm.n parametric support, or...?
  • Find the last commit where it worked on FPGA. 0071-2023-05-01.md describes it working on the DE0-Nano with Q16.16, and wall edge glitch fixed. That would place it at commit 9f90eaa.
  • Check whether changes to bit depth caused the problem
  • Try Q16.16 on FPGA again
  • Cherry-pick some stuff for FPGA in another branch?
  • Try changing lzc back to casez -- in fact I'm working on making 4 different implementations (lzc_a.._d) to try them all out.
  • Create VGA test output for lzc and reciprocal
  • Optimise lzc based on LIKELY input values. For instance, we won't normally have more than 8 M bits??

FPGA tests

  • lzc_a with Q16.16 doesn't run properly on FPGA. Slack:
    • Slow 85C slack -38.673; TNS -150.575; Fmax: 12.71 MHz (I guess I could go for half-rate, 320x480?)
    • Slow 0C slack -30.510; TNS -30.705; Fmax: 14.18 MHz
    • Fast 0C slack -5.179; TNS -5.179
  • lzc_b with Q11.9 runs just as badly. Slack:
    • Slow 85C slack -27.592; TNS -28.235; Fmax: 14.79 MHz
    • Slow 0C slack -20.509; TNS -20.509; Fmax: 16.53 MHz
    • Fast 0C slack +1.375; TNS 0
  • lzc_c with Q12.12 ditto:
    • Slow 85C slack -30.225; TNS -45.317; Fmax: 14.24 MHz
    • Slow 0C slack -23.050; TNS -23.050; Fmax: 15.86 MHz
    • Fast 0C slack -0.332; TNS -0.332

I was thinking the problem was a vector init issue: for some reason the FPGA always refuses to reset to my desired starting position and instead ends up at (0,0). However, after putting in a debug overlay to visualise the vector bit values, I can see that while playerX/Y are resetting to 0, the facing/vplane vectors are resetting fine.

Could part of the problem simply be that I'm using a generated clock (clock_25) that is not producing a true clock tree? Not sure; maybe Quartus is doing this anyway?? Is there a way to flag that should happen?

I tried adding more FSM cycles for store but this didn't help. The problem is probably happening earlier in the FSM.

Other notes

  • Quartus Signal Tap Logic Analyzer is interesting:

    The Signal Tap logic analyzer, available in the Intel® Quartus® Prime software, captures and displays the real-time signal behavior in an Intel FPGA design. Use the Signal Tap logic analyzer to probe and debug the behavior of internal signals during normal device operation, without requiring extra I/O pins or external lab equipment.

  • Find out more to do with SONOS and sky130. See this and see if we can find the actual lecture.
  • Check out psychogenic's moodle alpha.