artvvb

Hi @prudhvi The error occurs because the block design needs to have an HDL wrapper created for it, and the HDL wrapper needs to be set as the project's top module. The current top module for your project is the apxbt_v1_0 module. I think only constraining the clock port with the ILA as the only output should be sufficient, but in case Vivado optimizes out the majority of your logic in implementation, consider making some of the output ports external (constraining them to a Pmod interface maybe). Thanks, Arthur

Hi robb, The ethernet interface on the Arty Z7 is connected to a hard ethernet controller in the Zynq PS, rather than the PL, so you won't find it in the constraints. Creating an IPI design, adding the Zynq PS, and configuring it with the default preset from the board files will enable the interface. Digilent doesn't currently have much in the way of dedicated ethernet examples for this board, but you may have luck looking into various "Getting started with Zynq servers" guides, or at some threads on this forum on the topic. https://digilent.com/reference/learn/programmable-logic/tutorials/zybo-getting-started-with-zynq-server/start https://forum.digilent.com/topic/18577-arty-z7-20-using-xilinx-ethernet-example/ These materials are fairly old, but ought to get you moving in the right direction. Thanks, Arthur

Hi @K.K Apologies for the delayed response. The error isn't at runtime, so malloc actually returning NULL (which is usually defined as zero) at runtime is not necessarily what's happening here, but "if flash_env == NULL" is still good advice. Possibly compiler settings were modified between versions to be harsher on something which worked before, which might mean that either a NULL check or an explicit cast of the pointer to an unsigned integer could also help. As a note, Digilent hasn't tested the Zmod library sources in 2022.1 (edit: or 2022.2). Thanks, Arthur

Hi @venkatesh Apologies for the delayed response. Since the repeating pattern seems to be the same length as "Hello World!\r\n", I'm guessing this isn't a baud rate mismatch. Maybe the memory where the value of the string constant is stored in program memory is getting overwritten somehow, but that also seems unlikely. I'd check other uart parameters like stop bits and parity, in addition to confirming the baud rate in the Vivado design. Also, check the clock frequency being fed to the UART controller and Microblaze. When you added the DDR to the block design, how did you clock the rest of your design? Could you share your Vitis code and/or your block design so that we can reproduce the issue? Thanks, Arthur

Hi @zzzhhh Verilog file I/O is not applicable, it's only for use in simulation and for defining the initial states of signals and memories, not for dynamic loading and transfer of files - Verilog describes hardware and doesn't touch anything outside of the FPGA unless you explicitly describe a way to do so. Data transfer between a PC and FPGA hardware can be a big topic, however, for the simplest approach, I'd point to designing a UART receiver, implementing it in the FPGA, and sending data to it using a serial port on the host computer. USBUART hardware on the board provides an interface that lets this controller be relatively simple, and drivers that get installed with Vivado can be used to connect to a serial port from apps like Tera Term (or from stuff like Python with the pyserial module). In addition to the UART controller, you'd also need to design something to convert from the UART's 8-bit data to whatever your LED representation is and to control the LEDs. A project like this is a pretty good early thing for getting your hands dirty. Thanks, Arthur

Hi @Javier, welcome to the forums! Unfortunately, we don't currently provide PDF downloads for most of our online documentation, but it's something we're considering, and your feedback is appreciated. You can also find a lot of in-app documentation in your WaveForms installation, either in the Help tab that pops up when you first launch the app, or in the Help -> Browse menu, see the screenshots below. Thanks, Arthur

Sounds like a cool project, I haven't run across WLED before. It looks like it might be nontrivial to set up, looking through some initial documentation for WLED, it looks like it (at least by default) uses the GPIO36/Sensor_VP pin of the ESP32 for audio input, which isn't wired to any I/O on the Pmod ESP32. Maybe rewrites of the WLED code to accept data from the UART line would be possible, but I'd expect it to substantially drop the achievable data rates. Couple of sources: https://github.com/atuline/WLED/wiki: Default pins used section https://digilent.com/reference/_media/pmod/pmodesp32/pmodesp32_sch.pdf: Sensor_VP is N/C https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf: pin definitions on page 9 One other thing to note is that microphones can require some additional setup over line out audio from a PC:

Hi Paul, Not exactly level- and edge-activated. More that synchronous means "only affects things when the clock transitions" while asynchronous means "can affect stuff whenever", with the caveat that asynchronous signals usually need to be synchronized before use (at least in an FPGA). The clock is treated differently from data lines inside an FPGA, and whether a signal is considered synchronous with a particular clock matters for whether the tools can guarantee that that signal will be used correctly. Thanks, Arthur

