Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Paul Ruiz
    @pnru_gitlab
    I think in line 343-372 in Ulx3s_Top.v I have commented it out?
    emard
    @emard
    No, there's just comment text commented and code active
    It can be left as is especially if it generates any picture
    Paul Ruiz
    @pnru_gitlab
    In oberon_251020.tgz ?
    There may be a timing synthesis issue with video included, but maybe it works.
    It is not good if you don't see the commented out lines, because there were changes to the toplevel as well since yesterday.
    emard
    @emard
    yes oberon 251020. I compiled but no boot, Only D7 lit. Generates 1024x768 60Hz black screen, correct sync
    Oh sorry my mistake, yes you are right, I extracted wrong file
    Paul Ruiz
    @pnru_gitlab
    emard
    @emard
    I am compiling this with corrected memsel and video enabled
    emard
    @emard
    I compiled now latest 251020 but still the same effect only D7 lit and black screen
    Paul Ruiz
    @pnru_gitlab
    Uhm, i think i forgot to change pll.v back to 125 (0 deg) mhz.
    emard
    @emard
    You can use my ecp5pll.sv that's easy any setting
    Paul Ruiz
    @pnru_gitlab
    Yes.
    emard
    @emard
    My ecp5pll calculator reports that it can't fit parameters for 125,65,325 MHz to the same PLL and requires 2 different instances.
    your has generated 130MHz instead of 125 MHz which can't work
    BUT on 85F now there are not enough BRAM to support OSD HEX display :)
    Paul Ruiz
    @pnru_gitlab
    In general it should be able to work, but in this case I'm pushing it really close on timing. The SDRAM has data ready at "half a clock" as seen from the controller clock and I delay that by ~2ns. This means registered data is available 6ns after the controller clock positive edge. The cache block RAM clocks that in on the next positive edge. At 125MHz the cycle is 8ns, so the block RAM gets 8 - 6 = 2ns setup time. At 130ns it is even less.

    How about a test without video at 125MHz? It would be good to know if that boots to the expected leds.

    My simulation now ran for 400ms, but it is still doing stuff with the file system at that time.

    emard
    @emard
    I will compile it somehow with 125MHz to see what LEDs do
    emard
    @emard
    I compiled 125MHz but same as before D7 and no boot
    Paul Ruiz
    @pnru_gitlab
    Bummer - that can only mean that the sdram is not working. However, with the 12F yesterday getting a lot further in the sequence, I must be close. Back to the drawing board. Maybe that SDRAM test bench model that @edbordin located will help in pinning down the issue.
    emard
    @emard
    In video declaration there is 1 word too much reg [31:0] mem[0:24575]; while you used 24576
    Paul Ruiz
    @pnru_gitlab

    Another strange thing is that the screen is black - I think I am pre-filling the video ram with some content.

    Yes, you are right: 24575.

    emard
    @emard
    OK last word doesn't make it fit with OSD ...
    Paul Ruiz
    @pnru_gitlab
    You could reduce the size of video ram by half, just for testing. If the upper part of the screen works, probably the bottom half will too :^)
    emard
    @emard
    I will compile it this way
    Can't fit even with 8K words :(
    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.