Skip to content

Latest commit

 

History

History
52 lines (45 loc) · 2.97 KB

0084-2023-05-24.md

File metadata and controls

52 lines (45 loc) · 2.97 KB

24 May 2023

Previous journal: Next journal:
0083-2023-05-23.md 0085-2023-05-25.md

Raybox

  • Tried for a while today to see if I could get it to synthesise using OpenLane, set to an area (2900µm × 3500µm) that is almost a Caravel fit. The synth succeeded after several failed attempts (and in the end setting PL_TARGET_DENSITY to 10% got it there), but it has thousands of timing violations. More optimisation could be attempted later, but the design isn't finished yet.
  • I found that negative bit indices in Verilog seem to trigger a bug in the LVS step of OpenLane, i.e. an "unmatched pin" error occurs. I will try to report this later, but for now I worked around it by making sure any fixed-point IO pins just start at a bit index of 0.
  • I merged the sprites branch into the main branch. I will do more work later on trying to support more than 1 sprite.

Next steps

  • Need to fix codebase (namely wall textures) to work with fixed-point values other than Q12.12.
  • Support 64x64 map with more data depth (i.e. different textures, even if hard-coded for now).
  • Find out if OpenLane can use multiple CPU cores.
  • Work out how to send control data to the FPGA.
  • Start working on resource sharing. Prove that it actually simplifies the design.
    • Need to get solid metrics from OpenLane/Yosys before making changes!
    • Check utilisation also in Quartus; beware multiplier blocks!
    • Need to also check timing, inc. both FPGA reports and OpenSTA.
  • Consider modularising some blocks and hardening them independently. Might help speed up optimisation/hardening, and get a better fit. Should also make code more readable and configurable, e.g. have a specific sprite rendering module.
  • Find out how to define actual RAM blocks
  • Learn OpenRAM
  • Test whether Q16.16 or even just Q12.16 gives better texture stability.
  • Try a reduced design in OpenLane and see if we can get it to fit AND RUN (in sim, then FPGA):
    • Reduce ROMs:
      • Reduce textures/sprite to 32x32. This will quarter their ROM data.
      • Alternatively, do simple ROMs as boolean logic (bitwise operations).
      • Make ROMs external (and serviced by other modules/TBs). It should ultimately be like this anyway.
    • Do a 320x240 version.
    • Drop fixed-point stuff to Q9.9
    • Comment out sprite(s).
  • Optimising to get the design to fit in Caravel without compromising:
    • Sprite positions probably only need ~6 bits of sub-unit precision. In fact, they only need about Q6.6 (unsigned)?
    • Player position could be reduced to Q6.12 (unsigned)?
    • Facing and vplane vectors could be reduced to Q2.12 (signed). This allows vectors in the range [-2.0,2.0)
    • Trace buffer could be converted to OpenRAM.
    • Fewer IOs
    • Implement shared resources (i.e. for reciprocals and multiplication)
    • Plan/implement external ROMs