• Content Count

  • Joined

  • Last visited

  1. All great and thanks; Now there is a newbie's question regarding BitStream and .elf program, power-on loading from Flash: Does elf loading from Flash only work for internal-BRAM linked programs? As such, loading external SRAM (or SDRAM) addressed program would require the help of a bootloader.elf. This is the principle preached by many a tutorial from Digilent. If the above is not necessary, then I could simply 'combine' the RTL bitstream with my custom elf program (myapp.elf) into Download.bit and Flash that to the QSPI flash chip. On the other hand (if it is necessary) then th
  2. OK, so I proceeded to commenting out the actual memory testing actions, and then the programs moved onto the button and LED tests and seems to be alive and kicking. This is good and I can go back to the original issue of Flash storage and boot from Flash. So it is a good milestone achieved. Thanks for your help in getting to here. --- PaulJX
  3. Hi Ana-Maria, Good news and 'bad' news below: Good news first, 1) Vivado/SDK 2018.2 installation worked smoothly; 2) The OOB project successfully went through RTL all the way to Bitstream generation without incidents. 3) SDK loaded OK, but the OOB application project did not load, because there was a URI reference error that could not be resolved. So I manually created an empty application with a new name "OOBdemo1", and then copied over the <src> directory that was meant to be for the OOB-application. That seemed to have worked OK, and I was able to run the prog
  4. Thanks Ana-Maria for working the weekend. So far, I had setup Vivado 2016.4 (on both Windows and WSL2.0 Ubuntu 18.04 LTS), 2017.4, as.well as using 2019.2 briefly. I removed 2019.2 eventually because that version's SDK became 'merged into' Vitis that I found a little too far out for me. Thus I am quite used to trying different versions of Vivado for fun (not really, but rather mainly for debugging out issues such as Flash and memory types). (This morning I also discovered that I can install XCST to try things through script automation rather than through the SDK-GUI with Vivado.)
  5. Ana-Maria, I think I do have those IP blocks properly connected as shown below: But BitGen still has the same/similar errors, thus the problem probably lies somewhere else? Today's new error log attached. PaulJX OOB_errors_20200619a_003.log
  6. OK, upon further reading, the next paragraph did say how to set the <path>: "3.3, Open the copied init script in a text editor. Change the text “<extracted path>” in the script to the path to the extracted vivado-boards folder. Save and close the file." So it was there I just did not read through the whole thing. But what I did (copying the board_files into the Xilinx-Vivado installation tree) should be equivalent. So there. --- PaulJX
  7. Thanks; the instructions for installing the board files show two different ways, one is to install the *init.tcl script(s) but not being very clear in where to put the board archive source-files for the script to find the path when executed; the other instruction that is inside the file that in turn points to "" says basically to copy the board files to the Windows Vivado installation directory, which is pretty straightforward to follow and that was what I did. (By the way, before encounte
  8. Dan, Thanks for your advice and I totally agree. The only issue with this particular example is that it was provided to me as an OOB example for CMOD-A7 (by Anna-Maria) today to be a test case for resolving my original issue with Storing program in Flash . Thus it should have built squeaky clean, but may be due to a new build of Vivado-2016.4 (in 2017 according to the banner) Vivado seemed to have enforced more stringent checking than the original build (???) and resulting in these 'new' errors. Cheers, PaulJX
  9. --- today, I ran into BitStream Generation error when running syth/implement/BigGen, due to at least a couple errors that I could not resolve even if by setting the following tcl script lines: --- Vivado 2016.4 $$$ start TCL $$$: set_property SEVERITY {Warning} [get_drc_checks NSTD-1] set_property SEVERITY {Warning} [get_drc_checks UCIO-1] $$$ end TCL $$$: ======================================= ERROR: [DRC 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 5 out of 40 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of
  10. This is great material. Thanks. Please allow me a few days to test the basic configuration and all the variations (internal memory 32k vs 128k, Link to internal vs link to external, and flash the <app>.elf directly vs flashing the bootloader that will load the <app>_SREC). Thanks again, PaulJX
  11. Just a fine-point regarding using 32kB BRAM versus using 128kB BRAM, for internal memory; One hypothetical cause for the 128kB BRAM instantiation issue is that when the <myapp>.elf is running, it is running within the IP-integration's memory space; but when the internal memory is loaded from Flash, the loading of the BRAM is within the FPGA fabrics BRAM block-instance 'memory-space'. Thus theoretically if the IP's memory space is not aligned with the BRAM's 'slice' space assignment, the .elf may not be loaded correctly. But this is purely my speculation. Then the two oth
  12. Thanks Ana-Maria for your responding to me. Since my FPGA board is CMOD-A7 (35T) I was always following the other tutorial that is specific to CMOD-A7, which invokes the axi-emc 512kB external SRAM IP. On your note, supposedly I can / should use the MIG IP instead (hopefully addressing and everything can work for the CMOD-A7 SRAM) ??? Another observation that I made was, it seems that when I was using 32kB for the internal memory (BRAM instantiation), then
  13. ... was wondering how come no one responded to this question at all, oh well... After a few days of searching and experimenting, including installing Vivado-2017.4, and Googling on this topic no end, today I found another Digilent Forum thread that contains a couple of working project/SDK examples, one of which is on 2017.4. And after testing to confirm that it can write to flash and boot from USB plugging-in, looked into factors and differences with my own projects, and aside from setting the ext_spi_clk to 50MHz (instead of my 100MHz connection to the same master clock as the axi_c
  14. Could be that I made any mistakes in connecting up the AXi_QSPI interface from MicroBlaze to the flash part? My diagram picture is attached. I did connect to the ext_qspi_clk with the same axi clock of 100MHz clock as advised, from some source. Thanks again, PaulJX