Access to tumbleed/uhdl?

[ams]

Do you want access to the Fossil repository? Maybe this could be kept on a branch, of course that is up to you what you prefer! :-)

[nusgart]

I apologize for the extremely long delay in answering this, but yes, I would like access.
Also, a few things:

• In the mister branch of the repository, you've removed the sys directory. I would recommend against doing this as it makes compiling and using this code much more complicated. The MiSTer framework doesn't have a fixed "API" because they regularly add features (for example, commit fc3e01f37d56b35e4446822c940a4734ff38c43e changed the width of the VIDEO_ARX and VIDEO_ARY signals), so a given version of this core only supports the framework in its tree.
• I've been working on adding/updating testbenches and have noticed that the RAM controller testbench's VGA VRAM tests fail, but I haven't changed the VRAM logic from the LX45, which works. Does the testbench pass for the LX45 or is this a new problem (if it is, it's probably caused by differences in Xilinx and Altera's block RAM IPs).
• Also, I've been trying to get the spy port to work for a while now. Does the cc program that used to be included with USIM work for this (it doesn't seem to work, but that might be my fault). One other idea I've had is to use the extra HPS IO bus to directly interface with the debugging spy interface instead of going through the spy UART...
• In general, this project needs a lot more documentation, especially about getting started but eventually I'd like to document how to port the uhdl to different FPGAs and devboards. Eventually, I'd like to port uhdl to the ULX3S because of its open source toolchain, but I want to get the MiSTer port working first.

[ams]

I apologize for the extremely long delay in answering this, but yes, I would like access. Also, a few things:

No worries! I think you should also be able to register your own user .. I can then change the access rights. If that doesn't work, I should fix it.

Do you mind usnig Fossil instead of git?

• In the mister branch of the repository, you've removed the sys directory. I would recommend against doing this as it makes compiling and using this code much more complicated. The MiSTer framework doesn't have a fixed "API" because they regularly add features (for example, commit fc3e01f changed the width of the VIDEO_ARX and VIDEO_ARY signals), so a given version of this core only supports the framework in its tree.

My idea was to set a symlink to Template_MiSTer/sys in uhdl-mister/. Do you think that would work for you? I find it strange how MiSTer does things, since it is mixing ones own HDL with things that you shoujldn't be touching?

Or we can just import sys/ at some specific point and be happy. Whatever works for you.

I haven't been doing much HDL latley, been concentrated on trying to get System 98/99 working -- but with little success. I might go back to HDL hacking, since some of the debugging parts might be easier (which you touch upon below).

• I've been working on adding/updating testbenches and have noticed that the RAM controller testbench's VGA VRAM tests fail, but I haven't changed the VRAM logic from the LX45, which works. Does the testbench pass for the LX45 or is this a new problem (if it is, it's probably caused by differences in Xilinx and Altera's block RAM IPs).

I can see if I can check that.

• Also, I've been trying to get the spy port to work for a while now. Does the cc program that used to be included with USIM work for this (it doesn't seem to work, but that might be my fault). One other idea I've had is to use the extra HPS IO bus to directly interface with the debugging spy interface instead of going through the spy UART...

CC used to work, yes.

A proper SPY bus would be great -- specially if you could hook up two boards and have one debug the other. I am not familiar with the HPS IO bus. One idea I had was to move much of the bus interfacing to Wishbone; but I've heard good things about AXI-lite. This is a bit out of my leauge to decide on I feel. Do you have any opinions on that? I think it should be possible to present WB/AXI/.. to the CADR without it knowing that it isn't really a Unibux/XBUS.

• In general, this project needs a lot more documentation, especially about getting started but eventually I'd like to document how to port the uhdl to different FPGAs and devboards. Eventually, I'd like to port uhdl to the ULX3S because of its open source toolchain, but I want to get the MiSTer port working first.

Yes, it needs infinitly more documentation. If you have any points that you'd like for me to document, I can start doing that. Specially how to debug various low-level problems with the microcode would go a long way, and given a (proper, the cc.c hack is very basic) CC one could even run some of the diagnostics.

[nusgart]

So I'll try to figure out how tumbleweed.nu works at some point (I made an account, and also, I have some familiarity with fossil but for now I'd prefer to keep this as my main repository for several reasons), but I'd like to address the technical points here first.

Documentation

I know this point came up last but I think it is by far the most important so I'm addressing it first. I agree that this project needs a lot of documentation work and knowing how to debug the microcode would be very helpful, but I think the single most important piece of documentation would be a detailed guide on how to set UHDL up -- eventually we'd want specific documentation for each supported board but only the Pipistrello actually works right now. I think there used to be a guide in one of the issues in the old github repository but that no longer exists, so I'd appreciate it if you could write one. I've made a separate issue at #2 describing what work needs to be done. I'll document xbus and obviously porting uhdl when I finish this port, and probably some of the others, but I don't know enough to write the low level microcode debugging documentation along with some of the other stuff.

MiSTer Framework

As far as the MiSTer framework goes, I've been following what the main mister cores do as I'm thinking of trying to get this core included with the main set of cores once it works.

VGA RAM Access Testbench

Thanks. I'd like to eventually make sure all of the existing testbenches work and write more of them, or possibly even explore formal verification (I don't know much about this).

The Spy Bus and bus interfacing

It's good to hear that the CC.c program "works" (I only need something basic). I'm also interested in getting a better SPY bus implementation, and there are a few options. The most straightforward option would be to just expose the spy bus signals as GPIO, but that raises some synchronization issues and unfortunately the MiSTer is short on GPIO (already used up), and this wouldn't be easy for usim to hook up to (might be useful). The current of exposing a serial protocol is also fine at least for now, although we might need a way to halt the machine for single-stepping (I didn't see one on quick inspection of the documentation, but I might have missed it). Also, for reference, the HPS IO bus is a MiSTer specific thing describing a specific way for the control program on the Hard Processor System to interface with the FPGA core.

