<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=DE-CH link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Wojtek</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Currently, the design does not offer a multistage hierarchy of several types of Memory. It’s basically one L1 cache in FPGA BRAM between the RISC-5 and the LPDDR SDRAM.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If you design another board it will be your task to organize someone to write the firmware for your L2, L3 caches.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>br</p><p class=MsoNormal>Jörg</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Gesendet von <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> für Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Von: </b><a href="mailto:skulski@pas.rochester.edu">Skulski, Wojciech</a><br><b>Gesendet: </b>Montag, 11. Mai 2020 04:43<br><b>An: </b><a href="mailto:oberon@lists.inf.ethz.ch">ETH Oberon and related systems</a><br><b>Betreff: </b>Re: [Oberon] Project Oberon running from LPDDR memory on Pipistrello</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Magnus and Joerg:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>this is great news! Thank you! This is important to me because I am trying to decide how my ideal Oberon board will look like. I want to design such a board. So now I would like to use a memory hierarchy on the board. The closest to the CPU there will be the "tightly coupled memory" like Nios-II is using. (Described in the P.Chu's book on Nios-II SoPC.) This is purely firmware implemented in BRAM. It does not affect the HW design. Then I would like to use ZBT memory for the fast portion of the software. And then DRAM for everything else. Only the DRAM needs to be cached because ZBT is actually faster than the CPU can handle. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Your achievement is telling me that this is a feasible design. I was more afraid of the firmware than hardware because I know how to design the boards more easily than write firmware. So now I know there will be firmware to be adopted to such a board. This is great! Thank you!</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wojtek</p><p class=MsoNormal>________________________________________</p><p class=MsoNormal>From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Magnus Karlsson [magnus@saanlima.com]</p><p class=MsoNormal>Sent: Sunday, May 10, 2020 9:22 PM</p><p class=MsoNormal>To: oberon@lists.inf.ethz.ch</p><p class=MsoNormal>Subject: Re: [Oberon] Project Oberon running from LPDDR memory on Pipistrello</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I should clarify:</p><p class=MsoNormal>On power-up the cache is targeting the lower 128KB of the 1MB address space.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Magnus</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 5/10/2020 6:12 PM, Magnus Karlsson wrote:</p><p class=MsoNormal>> FYI, I have worked the last week with Jörg Straube on getting Project</p><p class=MsoNormal>> Oberon running from DRAM on the Pipistrello board and I just checked</p><p class=MsoNormal>> in the code on github:</p><p class=MsoNormal>> See</p><p class=MsoNormal>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Saanlima_Pipistrello_tree_master_Projects_Oberon-5Flpddr&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pQaHutcKTL4eMMurPT09ydwVh7yL-eyIdjlQoDySq0M&s=ElbN9RwmzLSJdX9SqSDoNfNi-tYpwS7fAFa2lF9zcsw&e=</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> It's using a 128KB cache organized as a 2-way 256-set cache with 256</p><p class=MsoNormal>> byte cache lines. The interface between the cache and the memory</p><p class=MsoNormal>> controller is 128 bits wide @100 MHz, and the memory controller itself</p><p class=MsoNormal>> has 800 MB/s peak memory bandwidth.</p><p class=MsoNormal>> On power-up the lower 128KB of the 1MB address space is covered by the</p><p class=MsoNormal>> cache. The main code for the cache is a simple state machine using</p><p class=MsoNormal>> about 150 lines of code with 4 states.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> The cache actually covers the lower 8MB address space so in theory we</p><p class=MsoNormal>> could have an 8MB Oberon system, but due to a bug somewhere in the</p><p class=MsoNormal>> Oberon code it crashes after about 1.25 sec with a trap (C2H on the</p><p class=MsoNormal>> LEDs) with more than 1MB of memory. The solution is to have the</p><p class=MsoNormal>> non-io address space aliased to the first 1MB. It seems like there</p><p class=MsoNormal>> are memory access cycles above 1MB that needs to actually affect the</p><p class=MsoNormal>> memory at the first 1MB. I did discover this way back when I did the</p><p class=MsoNormal>> 2MB version of Pepino and had the tie address bit 20 to 0 for it to</p><p class=MsoNormal>> boot (i.e. alias the second MB to the first MB) but never got around</p><p class=MsoNormal>> to pinpoint the problem. The same problem popped up again and I was</p><p class=MsoNormal>> able to trace it down.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Video memory is in dual-port BRAM and can be relocated by writing to a</p><p class=MsoNormal>> new register. At power-up the video is a the normal spot (0E7F00H)</p><p class=MsoNormal>> but can be moved up above the 8MB boundary to have a continuous 8MB</p><p class=MsoNormal>> memory section for program and data by simply writing to a register</p><p class=MsoNormal>> with the new video base address.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Cheers,</p><p class=MsoNormal>> Magnus</p><p class=MsoNormal>> --</p><p class=MsoNormal>> Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</p><p class=MsoNormal>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pQaHutcKTL4eMMurPT09ydwVh7yL-eyIdjlQoDySq0M&s=btdXkfnQU3BoNg-OsdQqh3co_uu3UBiBKbrzI2R6kWM&e=</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>--</p><p class=MsoNormal>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</p><p class=MsoNormal>https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pQaHutcKTL4eMMurPT09ydwVh7yL-eyIdjlQoDySq0M&s=btdXkfnQU3BoNg-OsdQqh3co_uu3UBiBKbrzI2R6kWM&e=</p><p class=MsoNormal>--</p><p class=MsoNormal>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</p><p class=MsoNormal>https://lists.inf.ethz.ch/mailman/listinfo/oberon</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>