Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    splinedrive
    @splinedrive
    The pmod 256Mbit uses 4x64 chips from spansion (cypress). https://1bitsquared.com/products/pmod-hyperram
    emard
    @emard
    ahaaa, so it makes 32MB total. The data pin bus is un-tidy, I would expect one PMOD 8-pin has D0-D7, the other PMOD 8-pin signaling, not the mix :) my wish for v2.0 hyperram :)
    Rob S
    @rob-ng15
    @emard It does have to be FAT16 at present as I had to quickly write my own file system reader.
    Rob S
    @rob-ng15
    I have to rely on what is provided in Silice at present.
    liebman
    @liebman
    Whats the minimum needed in order to effect a passthru for programming the esp32? I want to create seperate component to instantiate in my projects so at least during development I can easially re-flash the esp32 without disrupting whatever I have on the fpga at the time.
    Lawrie Griffiths
    @lawrie
    You need:
    assign wifi_rxd = ftdi_txd;
    assign ftdi_rxd = wifi_txd;
    But you can't do that if your project uses a uart interface to the host.
    emard
    @emard
    @liebman above is not enough as passthru for esp32 programming, it is just for serial console. I should review my project for passthru and make it reliably synthesize with yosys and clean it up from spi oled bnts etc what is current passthru that is in vhdl and compiles with diamond
    esp32 needs handling GPIO0 and GPIO2, EN I think with rs232 signaling rts dtr something
    fpga core has to simulate behavor of 2 BJT transistors found on usualy esp32 module. time-response of this logical circuit must be very fast
    liebman
    @liebman
    I think this (and the btn could be eliminated):
      -- TX/RX passthru
      ftdi_rxd <= wifi_txd;
      wifi_rxd <= ftdi_txd;
    
      -- Programming logic
      -- SERIAL  ->  ESP32
      -- DTR RTS -> EN IO0
      --  1   1     1   1
      --  0   0     1   1
      --  1   0     0   1
      --  0   1     1   0
      S_prog_in(1) <= ftdi_ndtr;
      S_prog_in(0) <= ftdi_nrts;
      S_prog_out <= "01" when S_prog_in = "10" else
                    "10" when S_prog_in = "01" else
                    "11";
      wifi_en <= S_prog_out(1);
      wifi_gpio0 <= S_prog_out(0) and btn(0); -- holding BTN0 will hold gpio0 LOW, signal for ESP32 to take control
    Irvise
    @irvise:matrix.org
    [m]
    Quick question. Has anybody here ran the Microwatt POWER CPU?
    Y just watched the Australian linux conf and in the Microwatt slides they say it has support for the ULX3S
    However, about a month ago I did not find anything related to that in their github
    liebman
    @liebman
    @emard this seems to work well
    module ulx3s_passthru (
      input  wire txd,
      output wire rxd,
      input  wire dtr,
      input  wire rts,
      input  wire esp_txd,
      output wire esp_rxd,
      output wire esp_en,
      output wire esp_io0,
    );
      // TX/RX passthru
      assign rxd     = esp_txd;
      assign esp_rxd = txd;
    
      // Programming logic
      // SERIAL  ->  ESP32
      // DTR RTS -> EN IO0
      //  1   1     1   1
      //  0   0     1   1
      //  1   0     0   1
      //  0   1     1   0
      assign esp_en  = ~( dtr & ~rts);
      assign esp_io0 = ~(~dtr &  rts);
    
    endmodule
    liebman
    @liebman
    This is a little cleaner
      assign esp_en  = ~dtr |  rts;
      assign esp_io0 =  dtr | ~rts;
    emard
    @emard
    @liebman hey great work, let me try this and I can add to ulx3s-misc examples :)
    emard
    @emard
    @irvise:matrix.org I know our board mentioned as supported on github https://github.com/antonblanchard/chiselwatt but I myself haven't tried it, but using chisel for code generation it should build straightforward make ECP5_BOARD=ulx3s synth
    liebman
    @liebman

    @emard this one is improved. It tristates gpio0 instead if setting it high so that it can be used elsewhere if needed. Also added an enable that can be used as a reset for the esp32.

    module ulx3s_passthru (
      input  wire txd,
      output wire rxd,
      input  wire dtr,
      input  wire rts,
      input  wire esp_txd,
      output wire esp_rxd,
      output wire esp_en,
      output wire esp_io0,
      input  wire en,
    );
      // TX/RX passthru
      assign rxd     = esp_txd;
      assign esp_rxd = txd;
    
      // Programming logic
      // SERIAL  ->  ESP32
      // DTR RTS -> EN IO0
      //  1   1     1   Z
      //  0   0     1   Z
      //  1   0     0   Z
      //  0   1     1   0
      assign esp_en  = (~dtr |  rts) & en;
      assign esp_io0 = ( dtr | ~rts) ? 1'bz : 1'b0; // we only want to drive this pin low
    
    endmodule

    can be called like

    module top(
        input wire clk_25mhz,
        output wire ftdi_rxd,
        input wire ftdi_txd,
        inout wire ftdi_ndtr,
        inout wire ftdi_nrts,
        output wire wifi_rxd,
        input wire wifi_txd,
        inout wire wifi_en,
        inout wire wifi_gpio0,
        output [7:0] led,
        input  [6:0] btn,
        output wire shutdown,
    );
        ulx3s_passthru passthru(.txd(ftdi_txd),
                                .rxd(ftdi_rxd),
                                .dtr(ftdi_ndtr),
                                .rts(ftdi_nrts),
                                .esp_txd(wifi_txd),
                                .esp_rxd(wifi_rxd),
                                .esp_en(wifi_en),
                                .esp_io0(wifi_gpio0),
                                .en(btn[0]),  // btn[0] will work as a reset for esp
        );
    
        // blinky for something to do so we know its operational
        assign led[0]   = btn[1];
        assign led[6:1] = 0;
        assign led[7]   = wifi_gpio0;
    endmodule
    emard
    @emard
    BRAM 200->400k at 85F could probably be achieved by using vendor-specific BRAM modules from yosys, I have those modules at my oberon code
    @liebman yes 3-state is more friendly. I think also in ulx3s_passthru module "inout" should be used instead of output but yosys does the right thing anyway
    emard
    @emard
    to 3-state wifi_gpio0 from yosys I think the reading function to outside pin must be applied like this (you have correctly done it)
    assign led[7] = wifi_gpio0;
    Without this 3-state logic will be optimized out
    emard
    @emard
    In my vhdl diamond version, I tried to autodetect programming esp32 by typical pattern traffic on RTS/DTR so en is internally made.
    liebman
    @liebman
    I want to be able to reset the esp32 from one of the buttons (or even have the FPGA do it) without disterbing what Im setting up in the FPGA.
    @emard do any of the example have esp32 read from FPGA via SPI?
    emard
    @emard
    Yes a lot, we use osd.py in all our retrogaming stuff. FPGA implements SPI slave emulator of something similar to SPI RAM chip, ESP32 is SPI master. There is gpio0 interrupt line from FPGA to ESP32 when FPGA (as slave) must initiate some SPI actions from ESP32.
    emard
    @emard
    You can take my ulx3s_c64 as example which is a bit shorter and cleaner than others. SPI slave stuff is actually verilog with vhdl wrappers. The mostly same code is also in https://github.com/emard/ulx3s-misc/tree/master/examples/dvi_osd/hdl - it implements BTNs interrupts and esp32 osd.py drive some SD card file selector
    liebman
    @liebman
    I’ll take a look - thanks
    emard
    @emard
    One drawback is that in current ulx3s boards there is no clock capable pins from esp32 to fpga, so SPI is scanned with clock and effective SPI max speed is cca clock_freq/5
    liebman
    @liebman
    thats good to know, which are the (non esp) pins that are clock capable?
    (that explains why some of my tests failed)
    emard
    @emard
    They are mentioned on pdf schematics_v3.0.8 let me see
    https://github.com/emard/ulx3s/blob/master/doc/schematics_v308.pdf page 2 GP,GN 12 are clock capable and shared with ESP32 but small design fail is those pins are on ESP32 input only. In new board v3.1.5 I tried to fix this by routing one esp32 output capable pin to FPGA clock input capable...
    New board is just drawing, not yet produced :)
    liebman
    @liebman
    What on the schematic denotes clock capable?
    PCLK?
    emard
    @emard
    PCLK .. means primary clock capable pins. they are best. GR_PCLK are second best, general routed to primary clock capable
    emard
    @emard
    A small fix could be possible with a jumper GN11-GN12 this will connect ESP32 pin 25 GN11 which is output capable to FPGA clock input capable at GN12
    Dave Anderson
    @danderson
    Hi, is there reference documentation for the format of the LPF files somewhere?
    Dave Anderson
    @danderson
    Couldn't find any decent docs other than nextpnr source code and poorly explained technical notes from lattice, so I wrote https://github.com/danderson/ulxs/blob/main/lpf.md
    Also comes with pointers to the Lattice tech notes that go into more detail about e.g. ECP5 configuration and I/O pin config.
    e2kgh
    @e2kgh
    @danderson : Excellent job, describing the LPF format!!! Just one small remark, when you describe the "signal name", please add, that it should be exactly the same name as in top level HDL, including upper/lower case letters. It bites me all the times, when I move between tools, some don't care, some do, and the error messages are not always meaningful ;-) THANKS AGAIN!
    emard
    @emard
    @danderson I have common problem most often with gp/gn pins. For simplicity I use as gp[27:0] but when they need to be 3-state and some pins IN, some OUT, then problems comes with yosys or ghdl. I still don't know how exactly opensource compilers interpret mixed directions, but often I have to change LPF instead of [] to define gp0, gp1, gp2 and specify each as input/output at toplevel, than things start to work. So I'm thinking first to double each LPF line, one for gp[0] and gp0. I don't know is there some better way to make them individually defined as gp0, gp1, ... and then make gp[27:0] bus out components gp0, gp1, ... without 2x repeating same BGA pin each time...
    Dave Anderson
    @danderson
    @emard hmm, that's useful info, thanks. Looking at the top-level HDL, I guess arrays can't be arbitrary direction per-bit, it's either all in, all out, or all bidirectional... So then by the time you get to nextpnr routing, it's too late to say "lol jk these pins are different"
    maybe the best way to go is to have a configuration utility to generate LPF files for individual projects... That way we can read the HDL ports and map them instead of having to guess the right config...
    Dave Anderson
    @danderson
    @e2kgh I added a section about signal names to clarify that (hopefully :) )
    splinedrive
    @splinedrive
    Hi, does someone know howto configure the olimex hx80k evb without flashing the flash? Do I have to use the jtag pins on the board? I have not seen any documentation about it. Does someone experience with it? :) thanx