[Oberon] Pipistrello

Wed Jun 10 16:06:58 CEST 2020

Dear Oberon-Mailing-Listeners

I'm rather new in using Oberon (AOS/A2), nevertheless i found it to be very straightforward.
Currently i'm writing a server app to read out smart electricity meters over tcp/ip and it works
fine. Now i read about this "Pipistrello" - could anybody tell me what it is about - i'm looking for
a device/box/board to implement an smart IoT-Node to enhance smart metering further to a smart grid.

Many thanks in advance for any explanations
Daniel Schmid

Am Donnerstag, den 28.05.2020, 12:00 +0200 schrieb oberon-request at lists.inf.ethz.ch:
> Send Oberon mailing list submissions to
> 	oberon at lists.inf.ethz.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> 	oberon-request at lists.inf.ethz.ch
> 
> You can reach the person managing the list at
> 	oberon-owner at lists.inf.ethz.ch
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
> 
> 
> Today's Topics:
> 
>    1. Project Oberon running from LPDDR memory on Pipistrello, now
>       with 8 bpp and 16 bpp color display modes (Magnus Karlsson)
>    2. Re: Project Oberon running from LPDDR memory on Pipistrello,
>       now with 8 bpp and 16 bpp color display modes (Magnus Karlsson)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 27 May 2020 15:50:42 -0700
> From: Magnus Karlsson <magnus at saanlima.com>
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] Project Oberon running from LPDDR memory on
> 	Pipistrello, now with 8 bpp and 16 bpp color display modes
> Message-ID: <af111d4b-b57f-9599-19d2-ecdcf62144fc at saanlima.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 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 
> 1440x900 display
> * 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 
> bit.
> 
> J?rg Straube have successfully shown the code working in both 1440x900 
> mono display mode and 8 bpp color display mode.
> 
> https://github.com/Saanlima/RISC5Verilog_lpddr
> 
> Cheers,
> Magnus
> 
> On 5/15/2020 7:53 AM, Magnus Karlsson wrote:
> > The project have been updated at 
> > https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr
> > This version is based on the current RISC5 verilog code (dated 
> > 11.12.2018).
> > 
> > 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).
> > 
> > Magnus
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 27 May 2020 16:05:49 -0700
> From: Magnus Karlsson <magnus at saanlima.com>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Project Oberon running from LPDDR memory on
> 	Pipistrello, now with 8 bpp and 16 bpp color display modes
> Message-ID: <3327a10d-9360-08d1-8bec-dc79a8020a73 at saanlima.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Correction:
> 8 bpp needs 0.75 MB memory, 16 bpp needs 1.5 MB memory for display buffer
> 
> On 5/27/2020 3:50 PM, Magnus Karlsson wrote:
> > 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 
> > 1440x900 display
> > * 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 0.75 MB memory, 16 bpp needs 1.5 
> > 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 bit.
> > 
> > J?rg Straube have successfully shown the code working in both 1440x900 
> > mono display mode and 8 bpp color display mode.
> > 
> > https://github.com/Saanlima/RISC5Verilog_lpddr
> > 
> > Cheers,
> > Magnus
> > 
> > On 5/15/2020 7:53 AM, Magnus Karlsson wrote:
> > > The project have been updated at 
> > > https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr
> > > This version is based on the current RISC5 verilog code (dated 
> > > 11.12.2018).
> > > 
> > > 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).
> > > 
> > > Magnus
> > 
> > -- 
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200527/fc6ac11a/attachment-0001.html
> >
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> ------------------------------
> 
> End of Oberon Digest, Vol 192, Issue 43
> ***************************************