0086-2023-05-26.md

26 May 2023

Previous journal:	Next journal:
0085-2023-05-25.md	0087-2023-05-27.md

Notes

• Raybox: Change external register (vector) writing to be buffered/queued so that it can happen any time the host controller wants, and then just commit the new vetors upon tick. Still try to support direct writing if it happens during visible, though.
• Trying 4 OpenLane cores (vs. 2) per this. Last run with defaults (2 OpenLane, 1 KLayout XOR) took about 196 minutes. NOTE: Most of OpenLane is single-threaded. I'm not even sure if the version that the MPW8 VM comes with will make use of these ROUTING_CORES and KLAYOUT_XOR_THREADS parameters.

Sending data to the FPGA

• Possible methods:
  • Quartus in-system memory editing.
    • https://www.intel.com/content/www/us/en/docs/programmable/683819/21-3/enabling-runtime-modification-of-instances.html
    • https://www.intel.com/content/www/us/en/docs/programmable/683819/21-3/editing-memory-contents-with-the-hex.html
    • https://www.intel.com/content/www/us/en/docs/programmable/683819/21-3/scripting-support-36438.html
  • Quartus In-System Sources and Probes.
    • Per this:

      The In-System Sources and Probes is ideal for toggling control signals.

  • Terasic GUI tool for controlling DE0-Nano devices.
  • vj-uart (might be same as Terasic GUI method).
  • ESP8266 attached to DE0-Nano.
  • STM32 attached to DE0-Nano. Could be either a PS/2 host/converter, or a USB bridge.
  • USB-Serial adapter attached to DE0-Nano, with UART core.
    • PC runs a util that captures mouse and keyboard input.
    • The util converts that input into vector updates. Later this can include game logic.
    • Vector updates are sent to the virtual COM port of the USB-to-TTL-RS232 board.
    • RS232 core on the FPGA decodes this into state updates that get written to raybox.
    • THUS, we'd need to:
      • Find a suitable USB-Serial adapter.
      • Write code to prove we can send/receive serial data (via loopback).
      • Wire up the board to the DE0-Nano, making sure there are no electrical issues: Ensure voltage is compatible, and use resistors to avoid bus contention in case we configure things incorrectly or cross our wires. For example, if we accidentally short 3.3V to GND, but want to safely limit current to no more than 20mA, then we need ~180R resistors in series for TX and RX. Maybe try proving this works with a loopback adapter on a long loopback wire. If we want to guard against 5V instead of 3.3V, then we need ~270R instead.
      • Find an RS232 core we can use, or Verilog, or write our own.
      • Decide whether we need to buffer/queue control data coming from the host PC, or do we just overwrite whatever is already there? Depends on the sync between the PC sending data and the VBLANK tick of the FPGA.
      • Prove that we can send basic control signals to the FPGA this way.
      • Implement proper keyboard/mouse mapping in the utility.
    • How much data do we need to send for real-time?
      • Assume for now we just need to send player position, facing, and vplane: 6x24 bits = 144 bits = 18 bytes equiv.
      • This needs to be done 60 times per second: 1080 bytes/sec. Assume 9 bits per byte (8N1): 9720bps. So, let's assume 19,200bps is what we want. However, does it need to be faster in order to avoid latency?
  • DE0-Nano direct PS/2 host: Needs either level shifter IC or simple resistor/diode limiting. Also needs extra logic for doing sin/cos for rotations.
  • Simple NES or Sega Megadrive controller adapter. Former needs 5V though?
  • Parallel-port-based interface.
  • Bus Pirate?? Could do SPI or something to the FPGA.
• An external device that actually asserts external register control pins on the FPGA would be ideal because it allows us to come up with a more realistic test. For this, we'll need to come up with our system bus design.