[Oberon] Project Oberon running from LPDDR memory on Pipistrello, now with 8 bpp and 16 bpp color display modes
magnus at saanlima.com
Thu May 28 00:50:42 CEST 2020
I have made updates to the code on github with the following changes:
* The code now has it's own repository with a master branch and two
versions with color display added
* The mono display buffer in BRAM is now 160 KB, big enough for a
* The CPU clock is now coming from the memory controller PLL, leaving
the video PLL free to implement any frequency needed by the video controller
* The cache is now 64KB (2-way, 128-set, 256 bytes/cache line) to make
room for the larger mono display buffer
* The color version have 8 bpp or 16 bpp color video added in parallel
with the mono display. 8 bpp needs 1.5 MB memory, 16 bpp needs 3 MB
memory for display buffer
* The color buffer can be at any place in the 15.75 MB lpddr memory
space (aligned to 16 bytes) controlled by a color buffer address register
* When using color display the cache needs to be flushed. There are
several ways to flush the cache - on demand by software, on every vsync
and using auto-flush where a cache line is flushed every 1024 CPU clocks.
* The selection between mono display and color display is via a register
Jörg Straube have successfully shown the code working in both 1440x900
mono display mode and 8 bpp color display mode.
On 5/15/2020 7:53 AM, Magnus Karlsson wrote:
> The project have been updated at
> This version is based on the current RISC5 verilog code (dated
> System info:
> Cache size: 128 KB (2-way 256-set).
> Cached area: lower 15.75 MB of the RISC5 memory map is mapped to
> cache/lpddr memory.
> The non-cached area (top 256 KB of the RISC5 memory map) is used for
> I/O (top 4KB), boot prom (next 4KB), then a free 248 KB area where the
> video display buffer can be relocated .
> Video buffer is in BRAM and is located at the default place at power
> up but can be relocated anywhere in the memory map by simply writing
> to a new 24-bit video base register.
> Since the video frame buffer is in non-cached BRAM there is no need to
> flush the cache, which btw uses write-back policy.
> The system will be slowed down by cache misses but there is about 11%
> gain by having the video buffer in BRAM (no cpu stalls due to video
> controller memory access).
More information about the Oberon