Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    hex needs only 1 BRAM block for the font
    but who knows how yosys infers this all
    ERROR: Failed to pack flipflop 'controller.dbi_FF[0]._TECHMAP_REPLACE_' with 'syn_useioff' set into IOLOGIC.
    ERROR: Packing design failed.
    Paul Ruiz
    @pnru_gitlab
    This is strange - I am using 2KB for the PROM, 16KB for the cache and 96KB for video (48KB if you cut it in half). That should be a very easy fit on the 85F.
    emard
    @emard
    I don't know, now I will compile only OSD mixer without hex decoder just to find what's up
    maybe divison by 6 it makes build BRAMs for lookup tables, that can be disabled
    emard
    @emard
    It could be other problem, OSD HEX decoder may refuse routing to sniff traffic at IFS blocks
    OK it was refused routing to IFS. Now I got hex display and video, will try to increase to 96K buffer now
    emard
    @emard
    I know why no boot: 96K video is too much burden for timing. Reducing it to 2K words (8K) lets it boot to D7+D2 but not any further
    emard
    @emard
    https://github.com/emard/oberon/blob/master/hdl/pnru_mix/Ulx3s_Top.v here is my edit of toplevel with ecp5pll and video mix for HEX OSD, hold BTN1 to view hex
    Even with reduced video mem, I can't get reliable boot to D7+D2 between synthesys
    Paul Ruiz
    @pnru_gitlab
    I need to make sdram timing less critical. I have an idea for that. Will try tonight.
    Paul Ruiz
    @pnru_gitlab
    The simulation ran for 972ms, reaching leds=0x00 at 706ms. Most of time is spent reading the sd card. At 972ms it stopped with a cache memory bug. I was not writing a log file, so I will run it again overnight with wave logging from 960ms or so to see what happened.
    emard
    @emard
    By fixing reset sequence (currently with pressing BTN0), I can get reliably D7+D2, having black screen and also HEX OSD BTN1 works, for possible bus display monitoring
    Paul Ruiz
    @pnru_gitlab
    I can currently replicate your h/w result. Playing with frequencies and little circuit tweaks never makes a difference, it always gets to leds = 0x84. Maybe it is not an sdram issue, but something else.
    emard
    @emard
    HEX sniffs CPU data bus side, does this traffic look ok to you?
    emard
    @emard
    I experimented several times power off board and upload bitstream then monitoring bus state. After each power on and reset, HEX shows significantly different data in/out bus state so i guess something must be wrong with memory. I expect boot procedure to look the same each time
    Simon Thornington
    @sthornington
    has anyone else seen a problem finding pytrellis with OSX Catalina? I've tried several different things but I am running into the same issue as this: YosysHQ/nextpnr#483
    Paul Ruiz
    @pnru_gitlab

    @sthornington I've not built from scratch for a while, so no recent experience. However, some 12 months ago I was building from scratch on Catalina and it took some time to get right (at that time the issue was with the boost libraries). In general, it seems to me that the Trellis build for OSX can be troubled from time to time.

    The daily builds over at https://github.com/open-tool-forge/fpga-toolchain may be your best source of clues: they will probably be the first to notice something going wrong in the build. Their build scripts may also provide an answer for your issue.

    Paul Ruiz
    @pnru_gitlab

    @emard Maybe indeed there is a total failure of sdram, although I would surprised that it would get as far as leds=0x84 in that case. I am running tests with the sdram model that @edbordin found and that has already identified some issues (like my refresh commands being spaced too closely together).

    Maybe the HEX interface can track the commands that are sent to the sd card? This way we can check that the sequence prior to leds=0x84 runs as expected or not.

    Ed Bordin
    @edbordin
    @pnru_gitlab fwiw I was checking the timing parameters on that sim model today and was unsure if the tRFC parameter on the micron part (auto refresh period) has an equivalent specified in the datasheet for the ISSI part
    emard
    @emard
    The problem could be around sdram and cache controller. HEX can display some debug register, let's say debug logic is made to store some value in reg just before 0x84 status. This reg should be wired to toplevel where is hex_decoder instance and during vsync move reg value to OSD_display reg. Here is my demo that shows CPU side. https://github.com/emard/oberon/blob/master/hdl/pnru_mix/Ulx3s_Top.v#L395
    Paul Ruiz
    @pnru_gitlab

    @edbordin Point taken. However, I also have an older ulx3s board with the micron chip. In general, I guess I'd like to write it such that a wide range of chips are covered.

    Further tests bring up no other issues, and inspection of the sdram and cache ram contents after a short run show the expected results.

    Paul Ruiz
    @pnru_gitlab
    @emard clear - hope to have some further time tonight.
    Paul Ruiz
    @pnru_gitlab
    Still not much further, no working code.
    An almost successful simulation run produced the following statistics: booting takes ~1000ms, of which the first 100ms runs from rom. In the remaining 900ms were to code runs from ram, there were 2500 cache misses, of which 1500 had to write a dirty cache line. It would seem to me that using "random" replacement instead of approximated LRU worked out well.
    emard
    @emard
    Real one also boots around 1s. Obviously task is not so easy to make. For experimenting, can it work work directly with sdram, without cache or only in combination?
    Paul Ruiz
    @pnru_gitlab

    @emard The sdram controller can work alone, but it is designed to read/write 128 (16 bit) word bursts. Not so easy to interface to a host that expects single words. The cache can really only work together with the sdram controller, because it expects signals and data to arrive in precise order (like: "if this signal is asserted, data will be available 2 clocks later", etc.). It could be possible to connect the cache/sdram combo a simple system with a monitor program.

    Maybe the least effort is to write a simple RISC5 assembler and put some short test programs in the rom and test that way. Heresy, as in the minds of the Oberoners there is no such thing as RISC5 assembler, it seems. The Oberon system has a UART that is easy to use: write to a register and a character gets send, etc.

    I am probably not seeing the forrest for the trees. I think I will leave this for a week and then have a fresh look.

    emard
    @emard
    @pnru_gitlab I see, sdram interface is significantly different than CPU so cache must be inbetween. OK good idea to let it be thinked about for a while. One of debug possibility is to add SPI slave and peek/poke RAM from ESP32
    Lawrie Griffiths
    @lawrie
    @goran-mahovlic @emard I have been converting a few more example programs to nmigen including a PS/2 keyboard example and some audio examples - https://github.com/lawrie/ulx3s-nmigen-examples
    The plaform resource for ulx3s seems to have several problems and really needs reviewing - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py
    Problems that I have found are the audio resource cannot be used as it has ring2 pins as duplicates of ring 1 - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L79-L84
    The default usb resource is not usable for PS/2 keyboards as it only defines one of the pull-ups - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L107-L109
    Lawrie Griffiths
    @lawrie
    It is also missing the usb_fpga_dp/dn version of the pins.
    The oled connector is completely missing.
    It should probably be used ujprog rather than openFPGALoader - https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L143-L146
    I am also not very convinced by how the buttons are done, and various other attributes seem to be missing or wrong.
    emard
    @emard
    looks nmigen board pinout is unfinished to be fixed later when someone tries to use them. I haven't participated in the making. Goran send board Luna for porting the USB sniffer, but we should probably load nmigen ourself, try and ask for fixing
    openFPGALoader itself is ok if someone prefers e.g. fujprog binary is not working on some platform. It can program fpga and flash, same as fujprog
    Goran Mahovlic
    @goran-mahovlic
    @Dolu1990 @lawrie wow! https://twitter.com/Ruinland_Mask/status/1321467724774535169 And I thought we are still at tetris :)
    Dolu1990
    @Dolu1990
    Cool :D
    kost
    @kost

    openFPGALoader itself is ok if someone prefers e.g. fujprog binary is not working on some platform. It can program fpga and flash, same as fujprog

    will investigate this.it stopped working with newest release?

    kost
    @kost
    user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v48-linux-x64 -j flash blink_12f.bit 
    ULX2S / ULX3S JTAG programmer v4.8 (git 96ebb45 built Oct  7 2020 20:34:11)
    Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors
    Using USB cable: ULX3S FPGA 12K v3.0.8
    Erasing sectors, please wait.
    Programming: 100%  
    Completed in 41.93 seconds.
    user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v46-linux-x64 -j flash blink_12f.bit 
    ULX2S / ULX3S JTAG programmer v4.6 (git 0a4cc36 built Jul 22 2020 20:50:14)
    Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors
    Using USB cable: ULX3S FPGA 12K v3.0.8
    Erasing sectors, please wait.
    Programming: 100%  
    Completed in 45.14 seconds.
    Tested released versions and they are working fine.
    kost
    @kost
    any specific platforms?
    I need to test it on?
    Lawrie Griffiths
    @lawrie
    @kost I thought @emard was saying that openFPGALoader was an alternative IF fujprog was not working on a particular platform at any time. I didn't think he meant it was not currently working. I would prefer nmigen changed to use fujprog. It is not particularly easy to switch between using one or the other.
    emard
    @emard
    @kost @lawrie Right fujprog could be working ok, but this nmigen source author maybe didn't know of fujprog, or for his multiplatform project he prefers to use the same tool (openFPGALoader) for as many platforms possible.
    When flashing fujprog is slightly faster than openFPGALoader
    kost
    @kost
    thanks on details. Just wanted to see if there is any bug i'm not aware. As I have spend quite some time on multiplatform support: from Windows, Linux, Mac and BSD.
    Goran Mahovlic
    @goran-mahovlic
    We have added few USB/OV7670 extensions to e-radionica https://e-radionica.com/en/catalogsearch/result/?q=ulx3s