[Oberon] Pipistrello

Jörg joerg.straube at iaeth.ch
Wed Jun 10 17:02:57 CEST 2020


Daniel

Pipistrello is a small FPGA-based board, with 1 MB of SRAM and 64 MB of DRAM and an HDMI output
https://sigrok.org/wiki/Saanlima_Pipistrello_OLS

I have it at home, run Oberon on it with more than 1MB and have a TCP/IP stack for this external board https://www.wiznet.io/product-item/wiz550io/ 

br
Jörg

Am 10.06.20, 16:07 schrieb "Oberon im Auftrag von Daniel Schmid" <oberon-bounces at lists.inf.ethz.ch im Auftrag von daniel.schmid at bluemail.ch>:

    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
    > ***************************************
    
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon
    




More information about the Oberon mailing list