Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I had no idea that the SCC read value not being stable for the required number of cycles could cause an effect like that.
    I knew if was a potential problem because of this comment - https://github.com/MiSTer-devel/MacPlus_MiSTer/blob/master/rtl/scc.v#L132-L134
    Your solution seems to stop the SCC irq being generated at all. I am investigating.
    Lawrie Griffiths
    @lawrie
    I also tried the Mister solution using fx68_phi1 for cep and fx68_phi2 as cen, but I am not sure if they are equivalent. With that, the irq was generated, but I got the same problem as before.
    Lawrie Griffiths
    @lawrie
    I am not sure why the low byte of SCC and IRQ is set to 8'hef, I copied it from the Mister project - https://github.com/MiSTer-devel/MacPlus_MiSTer/blob/master/rtl/dataController_top.v#L135-L144
    I think the reason that the if (cpu_as_n) rindex <= rindex_latch change is not working if that it prevents register 1 from being written.
    Lawrie Griffiths
    @lawrie
    If I initialize wr1_a and wr1_b to 1, then the scc interrupt gets generated, but the original problem is still there.
    Paul Ruiz
    @pnru_gitlab
    Would in not make sense to run a simulation and see what is going on?
    Lawrie Griffiths
    @lawrie
    There are a lot of external interfaces to simulate including SDRAM and the mouse interface, so setting up a simulation environment doesn't look that easy.
    Lawrie Griffiths
    @lawrie
    I did confirm that the next rom address after executing the instruction at 1AB6 is 2424 which is the tight loop waiting for the floppy, so that is consistent with an RTE being executed.
    Paul Ruiz
    @pnru_gitlab

    There is an sdram simulator here, in the Mini Cortex test bench:
    https://gitlab.com/pnru/cortex/-/blob/master/sys_tb.v#L292-385
    Note that it only does 512KB of sdram as written, but making it larger is simple tweak.
    Maybe for a test it is easier not to simulate the mouse, but to generate eg. x1 directly and have a minimal test program in the ROM.

    If I have time tomorrow, I'll see if I can set up a test bench using the simple M68K system and the SCC code.

    AndrewCapon
    @AndrewCapon
    Hi Guys, So I just got an 85 and after a few hours of swearing have managed to get the makefile and apio stuff going on my mac. fujprog seems pretty slow though, setting the baud rate seems to make no difference at all. This is even more annoying with apio as the bitstreams are so much bigger (why is that?). Is there anything I can do to improve flashing speed? Cheers Andy.
    emard
    @emard
    @AndrewCapon of course, ulx3s usually ships with micropython on esp32 already installed so you just need to setup a password for your wifi by writing a new main.py and then you can use ftp over network to program, flash and even manage sd card. https://github.com/emard/esp32ecp5
    Torfinn Ingolfsen
    @tingox_gitlab
    also, if everything you need is in the bitstream, you can just upload it to RAM (omit the -j from fujprog) for testing, this is quicker (than flash) @AndrewCapon
    Lawrie Griffiths
    @lawrie
    @AndrewCapon When you start building large bitstreams, it takes so long in yosys and nextpnr, that you hardly notice the time that fujprog takes :)
    Lawrie Griffiths
    @lawrie
    Also apio might not be using --compress on ecppack.
    AndrewCapon
    @AndrewCapon
    Hi Guys, thanks for all the info. I will look at the esp32 route, I didn't realise this was enabled on the board, I had looked at the instructions to get it installed and thought "Maybe tomorrow" ;)

    Also apio might not be using --compress on ecppack.

    Nice, I will look at that. the bit files are many times bigger

    emard
    @emard
    @AndrewCapon All is instealled on esp32 and should work, but maybe the version is a bit older so if you have bugs, upgrade ecp5 files and micropython to v1.12. If no bugs, let it as is
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I am making some progress with the Mac Plus. I don't think it was calling the subroutine at 1BA6. I think my diagnostics, which uses the external address from the cpu just showed that address 00401AB6 was put on the bus when the RTE at 1AB$ was executed. Possibly a pre-fetch.
    Lawrie Griffiths
    @lawrie
    I then determined that the addresses of the subroutines called at 1AAE are 1BA and 1CA, but should be 1B6 and 1CA, and both of these return the null subroutine at 1B10. If I path the value 401AC2 into 1CA from the ESP32 (after a reset and before moving the mouse), it calls 1AC2 and updates the variable containing the cursor position, but still does not cancel the SCC IRQ.
    So it makes a bit more sense but I don't know why the read from RR2B seems to getting a value 2 greater than it should.
    Lawrie Griffiths
    @lawrie
    (1AB$ should have been 1AB4, above).
    Javier de Sil贸niz Sandino
    @jdesiloniz

    Hello everyone, I'm having a bit of an issue trying to build a project for ULX3S using Yosys/NextPNR (under apio). NextPNR seems to be complaining about combinational loops:

    ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.

    But I don't seem to find what loops is it referring too. Forcing nextpnr to run ignoring errors, it throws this warning around 30 times. I thought it was because of how I handle FSM states but trying to follow a more "conventional" approach didn't seem to fix those. Doing so I got a seeming valid bitstream but in the FPGA it didn't work as expected (most of the signals didn't come out the expected ports at all), even though the simulations looked OK to me. So I think these timing issues could be the problem.

    It's the first time that I try to create something for the board and I'm a bit lost on how to fix these issues... if anyone could help taking a look at the design and see if there's something obvious I might be missing I'd really appreciate it: https://github.com/jdesiloniz/ulx3s_numeric_display/tree/main/rtl

    Thanks a lot!

    Javier de Sil贸niz Sandino
    @jdesiloniz
    Just in case it helps, I've tried to add the files in the project to a new blank project one by one... and when I got to this one https://github.com/jdesiloniz/ulx3s_numeric_display/blob/main/rtl/wb_hc164.v I started to get the same amount of warning errors as before (or even more). The rest of files I haven't added are dependant on this one, so I can't discard they have their own issues too. But at least things I suspected could be the case (i.e.: the way I handle FSMs) are discarded, as for instance clk_divider.v doesn't create that issue and I could synthetize and run a small blinker on the ULX3S based on that without issues.
    Doesn't look right
    state_next depending on itself is a combinational loop and likely to cause strange behaviour
    Javier de Sil贸niz Sandino
    @jdesiloniz
    I guessed so too, but for instance isolating this file (that does the same): https://github.com/jdesiloniz/ulx3s_numeric_display/blob/main/rtl/clk_divider.v nextpnr doesn't complain at all
    David Shah
    @daveshah1
    Thats such a simple case that Yosys might be optimising the loop away
    Javier de Sil贸niz Sandino
    @jdesiloniz
    but I think I'll have to rewrite all state machines in the project, I was trying to avoid latches by not using if-else unless necessary
    that's what I get for building everything based on the simulations and not trying to synthetize until the very "end" 馃槄
    David Shah
    @daveshah1
    But you are creating a latch of sorts anyway by having combinational feedback on a signal
    You'd be better off assigning the default value of state_next to state at the start and then having a bunch of ifs for each transition
    Javier de Sil贸niz Sandino
    @jdesiloniz
    so, assigning the start value when !i_reset_n, and then using if-else... is not dangerous regarding latches, isn't it?
    David Shah
    @daveshah1
    It isn't provided that next_state is given a value for every if else possibility
    Javier de Sil贸niz Sandino
    @jdesiloniz
    ok I see... thanks for the help!
    if I manage to get this working I'll let you know, my plan is to build a small adapter for 7-segment displays to use as a substitute of the OLED screen in simple projects
    emard
    @emard
    @jdesiloniz a simple try could be just to use reg state_next, replace combinatorial always with the clocked always at(posedge clock)... and replace "=" with "<=" there and see what happens. It can compile but just not work, or even maybe work :)
    Javier de Sil贸niz Sandino
    @jdesiloniz
    @emard thanks! I'll try that tomorrow. My whole thing with this is also trying to learn best practices to avoid these kind of situations pre-synth (because then debugging gets really hard), but it seems I still got tons to learn :D
    Javier de Sil贸niz Sandino
    @jdesiloniz
    yup, definitely it's helping (I tried fixing the FSM in my clock divider and using a shift register to drive the LEDs in the board), thanks!
    AndrewCapon
    @AndrewCapon

    @AndrewCapon All is instealled on esp32 and should work, but maybe the version is a bit older so if you have bugs, upgrade ecp5 files and micropython to v1.12. If no bugs, let it as is

    Got it going from FTP, super speedy now. Thanks :)

    Lawrie Griffiths
    @lawrie
    @pnru_gitlab What seems to be going wrong with the Mac Plus is that when it reads the value of RR2B at address 1A9C in the rom, it gets the value of RR0B (0x4c or 0x44) instead. It is a side effect of reading a register that rindex gets set to zero. That seems to be happening too early. So the problem is similar to what you suggested before, but I am not sure why it is different for me, as similar code seems to work on Mister, Mist and PlusToo versions. I am trying to find the best solution.
    AndrewCapon
    @AndrewCapon

    If anyone is interested in getting the ftp approach going in APIO then:

    You need to change a couple of son files in .../python3.7/site-packages/apio/resources/

    Add to programmers.json (with your correct ip address for the board):

    "ftpecp5prog": {
        "command": "ftpecp5prog",
        "args":  "192.168.0.89"
      }

    Add to boards.json:

    "ulx3s-85f-ftp": {
        "name": "ULX3S",
        "fpga": "ECP5-LFE5U-85F-CABGA381",
        "programmer": {
          "type": "ftpecp5prog"
        },
        "usb": {
          "vid": "0403",
          "pid": "6015"
        }
      }

    now use ulx3s-85f-ftp instead of ulx3s-85f in your apio.ini file.

    This is for the 85, for others just copy and rename the relevant block in boards.json.

    Paul Ruiz
    @pnru_gitlab

    @emard @charlesap I've uploaded a new version of the Oberon system that is more comfortable on timing:
    https://gitlab.com/pnru/ulx3s-misc/-/tree/master/oberon_pnr
    The big change is that the CPU now has a gated clock for pausing instead of the stallX signal (similar to what the FleaOhm version does, but smaller in scope as that system pauses the entire SoC and not just the CPU).

    This change allows an even simpler setup of the cache controller. It brings Fmax for the CPU up to 30-32MHz (it still runs at 25MHz). The cache runs at 100MHz, as does the block RAM. Typically I get an Fmax of 115-120MHz, although occasionally NextPNR generated a bad layout with an Fmax of 97-98MHz.

    There is something strange about the reset sequence. The Oberon station seems to need a long reset after loading the bit stream; subsequent resets only need a 20ms debounce. I think this may be related to the Oberon operating system. I am under the impression that on startup the Oberon OS checks ram for certain values and performs a "warm reset" if they are set. After a warm reset, the led's stay at 0x84 instead of moving all the way to 0x20, and the Oberon screen outputs "Abort at ..." in the top-right window.

    Lawrie Griffiths
    @lawrie
    @pnru_gitlab My fix for mouse movement isn't very neat, but it makes the mouse move fine: if (last_rom_addr != 24'h401a96 && last_rom_addr != 24'h401a9e) rindex_latch <= 0;
    Lawrie Griffiths
    @lawrie
    What I can't work out is what is causing the problem. At the first of those rom addresses, cpu_rw seems to be set to both read and write while scc_cs is still set, causing rindex to be reset to zero when it shouldn't be. On the second (the read) rindex is again set to zero before cpu_din is read.
    Lawrie Griffiths
    @lawrie
    So this is the line that needs a better solution - https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L489
    Charles Perkins
    @charlesap
    @pnru_gitlab Interesting, yes, the Oberon OS has a 'reset' path vs. a 'boot' path. I'll check it out
    Paul Ruiz
    @pnru_gitlab
    @charlesap Thanks! I think the cache & sdram controller are now of a simplicity that is commensurate to RISC5 itself; maybe even simple enough to teach to an undergraduate class. I'll leave it to you to let the Oberon community know that this exists.