Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Charles Perkins
    @charlesap
    @pnru_gitlab An excellent little assembler! I will now abandon my efforts to make one in Python because this one does everything I would need.
    emard
    @emard
    ULX3S v3.1.4 project is out https://github.com/emard/ulx3s maybe you alread know, but I just tried and it works, small vt100 onboard editor for esp32 https://github.com/emard/esp32ecp5#onboard-editor
    mara
    @vmedea
    that could definitely come in useful ! at least with the memory to spare
    Andrew Nesbit
    @ullbeking_gitlab
    :'-( :'-( :'-( Waaaahhhh!! I was SO EXCITED when this was being lobbied for and I was pledging for it. Then it was finally released and guess what, I am completely and utterly broke, and there's no way I can rationalize buying this now :'-( I thinkit will make it all the more sweet when I finally DO save up some money and finally am able to buy it myself. It will mean so much more to me then.
    emard
    @emard
    @ullbeking_gitlab production really took much time. If I click "mouser" at https://kitspace.org/boards/github.com/emard/ulx3s/ parts for 85F without PCB cost 93$. Design goal asked by FER uni was that 200-500 assembled boards cost approx equal as parts from one set from mouser For student buying at FER shop, less than 100$ per board. Price at CS is only exceeded by administrative amount, but it is still very tight, Goran must work really hard to get any income from this - if there is more than 8% of faulty boards from production it would mean loss of investition. Even I don't have latest v3.0.8 85F because Goran sent all to CS distribution. It is always unsure will new v3.1.4 or higher prototype, when assembled, work as expected.
    Goran Mahovlic
    @goran-mahovlic
    I am trying to organize production with e-radionica for 12F without some chips - like ADC/I2C/RTC that version would be in the e-radionica store so we would not pay for extra shipping/export/import/fees so it should be more affordable.
    One 100 pcs. production run is requested from Watterot - but we are waiting really long time for them. I also do not think it will be cheaper, it will only have 64Mb SDRAM - as the first batch they did...
    Goran Mahovlic
    @goran-mahovlic
    As for Crowd Supply - in after sale I really lowered all prices for them - as in campaign (after lots of negotiations) they offered good fee - almost too good, so they did not have any profit on campaign boards. Specially after sending all those "free" connectors in separate shipment.
    Michael Engel
    @michaelengel
    Yeah, the separate connectors (which came in a rather large package) were a bit of a surprise...
    Paul Ruiz
    @pnru_gitlab

    I've now got the cache to work reliably for the 99K system:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/cache.v
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/sdram.v

    NextPNR reports an Fmax of ~65MHz, but this seems wrong: I've tested with the cache/sdram running at 90MHz and 130MHz (CPU clocked at 25MHz) and both work just fine. I've not drilled down to the bottom of this, but probably NextPNR sees a limit on a signal that is stable for more than one clock.

    I was stuck for a long time on something that appears to be a Yosys/NextPNR bug. If I'm not mistaken, this does not work:

    reg   [0:SETS-1] dirty[0:WAYS-1];
    dirty[way][set] <= dirty[way][set] | wr;

    (appears to always set bit 15 regardless of the value of 'set') and this does work as expected:

    reg   [SETS-1:0] dirty[0:WAYS-1];
    dirty[way][set] <= dirty[way][set] | wr;

    (note reversal of bit range).

    Paul Ruiz
    @pnru_gitlab
    I hope to get back to the Oberonstation next week.
    David Shah
    @daveshah1
    @pnru_gitlab the indexing issue sounds like a Yosys issue to me
    as for the timing, that is because the FPGAs are turning out to be a lot better than Lattice specify these days
    -6 and -8 speed grades are essentially indistinguishable in practice
    Paul Ruiz
    @pnru_gitlab

    @daveshah1 The problematic line appears to be:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/cache.v#L144
    If I change that to a posedge the calculated Fmax goes up to ~130MHz. Originally that line was just an assign, but that left occasional data corruption. If I just register sdr_ctr[0] on negedge, Fmax is also calculated to about 130MHz.

    Maybe the circuit is helped by the block ram being sequentially accessed and staying in a single row; this may lead to an access time well less than 10ns ??

    emard
    @emard
    I made ESP32 micropython DCF77 fake sender which doesn't work :) https://github.com/emard/DCF77/tree/master/micropython I tried best I can and signal on the scope looks as it should be. But clocks don't recognize the carrier. I don't know do I have wrong clocks or too noisy environment so it can't work. If anyone sees anything wrong in my code let me know
    Thomas Hornschuh
    @ThomasHornschuh
    HI, I have a question about MASTER_SPI_PORT=ENABLE or DISABLE. Diamond tells me that I can only access flash pins from Bitstream with set to DISABLE. This is also stated on the comment in the standard .lpf file. With ENABLE it states "write to FLASH possible any time from JTAG:" . Does it mean, that after Bitstream load with set to DISABLE further FTP put over ESP32 will fail?
    mara
    @vmedea
    in general no, no matter what the bitstream does (as long as it keeps wifi_en=1 so that the ESP32 remains on) it doesn't prevent the ESP32 from flashing or programming
    Simon Thornington
    @sthornington
    is there an example of handling a button press on the esp32 in micropython, given the passthru bitstream? I am having trouble searching for this
    emard
    @emard
    @ThomasHornschuh It actually means that while bitstream is running, it is possible to write flash without interrupting of the bitstream for special applications which need minimal downtime. currently esp32ecp5 will always unload bitstream but you can disable this in the source.
    In most of our retrocomputing examples (take any from @lawrie QL, spectrum, vic20) or @Speccery it uses spi slave in FPGA and gpio0 interrupt pin. using current passthru bitstream is for C but not recommended from micropython as passthru communicates with SD card lines, expecting to unmount and release all SD lines, which is not possible with micropython but possible with C
    emard
    @emard
    DCF77 update: it started to work. Wiki documentation is wrong about modulation level. Modulated amplitude must go down to 25% of full level (100% value).
    Simon Thornington
    @sthornington
    Okay thanks I was just curious. I don’t really plan to do a whole whack of stuff in micropython, it was just handy to test the nonstandard OLED display I stupidly bought
    emard
    @emard
    I have examples for SSD1331, SSD1351, SSD1306 OLED displays
    Simon Thornington
    @sthornington
    Yeah i worked from your ssd1331 and the spec to get my ssd1327 working. Going to do st7789v next
    Simon Thornington
    @sthornington
    I have a question - are the oled and lcd examples, with the custom bitstream for the latter, rearranging the pins to conform to the lcd display or something (and therefore no longer match what's printed on the PCB?)
    because I've been making custom cables to match the PCB markings but now I'm getting confused between oled.py where self.gpio_csn = Const(17) but in top_st7789.v lcd_clk = wifi_gpio17;
    (and I am kinda assuming the 17 here refers to the same thing)
    Simon Thornington
    @sthornington
    perhaps this has to do with the oled example using SPI channel 1 but the LCD example using SPI channel 2
    maybe I literally need to read three years of scrollback in this gitter to get the gist
    emard
    @emard
    @sthornington yes bitstream projects do rearrange pins. At least GND and 3.3V must match, FPGA is flexible about pins, practical is to plug display directly without wires. Original markings are for SSD1331. ST7789 7-pin is similar but I think pin has BL (backlight) function instead of CS. wifi_gpio17 refers to the same thing and also ESP32 is flexible about SPI pinout so you can match practicaly any combination.
    esp32 Channels 1 or 2 itself are the same but if you mount SD card from ESP32 it will always use channel 1 so channel 2 remains free. Without SD channel 1 or 2 are for display the same.
    emard
    @emard
    For easy BTNs you can use simple FPGA logic to connect e.g. BTN0 to wifi_gpio0 and some other similar, directly in FPGA logic, simple approach
    Simon Thornington
    @sthornington
    @emard understood, I guess one way to make it so you could always plug in would be to put another gnd/vcc in the opposite order on the other side :). I think I need to read the schematic & pcb and try to match it up with the constraints or something, the OLED pins are not marked with their "site", only the ssd1331 defaults so it's a bit confusing.
    Simon Thornington
    @sthornington
    @emard (to be clear, the way I read the above is that the gnd and 3.3v are the two pins that cannot be rearranged by the fpga) ?
    emard
    @emard
    @sthornington of course GND and VCC can't be swapped by FPGA, because OLED draws current and must connect to hard power supply, can't be powered from FPGA 16mA pins (so low power devices actually could swap even GND/VCC). new board will have 8-pin LCD header instead of 7-pin but there's really crowded with routing so additional 2 pins are nearly impossible. But if display has GND and VCC swapped, then it will fit to external connector GN/GN 0-27 so there's still a possibility to plug such display directly on board on the side
    Simon Thornington
    @sthornington
    @emard understood.
    Simon Thornington
    @sthornington
    This message was deleted
    Paul Ruiz
    @pnru_gitlab

    @daveshah1 I'm trying to understand the speed of certain circuits. In a write-back cache I have to maintain a 'dirty bit' for each cache line.

    If I implement that as:

    reg   [SETS-1:0] dirty[0:WAYS-1];
    dirty[way][set] <= dirty[way][set] | wr;

    I seem to get to about 14ns delay, Fmax ~70MHz.

    Using a one-dimensional, wide vector seems a bit better

    reg   [WAYS*SETS-1:0] dirty;
    dirty[{way, set}] <= dirty[{way, set}] | wr;

    and reports about 10ns, Fmax ~100MHz.

    Using 4 different 16-bit vectors is better again (1 of 4 shown):

    reg   [SETS-1:0] dirty0;
    if (way==0) dirty0[set] <= dirty0[set] | wr;

    and reports about 8ns, Fmax ~125MHz.

    These are all NextPNR reports for an 85F as part of a larger circuit, not an isolated example. Are the above outcomes in line with your expectations and is there an even faster way to express the same?

    Ed Bordin
    @edbordin
    @emard I found in the chat logs here that you also hit this error with yosys -abc9: ERROR: Assert '!aig_map.count(bit)' failed in backends/aiger/xaiger.cc:435. Did you ever find out what the cause was?
    emard
    @emard
    @edbordin I don't know details, one of workarounds is to try to use or not to use -abc9 and/or --router router2. I don't remember exactly but this error could appear also while compiling some more complex design like oberon when some full featured BRAM couldn't be inferred and the workaround was actually to not infer but use vendor-specific BRAMs.
    Thomas Hornschuh
    @ThomasHornschuh
    Hi, I try to access the RTC from FPGA. Is there any special thing to take into account, because I have no success. Most likely some error in my design, but before digging into it I just want to know if there are pitfalls I'm not aware of
    emard
    @emard
    @ThomasHornschuh there are multiple possibilities. There are self-test binaries that show clock ticks. Saxonsoc linux has full support https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp for RTC, get my https://github.com/emard/hwclock4saxonsoc and it will natively compile with saxon lcc. There are some ESP32-RTC related demos here https://github.com/emard/ulx3s-misc/tree/master/examples/rtc https://github.com/emard/ulx3s-misc/tree/master/examples/lcd_st7789/micropython/st7789_240x240_polyline/esp32
    Usually you need CR1225 3V lithium battery + polarity to metalic holder, - polarity to PCB pad. RTC can run without battery but for shutdown battery is mandatory.
    Thomas Hornschuh
    @ThomasHornschuh
    My question was meant in a different direction: I want to know if the RTC should work when the I2C io port of my RTL design is just mapped to pins in the reference I/O constraint file, or if the can be interference with e.g. esp32.
    emard
    @emard
    There is example https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/i2c_master/proj which makes i2c master in verilog, talks to RTC and displays time as HEX on DVI and LCD. There can't be interference with ESP32 because ESP32 is not directly connected to RTC, FPGA is between them.
    emard
    @emard
    @pnru_gitlab I can only speculate, but last notation looks like dirty0 is allowed to be placed to location independent of dirty1 etc (other examples make array and possible tie them all together) and this scatterness maybe results in a big design more optimally placed and routed = faster circuirt.
    cybermancer
    @cybermancer_gitlab
    Just ordered a ULX3S with ECP5 85F from Crowdsupply. However I am now confused as I hear there is supposedly a 32MB and a 64MB version of this board available... Obviously I would prefer a 64MB version if they exist but don't recall there bing any such option. What gives?
    Goran Mahovlic
    @goran-mahovlic
    @cybermancer_gitlab 64Mb version was just one run by Watterot, and they are not available