Hi Nathan, Digilent doesn't have any materials on using the two Pmods together, other than what you might have found already for using each of them with various different dev kits individually (here are some links for resource centers with documentation for the Pmod ESP32 and the Pmod I2S2). How to proceed really depends on what you're trying to do with them. Couple examples: you might be able to stream audio data from a computer, might be able to play different locally-stored sounds based on commands sent over WiFi, or might be able to configure I2S clock settings or some audio DSP parameters in an audio processing chain through WiFi access. It really depends. Thanks, Arthur

Hi Paul, welcome to the forum, Sounds like clr is a reset signal and the 74x175 is a straightforward DFF. You'd need to be using an if statement to determine the state of the reset signal and choose to clear the register or load it from the input, doing this as logic inside the always block rather than in the sensitivity list. There are a bunch of examples for different types of resets in the link below, both synchronous and asynchronous. Note that Xilinx recommends using synchronous resets if you're actually implementing your design and putting it into an FPGA. https://www.fpga4student.com/2017/02/verilog-code-for-d-flip-flop.html Thanks, Arthur

If you don't include a location constraint, I think Vivado picks one that it thinks would work for timing. This is probably somewhat useful when working on a project for which no PCB or dev board exists yet, and you are just in the early planning stages, but the behavior can be confusing. Constraints limit where Vivado is allowed to place design elements - if you don't tell it it has to place a port in a particular location, it's allowed to place it anywhere. To tell that the constraints are correct, you should check the board schematic and the master XDC file, and compare them to your physical hardware setup. You can also look in the implemented design to find the placement of individual ports, which tells you that Vivado didn't map the port to some other undesired pin. A screenshot is below, where pin U16 is mapped to an output buffer that is connected to an LED. Vivado doesn't know the LED exists except by what it learns from the constraints (or board files if they were used) and top module. Constraints aren't needed for the power rail or ground, since they aren't FPGA signals. For non-Zynq boards like the Nexys, you can tell which signals require location constraints by seeing which signals are present in the master XDC file and are connected to FPGA banks in the schematics. Thanks, Arthur

Hi @cb02, welcome to the forums, To confirm, what changes did you make to the xparameters header? This file shouldn't need to be modified - It describes the IPs that exist in the hardware project. Changes could make things not work correctly, like not being able to find an IP in the memory space after changing its base address definition. The typical process for making changes to a hardware project and bringing them back up to Vivado would be to regenerate the bitstream, reexport the XSA file, then update the platform project's hardware specification, make any necessary software changes to application source, rebuild everything, and run in hardware. The "baremetal update specification" section of this page details this process: https://digilent.com/reference/programmable-logic:guides:using-github-releases#baremetal_update_specification Thanks, Arthur

I'm biased since I work for Digilent, but the Analog Discovery 2 (you also get analog inputs) or Digital Discovery (has higher sample rates and more digital I/O) are both pretty useful for testing this kind of thing. Thanks, Arthur

Hi @Saikot Das Joy Your XDC port names may not match the port names in your generated HDL wrapper. I would expect pin names along the lines of "IIC_0_scl_tri_i". Also, please provide the error messages and any critical warnings that appear when bitstream generation fails. Thanks, Arthur

Hi @Sarah01 Once the BT2 is connected to another device, the host board just uses the UART interface to send data back and forth, it reads incoming bytes and writes outgoing bytes. Bytes written to either Pmods' serial interface should just show up on the others'. Thanks, Arthur

Hi @Devesh Abhyankar Your module is connected to the seven-segment display common anode pins. These pins determine whether each of the digits of the display is illuminated or not - one pin per digit. The cathode pins (CA-CG, plus the decimal point DP) drive the segments of each digit. If you switch out the pins that the module is connected to, to drive the cathodes, I expect that your design should work as intended. If you want to individually address each digit, you will also need additional circuitry to drive the common anodes. Take a look at the seven-segment display section of the reference manual for more info: https://digilent.com/reference/programmable-logic/nexys-a7/reference-manual#seven-segment_display. Thanks, Arthur

You could probably replace one of the files with a link to the other one or to a file outside of the workspace, though you'd still need to do it again whenever the BSP is reset.

