<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>Magnus</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Don’t know if this is the culprit:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There was this line in the RISC5.v you used:</p><p class=MsoNormal>assign adr = stallL ? B[23:0] + <span style='color:red'>{4'b0, off}</span> : {pcmux, 2'b00};</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For backward jumps this would be better</p><p class=MsoNormal>assign adr = stallL ? B[23:0] + <span style='color:red'>{{4{off[19]}}, off}</span> : {pcmux, 2'b00};</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m in the process to verify and will include the newest enhancements and bug fixes in the Verilog files. (rounding error in floating points, new shifter and registers…) and compiler.</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:magnus@saanlima.com">Magnus Karlsson</a><br><b>Gesendet: </b>Montag, 11. Mai 2020 03:23<br><b>An: </b><a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</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>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://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr</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://lists.inf.ethz.ch/mailman/listinfo/oberon</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://lists.inf.ethz.ch/mailman/listinfo/oberon</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>