• Content Count

  • Joined

  • Last visited

Posts posted by wanderso

  1. I'm looking to create a Verilog interface for the Digilent PmodMIC3, since the provided IP core has been too slow to get a 48KHz sample rate (the problem isn't actually with the IP core, but with the interrupt service routines, each of which seems to take at least 120 cycles).

    The datasheet says the maximum safe serial clock rate for the PmodMIC3 's onboard microphone is 20MHz. I want to create some sample Verilog programs that directly read the PMod off the jumper port ('jd' if it's relevant), and that'll mean creating a 20 MHz clock that connects to jd[4]. Does that make sense? 

  2. I have the sample constraint file for my Arty board. I notice that where it says a clock signal is created in the file, it specifies a specific port that the clock is found on, specifically PACKAGE_PIN E3. 

    set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { CLK100MHZ }]; #IO_L12P_T1_MRCC_35 Sch=gclk[100]

    create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {CLK100MHZ}];

    This creates a 100 MHz clock for the Arty. However, my current project needs a 20 MHz clock.

    I lack the FPGA knowledge to know whether these two lines of code are *describing* a clock that already exists at E3 on the Verilog board, or *creating* it. The "create clock" implies that it's creating, but the way the rest of the constraint file is formatted - with a list of the pins that exist on the Arty and their locations - suggests that it's only describing.

    Is it safe or even possible to make a 20 MHz clock by simply changing the number after -period to 50.00 for a 50 ns 20 MHz clock? Is there a way I can also keep the 100 MHz clock at the same time?

  3. I'm working on some embedded software on the Arty board and programming in Microblaze. When I try to allocate an array of sixteen-bit numbers, length 512, it works just fine, but the same array set to length 1024 causes malloc to return NULL. After some experimentation and testing, I believe this is because the Microblaze processor has run out of internal memory. However, the Arty board is supposed to have 256MB of DDR memory. 

    An interface to the memory already existed in my block diagram (copied from Getting Started With Microblaze with some PMods added), so I assumed that the DDR memory was already being used by the Microblaze processor, but 256 MB of memory shouldn't be struggling to deal with a 2KB array. (Outside of the allocated array, the program is very small.) Is there something special I need to be doing to access the DDR memory from inside Microblaze?

  4. I have a PmodMIC3 I would like to use with my Microblaze processor on a digilent Arty board. While trying to get the two devices to communicate through Vivado and the Vivado SDK, I have several questions that I could not find answers to.

    First, I assume that since there is no specific PmodMIC3 IP block, I should be using the generic PmodBridge IP block in Vivado. The 6-pin PmodMIC3 is plugged into the top row of the 2x6 Pmod output port, so the PmodBridge has it's top row interface set to SPI and the bottom row set to 'Disabled'. The PmodBridge then leads to the AXI Quad SPI block, which is one of the many things going into the Microblaze's AXI Interconnection block. (I assume that the ext_spi_clk on the Axi Quad SPI is meant to be the same ~50 MHz clock as the ext_spi_clk on the PmodOLEDrgb block, also included in this project.)

    Assuming that this set of connections is the 'proper' way to get PmodMIC3 to communicate with the Microblaze processor, is there any sample code I can look at, even just to see how to configure the SPI for the microphone by setting up the XSpi_Config block in Microblaze? I've been trying to reverse-engineer it from how the PmodOLEDrgb (which works fine)'s sample code uses SPI to communicate, but haven't had success yet.




  5. In order to figure out how to connect the on-board switches, buttons, and LEDs to Microblaze, I tried to follow the instructions in this Learnable. Sadly, the 'create_project.tcl' script seems out of date and can't be used to create a board design. I get the following error messages -

    ERROR: This script was generated using Vivado <2015.4> and is being run in <2016.3> of Vivado. Please run the script in Vivado <2015.4> then open the design in Vivado <2016.3>. Upgrade the design by running "Tools => Report => Report IP Status...", then run write_bd_tcl to create an updated script.
    ERROR: [BD 5-229] Please open or create a block design first.
    ERROR: [Common 17-39] 'get_bd_designs' failed due to earlier errors.

        while executing
        invoked from within
    "set design_name [get_bd_designs]"
        (file "./create_project.tcl" line 106)


    Trying to run the entries in the create_project.tcl one at a time, or one at a time after creating and opening a block design, also failed with similar messages. Is there something obvious I'm missing? Could I get an updated version of the script?

  6. Yeah, I saw a "06/15/2016: fixed usleep delays" in the code's revision changes, but the usleeps were still assumed to be microseconds in length, not milliseconds. Probably just didn't get committed right. I tried manually changing the usleep duration in the Xilinx/Vivado SDK (actually just reskinned Eclipse), but the file system overwrote my changes when I tried to push everything to the FPGA. Is there something special I have to do to fix this myself, or should I just wait for this to get corrected?

  7. I've been trying to run a OLEDRGB display on my Arty, using the sample pMod learnable and Vivado on my new machine. It had worked perfectly on my old machine, but unfortunately on the new machine I'm getting some issues with the clocking - it's running roughly 1000 times slower (I checked) than it actually should be. I get some critical warnings when I try to make a bitstream:

    [Common 17-55] 'get_property' expects at least one object. ["/home/wanderso/Tools/VivadoProjects/ARTY_Display_Attempt_2/ARTY_Display_Attempt_2.srcs/sources_1/bd/system/ip/system_PmodOLEDrgb_0_0/ip/PmodOLEDrgb_axi_quad_spi_0_0/PmodOLEDrgb_axi_quad_spi_0_0_clocks.xdc":51]

    That warning appears in 5 other places as well. Digging a bit deeper, I found this critical warning in the tcl process-

    CRITICAL WARNING: [IP_Flow 19-4965] IP PmodOLEDrgb_axi_quad_spi_0_0 was packaged with board value 'digilentinc.com:zybo:part0:1.0'. Current project's board value is 'digilentinc.com:arty:part0:1.1'. Please update the project settings to match the packaged IP.

    Putting these two things together, I *think* it indicates that the pMod IP files I have are for Zybo, and I'm supposed to have the version for Arty? But I used the most recent board files and ip/ifs from Digilent's github. Could anyone help me with this?