Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Paul Ruiz
    @pnru_gitlab

    @emard Maybe indeed there is a total failure of sdram, although I would surprised that it would get as far as leds=0x84 in that case. I am running tests with the sdram model that @edbordin found and that has already identified some issues (like my refresh commands being spaced too closely together).

    Maybe the HEX interface can track the commands that are sent to the sd card? This way we can check that the sequence prior to leds=0x84 runs as expected or not.

    Ed Bordin
    @edbordin
    @pnru_gitlab fwiw I was checking the timing parameters on that sim model today and was unsure if the tRFC parameter on the micron part (auto refresh period) has an equivalent specified in the datasheet for the ISSI part
    emard
    @emard
    The problem could be around sdram and cache controller. HEX can display some debug register, let's say debug logic is made to store some value in reg just before 0x84 status. This reg should be wired to toplevel where is hex_decoder instance and during vsync move reg value to OSD_display reg. Here is my demo that shows CPU side. https://github.com/emard/oberon/blob/master/hdl/pnru_mix/Ulx3s_Top.v#L395
    Paul Ruiz
    @pnru_gitlab

    @edbordin Point taken. However, I also have an older ulx3s board with the micron chip. In general, I guess I'd like to write it such that a wide range of chips are covered.

    Further tests bring up no other issues, and inspection of the sdram and cache ram contents after a short run show the expected results.

    Paul Ruiz
    @pnru_gitlab
    @emard clear - hope to have some further time tonight.
    Paul Ruiz
    @pnru_gitlab
    Still not much further, no working code.
    An almost successful simulation run produced the following statistics: booting takes ~1000ms, of which the first 100ms runs from rom. In the remaining 900ms were to code runs from ram, there were 2500 cache misses, of which 1500 had to write a dirty cache line. It would seem to me that using "random" replacement instead of approximated LRU worked out well.
    emard
    @emard
    Real one also boots around 1s. Obviously task is not so easy to make. For experimenting, can it work work directly with sdram, without cache or only in combination?
    Paul Ruiz
    @pnru_gitlab

    @emard The sdram controller can work alone, but it is designed to read/write 128 (16 bit) word bursts. Not so easy to interface to a host that expects single words. The cache can really only work together with the sdram controller, because it expects signals and data to arrive in precise order (like: "if this signal is asserted, data will be available 2 clocks later", etc.). It could be possible to connect the cache/sdram combo a simple system with a monitor program.

    Maybe the least effort is to write a simple RISC5 assembler and put some short test programs in the rom and test that way. Heresy, as in the minds of the Oberoners there is no such thing as RISC5 assembler, it seems. The Oberon system has a UART that is easy to use: write to a register and a character gets send, etc.

    I am probably not seeing the forrest for the trees. I think I will leave this for a week and then have a fresh look.

    emard
    @emard
    @pnru_gitlab I see, sdram interface is significantly different than CPU so cache must be inbetween. OK good idea to let it be thinked about for a while. One of debug possibility is to add SPI slave and peek/poke RAM from ESP32
    Lawrie Griffiths
    @lawrie
    @goran-mahovlic @emard I have been converting a few more example programs to nmigen including a PS/2 keyboard example and some audio examples - https://github.com/lawrie/ulx3s-nmigen-examples
    The plaform resource for ulx3s seems to have several problems and really needs reviewing - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py
    Problems that I have found are the audio resource cannot be used as it has ring2 pins as duplicates of ring 1 - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L79-L84
    The default usb resource is not usable for PS/2 keyboards as it only defines one of the pull-ups - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L107-L109
    Lawrie Griffiths
    @lawrie
    It is also missing the usb_fpga_dp/dn version of the pins.
    The oled connector is completely missing.
    It should probably be used ujprog rather than openFPGALoader - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L143-L146
    I am also not very convinced by how the buttons are done, and various other attributes seem to be missing or wrong.
    emard
    @emard
    looks nmigen board pinout is unfinished to be fixed later when someone tries to use them. I haven't participated in the making. Goran send board Luna for porting the USB sniffer, but we should probably load nmigen ourself, try and ask for fixing
    openFPGALoader itself is ok if someone prefers e.g. fujprog binary is not working on some platform. It can program fpga and flash, same as fujprog
    Goran Mahovlic
    @goran-mahovlic
    @Dolu1990 @lawrie wow! https://twitter.com/Ruinland_Mask/status/1321467724774535169 And I thought we are still at tetris :)
    Dolu1990
    @Dolu1990
    Cool :D
    kost
    @kost

    openFPGALoader itself is ok if someone prefers e.g. fujprog binary is not working on some platform. It can program fpga and flash, same as fujprog

    will investigate this.it stopped working with newest release?

    kost
    @kost
    user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v48-linux-x64 -j flash blink_12f.bit 
    ULX2S / ULX3S JTAG programmer v4.8 (git 96ebb45 built Oct  7 2020 20:34:11)
    Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors
    Using USB cable: ULX3S FPGA 12K v3.0.8
    Erasing sectors, please wait.
    Programming: 100%  
    Completed in 41.93 seconds.
    user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v46-linux-x64 -j flash blink_12f.bit 
    ULX2S / ULX3S JTAG programmer v4.6 (git 0a4cc36 built Jul 22 2020 20:50:14)
    Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors
    Using USB cable: ULX3S FPGA 12K v3.0.8
    Erasing sectors, please wait.
    Programming: 100%  
    Completed in 45.14 seconds.
    Tested released versions and they are working fine.
    kost
    @kost
    any specific platforms?
    I need to test it on?
    Lawrie Griffiths
    @lawrie
    @kost I thought @emard was saying that openFPGALoader was an alternative IF fujprog was not working on a particular platform at any time. I didn't think he meant it was not currently working. I would prefer nmigen changed to use fujprog. It is not particularly easy to switch between using one or the other.
    emard
    @emard
    @kost @lawrie Right fujprog could be working ok, but this nmigen source author maybe didn't know of fujprog, or for his multiplatform project he prefers to use the same tool (openFPGALoader) for as many platforms possible.
    When flashing fujprog is slightly faster than openFPGALoader
    kost
    @kost
    thanks on details. Just wanted to see if there is any bug i'm not aware. As I have spend quite some time on multiplatform support: from Windows, Linux, Mac and BSD.
    Goran Mahovlic
    @goran-mahovlic
    We have added few USB/OV7670 extensions to e-radionica https://e-radionica.com/en/catalogsearch/result/?q=ulx3s
    still no pictures, but will be there
    Torfinn Ingolfsen
    @tingox_gitlab

    this might show my lack of verilog knowledge, but still. In the example https://github.com/lawrie/ulx3s_cpm_z80 in the file Microcomputer.v I find this little snippet:

       // ===============================================================
       // System Clock generation
       // ===============================================================
       wire clk125, clk;
    
       pll pll_i (
         .clkin(clk25_mhz),
         .clkout0(clk125),
         .clkout1(clk)
       );

    But no further definition in any file related to this project. Is this some kind of built in primitive for verilog? (I couldn't find a description in Lattice ecp5 documents, so I don't think it comes from there). How is one supposed to figure out what 'clk125' and 'clk' are? (ok, I might guess that clk125 is 125 MHz, but that is just a guess).

    Lawrie Griffiths
    @lawrie
    Torfinn Ingolfsen
    @tingox_gitlab
    never mind, I just found the pll.v file that comes with the project blush
    Paul Ruiz
    @pnru_gitlab
    I wrote a simple assembler for the Oberon RISC5 cpu and with that some simple test programs for the Oberon rom:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/as5.c
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/test.s
    To my surprise, the cache does not seem to read from sdram at all, and just keeps showing the pre-loaded content. A small anomaly every 64 words suggests that it does recognize cache lines and updates the tag for the line. This overall outcome surprised me: I had expected it so see it read garbage or maybe data with a location offset, etc.
    Then I configured a simple 99K system with the cache + sdram (and a bit of rom and bram for a monitor). With that system the cache + sdram mostly works, there is some data corruption that suggests my timing is not quite right but otherwise results are as expected.
    Krome Plasma
    @kromulan
    Where is ULX3s sold ? I mean where can i buy the board ECP5 85F?
    Ed Bordin
    @edbordin
    you can preorder from the next batch of 85F on crowdsupply or mouser. I'm not sure if Radiona sells through other channels too
    Goran Mahovlic
    @goran-mahovlic
    @kromulan I have 85F prepared for CrowdSupply, but currently waiting for some papers from them.
    And currently no other chanels for 85F
    emard
    @emard
    @pnru_gitlab hey cool small source of assembler!! Obviously risc5 cpu presents some bus transitions that confuse the cache. Generally it is possible that cache and ram controller have a bug which doesn't manifest when used on one soft-core because it has always the same access pattern, while on other core the bug may manifest
    Charles Perkins
    @charlesap
    @pnru_gitlab An excellent little assembler! I will now abandon my efforts to make one in Python because this one does everything I would need.
    emard
    @emard
    ULX3S v3.1.4 project is out https://github.com/emard/ulx3s maybe you alread know, but I just tried and it works, small vt100 onboard editor for esp32 https://github.com/emard/esp32ecp5#onboard-editor
    mara
    @vmedea
    that could definitely come in useful ! at least with the memory to spare
    Andrew Nesbit
    @ullbeking_gitlab
    :'-( :'-( :'-( Waaaahhhh!! I was SO EXCITED when this was being lobbied for and I was pledging for it. Then it was finally released and guess what, I am completely and utterly broke, and there's no way I can rationalize buying this now :'-( I thinkit will make it all the more sweet when I finally DO save up some money and finally am able to buy it myself. It will mean so much more to me then.
    emard
    @emard
    @ullbeking_gitlab production really took much time. If I click "mouser" at https://kitspace.org/boards/github.com/emard/ulx3s/ parts for 85F without PCB cost 93$. Design goal asked by FER uni was that 200-500 assembled boards cost approx equal as parts from one set from mouser For student buying at FER shop, less than 100$ per board. Price at CS is only exceeded by administrative amount, but it is still very tight, Goran must work really hard to get any income from this - if there is more than 8% of faulty boards from production it would mean loss of investition. Even I don't have latest v3.0.8 85F because Goran sent all to CS distribution. It is always unsure will new v3.1.4 or higher prototype, when assembled, work as expected.
    Goran Mahovlic
    @goran-mahovlic
    I am trying to organize production with e-radionica for 12F without some chips - like ADC/I2C/RTC that version would be in the e-radionica store so we would not pay for extra shipping/export/import/fees so it should be more affordable.
    One 100 pcs. production run is requested from Watterot - but we are waiting really long time for them. I also do not think it will be cheaper, it will only have 64Mb SDRAM - as the first batch they did...
    Goran Mahovlic
    @goran-mahovlic
    As for Crowd Supply - in after sale I really lowered all prices for them - as in campaign (after lots of negotiations) they offered good fee - almost too good, so they did not have any profit on campaign boards. Specially after sending all those "free" connectors in separate shipment.