As far as interfacing another bus to xbus, the important thing to remember is that xbus was designed as a traditional shared bus and isn't particularly high throughput. Both AXI and AXI-lite are fairly complicated to enable high throughput and a lot of that complexity would be wasted: xbus only has a shared read/write channel so AXI/AXI-lite's split channels (read address, write address, read data, write data, and read response) would go to waste, xbus doesn't appear to have any burst functionality, and it also doesn't support byte-enables. As a result of this, I don't think that AXI or AXI-lite would be good options. Wishbone is a lot simpler and would be a better match to xbus, and perhaps adding a bus bridge would be a good idea.

[ams]

Sorry for the delay in an answer. You raise multiple important points, and I totally agree. I've been trying to re-setup my Xilinx setup again (change of computers means I lost my install), in a effort to document it, and uhdl. I'll comment some more a bit later.

[ams]

Minor update. I've spent the last days fixing up a new environment for uhdl. And will re-verify that everything works as it should and (continue) documenting how to build, and see if I can also document some of the surrounding parts (debugging the board using cc etc).

[ams]

Current uhdl trunk is verified to work. And I've started to write some instructions on how to use things. Please see https://tumbleweed.nu/r/uhdl/doc/trunk/README.md

I am having some issue with getting the ./cc command working, where I keep getting EAGAIN errors when doing read(3)/write(3). Out of curiosity, was that the same type of issue you ran into?

[ams]

Good news, I've managed to reproduce the issue with the UART/CC you are having. I'll spend this weekend fixing that.

[nusgart]

I apologize for not responding sooner, but actually, no, that wasn't the problem I was getting (I may have in the beginning, I don't remember). I managed to get CC working on the Arty A7 a few weeks ago and intended to tell you sooner, but didn't get around to it until now (sorry).

I did have problems that sounded like that at one point, but I solved most of them by using the following shell script to run cc.

#!/bin/sh
# substitute the appropriate device file here
FILE=/dev/ttyACM0
# setup correct terminal mode for CC
stty -F $FILE raw
stty -F $FILE -echo -echoe -echok
stty -F $FILE speed 115200 cs8 cstopb -parenb -crtscts
# run CC
exec ./cc $FILE $*

