Category: Team Status Reports

Progress:

• Tetris is playable, with fully working controller inputs, but runs at ~4* speed
• Found a timer initialization and incrementation bug.

Risks and Risk Management:

Progress:

• Tetris is playable, with bugs
  • Games run at double speed (but seemingly, this unfortunately is not tied to clock frequency or timer registers)
  • Joypad inputs don’t always get processed
• Dr. Mario
  • Mario won’t toss his pill. We are suspicious of an HRAM or vblank handler interrupt routine error.

• Implemented Serial Transfer Control/Data Registers because Dr. Mario ROM polls from them

Risks and Risk Management:

Progress:

• Integration
  • Full integration in progress
    • We are able to render specific frames statically with Tetris/Dr.Mario/other rom tests in simulation now, but rendering the full game code in synthesis is still being debugged.
      • Successfully generated first frame for Tetris in simulation.
      • Successfully generated 3 frames for Dr Mario using actual Joypad interrupts in simulation.
      • VGA Support added in synthesis.
      • Full design (including controller) integrated and synthesized on FPGA  — debugging (using SignalTap 🙁 ) in progress.
      • DMG Acid Test face runs and shows up as a mostly intact fact on synthesized design
      • Dr. Mario ROM in synthesis has yet to work–after starting it up on an FPGA, the first frame shows up as a flicker and then it’s a white screen. We are fixing this currently. 

• PPU: DMG Acid Test in simulation almost fully debugged. PPU integrated with design fully. VGA + BRAM based Frame Buffer support added.
• APU:
  • Wrote/compiled APU (4 channels, 2 PWM, 1 wave ram, 1 pseudorandom with envelope/sweep/frequency change support)
•  I/O
  • New controllers have been assembled

Design Changes:

• There are now 4 clocks in the design. 
  • MMU clock that runs at 8MHz
  • PPU clock that runs at 4MHz (1 cycle is called a dot) 
  • CPU clock that runs at 1MHz (1 M-cycle = 4 dots)
  • VGA clock that runs at 50MHz 
• The reason for these clocks is due to the spec. 
  • The MMU must run twice the CPU frequency, because our FPGA BRAMS (gameboy memory) have a 2 cycle read latency. 
    • The PPU is clocked at 4 MHz according to Gameboy spec
    • The CPU executes an instruction across 4 cycles of the 4 MHz clock–hence, we made the CPU clocked according to 1 MHz. This is a subtle distinction that took us a while to dig out during integration and clarify. The discrepancy between the CPU and PPU clocks are documented poorly online and likely isn’t as big of a concern for software emulators.
    • The VGA must communicate at 50 MHz. 
• In our FPGA, we have two clock generators – a 50 MHz one and an 8 MHz one. The other 4 MHz and 1 MHz signals are derived from the 8 MHz to ensure that the clock edges are properly aligned. This was another bug we fixed this week. 

Risks and Risk Management:

• Switching to Joypad GPIO for now to reduce USB integration complexity
• Postponing NIOS II integration for after MVP gets hit, especially because its more well understood now
• Potentially cutting APU from final, because of time considerations (even though the pieces to put it together exist)

Verification & Validation Progress:

• CPU:
• • • passes Blargg Test ROM cpu-tests (minus interrupt tests due to optimizations in PPU)
    • passes hand-made tests
    • Is able to generate multiple frames and process joypad input.

• PPU: 
• • • Passes mode-level, line-level, and frame level timing requirements 
    • 100% palette mapping accuracy
    • Minor Sprite bugs – but these will be debugged soon to achieve sprite accuracy requirement 
    • Frame Output latency well under requirement threshold 

• MMU:
• • • Passes in personal testbench that did:
      • Queries to memory regions (rom/wram/exram/vram/oam/hram)
      • Queries to memory IO registers
      • DMA Query
      • Basic interrupt checks

• APU: Work in progress – no tests have been done so far 

• I/O:
• All key presses on the controller are very responsive – complete testing of latency will be done soon to validate if controller response time meets use case and design requirements. 

Bugs we fixed over the last two weeks:

