Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    e2kgh
    @e2kgh
    @emard: 32-bit SDRAM, did Paul look into it already ? Is it much faster (higher bandwidth) then the 16-bit version?
    emard
    @emard
    However supply choice of different vedhors for 32-bit sdram is small are chips expensive so board price will rise. To get FER-KONČAR support in prototyping and assembly, design must be low-cost, 100$ for all parts if obtained in 1-pcb quanty and currently it is 92$ https://kitspace.org/boards/github.com/emard/ulx3s/ (click mouser).
    @e2kgh 32-bit SDRAM behaves just like 2 16-bit SDRAM glued togheter. All commands are the same, there are 4 byte select inputs and bandwidth is 2x later also they come in 64MB total size. They cost around 15$ compared to 32MB 16-bit around 2$
    emard
    @emard
    @pnru_gitlab I remember pullps discussion and that was exactly what I was aiming for. ESP32 pullups are weaker, and when it engages MMC driver ESP32 either doesnt or cant enable internal pullups so they require in datasheet for SD card to be pulled externally by 10k resistors. FPGA pullups are much stronger than ESP32's, I dont know how much they exactly are but obviously make SD card work. Loose 3 free pins for 40% speedup is not very fair trade, and I dont know why micropython is so inefficient because SD card should deliver 12MB/s (120mbit) in 4-bit mode
    It could be FAT driver the speedbraker
    Maybe a raw SD sector dump should be a better test
    emard
    @emard
    FAT is not speedbreaker, if buffer is larger 8-16KB it reaches its top speed above 2MB/s which is the same arduino gets from compiled C code:
    1-bit mode SDCard(slot=3):
    
        >>> import sdtest
        ['long_file.bin']
        1056 KB in 752 ms => 1404 KB/s file read
        4096 KB in 2746 ms => 1491 KB/s raw sector read
    
    4-bit mode SDCard():
    
        >>> import sdtest
        ['long_file.bin']
        1056 KB in 492 ms => 2146 KB/s file read
        4096 KB in 1777 ms => 2305 KB/s raw sector read
    emard
    @emard
    This itself should be faster than your WDC controller but there needs to be also SPI streamng back so this speed will be reduced, I expect something 0.25-1MB/s
    Paul Ruiz
    @pnru_gitlab

    It is not difficult to be faster than a 1980 MFM hard drive. For example the ST506, which is similar to the disks on the mini-computers of the late 70's. The track-to-track seek time was ~5ms (3ms step + 15ms settle) and there were a lot of track seeks happening. The main s/w optimisation was to sort the pending disk accesses by track, to minimise the seeking. The data rate was 5Mb/s = 625KB/s. The SD Card will not be the bottleneck, and even with the SPI_IDE bridge it will be about the same.

    Many thanks for the testing & measuring - much, much appreciated!

    emard
    @emard
    @pnru_gitlab I'm glad that we can make it technically possible. According to test from practical point of view, disk image can be a seeked file in SD cards FAT, SD raw access won't provide any speed. If buffer is 512 bytes 4-bit mode is unnoticeable faster than 1-bit mode.. If buffer is 8K then 4-bit will provide a small speedup
    Paul Ruiz
    @pnru_gitlab
    @e2kgh If you need more speed, perhaps a more advanced controller gets you there quicker. If you build a controller to do a 2-word burst read/write you get to 32 bit access at the expense of one more clock cycle (which you may even have available in your use case already) - this is a minor project. As @emard observed already, what really gets you ahead is combining the controller with a simple cache. For example, to fill a 64-byte cache line using one RAS and 8 consecutive CAS cycles of 4-word burst reads takes less than 40 clocks, 280ns on a speed grade 7 device. With maybe a 90% cache hit rate and 10ns bram access, your average access time would be a little less than 40ns. It is a much bigger project though. So far, none of my projects need that kind of bandwidth.
    Goran Mahovlic
    @goran-mahovlic
    What was easiest example I could try for checking if ENC28J60 PMOD is working - I finally managed to get some time to order parts and solder them all on board
    SaxonSoc probably - but I do not remember where I should connect it
    emard
    @emard
    @goran-mahovlic I see in esp32 micropython docs somehow esp32 also has ENC28J60, i tried to load this module but my mpy v1.12 doesn't have this module https://software.open-dev.ru/docs/online/micropython/library/network.ENC28J60.html
    It's a digiowl's mod/fork of micropython maybe so
    Goran Mahovlic
    @goran-mahovlic
    ok, ENC is detected by SaxonSoc - but I do not get IP
    SaxonSoc.jpg
    emard
    @emard
    I can't try my full setup but I remember I have crimped flat cable to accept standard ebay's ENC28J60 and I got IP from my network
    Goran Mahovlic
    @goran-mahovlic
    Yes, I know it should work, but my does not :) - but good thing is that it is detected so SPI pins are ok
    I do have more pins connected -- RST pin in on GP16 - CO to GP17 - WOL to GN16
    emard
    @emard
    It is 10-mbit maybe your net structure refuses this low speed. Those pins I have also connected on crimped cable and module still worked
    Goran Mahovlic
    @goran-mahovlic
    but only reset should be important
    emard
    @emard
    I'd sniff with tcpdump, does module place some packets on the net
    Lawrie Griffiths
    @lawrie
    It is a while since I have used it. Check you have /etc/network/interfaces and try ifup eth0.
    Goran Mahovlic
    @goran-mahovlic
    I would say that everything is fine with SaxonSoc - if I assign manual address and ping from PC I do get led blink on connector - and if I ping gateway from SaxonSoc - I also get blink - ping does not pass in any direction. I need to recheck parts I have on PMOD - as I did half of PMOD log time ago - so there is a chance I did something wrong ...
    e2kgh
    @e2kgh
    @pnru_gitlab : You don't need the bandwidth yet ;-) I just fooled around with different screen resolutions. So getting the higher bandwidth for the display controller is "easy", as it simply reads n-words, as fast as clock goes. The other good (?) issue is, that filling/flushing caches can also use the DRAM burst. And even when @Lawrie starts with his GPU, burst still can be used for reading/writing tiles/caches etc. Was just hoping to get as much raw bandwidth as possible, to get at least SVGA in 24bit ... (and still have bandwidth to access the display memory)
    @emard: please forget the ESP-S2 ;-) I think it is more "logical" to use the ESP32 for the SD-CARD, booting and slow keyboards/mice, and even ftp. But we are pumping all this data through an SPI ... It would be more beneficial, to have a real USB on the FPGA side (USB3340?) and do it right there ...
    @emard: and don't forget, the ESP32-S2 is slower than the ones you have now ...
    emard
    @emard
    I know, S2 is not yet ready, goran ordered few S2 modules and we will try it external with wires, no replacing usbserial in ulx3s design yet. I have USB3340 module and never could get anything from ths PHY, tried several downloaded ULPI sources but this chip its so full of regs and compilicated. Id like if somehow would sorted out replacement of soft-core PHY with 3340.
    OTOH my soft-core US2 phy works well for low and full speed USBs
    Even if we get 3340 PHY, we would have heavy FPGA core handling VFAT and protocols, that's why ESP32 is easy way to offload core development with benefit of programming convenience and in many cases slow speed is acceptable for what we do
    e2kgh
    @e2kgh
    @emard: you know this on github:
    emard
    @emard
    I know and I could get 3340 to work only as sniffer but not as host or device.
    e2kgh
    @e2kgh
    And, I thought, all the USB protocol could be done in a small microcontroller, which sits in the FPGA to, would be a common block for all designs, like the ESP interface?
    emard
    @emard
    That for sure is possible and orangecrab is demonstration of how good can it work
    emard
    @emard
    @pnru_gitlab SD card 4-bit additional: one card didnt wanted to work, I have explicitely set ESP32 CPU to run at 240MHz instead 160MHz default and now this SD card mounts well also in 4-bit mode
    from machine import freq
    freq(240*1000*1000) # 80/160/240 MHz, faster CPU = faster SD card
    promach
    @promach
    does open-source lattice tool have real-time signal capturing capability like what Altera SignalTap or Xilinx ILA/chipscope do ?
    emard
    @emard
    no but for ULX3S we have scopeio https://github.com/hdl4fpga/hdl4fpga I debugged usb-host with it. VHDL too advanced for openosurce to compile, need diamond
    promach
    @promach
    drr
    @danrr_au_twitter

    More fun with audio + ULX:
    https://twitter.com/danrr_au/status/1293501360021757952?s=20

    Also saw this VHDL encoder for HDMI video + audio, I noticed you had a fork for this @emard but from a few years ago. Did you have success with this on the ULX?
    https://github.com/emard/hdmi-audio

    I'll run it through GHDL + yosys at some point, HDMI video/audio is ideal and the interface on that module looks pretty much the same as the one I currently use , but with bonus audio

    emard
    @emard
    This source is problematic has some logical loop and written by C-style programmer. It works good only on altera. Needs to be rewritten or new source found that is clean and portable
    Paul Ruiz
    @pnru_gitlab
    In the Fall I'd be interested to take a look at that HDMI-audio code. At some point I would like to understand the details of HDMI data islands and the lot.

    For the mini-Cortex I have the IDE emulation working - it can now load the 2nd stage boot loader from disk and that stage can load the kernel from disk. Haven't done the MMU yet, so there is where it currently stops. @emard In your OSD code you have this:

        self.irq_handler(0)
        self.irq_handler_ref = self.irq_handler # allocation happens here
        self.spi_request = Pin(0, Pin.IN, Pin.PULL_UP)
        self.spi_request.irq(trigger=Pin.IRQ_FALLING, handler=self.irq_handler_ref)

    Why is that necessary? It (Pin.irq) seems to work for me with just giving the function name as handler.

    Paul Ruiz
    @pnru_gitlab

    @pnru_gitlab SD card 4-bit additional: one card didnt wanted to work, I have explicitely set ESP32 CPU to run at 240MHz instead 160MHz default and now this SD card mounts well also in 4-bit mode

    Is there any downside to running at 240MHz (other than power)? Do some things break at that speed? If not, would it not make sense to always run at 240MHz??

    emard
    @emard
    @pnru_gitlab First call of the handler(0) is to catch some stale irq. Second line .ref is micropython trick to force allocation for a function before it will be called by interrupt (reduce latency). Third line sets pin status and pullup to avoid glitches if FPGA side is missing. Last line activates IRQ handler passing it already allocated function. If you change it and it works, it's ok :)