The problems with CC were actually on the FPGA side, and there were two of them for the Arty A7. The first problem was that I didn't read the datasheet for the A7 closely enough and accidentally swapped the TX and RX pins because of confusing naming (they're named UART_TXD_IN [FPGA RX pin] and UART_RXD_OUT [FPGA's TX pin] -- resolving that was a pain). The other problem was a bug in spy_port itself where the response data was never set. I've pushed the commit to that repository (https://github.com/nusgart/uhdl), and I've also put the patch data for that change below.

diff --git a/spy_port.v b/spy_port.v
index b9d3266..2c01d48 100644
--- a/spy_port.v
+++ b/spy_port.v
@@ -173,6 +173,18 @@ module spy_port(/*AUTOARG*/
      end else begin
    dbwrite <= (spyu_state == SPYU_OPW1);
      end
+     
+   always @(posedge clk) begin
+     if (reset) begin
+       response <= 16'b0;
+     end else begin
+       if (dbread) begin
+         response <= spy_in;
+       end else if (start_bd_read) begin
+         response <= spy_bd_reg;
+       end
+     end
+   end

    always @(posedge clk)
      if (reset) begin

[ams]

Yeah, the bug in spy_port is what I was referring to. And that is the fix I tried yesterday ... but I haven't pushed anything. FPGA hacking between managing two kids is interesting, so my workflow is very compartmentalized -- where I do one small thing at a time, either troubleshooting, investigating, or solving.

The stty hackery, I'll try that -- but ./cc should take care of it. I also started working on getting the diagnostics working with uhdl. Documentation is still being worked on, as I tackle things.

Thank you for the note on the A7 and the confusing naming of the pins too! I have a A7 which I wanted to work with when I've retested all the things on the LX45. When I've done that, I'll bundle up a archive as reference point with all data.

[ams]

One thing to note is that the SPY port runs of the CPU clock -- so since the clock is halved on the LX45, one needs to reduce the baud rate as well in the serial comm side.

But, that is my least worry right now -- my board stopped booting. And that is with a well known bit stream for the LX45 that I know for a fact works.

Seems the disk image was trashed for whatever reason?

  00424 (PROCESS-SECTION 1) ...in the PROM.
  00425 (PROCESS-SECTION 2) ...in the PROM.
  00524 (GET-NEXT-WORD) ...in the PROM.
  00525 (GET-NEXT-WORD 1)   ...in the PROM.
  00526 (GET-NEXT-WORD 2)   ...in the PROM.
  00527 (GET-NEXT-WORD 3)   ...in the PROM.
  00530 (GET-NEXT-WORD 4)   ...in the PROM.
  00426 (PROCESS-SECTION 3) ...in the PROM.
  00427 (PROCESS-SECTION 4) ...in the PROM.
  00524 (GET-NEXT-WORD) ...in the PROM.
  00525 (GET-NEXT-WORD 1)   ...in the PROM.
  00526 (GET-NEXT-WORD 2)   ...in the PROM.
  00527 (GET-NEXT-WORD 3)   ...in the PROM.
  00530 (GET-NEXT-WORD 4)   ...in the PROM.
  00430 (PROCESS-SECTION 5) ...in the PROM.
  00431 (PROCESS-SECTION 6) ...in the PROM.
  00432 (PROCESS-SECTION 7) ...in the PROM.
  00433 (PROCESS-SECTION 10)    ...in the PROM.
  00434 (PROCESS-SECTION 11)    ...in the PROM.
  00435 (PROCESS-SECTION 12)    ...in the PROM.
  00032 (ERROR-BAD-SECTION-TYPE)    ...in the PROM.

[nusgart]

That's interesting, I don't think I've ever had that problem other than when I tried to get SDHC cards to work (I've suspended that work until I get this working). The problems I have relate to it either getting stuck in findcore3 looking for memory (thrashing) or in the ethernet code (ether-rcv-new-packet, 22443-22446) (this is what's happening in my current test).

Edit: Forgot to mention this, but it's possible that the SD card is starting to go bad. What I would do during SDHC testing was to diff the SD card against the image I dd'd to it.

[ams]

The SD card is quite old, and whatever original image I had on it is since long gone. I just copied a new one, and that seemed to take care of the issues.

I would strongly suggest that you take https://tumbleweed.nu/r/sys78/uv/disk.img.gz as your base line -- I am not sure where from the ETHER-RCV-NEW-PACKET code came from, I think it was some attempt by RJS (I think?) to add some kind of a OpenCores Ethernet layer in usim. The above disk image has been well tested, and if I know your baseline for the microcode, then it makes it much simpler to discuss any issues.

[nusgart]

Ok. I'll try using that. Does this use microcode 841 or will I need to find the symbols for it? Also, I've been meaning to ask this for a while, but I just need to dd the disk image to the directly SD card (i.e. no filesystem involved), right?

Edit: completely forgot about diskmaker's ability to check microcode and lod versions

[ams]

The symbol files etc, https://tumbleweed.nu/r/sys78/info/f4952597ed98563b .

Do not blindly trust the output from diskmaker -- since Unix has no ability of registering the version of a file. It is indeed a minor pain point (e.g., I have updated UCADR LISP slightly to remove the PUP code, but have not re-assembled the microcode in the repository).

About the disk image, you just dd it straight to your SD card. You can use a file-system, but it would be from the Lisp Machine side, and not anything the host knows about...

[nusgart]

Ok -- I've started up the disk image you sent, and I'll see if it boots. Thus far, it seems to be doing a lot of paging (but based on my admittedly limited understanding of the CADR boot process, that should be the case anyways). About the disk image, that's what I thought, but I just wanted to sanity check. Also, it would be nice if you'd change the microcode version to something obviously bogus like 000 to make it clear that it's not very meaningful, unless the system code does a compatibility check or something like that.

[ams]

I'll ponder the idea -- it would indeed be nice, likewise for the System version to somehow "bump" it away from the "historical" ones to keep somewhat better track. I ran into this when starting with the original code from Brad, which had a "841" but didn't match anything.

(And yes, there is quite some paging going on during boot)

[ams]

I wrote some minor notes about my setup, for posterity, and made an archive of what I tested. https://tumbleweed.nu/r/uhdl/timeline?r=good&c=2021-03-09+19%3A19%3A51

[ams]

Here is (some) documentation on the CC protocol (https://tumbleweed.nu/r/uhdl/file?name=spy_port.v&ci=tip). For the EADR's, see https://tumbleweed.nu/r/uhdl/file?name=CADR4/IRAML/SPY0.v&ci=tip .

// SPYTX<7-4>   = Operation
//            0-1   Unused.
//            2     Read content of spy register. [??? Is this used?]
//            3     Set DATA<15-12>.
//            4     Set DATA<11-8>.
//            5     Set DATA<7-4>.
//            6     Set DATA<3-0>.
//            7     Unused.
//            10    Read content of spy register.
//            11    Read content of spy register.
//            12    Write DATA into spy register.
//            13    Write DATA into spy register.
//            14    Read spy block-device register.
//            15    Write DATA into spy block-device register.
//            16-17 Unused.
// SPYTX<3-0>   = Data source.  When reading or writing the spy register
//        (operations 10-13), this is the EADR signal used in SPY0.
//
// The response when reading (operation 10 and 11) will be split into
// four octets (same format when setting DATA):
//
// SPYRX<7-4>   = What part of the DATA register that was read:
//            0-2   Unused.
//            3     DATA<15-12>.
//            4     DATA<11-8>.
//            5     DATA<7-4>.
//            6     DATA<3-0>.
//            7-17  Unused.
// SPYRX<3-0>   = Data that was read.

[ams]

Continuing on the documentation front, I've done some more minor writing. I've also fixed up the CC to work with the board, currently only tested on GNU/Linux, and against the Pipistrello. For fun, I also tried CC-SCAN-A-MEM-FOR-BAD-PARITY while that executed, it complained about bad parity (probably because we don't implement it).

I will try and document how to use this, currently I am just calling the functions defined in https://tumbleweed.nu/r/zl-cc/file?name=lcadrd.lisp&ci=tip but I should get the real CC debugger working in a bit which provides the "nicer" interface. Will have to go through each function and see that it does the right thing, and then go through https://tumbleweed.nu/r/zl-cc/file?name=diags.lisp&ci=tip, and somewhere between getting CC working well enough.

CC> (cc-read-ir)
625255588003 (#o11062410620243)
CC> (cc-write-ir #o11062410620244)
T
CC> (cc-read-ir)
625725431972 (#o11066011060244)
CC>

[ams]

Do you have a current list of issues you are experiencing? I've gotten enough parts so I can setup something usable with my Arty A7 board.

[ams]

So I've gottent to a bitstream, had to regenerate the MIG DDR interface since some files are missing in the repo. Seems to be booting, guess time to start debugging.

[nusgart]

I apologize for not responding sooner, I've been quite busy. To get started, before I forget, I've noticed that you've started work on porting to the Arty A7 yourself. Since we're no longer using the same vcs, it might be difficult to synchronize larger changes — do you have any suggestions here? Some advice: the 7-series DDR controller is very different than the Spartan 6's, so I found it easiest just to completely rewrite the memory controller -- I could never get the old controller to work at all. I also noticed a problem in mouse.v: you assign .ps2_data(ps2_data_out), but should assign .ps2_data(ps2_data_in) (ps2_data_out is generated by an instance of ps2_send, not by the mouse).

Moving on to the issues I have, the main issue I've been having is that the A7 seems to get stuck in findcore3 - I'm not sure exactly why. If you could test the code that's currently in https://github.com/nusgart/uhdl/, that would help narrow things down. An important question I have is when the prom loads the microcode, does it load into main memory or directly into IRAM? If it loads the microcode into main memory first, this would indicate that my memory controller does work since it loads the microcode successfully. The comments do indicate that the microcode is loaded into main memory, but I want to make sure so I don't incorrectly rule out my memory controller.

I'm not exactly sure what's going wrong. Assuming that the successfully loading microcode shows that my memory controller works at least partially, then I can think of a few things. Firstly, since I've never seen any successful boots, my setup might be wrong. It's also possible that I've misconfigured the refresh in my memory controller, which would cause things to go very wrong after about 64 milliseconds (enough time to load microcode), although I have tried to check this. It could also be that one of the other changes I've made broke it, or that the xbus_chaos module causes problems (when I have time, I'll try removing it). Alternately, I might have made some other mistake, like mixing up pin locations.

Edit: just saw your new comment after posting this one, will take a look at that. Edit 2: This is with the code on tumbleweed, right? Is the online repository up-to-date?

[nusgart]

How did you attach a VGA pmod, 2 PS/2 pmods, and a microsd pmod -- unless your VGA pmod doesn't take up two slots (mine does), that uses one more pmod port than the Arty has? Also, just a comment: I have an A7-35T board instead of the A7-100T. What BRAM utilization are you at (right now, my code uses 49 of the 50 BRAMs)?

[ams]

No worries about the delays. Since PS/2 Pmod is just six pin, a split cable and two of them on the same header (JB in my case). I also have an Pmod shield that attaches to the ChipKit / Arduino header in case that doesn't work out for whatever reason. And I'll probobly hook up a seven segment display or some other debugging means, the LEDs aren't working out for me.

I have not yet updated tumbleweed, I'm working of your changes currently and will update tumbleweed when I have something usable / shareable. My plan -- I hope -- is to get this working before you do, and then we just use one repository. :-)

The files missing are at least the MIG .prj files which are needed to regenerate the core (since I'm on a later version of Vivado).

Regarding BRAM 49 out of 135. Regarding PROM, it goes into IRAM / I-MEM if I recall the minute details of how the MCR is loaded.

[nusgart]

No worries about the delays. Since PS/2 Pmod is just six pin, a split cable and two of them on the same header (JB in my case). I also have an Pmod shield that attaches to the ChipKit / Arduino header in case that doesn't work out for whatever reason. And I'll probobly hook up a seven segment display or some other debugging means, the LEDs aren't working out for me.

I see. I did pretty much the same thing — I use one PS/2 pmod and a splitter cable.

I have not yet updated tumbleweed, I'm working of your changes currently and will update tumbleweed when I have something usable / shareable. My plan -- I hope -- is to get this working before you do, and then we just use one repository. :-) The files missing are at least the MIG .prj files which are needed to regenerate the core (since I'm on a later version of Vivado).

If you have something that boots could you at least send a tarball of your current code — I'd like to compare and see what I messed up.

Regarding BRAM 49 out of 135. Regarding PROM, it goes into IRAM / I-MEM if I recall the minute details of how the MCR is loaded.

Ok, I thought that the disk controller had to DMA into main memory because IRAM doesn't seem to be attached to the xbus? I guess I need to remember how to use CC (I only have the C version right now) to test if the memory controller works in hardware (it does in the testbench) — I thought that I had checked, but might as well make sure.

Also, random side-note: I've thought about implementing an sdram cache (would go right in front of or inside the memory controller to avoid cache coherency problems) for larger FPGAs, like the DE10-nano (the MiSTer), which has ~114 KWords worth of unused block ram. Obviously, I would implement this after those boards are tested working, if it's even worth doing (modern DDR-sdram is probably faster than the CADR).

Edit: just to clarify, I've currently put the MiSTer port on-hold until the Arty A7 port works.

[ams]

IRAM is indeed not mapped to main memory on the xbus, rather IRAM[0-1K] is the PROM while PROMDISABLE is false. By writing a value to the right Unibus address (after loading the microcode into IRAM), this will toggle it to true, and then you are execution the loaded microcode (starting at I-MEM 6).

I've put up whatever I have in my directory here: https://tumbleweed.nu/tmp/uhdl-2021-04-09.tar.gz -- it is very much unfiltered. And I really mean unfiltered, I've only had time to get it synthesized, generate a bitstream, and load it on the board. The board LEDs flicker, so something is going on but that is all I know. The file 1620590299.gcov contains a log of a run I made just for this.

Edit: So unfiltered, that I see that I messed up the constraints on the VGA output, which I've amended to:

## Pmod Header JC   VGA PMOD
#set_property -dict { PACKAGE_PIN U12   IOSTANDARD LVCMOS33 } [get_ports { jc[0] }]; #IO_L20P_T3_A08_D24_14 Sch=jc_p[1]     # VGA_R[0]
#set_property -dict { PACKAGE_PIN V12   IOSTANDARD LVCMOS33 } [get_ports { jc[1] }]; #IO_L20N_T3_A07_D23_14 Sch=jc_n[1]     # VGA_R[1]
#set_property -dict { PACKAGE_PIN V10   IOSTANDARD LVCMOS33 } [get_ports { jc[2] }]; #IO_L21P_T3_DQS_14 Sch=jc_p[2]     # VGA_R[2]
set_property -dict { PACKAGE_PIN V11   IOSTANDARD LVCMOS33 } [get_ports { vga_r }]; #IO_L21N_T3_DQS_A06_D22_14 Sch=jc_n[2]  # VGA_R[3]
#set_property -dict { PACKAGE_PIN U14   IOSTANDARD LVCMOS33 } [get_ports { jc[4] }]; #IO_L22P_T3_A05_D21_14 Sch=jc_p[3]     # VGA_B[0]
#set_property -dict { PACKAGE_PIN V14   IOSTANDARD LVCMOS33 } [get_ports { jc[5] }]; #IO_L22N_T3_A04_D20_14 Sch=jc_n[3]     # VGA_B[1]
#set_property -dict { PACKAGE_PIN T13   IOSTANDARD LVCMOS33 } [get_ports { jc[6] }]; #IO_L23P_T3_A03_D19_14 Sch=jc_p[4]     # VGA_B[2]
set_property -dict { PACKAGE_PIN U13   IOSTANDARD LVCMOS33 } [get_ports { vga_b }]; #IO_L23N_T3_A02_D18_14 Sch=jc_n[4]      # VGA_B[3]

## Pmod Header JD   VGA PMOD
#set_property -dict { PACKAGE_PIN D4    IOSTANDARD LVCMOS33 } [get_ports { jd[0] }]; #IO_L11N_T1_SRCC_35 Sch=jd[1]      # VGA_G[0]
#set_property -dict { PACKAGE_PIN D3    IOSTANDARD LVCMOS33 } [get_ports { jd[1] }]; #IO_L12N_T1_MRCC_35 Sch=jd[2]      # VGA_G[1]
#set_property -dict { PACKAGE_PIN F4    IOSTANDARD LVCMOS33 } [get_ports { jd[2] }]; #IO_L13P_T2_MRCC_35 Sch=jd[3]      # VGA_G[2]
set_property -dict { PACKAGE_PIN F3    IOSTANDARD LVCMOS33 } [get_ports { vga_g }]; #IO_L13N_T2_MRCC_35 Sch=jd[4]       # VGA_G[3]
set_property -dict { PACKAGE_PIN E2    IOSTANDARD LVCMOS33 } [get_ports { vga_hsync }]; #IO_L14P_T2_SRCC_35 Sch=jd[7]       # VGA_HS_O
set_property -dict { PACKAGE_PIN D2    IOSTANDARD LVCMOS33 } [get_ports { vga_vsync }]; #IO_L14N_T2_SRCC_35 Sch=jd[8]       # VGA_VS_O
#set_property -dict { PACKAGE_PIN H2    IOSTANDARD LVCMOS33 } [get_ports { jd[6] }]; #IO_L15P_T2_DQS_35 Sch=jd[9]
#set_property -dict { PACKAGE_PIN G2    IOSTANDARD LVCMOS33 } [get_ports { jd[7] }]; #IO_L15N_T2_DQS_35 Sch=jd[10]

[nusgart]

IRAM is indeed not mapped to main memory on the xbus, rather IRAM[0-1K] is the PROM while PROMDISABLE is false. By writing a value to the right Unibus address (after loading the microcode into IRAM), this will toggle it to true, and then you are execution the loaded microcode (starting at I-MEM 6).

Ok, that's what I thought. To make my thought process more clear, when I originally got the microcode to load, I took that as a sign that my ram controller was working because I thought that the prom loads the microcode into memory and then copies it into IRAM, which relies on the ram controller to work. It's good to confirm that is how it works.

I've put up whatever I have in my directory here: https://tumbleweed.nu/tmp/uhdl-2021-04-09.tar.gz -- it is very much unfiltered. And I really mean unfiltered, I've only had time to get it synthesized, generate a bitstream, and load it on the board. The board LEDs flicker, so something is going on but that is all I know. The file 1620590299.gcov contains a log of a run I made just for this.

One request: would it be possible for you to minimize the formatting and naming changes to the modules I wrote (i.e. led_controller.sv and memory_controller_A7.v) to make it easier to diff them? If the formatting I have is a problem, then I can adopt yours, but I think the name ram_controller_2_arty_a7 is really ugly (which is why I changed the name to memory_controller_A7) — it might be better just to get rid of the original ram_controller_arty_a7 (I don't think it ever worked). It might be best to call the new ram controller ram_controller_x7 because it should work for any Xilinx 7-series FGPA. If there are any other ports to Xilinx 7-series boards, they should be able to use that module so long as the DDR IP they generate has the same name.

Also, I've been meaning to bring this up for some time: we should consider deciding the license of this project. I don't particularly care what open-source license we use so long as it is open source. Thus, within reason, I will go along with whatever license you want, but we should probably choose sooner rather than later.

Edit: So unfiltered, that I see that I messed up the constraints on the VGA output, which I've amended to:

## Pmod Header JC VGA PMOD
#set_property -dict { PACKAGE_PIN U12   IOSTANDARD LVCMOS33 } [get_ports { jc[0] }]; #IO_L20P_T3_A08_D24_14 Sch=jc_p[1]       # VGA_R[0]
#set_property -dict { PACKAGE_PIN V12   IOSTANDARD LVCMOS33 } [get_ports { jc[1] }]; #IO_L20N_T3_A07_D23_14 Sch=jc_n[1]       # VGA_R[1]
#set_property -dict { PACKAGE_PIN V10   IOSTANDARD LVCMOS33 } [get_ports { jc[2] }]; #IO_L21P_T3_DQS_14 Sch=jc_p[2]       # VGA_R[2]
set_property -dict { PACKAGE_PIN V11   IOSTANDARD LVCMOS33 } [get_ports { vga_r }]; #IO_L21N_T3_DQS_A06_D22_14 Sch=jc_n[2]    # VGA_R[3]
#set_property -dict { PACKAGE_PIN U14   IOSTANDARD LVCMOS33 } [get_ports { jc[4] }]; #IO_L22P_T3_A05_D21_14 Sch=jc_p[3]       # VGA_B[0]
#set_property -dict { PACKAGE_PIN V14   IOSTANDARD LVCMOS33 } [get_ports { jc[5] }]; #IO_L22N_T3_A04_D20_14 Sch=jc_n[3]       # VGA_B[1]
#set_property -dict { PACKAGE_PIN T13   IOSTANDARD LVCMOS33 } [get_ports { jc[6] }]; #IO_L23P_T3_A03_D19_14 Sch=jc_p[4]       # VGA_B[2]
set_property -dict { PACKAGE_PIN U13   IOSTANDARD LVCMOS33 } [get_ports { vga_b }]; #IO_L23N_T3_A02_D18_14 Sch=jc_n[4]        # VGA_B[3]

## Pmod Header JD VGA PMOD
#set_property -dict { PACKAGE_PIN D4    IOSTANDARD LVCMOS33 } [get_ports { jd[0] }]; #IO_L11N_T1_SRCC_35 Sch=jd[1]        # VGA_G[0]
#set_property -dict { PACKAGE_PIN D3    IOSTANDARD LVCMOS33 } [get_ports { jd[1] }]; #IO_L12N_T1_MRCC_35 Sch=jd[2]        # VGA_G[1]
#set_property -dict { PACKAGE_PIN F4    IOSTANDARD LVCMOS33 } [get_ports { jd[2] }]; #IO_L13P_T2_MRCC_35 Sch=jd[3]        # VGA_G[2]
set_property -dict { PACKAGE_PIN F3    IOSTANDARD LVCMOS33 } [get_ports { vga_g }]; #IO_L13N_T2_MRCC_35 Sch=jd[4]     # VGA_G[3]
set_property -dict { PACKAGE_PIN E2    IOSTANDARD LVCMOS33 } [get_ports { vga_hsync }]; #IO_L14P_T2_SRCC_35 Sch=jd[7]     # VGA_HS_O
set_property -dict { PACKAGE_PIN D2    IOSTANDARD LVCMOS33 } [get_ports { vga_vsync }]; #IO_L14N_T2_SRCC_35 Sch=jd[8]     # VGA_VS_O
#set_property -dict { PACKAGE_PIN H2    IOSTANDARD LVCMOS33 } [get_ports { jd[6] }]; #IO_L15P_T2_DQS_35 Sch=jd[9]
#set_property -dict { PACKAGE_PIN G2    IOSTANDARD LVCMOS33 } [get_ports { jd[7] }]; #IO_L15N_T2_DQS_35 Sch=jd[10]

I see — when you said you had it booting I took that to mean that it had booted to lisp, so I was interested in seeing what was different in your code.

[ams]

Yeah, when I said booted I meant only meant something works, not that anything boots into Lisp and is functioning. The renaming was for my own sake, sorry for that. Right now this should be very much what you have, but with a different MIG core and some different constraints.

I have no special attachment to any specific naming, and only did it so I could easily diff it on my side to understand what you have done; what you got was a whatever is in my working directory. When/If I have something remotely useful I'll restore it to whatever you prefer. Generally "make indent" should do most of the trickery if you use hdlmake.mk, but I'll take it on me to no mess it up for you.

License wise, tumbleweed has it covered (with an OK from Brad) already:

Copyright 2005-2016 Brad Parker

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the
   distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

[ams]

Not sure it matters, I tried generating a bitstream for my Pipistrello (reverting some of the Pipistrello specific files), that doesn't boot.

[ams]

On a slightly different topic, do you have any ideas for adding Ethernet? The side on the Lisp Machine is simple, address to write data too, address to read data from, a special address to send data in said buffer, and a interrupt that is triggered when receiving a packet. I was thinking raw Etherne frames, with the type set to Chaos, and then whatever data following (I have code for handling the Unix side of this).

[ams]

If you're fine with it, I'll post a PR against this repository to sync Tumbleweed and your changes, I've fixed the 2001 issues, and the various comments you had. Keeping the files you started on with minimal changes, the modules/files are renamed to uhdl_arty_a7.v, etc, and the "old" ram controller is gone in favor of the code in memory_controller_A7.v (if that should be called _x7 or something I'll leave for another day). Any modifications you did on your side I'll leave intact.

[nusgart]

If you're fine with it, I'll post a PR against this repository to sync Tumbleweed and your changes, I've fixed the 2001 issues, and the various comments you had. Keeping the files you started on with minimal changes, the modules/files are renamed to uhdl_arty_a7.v, etc, and the "old" ram controller is gone in favor of the code in memory_controller_A7.v (if that should be called _x7 or something I'll leave for another day). Any modifications you did on your side I'll leave intact.

That would be great. I was actually in the process of replying to your previous comments (so expect to see a few further comments covering the things you mentioned). We can work out naming, a common vcs, and stuff later down the line. Thanks

[nusgart]

License wise, tumbleweed has it covered (with an OK from Brad) already:

Great, that's good to know.

Not sure it matters, I tried generating a bitstream for my Pipistrello (reverting some of the Pipistrello specific files), that doesn't boot.

That helps enormously, actually. Can you try bisecting to see what change broke things (I would, but I don't have a Pipistrello)?

[nusgart]

On a slightly different topic, do you have any ideas for adding Ethernet? The side on the Lisp Machine is simple, address to write data too, address to read data from, a special address to send data in said buffer, and a interrupt that is triggered when receiving a packet. I was thinking raw Etherne frames, with the type set to Chaos, and then whatever data following (I have code for handling the Unix side of this).

This sounds similar to the ideas I had, assuming that it would provide the same interface as the original xbus adapter (or whatever the system 78/98/99 chaos drivers support). It would be more a lot more convenient for end users if we tunneled chaos over IP, or even over UDP/TCP. There is the chaos-bridge, but I'd imagine that it needs a separate ethernet adapter so it can take exclusive access (if it can share the ethernet adapter with the kernel's IP stack, then ignore these last two sentences).

[ams]

Chaosnet is on the Unibus, tunneling is definitely an option. But I suspect it would require much more work. My idea was rather to get the kernel driver that hooked into the network stack, and add a layer on there. This is what was done back in the day -- but first I guess we need to have something booting.

Ehternet (or any kind of network) is a very high priority for me since that would mean we can bootstrap the machine from the FPGA.

[nusgart]

Tunneling would definitely require a lot more work, except on the MiSTer, where we could just take advantage of the HPS and use Linux's IP stack. I was thinking of that as a possibility later down the line, not immediately. I agree that ethernet/networking should be the highest priority after getting the thing to boot in the first place. If a kernel driver could help avoid needing to have a dedicated ethernet interface, that would be convenient.

Also, I'm not sure if you've already noticed this, but the code on tumbleweed only has the renamed spartan 6 ram controller (ram_controller_arty_a7.v)

[ams]

Yeah, the changes are currently on a branch. Will get back with that PR in a day or two.

[nusgart]

Great, take your time, there might be a lot of merge conflicts from various things depending on how you get the changes from fossil to git.

[ams]

By the way, would it be possible if you could commit the missing MIG files?

 [Project 1-311] Could not find the file '/home/ams/uhdl-nusgart/cadr.srcs/sources_1/ip/dram_memif/mig_a.prj', nor could it be found using path '/home/nnusgart/Xilinx/cadr/cadr.srcs/sources_1/ip/dram_memif/mig_a.prj'.
 [Project 1-311] Could not find the file '/home/ams/uhdl-nusgart/cadr.srcs/sources_1/ip/dram_memif/mig_b.prj', nor could it be found using path '/home/nnusgart/Xilinx/cadr/cadr.srcs/sources_1/ip/dram_memif/mig_b.prj'.
 [Project 1-311] Could not find the file '/home/ams/uhdl-nusgart/xil_tcl/bit_pre.tcl', nor could it be found using path '/home/nnusgart/Xilinx/cadr/xil_tcl/bit_pre.tcl'.

[nusgart]

I've added and pushed them.

[ams]

Seems I missed two files:

 [Project 1-311] Could not find the file '/home/ams/uhdl-nusgart/cadr.srcs/sources_1/ip/ddr_memif/mig_b.prj', nor could it be found using path '/home/nnusgart/Xilinx/cadr/cadr.srcs/sources_1/ip/ddr_memif/mig_b.prj'.
 [Project 1-311] Could not find the file '/home/ams/uhdl-nusgart/cadr.srcs/sources_1/ip/mig_32bit/mig_32bit/user_design/mig.prj', nor could it be found using path '/home/nnusgart/Xilinx/cadr/cadr.srcs/sources_1/ip/mig_32bit/mig_32bit/user_design/mig.prj'.

There is a ISE report, and obviously .version missing too but those aren't that important.

[ams]

Here you go. https://github.com/nusgart/uhdl/pull/5

I've been careful to keep your changes as they are.

[ams]

The SDHC controller -- is that verified to work?

Edit: Nope, not in its current form at least (this is on the Pipistrello, where I only changed the block_dev_mmc to sd_block_dev, and adjusted the clock from a known working setup).

Edit 2: This is with a low density card 2GiB SDSC card that I normally use, and a 16G card which should be a SDHC.

Edit 3: Seems to be stuck in a write; after doing a read or two.

Edit 4: Switching back to block_dev_mmc with your changes, that works with a SDSC card, but not a SDHC card. That gets stuck in a read, but gets far enough into the prom to display the run light.

[ams]

That helps enormously, actually. Can you try bisecting to see what change broke things (I would, but I don't have a Pipistrello)?

Was me from the looks, I had the wrong clock.

[ams]

So yeah, the SDHC mode is totally bust; will see what I can do with it tomorrow.

[ams]

Are there any good SDHC models out there that can be used for simulation? Seems I can't get the initialization sequence right for whatever card I have. Will need to setup ILA and some other stuff.

EDIT: The right thing here would be to rewrite block_dev_mmc.v so that instead of using HDL to initialize, and communicate with the SD card, one would write microcode instead and just talk SPI commands from a slightly friendlier place (i.e. replacing %DISK-WRITE/READ and such with SPI versions).

[nusgart]

I apologize for not responding sooner, I was very busy during the past week.

The pull request

Thanks for submitting the pull request, I've merged it. I've noticed that the source code is starting to become disorganized (too much stuff in the main directory), so I'm receptive to ideas on that. Otherwise, I'll look at organizing it myself.

SD card stuff

The SDHC controller -- is that verified to work?

Unfortunately, both attempts at making SDHC controllers (both modifying block_dev_mmc and using the external sd_block_device) are verified to not work, as you seem to have found out. There must be SDHC models out there, but I had trouble finding any the last time I looked. I think one problem with my modifications to block_dev_mmc is that some SDHC cards violate the standard and don't allow CRCs to be disabled.

I'm not sure that moving the SD card logic to microcode is a good idea. Although it would be more flexible, it would probably also kill our transfer speeds and it would definitely make UHDL incompatible with unmodified system software. We could use an intermediate approach where we add a soft-core that interfaces with the SD card and presents an unmodified interface on the xbus side.

Boot problems

Was me from the looks, I had the wrong clock.

It's good that you have it working again. Would this affect the arty a7 code? Edit: also, what was the exact change?

[ams]

I apologize for not responding sooner, I was very busy during the past week.

The pull request

Thanks for submitting the pull request, I've merged it. I've noticed that the source code is starting to become disorganized (too much stuff in the main directory), so I'm receptive to ideas on that. Otherwise, I'll look at organizing it myself.

Thank you. I tried leaving most of your files where they where, if you look in tumbleweed the top-level is slightly less cluttered since they are not included there. But tumbleweed doesn't contain some of your changes, mostly since I wanted to keep that in a known working state.

SD card stuff

The SDHC controller -- is that verified to work?

Unfortunately, both attempts at making SDHC controllers (both modifying block_dev_mmc and using the external sd_block_device) are verified to not work, as you seem to have found out. There must be SDHC models out there, but I had trouble finding any the last time I looked. I think one problem with my modifications to block_dev_mmc is that some SDHC cards violate the standard and don't allow CRCs to be disabled.

Ok, that is good to know. I've read the same, and others which say that CRC should be disabled when you enter SPI mode. The SD specification is also confusing as to what I'm seeing my cards (2G, 16G, 32G -- I think all Sandisk) respond to and do.

I'm not sure that moving the SD card logic to microcode is a good idea. Although it would be more flexible, it would probably also kill our transfer speeds and it would definitely make UHDL incompatible with unmodified system software. We could use an intermediate approach where we add a soft-core that interfaces with the SD card and presents an unmodified interface on the xbus side.

Soft-core would be interesting, specially since that could be used for Ethernet, or even providing the hoist environment for bootstrapping the system -- if there is enough space.

Boot problems

Was me from the looks, I had the wrong clock.

It's good that you have it working again. Would this affect the arty a7 code? Edit: also, what was the exact change?

I'd need to check -- I remember that I had to revert parts MMC parts and some other things, I never committed those changes since the changes in the vga_display.v weren't playing with my monitor. I only checked that the system booted past the PROM and read things correctly from disk and inspected some known places on the XBUS.

[nusgart]

Thank you. I tried leaving most of your files where they where, if you look in tumbleweed the top-level is slightly less cluttered since they are not included there. But tumbleweed doesn't contain some of your changes, mostly since I wanted to keep that in a known working state.

Ok. Right now it's not really that high of a priority but we should look at organization some time.

Ok, that is good to know. I've read the same, and others which say that CRC should be disabled when you enter SPI mode. The SD specification is also confusing as to what I'm seeing my cards (2G, 16G, 32G -- I think all Sandisk) respond to and do.

The SD spec says that "The SPI interface is initialized in the CRC OFF mode in default", which clearly indicates that once CMD00 is processed, the CRC bits should be ignored for all commands (except for CMD08) unless the host issues a CMD59 that enables "CRC ON" mode. Real SDHC cards don't always get this right -- some always check the CRC. My best guess is that they weren't properly tested in SPI mode -- most devices tend to use the more-efficient SD mode (I'm not sure if the publicly-available spec has all the details on it).

Soft-core would be interesting, specially since that could be used for Ethernet, or even providing the hoist environment for bootstrapping the system -- if there is enough space.

I agree, there are a lot of things a support coprocessor/SoC/... (we need to decide on a better name for that) could provide for us, and a lot of later Lisp machines had something along those lines. That's one of the things that makes the MiSTer framework nice. Just off of the top of my head, with some work, a support CPU could provide:

• network interface (ethernet, wifi, bluetooth, ...)
• block device adapter (SD, USB, ...)
• optional system host (optional to allow for more advanced setups)
• extra debugging capabilities (in addition to the spy: if it's connected to the bus, it could provide memory viewers, device testers, ......)

I'd need to check -- I remember that I had to revert parts MMC parts and some other things, I never committed those changes since the changes in the vga_display.v weren't playing with my monitor. I only checked that the system booted past the PROM and read things correctly from disk and inspected some known places on the XBUS.

It would be nice to know, especially since I've never been able to get the A7 code to boot to lisp, and I haven't been able to figure out exactly why.

[ams]

I'd need to check -- I remember that I had to revert parts MMC parts and some other things, I never committed those changes since the changes in the vga_display.v weren't playing with my monitor. I only checked that the system booted past the PROM and read things correctly from disk and inspected some known places on the XBUS.

It would be nice to know, especially since I've never been able to get the A7 code to boot to lisp, and I haven't been able to figure out exactly why.

I wonder if we might be miscommunication here. I never got things to work on the Arty. Not having a SD card working is a show stopper for that -- I haven't tried doing it with the working MMC controller (or should that be known working MMC card?) though. That might be easy attempt though. But I only have one 2G SD card, and was a bit excited to get SDHC support working since it makes things a bit easier.

The way the Lisp Machine boots is to read the microcode from the SD card, it then switches to PROMDISABLE. That will then start loading the LOD partition on the disk. When that is done, it will call LISP-TOP-LEVEL (which is the first Lisp function to be called).

What I did was take your changes, and got them to a bit stream for the Pipistrello, but that involved reverting some parts which did not work for my setup (mainly monitor).