• VRAM/OAM cpu write propagation (simulation)
• Reworked MMU/CPU/PPU clocks (simulation/synthesis)
• PPU reset behavior (simulation)
• Sprite priority bugs (simulation)
• Sprite horizontal and vertical flipping bugs (simulation)
• Window internal counter bug (still needs to be fully fixed) (simulation)
• Sprite sorting edge case (when sprite is technically off screen) (simulation)
• Horizontal and vertical background scrolling glitch (simulation)
• Fixed clock misalignment issue between PLLs on FPGA (synthesis)
• HRAM access issue (simulation)
• VGA upscaling issue (synthesis)
• VGA frequency issue, had to reparameterize to fit different resolution specs (synthesis)
• Joypad reading bug (simulation)
• Joypad register writing bug (simulation)
• Color Palette map bug (simulation)
• Lingering `DOC flag that took 4 hours to find (synthesis) 
  • I hate signaltap
• LCDC reset condition bug (simulation)
• Improper LY increment bug (simulation)
• Timer bug (simulation)
• IE IF register bug (simulation)
• STOP instruction bug (simulation)
• STAT interrupt and LY==LYC flag bug (simulation)
• TMA and TIMA mapping bug (simulation)

Known bugs that need be fixed:

• Simulation: DMG Acid Test – tile flipping bug
• Simulation: DMG Acid Test – window internal line counter bug (off by 1 line)
• Simulation: Dr. Mario – Frame 3 – Mario’s right hand is missing (overlapping sprite case)
• Synthesis: Dr. Mario’s first frame from ROM has yet to show up successfully. It flickers on FPGA screen and vanishes currently. 

Progress:

• Integration
  • MMU and CPU integration has been verified. All tests pass except interrupts (which we are debugging now that the PPU is introduced)
  • Testbench made for full integration
  • Full integration in progress
    • Working on generating a frame of Tetris
    • Working on debugging Acid tests
  • With initialized VRAM/OAM and a few hardcoded PPU registers, we managed to generate a tetris frame. This confirms that the PPU is accessing MMU correctly.

• I/O
  • New controllers have been assembled

Progress:

• Integration
  • MMU and CPU have been integrated
  • Testbench made for MMU and CPU integration
  • MMU and CPU integration debugging is in process.
• PPU
  • CGB PPU debugging — backgrounds and windows works.
• MMU
  • BRAM works in testbench
  • IO timer/apu/ppu/interrupt registers work in testbench
  • debugging DMA transfer details but CPU/MMU integration has begun
• APU
  • Implemented I2S logic — works in simulation.
  • Sketched APU datapath + RTL.
• I/O
  • New controller has been assembled

• Continuing along with clock at 2x CPU frequency for MMU, given that MMU BRAMs have to read out in 2 clock cycles (and we are expecting single cycle delay in CPU case)

Progress:

• CPU:
  • Made testbench to test CPU using Blargg test ROMs
  •  Almost all CPU Blargg test ROMs pass. (~24M instructions)
    • Test 2 (interrupts) requires integration with MMU and PPU to pass.
• PPU
  • DMG PPU debug + CGB PPU Updates.
  • basic VGA test on FPGA works + VGA & Frame Buffer logic integrated with PPU.
• MMU
  • Made personal testbench for MMU
  • All basic BRAM tests are passing, currently debugging IO and DMA features. Expected to start integration next weekend.
• APU
  • WM8731 I2C reset test works on FPGA –> learned SignalTap on Quartus to get this working.
  • Full I2C Config logic implemented + fully works in simulation.
  • I2S logic sketched out.

• Reworked a lot of interrupt routine handling after talk about CPU/MMU

Risks and Risk Management:

Progress:

• CPU:
  • Instructions implemented: 103 (all of them)
  • Interrupts implemented (needs thorough testing)
• PPU
  • DMG PPU (4-color PPU) is pretty much done!
  • Integrated testing and debugging with VGA logic
  • Full-color (CGB) implementation done, debugging in progress
• MMU
  • MMU has been written, undergoing debugging and soon-to-be integrated
• APU
  • APU writing has started and will be completed soon. Debugging postponed until after MMU/PPU/CPU integration.
  • Research into how to use WM8731 (Audio CODEC on the DE2-115)
  • Implemented simple I2C based sound check test for the WM8731
• Other I/O
  • Spent a lot of time researching USB integration
  • Confirmed GPIO NES controller works.
  • Resolved NIOS II blocker of lacking library support (had to source specific directory and add to LD_LIBRARY_PATH)

• Block RAMS are all 16 bit-width, 2 column format (given that the original gameboy’s data is 8 bit data words).
  • The reason for this is because we can instantiate dual port RAMS with 16 bit width that can allow OAM entries (32 bit wide) to be accessed in a single clock cycle by the PPU
  • Leaving other Block RAMS as 16 bit width as well is reasonable for the CPU and makes things consistent

Risks and Risk Management:

There are several environmental considerations on how our choice to emulate a Gameboy using an FPGA. The greatest benefit of our choice to use an FPGA is the inherent reconfigurable capabilities of an FPGA compared to an ASIC. FPGA development boards can be reprogrammed to serve completely different purposes, and do not require manufacture of new chips. In fact, we were able to avoid incurring any actual cost in our project because FPGAs already exist in the inventory. Once we complete our project, the FPGA can simply be returned and reused for a completely different purpose–therefore, we generate no E-waste with our project.

In addition, if our project succeeds and we open source our FPGA capstone project to other people, they also may be encouraged to enhance or build upon our work. This also can reduce material consumption in the greater community.

Progress:

• CPU:
  • All memory instructions completed
  • Instructions implemented: 26
  • Instruction tests written: 40
• PPU
  • Single frame test debugging mostly done (still debugging testcases with more than one sprite)
  • Debugging multi-frame rendering test
  • Scoping full-color PPU design updates
• MMU
  • Created several Altera MM modules that were able to be placed in Qsys Platform Designer, and routed to the SRAM controller and other interfaces
• Other I/O
  • Spent a lot of time researching USB integration

• After evaluating the Cypress USB Controller, the decision was made to pivot to the Raspberry Pi GPIO approach as a backup plan, while exploring the synthesis of the NIOS II soft core CPU for improved integration

Risks and Risk Management:

Progress:

• CPU:
  • Multicycle CPU framework completed
  • Instructions implemented: 11
  • Instruction tests written: 23
• PPU
  • RTL updated based on Memory organization / controller related design updates.
  • Implemented testbench, Python script to render image based on frame dump.
  • Unit tested most of the design and parts of the integrated logic. Working on debugging the PPU with a full end-to-end test.
• MMU
  • Re-designed memory controller to utilize FPGA Block RAMs instead of DE II SRAM/SDRAMs for simplicity of integration
  • Synthesized and tested Block Rams of different sizes (in ROM and RAM variant) and confirmed that they work
  • Creating Memory Controller according to updated spec (DMA support)
• Other I/O
  • Did research into USB/Audio integration. Discovered that NIOS II cannot be used,  but there are IPs provided by Altera that use an Avalon master/slave interface.
  • Learned more about the Quartus Avalon Slave Interface, currently working to create unit tests

• Swapped to cycle-accurate multicycle CPU.
• Reworked DMA responsibility

Risks and Risk Management: