Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    It's speed of VCC fall time and MCP datasheet is in Note1 not "100%" shure how fast can it fall for reliable switchover to battery so I keep refering to PCF datasheet which "knows"
    emard
    @emard
    I can verify that your divider 27 and above ROM patch make cortex work at 115200. I promise I won't type faster than 1000 cps
    If I'm asked, this patch can go to mainstream :)
    Kristin Davidson
    @aphistic
    @emard thanks for the recommendation on the female headers for the SD1331 display! I wouldn't have thought of that but it makes so much sense. :)
    Kristin Davidson
    @aphistic
    @lawrie thanks for the insights on risc-v on ulx3s. :) i was thinking of following the linux-on-litex-vexriscv because i want to work on a hobby OS for risc-v in rust and thought it would be a good place to start because it comes with things like an MMU and other hardware. I don't mind learning new things (on the contrary!), though, so if it's better for me to start with something less involved and build something simpler to start with i could do that. for the usb to jtag programmer, do you have one you'd recommend? i've done some preliminary searching in the past but so far i've only gotten an stlink-v3mini and jlink edu mini, not a jtag device. i don't mind paying more than normal for a hobbyist for one but it is still a hobby, so i'm looking for something that's not too expensive. i think i'm jumping in the deep end here (my experience is software dev with a focus/interest in systems) so i'm still trying to learn what all a jtag, uart and the like do.
    Kristin Davidson
    @aphistic
    oh, and for the headers being soldered on the ulx3s I was trying to figure out the best way to do it. Should I have two rows on each side pointing "up" (fpga side), "down" (opposite fpa side) or one row on each side going both "up" and "down" so it can be used with either a bread board or some male-female jump wires... or even a row of female headers to use male-male jump wires?
    Lawrie Griffiths
    @lawrie
    @aphistic It is VexRiscv (written in SpinalHDL) which supports the MMU. LiteX is a collection of peripherals written in migen that talk to the risc-v cpu via a wishbone bus. Litex used to support a lot more peripherals than were supported by SpinalHDL but SpinalHDL with SaxonSoc is catching up fast.
    There are projects that support Rust using litex on the the Ulx3s board, such as http://pepijndevos.nl/2020/08/04/a-rust-hal-for-your-litex-fpga-soc.html
    There are pure SpinalHDL examples on an ECP5 board such as https://craigjb.com/2020/01/22/ecp5/. (That is not on a Ulx3s but porting is probably not hard).
    Lawrie Griffiths
    @lawrie
    If you are new to FPGAs you need to decide which HDLs to learn such as Verilog, VHDL, SystemVerilog, SpinalHDL, Migen, nMigen, Chisel. Or you may be interested more in the software side and want to build SoCs from a library of existing components.
    I have not tried Rust on an FPGA. I don't currently use Migen or nMigen, and I have delayed using LiteX as it uses the older Migen and I don't really want to learn both python HDLs. I believe it is in the LiteX roadmap to move to nMigen, but that may take a while.
    Lawrie Griffiths
    @lawrie
    I don't often use JTAG with my FPGA projects as there are usually better alternatives. When I did I mainly used the Lychee Tang programmer - https://www.aliexpress.com/i/4000042458146.html?spm=2114.12057483.0.0.38051d79Az7DT9
    But that is not the best supported one.
    emard
    @emard
    @aphistic I would recommend soldering MALE pins pointing DOWN. It is "compatible" with 3D printed plastic box. Standard IDE 40-pin cable can be used to connect and this cable you can either cut or recrimp to fit different modules. For protobard it needs some "inventions" perhaps obtaining male-female 1-row adapters or making flat cable to protoboard adapter by soldering male header to male IC sockets.
    @emard best programmer is to obtain FT2232 or FT4232 breakout board. It doesn't need to be exactly named JTAG programmer, but this FT2232 chip is all that is needed. try to optimize price and find some board with EEPROM onboard so you can program USB ID to make it be "recognized" as something vendor specific. Lattice and xilinx and all tools support natively FT2232 programmers. Im not sure is altera still living in stone age with some usb-8051 chips
    Lawrie Griffiths
    @lawrie
    @aphistic I tend to solder 90 degree female headers to my Ulx3s boards, as they work best with Pmods, but it depends what project you have in mind.
    emard
    @emard
    To have GP/GN not be swapped from "default" design, Either solder 90° FEMALE headers on top side of board (nice for PMODs directly) or straight 0° MALE pins down on bottom side of board. PMODs can also plug to other end of flat cable and pinout will be identical as if 90° was soldered onboard.
    Lawrie Griffiths
    @lawrie
    I have just tried nmigen on the Ulx3s and getting it working was a pain, but I now have a blinky.
    My first mistake was installing the m-labs version which I got when I googled nmigen. That version is out of date and did not support the Ulx3s. So I uninstalled that.
    emard
    @emard
    Wow I know installation is terrible but great. I have tried "Silice" (the one for DOOM engine). The installation is not needed, just one exe file which works everywhere and blinky quickly
    Lawrie Griffiths
    @lawrie
    I am using Ubuntu 20.04, so I need to use pip3 not pip. (You can't get python2 pip on 20.04 easily).
    The installation instructions for nmgen-boards says "Todo", so I installed it like the m_labs version said.
    I changed the blinky example to use ULX3S_85F_Platform and ran that. It complained that tool {} was missing.
    It seemed that it needed OpenFpgaLoader for upload, so I installed that, and then the blinky worked.
    Lawrie Griffiths
    @lawrie
    So this is the nmigen blinky:
    from nmigen import *
    from nmigen_boards.ulx3s import *
    
    
    class Blinky(Elaboratable):
        def elaborate(self, platform):
            led   = platform.request("led", 0)
            timer = Signal(26)
    
            m = Module()
            m.d.sync += timer.eq(timer + 1)
            m.d.comb += led.o.eq(timer[-1])
            return m
    
    
    if __name__ == "__main__":
        platform = ULX3S_85F_Platform()
        platform.build(Blinky(), do_program=True)
    emard
    @emard
    Wow, very pythonic :)
    @pnru_gitlab did you get RTC working? i2c bridge example I have recommended to set RTC time but it works only if compiled with diamond and not compiled with trellis, some bidirectional issues we have. Not initialized RTC will not start ticking.
    Lawrie Griffiths
    @lawrie
    There are some Ulx3s nmigen examples here - https://github.com/GuzTech/ulx3s-nmigen-examples
    emard
    @emard
    Hey they also have OLED examples!
    They also pythonized ecp5pll.py :)
    Lawrie Griffiths
    @lawrie
    The DVI example put a pattern on my screen. I assume the Oled example is for the SSD1331. I need to find that.
    emard
    @emard
    Yes example seems to be for SSD1331. I have generalized the spi_display core to fit for several displays SSD1331/1351/1306 and SST7789
    Lawrie Griffiths
    @lawrie
    I have a pattern on the SSD1331 now.
    Those @GuzTech examples are very recent - just 7 days ago.
    emard
    @emard
    Wonderful work is done there to make programmers work easier. Probably he didnt knew (or I have hidden too much spi_display which replaces ssd1331-only driver). But kudos for porting ecp5pll.py that is difficult stuff to port
    I don't know if that is possible but like to have possibility for nmigenator (like verilator), the interpreter that will only from given nmigen code produce signals, skipping translation to verilog. It can then allow introspection using python to use hi-level language to track down bugs
    Lawrie Griffiths
    @lawrie
    Another interesting project written in nmigen, which now runs on the Ulx3s is Luna - https://github.com/greatscottgadgets/luna
    emard
    @emard
    Yes this project is great! I think LUNA should already have ulx3s board, Goran told me something. For USB sniffing, here's shopping lists in the manual https://github.com/emard/ulx3s/blob/master/doc/MANUAL.md#us2-connector-as-otg-ps2-or-sniffer I have all parts and it works for kbd/mouse
    emard
    @emard
    I see I have to refresh ebay links changed
    Paul Ruiz
    @pnru_gitlab
    @emard did you get RTC working? Uhm.. haven't tried really - sorry. The way I understand the example is that it demonstrates an i2c controller reading a responder. What I need is a module that hides the i2c completely and exposes a retro RTC chip interface, both read and write (a bit like the spi_ide module does). Moving from the example to what I need requires a deep dive into i2c and the RTC chip - I do not want to do that deep dive at this point in time.
    Goran Mahovlic
    @goran-mahovlic
    @MartyMacGyver I have all packets ready, but I need to wait for mouser PO number - I am already waiting for 2 weeks - CrowdSupply promised to get me number until next week - so that is when I will ship all boxes to mouser...
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab If you let me know what interface you want for the RTC, I may look at it, as I have done i2c interfaces on ice40 devices before, and was thinking about doing something similar for the QL.
    emard
    @emard
    @pnru_gitlab in the toplevel it uses the master to read 7 registers but if you want clarity I can move it in a separate module and get you 56 bit vector of BCD coded date/time which changes every second
    BCD is format RTC gives, it doesn't provide count of seconds since epoch, that's a job of CPU to make
    emard
    @emard
    @pnru_gitlab here I have separated mcp7940n.v module that will do reading into 56-bit vector and you can use it as the preliminary version for your unix. I will keep improving mcp module, there are few purity-related details to be fixed. https://github.com/emard/ulx3s-misc/blob/master/examples/rtc/i2c_master/proj/hdl/mcp7940n.v
    Paul Ruiz
    @pnru_gitlab

    @lawrie @emard I don't intend to sound demanding, although probably I do. It is just that with summer behind us I have to focus on the day job as well.

    My plan is to make it similar to Linux on an (retro) PC. The AT used the MC146818 chip and I'm sure that an equivalent is still hiding in the north/south bridges. On Linux you have the hwclock command to copy between the RTC chip and the system clock. See man page here. I will add a /dev/rtc device driver that reads/writes the RTC chip and add a hwclock program. This program can then be put in the /etc/rc boot script.

    The MC146818 is a good model, but I don't like the multiplexed AD bus too much. I like the MM58167 better as a model. All these chips are the same: they provide a bank of byte sized registers with the time, etc. I think the MCP790 is still the same (I'm often surprised how little has changed in 40 years, other than size/speed/bloat increasing by a factor of 1000.)

    Maybe the module interface should be something like:

    module RTC (
      input  wire       clk, // prefer 25 or 125Mhz
    
      // retro CPU interface
      input  wire [5:0] ab,  // 4,5,6, etc. wires all the same to me.
      input  wire [7:0] di,
      output wire [7:0] do,
      input  wire       csn,
      input  wire       wrn,
      input  wire       rdn,
    
      // I2C to RTC chip
      inout wire       scl,
      inout  wire      sda
    );

    How many registers there are, or what data/command is in which register does not really matter to me: that is all easily handed in the /dev/rtc device driver (it will probably read the registers and convert to a string, and vice versa when writing; maybe converting to a time value is even easier).

    I am not sure what the best policy is for syncing between the FPGA and the RTC chip. My first gut feel would be to have a duplicate set of registers in the FPGA and to refresh those autonomously each second (maybe 10x per second). If the duplicate register block had its dirty bit set (i.e. was written to) then the copy would be in the other direction.

    The rc boot script would read /dev/rtc and set the system time from it if it was ahead of system time. If system time is ahead of /dev/rtc it would write the system time to the RTC. To get the ball rolling the user would have to set the right date once. When I get TCP/IP working on the FPGA Cortex it can read out an NTP server and use that as a time base.

    emard
    @emard
    Your retro-pc interface is easiest for me to implement, so OS will then take care of race condition of reading when it changes. For example say you first read 59 minutes and next reading you read incremented hour, so instead of 01:00 you have 01:59, more than hour later :). I don't have to fix in the core, OS will
    emard
    @emard
    is "wire [5:0] ab" the address for RTC's register? there are 32 RTC registers 0x00-0x1F and small general purpose RAM 0x20-0x5F; so [6:0] should be sufficient here
    Paul Ruiz
    @pnru_gitlab
    The MM58167 offers a rollover status bit, but I can live without that. The /dev/rtc device driver can read the registers twice in succession and if the two values are not the same repeat the double read until they are. As the time value on ancient Unix only has 1 second resolution, I don't really need to read the faster registers.