Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/power_management.html here is a lot of ESP32 dynamic frequency control, I think main reason is power saving
    Paul Ruiz
    @pnru_gitlab
    Got the "mini-cortex" model booting ancient Unix. It is about 4 times faster than the SBC (double the clock frequency and a 16-bit bus instead of 8-bit). IDE simulation from the ESP32 works fine.
    emard
    @emard
    @pnru_gitlab wwoooww amazing project! Is the source on git with some download lines for disk image?
    I was playing with line draw hardware accelerator (a simple SPI controlled "GPU") https://github.com/emard/ulx3s-misc/blob/master/examples/lcd_st7789/micropython/st7789_240x240_spi_slave/proj/hdl/draw_line.v and demo is for LCD ST7789 which doesn't have built-.in hardware line like OLED SSD1331 has. Now it has 3330 lps
    Dobrica Pavlinušić
    @dpavlin
    @goran-mahovlic I'm also having problems with ENC28J60 and saxonsoc with ebay module and wires which used to work, so you pmod is probably ok, it's a software problem. I will try to go through all kost builds and find one which works for you
    Dobrica Pavlinušić
    @dpavlin
    @goran-mahovlic https://github.com/dok3r/ulx3s-saxonsoc/releases/tag/v2020.01.24 works for me, you can test ENC28J60 pmod using this image
    emard
    @emard
    when we are at saxonsoc, is there some chance for RTC MCP7940N i2c support, can we demonstrate that saxonsoc can boot with clock set, make hardware shutdown and wake up again from RTC. I have esp32 mictopython example for this https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n
    Paul Ruiz
    @pnru_gitlab
    @emard Yes I will put all that on Gitlab in the next few days. At the moment the code still needs some cleanup and I'm chasing a few issues: I discovered that my CPU microcode for signed divide has a bug and also that I never implemented NMI (which is used for single stepping in the debugger - a bit like the "trap" status bit on a PDP11).
    Goran Mahovlic
    @goran-mahovlic
    @dpavlin tnxI will check, as I did recheck everything and did not find anything wrong wirh PMOD
    Goran Mahovlic
    @goran-mahovlic
    Working.png
    @dpavlin tnx - it is working :)
    Paul Ruiz
    @pnru_gitlab

    I've now cleaned up the source and posted the repo for the Mini Cortex project. It is located here: https://gitlab.com/pnru/cortex
    Let me know if it works on other boards too.

    If there is an emerging standard for how to organize projects on the SD card let me know, and I'll try to conform.

    emard
    @emard
    AMAZING!!! I will check this. Usually something like /sd/cortex/disk/idedisk.img /sd/cortex/bitstream/tms99xx.bit or similar
    Important is that it works :)
    Paul Ruiz
    @pnru_gitlab
    OK, I'm close then: I now put both the bit file and the disk image in /sd/cortex. The python disk routine (spi_ide.py) is in the root directory.
    The python code could probably be a bit more sophisticated: now if uftpd programs the FPGA, the spi_ide code gets a deinitialized SPI driver and barfs.
    emard
    @emard
    I can take a look at python and optimize if necessary. This spi sharing between different applications and pinouts is expected. It could be fixed but sometimes its better to have simple code than some commodity
    emard
    @emard
    HEY, this thing is even FAST and very responsive. IDE emulation is incredibly simple and everything works. WOW! I will see if anything could be done to this pinout sharing with uftpd...
    emard
    @emard
    This stuff also has cc compiler (btw can saxonsoc also get something that compiles)
    What I'd also be "happy" to see if RTC can get supported. If TMS99xx board had some concept of RTC I guess we can make i2c core converter from onboard RTC to the RTC TMS99xx expects
    Kristin Davidson
    @aphistic
    Hi everyone! I'm super new to FPGAs but i bought a ulx3s today because I'm interested in both FPGAs and RISC-V and I've been reading that the ulx3s is a good board to experiment with RISC-V on. I also ordered an ssd1331 display module to put on the board as well. I'm wondering, is there anything else i need besides those two things and a micro usb cable to get started with both FPGAs and RISC-V on the ulx3s? Do I need anything to put between the display module and the FPGA to deal with heat? I've been looking at the linux-on-litex-vexriscv repo as a place to get the bitstream i need for RISC-V but since I'm so new to both I'm not sure what else I'd need. I don't plan on using linux because I want to work on bare-metal RISC-V and the only other bare-metal work I've done is using a stlink-v3mini and an STM32F3DISCOVERY board. Would the JTAG provided by the FTDI on the ulx3s provide the gdb "load" functionality to the RISC-V core like the stlink did for the STM32F3? Sorry for this being so long, I didn't want to split it into a whole bunch of different messages. :)
    Oh, and in addition to the question about heat related to the FPGA and the SSD1331 module, do I need anything else to stabilize the top of the display module or will the soldering on the bottom be enough?
    Martin Falatic
    @MartyMacGyver
    Is there any news on shipping estimates? I ask only because there is a chance my info might change before then depending on how far out that might be.
    Paul Ruiz
    @pnru_gitlab
    @emard Maybe the solution for SPI h/w sharing is to let spi_ide re-initialise the SPI h/w at the start of every request. Hopefully it is a very fast operation.
    emard
    @emard
    @aphistic SSD1331 96x64 is full featured OLED beautiful contrast, but currently best buy is ST7789 1.3" 240x240 LCD less contrast but more pix and less $. Do not solder directly the display. Solder female 7-pin header and plug the display. Mechanical stabilization can be 3D printed https://github.com/emard/ulx3s/tree/master/box it will "work" properly only if whole box is printed. There is no problem with heat normally to FPGA but SSD1331 with wrong software commands can become hot to fry fingers and smoke, it happened to me once, colors faded and I just replaced display. Onboard USB-SERIAL can provide 2nd JTAG channel for openocd debugger of RISCV processor it will work but it will be VERY slow (for debug single step ok, but for transferring Mbps no).
    emard
    @emard
    @pnru_gitlab SPI can be only channel 2 and some "cooperation" between uftpd, ecp5.prog and ide emulation should be done, but as your IDE code looks so clean and short, it's pity to bloat with large code. We must rethink is there some short coded and memory efficient python technology which would alllow it. Supposed ESP32 MPY wont crash internally, SPI could be re-initialized any number of times without de-initialization. By reinit you can change everything including pinout and frequency
    emard
    @emard
    @MartyMacGyver what I know is that 824 boards for CS campaign have passed self-test procedure and packed into boxes. Some bureau procedure from campaign is waited for otherwise shipment to US will already be done last week. Goran may know more details as he's doing it actually
    emard
    @emard
    @pnru_gitlab For ecp5.prog reinitialization is actually often done during JTAG as it must switch between software and hardware SPI. For IDE, if python can detect uninitialized/spoiled SPI it can then try initialization using try/except python syntax
    Paul Ruiz
    @pnru_gitlab
    @emard Doing the RTC thing sounds like a fun project. AFAIK there never was an RTC chip for the 99xx series, but maybe there was an RTC board in TI990 mini - I will look. The current Unix version has no support for it, but it would not be difficult to add a driver and read out the RTC on system startup. After that, Unix maintains its own clock: even now you will see the time progressing (use the date command for current time).
    @emard Had not thought of try/except - that is an excellent idea.
    emard
    @emard
    Yes for RTC I first saw it "works" but after few reboots I found out that it resets to compile time or something. Core could consult onboard RTC using i2c and then set unix time integer counter which will continue ticking afterwards. For setting RTC we have esp32 and other options. Btw import ntptime; ntptime.settime() will set ESP32 localtime() from a pool of network NTP servers and then esp32 can initialize onboard RTC here I have played with this https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n/esp32
    Paul Ruiz
    @pnru_gitlab

    @emard Unix reads the the disk timestamp on startup. Whenever the disk is synced the disk timestamp is updated with the current system time. This way, time will not normally go backwards for file time stamps. In the late 70's your PDP-11 might crash once a day due to some hardware glitch - doing time this way was a useful feature to have. It also reminds me that I need to configure a daemon to sync the disk every 5 seconds; on my research setup I don't have that.

    If the ESP32 is the time reference, why bother with the RTC chip (other than technical challenge)? The ESP32 might as well drive the emulated 99xx RTC chip directly.

    emard
    @emard
    Yes if IDE emu can provide timestamp, we don't bother with i2c, networked ESP32 will know time already and I have i2c solution for onbard RTC if we ever need it :)
    Paul Ruiz
    @pnru_gitlab
    I actually like the technical challenge (not this week, but soon) of doing a 99xx RTC "chip" that is backed by the real RTC chip over i2c. I will first see what I can find out about RTC boards on the TI990 mini's.
    Paul Ruiz
    @pnru_gitlab
    Another (but related) topic: the 99000 core can actually run at 30MHz when used with block RAM (~5 times faster than the Cortex setup) and it is less than 1000 lines of Verilog. Is the USB protocol simple enough that the controlling code can fit in 128KB code+data? Maybe that way a small USB controller is possible.
    Lawrie Griffiths
    @lawrie
    @aphistic There are lots of RISC-V implementations that you can use. If you don't plan to use Linux then the linux-on-litex-vexriscv repo is not the place to start. The picorv32 core is a simple one to start with, for example - https://github.com/YosysHQ/prjtrellis/tree/master/examples/picorv32_ulx3s
    picorv32 does not support JTAG and is not very fast, but it is easy to get get started with, particularly if you want to use Verilog.
    emard
    @emard
    @pnru_gitlab I can assist you with i2c real RTC I also think it's cool. BTW board can even power off and wakeup from RTC. I've done soft-core PHY for USB, 1.0 and 1.1 host and device mode are possible. 128KB should be more than enough for basic protocol, most devices will work even if we don do USB descriptor parsing and get GB of mykr0$opht dabases of registered devices
    Lawrie Griffiths
    @lawrie
    The two Linux-capable versions of RISC-V that run on the Ulx3s are litex-vexriscv and SaxonSoc. They both use the VexRiscv version of RISC-V. VexRiscv is fast and very flexible, and it written in SpinalHDL, but there is a repository with generated Verilog versions of it (which is what linux-on-litex-vexriscv uses.
    VexRiscv supports JTAG, but I never got it to work with the built-in USB JTAG, so have always used it with a separate USB to JTAG programmer connected to GPIO pins. For that you need headers soldered to your Ulx3s.
    If you learn SpinalHDL you can build bare-metal VexRiscv SoCs using SaxonSoc or the older Murax or Briey SoC generators.
    Lawrie Griffiths
    @lawrie
    SpinaLHDL (like Chisel that is used for the SiFive RISC-V processors freedom and rocket) is based on the Scala language.
    emard
    @emard
    @pnru_gitlab for USB protocol to keep "alive" also SIE is required to be done in core and presented as bus interface. SIE handles USB packets and you can consider this as some circuit-bent UDP protocol having few IN and OUT "ports" or "sockets" called endpoints that handle 8-byte or 64-byte packets. Once you get at packet level you are mostly time non-critical
    Lawrie Griffiths
    @lawrie
    LiteX is written in the python-based Migen language. You can use it to build SoCs based on several different RISC-V processor (e.g. VexRiscv, picorv32, minerva) if you learn migen.
    nmigen is a newer version of migen (still python-based). The minerva RISC-V processor is written in that. I am pretty sure that would run on the Ulx3s board.
    There are lots of other open source RISC-V processors that will probably run on the Ulx3s board - see https://riscv.org/exchange/cores-socs/.
    Lawrie Griffiths
    @lawrie
    There is also f32c written in VHDL, which runs on the Ulx3s board. @emard will know more about the current state of that.
    Personally, I use VexRiscv and picorv32, and I use VexRiscv via SaxonSoc. This is a minimal bare-metal SoC using SaxonSoc - https://github.com/SpinalHDL/SaxonSoc/blob/dev/hardware/scala/saxon/board/ulx3s/Ulx3sMinimal.scala
    But SaxonSoc is under active development and is changing.
    emard
    @emard
    Yes f32c has very efficient and stable MIPS core and some attempt to repurpose MIPS to also decode RISCV ISA. Proof of concept works but not much development happened recently so f32c-RISCV only supports BRAM, while f32c-MIPS supports SDRAM and BRAM