Hi @jayfunk I don't have access to an MKR Zero to try to reproduce. The pin connections look pretty much correct to me, but I could also be missing something. Philips format data looks to be the correct choice. Arduino docs make it look like your sample rate will be 8 kHz. Couple ideas: You might check that your serial print output can keep up with the sample rate of the I2S controller - just storing samples in an array to print back later might be necessary. Also, if you have access to a logic analyzer of some kind, using it to look at the I2S frames could be a good idea. Check clock polarities. The transmitter (A/D) should be changing data on the falling edge of the serial clock and the receiver (MKR Zero) should be sampling on the rising edge. The SAM D21 documentation also looks to be a useful source to check the timings involved: https://microchipdeveloper.com/32arm:samd21-i2s-overview. Thanks, Arthur

Hi DH, Further debugging as described would likely be fine with regards to the warranty, however, I'd recommend that you pursue an RMA. You can start the process by filling out the Sales and Order Support form available on the Digilent website here: https://digilent.com/shop/shipping-returns/#return-policy. You can link to this thread to show the Sales and Order Support team that you already worked with us here on the Forum. Thanks, Arthur

Hi @xilinx_pmod123 Check the position of JP4 (relevant reference manual section). Could be either the stored 115200 baud configuration has been changed, or it's in the 9600 baud fallback mode. Thanks, Arthur

Hi @feplooptest, Digilent doesn't provide any specific examples on partial reconfig for any of our boards, however, it's my understanding that pretty much any of them ought to support it - though we haven't done any testing. I haven't run through these tutorials, but Unit 6 and 7 here look promising for using a Zybo Z7: http://www.secs.oakland.edu/~llamocca/EmbSysZynq.html. Thanks, Arthur

Hey, There are a couple of different options: You can potentially instantiate the microblaze HDL wrapper in your own sources - I haven't tried this before and you might run into some unexpected issues, and as you say, potentially lots of inputs and outputs to manage in the HDL. You can edit the generated HDL wrapper (making sure to turn off automatic updates) to instantiate your cores and wire them to ports and microblaze. You can add the top level of your sources to the microblaze block design as an RTL module (right-click on an empty part of the bd and "Add Module"), then wire up some ports and constrain them as before. This is easier than exporting to a custom IP. If you don't have strict requirements, you can control the module's ports from microblaze using various AXI IP like an AXI GPIO or an AXI FIFO (or if you do have stricter requirements, something like DMA, but that's more complex). I personally would tend to prefer #3, but everyone has their own preferences. Thanks, Arthur

Hi @Juan05, If I understand correctly, you'd like to base the size of a Scope acquisition buffer on the size of an AWG buffer that is created using a custom waveform. Based on the SDK manual, the data passed to nodeDataSet is actually interpolated to fill the entire output buffer, rather than using a user-settable custom buffer size. This means that the wavegen frequency passed to nodeFrequencySet should effectively be in Hz and the signal period doesn't depend on the length of the list passed to the DataSet function. - If possible, you might want to use another scope to check that the pulse length is actually as long as intended. So, the analog output buffer has a fixed time that it takes to play out the waveform, defined by the frequency setting. You could just tune the sample rate, number of samples, trigger level, trigger position of the analog input for this time interval. I've attached a modified example (custom.py) that starts to do this. It generates a chain of ten pulses and uses a "tuned" triggered acquisition to capture only one of them. Thanks, Arthur As an aside, I dropped your question into ChatGPT and asked it to explain what the code does, to see if I could get a better understanding quickly, the results are neat:

For using IPI, instructions are in here, you run block automation after adding the Zynq PS to the block design, and make sure the apply preset box is checked: Getting Started with Vivado and Vitis for Baremetal Software Projects Without IPI, it's more complicated, and requires a file that you would need to export from the Zynq config with it loaded in IPI, which is where asmi's suggestion comes from - which we'll consider, I think it's a good idea. Thanks, Arthur

Hey y'all, Make sure you're checking the "Install Cable Drivers" box in the installer (the bottommost option in the screenshot below). This screenshot is from a guide that was produced with Windows 10, but the checkbox is still there in 11 (I also checked with a Windows 11 Pro machine). You can relaunch the installer with the Help -> Add Design Tools or Devices menu option in Vivado. If working correctly, for the Nexys A7, your device should show up in the Device Manager as a couple of USB Serial Converters (A and B) under Universal Serial Bus controllers and a COM port under Ports (COM & LPT). Thanks, Arthur