This week was system bring-up week. Our goal was to get Controller Input, HDMI Video, and Linux running and communicating with each other. Additionally, this would include setup of our development environment, including Quartus, Platform Designer (Qsys), and arm-none-linux-gnueabihf.<\/p>\n
<\/p>\n
Out of these goals, only Controller-Input and Linux can talk to each other. HDMI Video has been tested via a demo 2 weeks ago, but the PPU and System-Interconnect design itself isn\u2019t finalized yet, so Linux cannot control the PPU and HDMI output yet. Specifically, this requires DRAM-fetch (Joseph\u2019s task for this week) and Tile-Engine (Joseph\u2019s task for next week) to be completed first.<\/p>\n
<\/p>\n
The results of Joseph\u2019s DRAM latency research forced us to come to the conclusion that our original idea of using DRAM as our VRAM was infeasible. The risk of the PPU repeatedly missing pixels turned out to be much larger than we had anticipated. As such, we have slightly reorganized our internal design for the PPU in a way that won\u2019t require us to change the MMIO interface but will still allow us to use the vast majority of our design as we originally specified it. Under the new design, the memory locations specified by MMIO will instead be transferred to an internal VRAM buffer at the beginning of each frame. The VRAM will be implemented in M10K, which we can access once per cycle. At the start of each VBLANK, the VRAM buffer will be committed to actual VRAM, which the PPU will then render from.<\/p>\n
<\/p>\n
There are no schedule changes this week.<\/p>\n","protected":false},"excerpt":{"rendered":"
This week was system bring-up week. Our goal was to get Controller Input, HDMI Video, and Linux running and communicating with each other. Additionally, this would include setup of our development environment, including Quartus, Platform Designer (Qsys), and arm-none-linux-gnueabihf. Out of these goals, only Controller-Input and Linux can talk to each other. HDMI Video … <\/p>\n