[lowrisc-dev] need help with dram test - untether - v0.2
Dr Jonathan Kimmitt
jrrk2 at cam.ac.uk
Wed Jan 31 14:46:42 GMT 2018
I don't have any experience with the Nexys4. I am using the Nexys4DDR
which is substantially different.
It is possible to run a simulation using
src/test/verilog/sd_verilator_model.sv (from the ethernet-v0.5 release)
Of course this model will not be exactly the same as the card you want
to use. The fault might be in the way
that the card is put into SPI mode. This is one reason why we have moved
to an SD driver and hardware in the
latest release. You could retrofit SD mode to the v0.2 release, but why
would you not want all the bug fixes and
improvements from the latest release ? Usually the SPI mode is triggered
by a particular pin being pulled as reset.
I can't remember more details than that, but it is well explained in the
On 31/01/18 13:41, Anup Kini wrote:
> Hi Jonathan,
> Thanks for the pointers, few parameters were wrong in the mig settings.
> I could run the dram test successfully.
> Now, the sdcard test fails with the following error message in the
> uart console:
> Fail to mount SD driver!
> error! exit(0x0000000000000001)
> Is there a specific SD Card we need to use, I have tried the following
> two cards
> 1. SanDisk Ultra SDXC 1 (64 GB, 80MB/s)
> 2. Lexar Professional SDXC 1 (64 GB, 95 MB/s 633x)
> I have cross checked the fpga pin locations, from Nexys 4 Ref Guide
> <https://reference.digilentinc.com/_media/nexys:nexys4:nexys4_rm.pdf> Page
> 22 of 29, for spi_cs, spi_sclk, _spi_mosi & spi_miso.
> I have connected the above signals to the corresponding pins in my
> device under the SD Card connection section.
> SPI_CS -> DAT3
> SPI_SCLK -> CLK
> SPI_MOSI -> CMD
> SPI_MISO -> DAT0
> Kindly let me know how to debug this further.
> Thanks & Regards,
> Anup Kini.
> On Wed, Jan 31, 2018 at 6:22 PM, Dr Jonathan Kimmitt <jrrk2 at cam.ac.uk
> <mailto:jrrk2 at cam.ac.uk>> wrote:
> The hello world test uses only internal block ram. So not much to
> go wrong.
> As soon as you exercise DDR memory, the processor will hang if the
> AXI bus does
> not respond. The situation is complicated by the presence of
> caching which might mean
> you don't see the problem straight away.
> I suggest you run the DRAM example design that comes with MIG
> (right click on the MIG IP in Vivado and use 'Open IP example
> design') to prove that
> your MIG settings are correct. This can be done in simulation and
> the real FPGA.
> If it passes the Vivado example design, it is a simple matter to
> capture the settings in
> mig_config.prj for lowrisc. Also pay attention to any interface
> signals that might be different
> in that version of the MIG IP.
> There may also be a pre-configured MIG project for your board on
> the manufacturer's website already
> for comparison. Also check your board revision, sometimes the DDR
> chip changes between revisions
> and this could require MIG settings file to be changed.
> On 31/01/18 12:41, Anup Kini wrote:
> Hi All,
> I was able to successfully port the untethered design to a
> custom Virtex 7
> 2000T device.
> I also ran the hello world example, which ran successfully.
> When I try to run the dram test, the print stops after the 1st
> DRAM test program.
> Write block @0 using key 0
> I did a little debugging and added a print step inside the
> dram.c code,
> line: 57, inside the for loop.
> It gets stuck at step 8 (i.e i iterated 8 times.)
> SetUp details:
> Vivado 2015.4
> Virtex 7 2000T - xc7v2000tflg1925-1
> lowrisc - untether v0.2
> MIG UI Clock @ 100 MHz
> Uart, BRAM, SPI-SD, Core - all running at 25 MHz
> I have configured the axi_clock_convertor to 1:4 ratio for the
> above clock
> Kindly let me know how to proceed debugging this issue further.
> Thanks & Regards,
> Anup Kini.
More information about the lowrisc-dev