Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    I would probably have to upgrade my laptop memory to 32GB to build the current doomchip.
    Rob S
    @rob-ng15
    Hi there, I've just tried editing the build scripts. It was me who requested the sed, looks like it can be removed. I've also built without the scratchpad part of the command to.
    Goran Mahovlic
    @goran-mahovlic
    @lawrie I think that on linux you can use tmp folder as virtual memory - it will be slower but when main memory fills up it will just use drive space
    Lawrie Griffiths
    @lawrie
    The oled version of doom is now on to nextpnr, so that might work.
    Lawrie Griffiths
    @lawrie
    I am playing doom on the Oled screen now :-)
    The 90 degree rotation makes the buttons a bit hard to use.
    Lawrie Griffiths
    @lawrie
    @goran-mahovlic I think I must have swap space to configured, and the virtual memory usage did go above the 12GB of physical memory. The HDMI version seems to want more than 12GB of physical memory. And it is already very slow. We could do with a multi-threaded Yosys.
    I don't seem to have a gun to shoot the zombies with.
    sylefeb
    @sylefeb
    @lawrie It's great it works on your side now! I pushed on 'wip' an updated README (also explaining why there is no gun ; the latest version is being developed in a different repo, but not stable yet). Fixed the 90 degrees rotation. Also split the compilation script so dependencies are in a different script and updated instructions. https://github.com/sylefeb/Silice/tree/wip/projects/doomchip
    Lawrie Griffiths
    @lawrie
    @sylefeb Thanks for that. It is only the Oled version that works for me - I do not have enough RAM to build the HDMI version. I wasn't really expecting more than the video to work, so I was surprised that there was some interaction. Have you any plans for audio in doom?
    Silice looks a really interesting language with some very nice features, but I do not quite understand its semantics yet, so will need to experiment with it.
    I did look at other implementations of Doom, including the one by @tnt (Sylvain Munaut) on the icebreaker board - see https://www.youtube.com/watch?v=3ZBAZ5QoCAk
    Lawrie Griffiths
    @lawrie
    That could be ported to the Ulx3s. It users VexRiscv and a cache and framebuffer implementation using the up5k spram. It needs a psram chip piggy-backed on the spi flash chip, but on the Ulx3s could probably use BRAM and SDRAM.
    I also believe Doom could be implemented on SaxonSoc Linux using the Linux frame buffer. I am not sure if @Dolu1990 has the working on other boards.
    Dolu1990
    @Dolu1990

    I also believe Doom could be implemented on SaxonSoc Linux using the Linux frame buffer.

    Right, i have seen some tweet about it running on ArtyA7 SaxonSoc

    sylefeb
    @sylefeb

    Have you any plans for audio in doom?

    Yes :) I experimented a bit with that already (see audio_sdcard_streamer this is to stream the Doom music). But as the game logic grew it became clear I'd rather have a RiscV core on the side for scripting it (monsters movement, triggers,sounds, etc.) ... so now I am redesigning, trying to keep the DooM-chip spirit of having its core in full hardware.
    @tnt's port is fantastic -- would work well with SDRAM + BRAM cache on the ULX3S. What I am trying with the DooM-chip is a bit different, as it is more for the challenge of the hardware take on it, rather than a source port (I like the concept of a hard-wired Doom, for some reason ;) ).

    sylefeb
    @sylefeb

    but I do not quite understand its semantics yet

    Started to work on some tutorials+guidelines - also there is an open issue for syntax/semantics help: sylefeb/Silice#108
    Feel free to post questions there!

    Lawrie Griffiths
    @lawrie
    So, here is an example of my lack of understanding. I am trying to convert a simple Verilog example to make an LED glow on the Ulx3s.
    Here is the verilog
    
    module LEDglow(clk, LED); 
    input clk; 
    output LED; 
    
    reg [27:0] cnt; 
    always @(posedge clk) cnt<=cnt+1; 
    
    wire [3:0] PWM_input = cnt[27] ? cnt[26:23] : ~cnt[26:23]; 
    reg [4:0] PWM; 
    always @(posedge clk) PWM <= PWM[3:0]+PWM_input; 
    
    assign LED = PWM[4]; 
    endmodule
    Here is my attempt in Silice:
    algorithm main(output uint$NUM_LEDS$ leds) {
      uint28 cnt = 0;
      uint5 pwm = 0;
      uint4 pwm_input := cnt[27,1] ? cnt[26,4] : ~cnt[26,4];
    
      leds[1,7] := 0;
      leds[0,1] := ~pwm[4,1];
    
      while (1) {
        cnt = cnt + 1;
        pwm = pwm[3,4] + pwm_input;
      }
    }
    That does not work as it does not use the clock.
    What am I doing wrong?
    Lawrie Griffiths
    @lawrie
    (That example originally came from fpga4fun - https://www.fpga4fun.com/Opto0.html).
    Lawrie Griffiths
    @lawrie
    This is my attempt with a configurable number of bits for the counter (also does not work):
    $$bits = 24
    
    algorithm main(output uint$NUM_LEDS$ leds) {
      uint$bits$ cnt = 0;
      uint5 pwm = 0;
      uint4 pwm_input := cnt[$bits-1$,1] ? cnt[$bits-2$,4] : ~cnt[$bits-2$,4];
    
      leds[1,7] := 0;
      leds[0,1] := ~pwm[4,1];
    
      while (1) {
        cnt = cnt + 1;
        pwm = pwm[3,4] + pwm_input;
      }
    }
    sylefeb
    @sylefeb
    @lawrie Made a quick test, it seems the issue is that the ranges you specified are out of bounds, e.g. cnt[26,4] is a four bit width uint extracted from bit 26 to 29 (while cnt has only 28 bits). Silice linter is being revised to incorporate this check, but another way to spot it is to do make verilator (same for pwm[3,4] => pwm being five bits this goes out of bounds)
    Lawrie Griffiths
    @lawrie
    Ah, I see, I misunderstood the numbering of the bits in swizzling. I thought it was more like Verilog.
    This version works:
    $$bits = 26
    
    algorithm main(output uint$NUM_LEDS$ leds) {
      uint$bits$ cnt = 0;
      uint5 pwm = 0;
      uint4 pwm_input := cnt[$bits-1$,1] ? cnt[$bits-5$,4] : ~cnt[$bits-5$,4];
    
      leds[1,7] := 0;
      leds[0,1] := pwm[4,1];
    
      while (1) {
        cnt = cnt + 1;
        pwm = pwm[0,4] + pwm_input;
      }
    }
    Lawrie Griffiths
    @lawrie
    And this version makes all the leds glow:
    $$bits = 26
    
    algorithm main(output uint$NUM_LEDS$ leds) {
      uint$bits$ cnt = 0;
      uint5 pwm = 0;
      uint4 pwm_input := cnt[$bits-1$,1] ? cnt[$bits-5$,4] : ~cnt[$bits-5$,4];
    
      $$for i = 0, NUM_LEDS-1 do
        leds[$i$,1] := pwm[4,1];
      $$end
    
      while (1) {
        cnt = cnt + 1;
        pwm = pwm[0,4] + pwm_input;
      }
    }
    Lawrie Griffiths
    @lawrie
    I have started a repository of my Silice examples, and here is a PS/2 keyboard test that appears to read scan codes from a PS/2 keyboard using a Digilent PS/2 PMod. I know @rob-ng15 was having problems with PS/2 keyboards.
    @sylefeb To use a PS/2 keyboard on the US2 connector, we would need a new ifdef, say US2_PS2 in your top-level Verilog module for the Ulx3s, which declares the ports for the US2 connector and sets the pull-up resistors for PS/2.
    Lawrie Griffiths
    @lawrie
    PS/2 keyboard are useful, particularly for retro computer implementations on the Ulx3s, and they are most conveniently used by plugging in a USB keyboard that supports PS/2, using the US2 connector.
    USB keyboards can also be supported but it is a lot more code and not that reliable.
    sylefeb
    @sylefeb
    @lawrie just tried the led glow, great example! Nice use of the pre-processor. You could also write leds := {$NUM_LEDS${pwm[4,1]}}; (akin to Verilog replication)
    PS/2 sounds great! will add the define.
    sylefeb
    @sylefeb
    I see in the lpf that the US2 connector has six pins, two differential inputs (usb_fpga_dX) and four inouts (usb_fpga_bd_dX/usb_fpga_pu_dX). How should these be exposed for the PS/2 keyboard? (in particular, do we keep the differential pair as a true differential LVCMOS33D?)
    Rob S
    @rob-ng15
    Thanks @lawrie , that looks incredibly helpful. I still need to get another PS2 keyboard to try it with.
    Lawrie Griffiths
    @lawrie
    @sylefeb Here is an example of a PS/2 keyboard in Verilog - https://github.com/lawrie/ulx3s_z80_template/blob/main/src/top.v#L187-L202
    It uses usb_fpga_bd_dp for the clock and usb_fpga_bd_dn for the data, and both the pullups are set high.
    Lawrie Griffiths
    @lawrie
    @sylefeb I remain very confused about the semantics of Silice. I imagined that continuous assignment with the := operator were combinatorial. But in section 4.7 of the manual, you say These assignments are performed immediately after each rising clock and are order dependent., which implies they are synchronous. Which is it, or can they be either?
    You also say that the always block is combinatorial, but the examples seem to contradict that, for example increasing counters in the uart example https://github.com/sylefeb/Silice/blob/master/projects/common/uart.ice#L66
    Also, in that uart example, I am confused by the setting of uart_tx after the always block - https://github.com/sylefeb/Silice/blob/master/projects/common/uart.ice#L79
    What relationship does that have to the assignments of uart_tx within the block?
    Lawrie Griffiths
    @lawrie
    (Incidentally when I tried your uart echo example on the Ulx3s, it appeared to lose characters. Sending "Hello" echoed "Hlo").
    So, if always can contain synchronous logic, what is the difference between while (1) {...} and always [ ...]?