ulx3s/Lobby

Lawrie Griffiths

@lawrie

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.

David Shah

@daveshah1

https://github.com/jdesiloniz/ulx3s_numeric_display/blob/dbc1ba8e7b1e7321a365c3490bd4a7a70a4bcd0d/rtl/led_display_controller.v#L242

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.

Paul Ruiz

@pnru_gitlab

@lawrie Have a look at this figure from the MC68000 user manual on bit savers:

In a real cycle, your SCC chip select becomes active along with ASn. On the rising edge between S3 and S4 the SCC will read RR2B and reset rindex back to 0. On the rising edge between S5 and S6 it will hence read RR0B. The 68K CPU clocks in this value on the falling edge between S6 and S7.

My thinking was to defer the set/reset of rindex until the rising edge between S7 and S0. The set/reset of rindex_latch happens twice (S4 & S6), but that should be okay. I am not sure why the simple deferral until ASn was high again did not work.

Where communities thrive

People

Repo info

Activity