artvvb

VC707 is an AMD/Xilinx eval kit, I'd recommend trying their forum. Thanks, Arthur

The Nexys A7 clock is single-ended, connected only to E3, and a create_clock constraint is required in the XDC file. I'd recommend using the template XDC file or board files - see these guides to install board files and use them with a Microblaze block design: Installing Vivado, Vitis, and Digilent Board Files, Getting Started with Vivado and Vitis for Baremetal Software Projects. Thanks, Arthur

Digilent doesn't support Petalinux on the Nexys Video or provide a BSP for it. There may be third-party BSPs around on the web, but our ability to provide support for them is limited. Thanks, Arthur

Digilent doesn't support Petalinux on the Nexys Video. Passing this on to a coworker to see if it might be an error they recognize from other projects. Thanks, Arthur

There's dedicated hardware in the FPGA part that is capable of reading the bitstream out of quad SPI flash through a fixed set of pins and putting the bitstream into the fabric, which occurs as long as the programming mode pins on the part are tied off correctly, which is what the programming mode select jumper does. There's a bit more info in the board's manual: https://digilent.com/reference/programmable-logic/cmod-a7/reference-manual#quad-spi_configuration Thanks, Arthur

There's a lot more detail on what the different clocks involved are that can be found in UG586, "Clocking Architecture" starts on page 120: https://docs.xilinx.com/v/u/en-US/ug586_7Series_MIS. As asmi and zygot mentioned, the distinction between the interface data rate (the first clock period spec) and system clock input (second period spec) is critical. That said, I think this is still a mistake in the manual - it should be maximum transfer rate or similar - but am happy to be corrected. You can see the same spec for other boards (Nexys A7 for example) listed with a maximum clock period less than a recommended clock period. The limit is mainly relevant because the allowed selection in the MIG is 3000 ps to 3300 ps instead of 2500 to 3000 ps. There's a warning that pops up for values below the range. See blue text, below. I found the DDR3L Micron datasheet here, for reference: https://www.micron.com/products/dram/ddr3-sdram/part-catalog/mt41k128m16jt-125. Of particular interest are the speed bins tables, table 72 and table 73, CL=5, CWL=5. Thanks, Arthur

Supported versions for different materials are a problem, not sure if there's one specific version that would be best to start with - you might end up with a couple of installations. In general, any guides that you're following steps of are relatively safe to use different versions of the tools with while demos with provided sources (especially the 2019.1 demos, unfortunately, since Vitis was released since) are relatively likely to require a specific version of the tools. For the IPI guide, this older version shows the flow with Xilinx SDK, in the older versions of the tools: https://digilent.com/reference/vivado/getting-started-with-ipi/start Thanks, Arthur

The previously mentioned filter demo should be useful, I'd expect the likely approach to your application would be to use that demo as a baseline and modify it to suit your needs. For best understanding of how the IP used in that design works, which will also tell you a lot about the Zmods themselves, there are IP user guides packaged in the demos and vivado-library source code - right-click on an IP and select "IP Documentation -> Product Guide". This guide is a starting point to learn the design flow if you need to get the processor involved: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi. The steepest part of the learning curve would be if you want to get data into DDR or back to a host PC at any decent speed. The former involves DMA, for which there are various examples, but all of which require a lot of customization for specific applications, and the latter involves USB and ethernet, which there aren't really any good examples for at this time. If your data path stays inside of the FPGA PL, between the Zmod Scope and digital I/Os, that simplifies things a lot. There's also a baremetal software app in this under-construction demo (https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming) that would help extract calibration coefficients from the SYZYGY DNA, which could then be hardcoded into the Scope IP configuration, without needing to load the Linux image. Thanks, Arthur

Hi @latot You should create a testbench for your simulation. This is another Verilog module that will be the top level of the design in the Simulation Sources and will be responsible for generating the clock signal and any other inputs to the design. A basic testbench module for your module might look like the following: module testbench (); reg clk = 0; always #1 clk = ~clk; wire led; blinky dut ( .CLK100MHZ(clk), .led(led) ); endmodule Thanks, Arthur

The Nexys 4 doesn't have dedicated built-in DAC components. You could get an additional module like a Pmod DA4 or R2R that produces analog output and connects to a Pmod header, or you could create your own, using something like a resistor ladder DAC. Depending on your project, one of the VGA color output pins could be used as a 4-bit 0-3.3V DAC, though taking care with output impedance would be important. Thanks, Arthur

Some form of JTAG controller is necessary inside the FPGA, if you're trying to implement a controller in verilog, then this would be what you would be debugging. Alternatively, setting up a microblaze debug module with external BSCAN could potentially let you look at JTAG signals. Instantiating a BSCANE2 primitive would be necessary in either case to gain access to the JTAG pins. Analog Discovery 2 would likely only be helpful insofar as it would be able to decode JTAG transactions, taking the place of the ILA. Thanks, Arthur

Digilent has made the business decision to not publish the pages of our devices' schematics covering JTAG programming circuitry. You can read more about it on other similar Forum threads such as this one here:

Hi @Xband, welcome to the forums. Apologies for the delayed response. This is the right place to ask. The application sounds like Eclypse would be a reasonable fit, although the amount of work/time required will depend heavily on how familiar you are with FPGAs and Vivado, and on the specifics of your application. Provided demo projects are fairly limited, implementing basic acquisition systems in one case, and a filter passthrough in another. The latter might be a good place to start for your application, cutting the AWG output path for digital signals through the Pmod ports. The requirements on the digital logic signals could also present a problem: do not expect to easily be running fast signals through Pmod ports (maybe 20+ MHz, some users here have posted test data for other boards). Digilent doesn't specify how fast they can be run. Thanks, Arthur

Hi @mahinay Are you trying to package everything in that hierarchy into one IP? There would be a fair amount of difficulty in doing that, since that IP would also then be responsible for providing all drivers and everything else to the Vitis platform, for example. If you are trying to package everything so that it is relatively easy to recreate a portion of a design in another Vivado project, I would recommend looking into the write_bd_tcl command with the -hier_blks argument. It will generate a script that can be used to recreate your blocks in another block design. https://docs.xilinx.com/r/2020.2-English/ug835-vivado-tcl-commands/write_bd_tcl Thanks, Arthur

Hi @FPGAtor Yes, you can use the flash without Microblaze. See here: https://digilent.com/reference/learn/programmable-logic/tutorials/cmod-a7-programming-guide/start A project only needs to implement an SPI controller if you want to access SPI flash after the bitstream is loaded. Microblaze requires this in order to fetch the stored program using a bootloader. If you just want to store a bitstream in flash and don't need other data, you can use the Hardware Manager, as in the link above. Storing other application data is also possible, but may require writing data into flash with another bitstream, or somehow adding your own data to the end of the bin file, or similar. It would usually be easier to bake data into the bitstream, if there's room. Thanks, Arthur

Hi @Francesco Crevatin, Yes, you can decode buses to hex or ASCII, or several other formats, with just the base WaveForms application. Decoded values can also be used to trigger acquisitions. This also works with protocols in the logic analyzer instrument, so that you can view decoded values alongside the samples: Thanks, Arthur

I don't see anything in particular wrong with the testbench file. Make sure that all of the registers inside the DUT are getting initial values, either in-line with their declaration or in initial statements - uninitialized registers work fine in actual fabric (the actual initial state ought to default to zero), but the simulator can't interpret them and displays value "X" (or "Z"). Constraints can't be used to change physical properties of signals, they instead describe what exists on the board - the actual oscillator on the board has a fixed 125 MHz frequency. To get a 100 MHz clock from the 125 MHz system clock, you would typically use clocking hardware in the FPGA like MMCMs/PLLs, which you can instantiate with a Clocking Wizard IP. I'd just start by using the 125 MHz clock directly. Vitis is also free. Both it and Vivado get installed if you pick the "Vitis" option in the installer - you likely picked the "Vivado" option, which only installs Vivado. You can rerun the installer by going through Help -> Add Design Tools and Devices in Vivado. That said, skipping Vitis makes perfect sense.

Hi @mnorth Could you provide more detail about what you're trying to do? If you're trying to simulate a module written in Verilog, there shouldn't be anything fancy required for Zynq, all stimulus signals including the clock should be generated in the testbench. You'd still just be simulating that Verilog module rather than the whole Zynq system. If you're trying to clock a design that uses the PL without the Zynq PS, you should likely either 1. use Vitis to run some simple software app, to ensure that the FCLK is running correctly, or 2. use the 125 MHz system clock to clock your design instead of an FCLK, as it is routed directly into PL pins. Thanks, Arthur

Hi @SnaumTG Digilent hasn't tested with the Pi 400, but I don't see a reason it wouldn't work. The Pi 4 is compatible, see here: https://digilent.com/reference/test-and-measurement/guides/getting-started-with-raspberry-pi Thanks, Arthur

The proposed fix for moving the Demo declaration to the C file worked for me in 2022.2. Please make sure that the Demo.verbose bit is set, and what error messages are you seeing? (added the 2022.2 text as the only other change to ensure I was running the right project) It's possible that an IP minor version change in the I2C controller could be affecting things, but the changes between rev 2.0 and 2.1 of AXI IIC appear to be pretty small. To check possible differences, what revision of the board do you have (mine's a new rev F), and have you successfully run the demo in 2018.2? Thanks, Arthur

Hi @RAJAT99, I was able to get the project set up in Vivado 2018.2 using the release files as described in the readme, without encountering errors, and managed to record audio from line in and play it back over hph out. What version of the tools are you using, and what are the specific errors you encountered? Thanks, Arthur

The oldest version of the Zedboard board files I can find on our Github specifies revision D.3: https://github.com/Digilent/vivado-boards/tree/9926feb0998c04eb82fdf30883f2ebbf20a2dfd8. These may still work for the Rev B, but I can't confirm. Some of the older support materials for the Zedboard can also be found here: https://github.com/Digilent/Zedboard-old, can't tell which rev it targets, but the DMA demo in there also has Zynq settings. Apologies to not be of more help, Arthur

Microblaze doesn't have a built-in counter by default - it implements sleep functions in software, using instructions with known durations, for example. You could use an AXI Timer/Counter and the xtmrctr driver. xtime_l looks to be a Zynq-7000-specific driver and uses the built-in hardware timer featured by the A9 processor, I don't know why it might be showing up in a Microblaze BSP. Thanks, Arthur

Hi @biosbob FPGA logic, such as the mentioned Quad SPI IP, is required to access the flash. As I understand it, the way that Vivado writes to flash via JTAG is actually by putting a pregenerated bitstream into the FPGA that creates a bridge between the JTAG circuitry and the flash's SPI interface. Thanks, Arthur

Not much to add to what Zygot has already said, it's spot on. Digilent's applications and support team is pretty small - we're doing what we can. That said, the frustration is heard. For debugging the UART connection, I've attached a couple of python scripts, and a modified version of the source. There could be additional libraries to install off of a baseline python installation, but pyserial and numpy are both common. For using either, start the Vitis app first, it should be sitting in the recv while loop when the host is sending characters. The first one connects to the serial port and dumps out imageSize characters, and checks a returned checksum. The second one generates a file full of random 0-9 characters which can be dumped through teraterm, where you can see a returned checksum and whether there were UartLite overruns. Worked with no loss on my machine at 10k bytes, but your mileage may vary. import serial import numpy as np imageSize = 10000 with serial.Serial('COM13', 9600) as ser: buffer = [x & 0xFF for x in range(imageSize)] s = ser.write(buffer) line = ser.readline() if (np.sum(buffer) & 0xFF) != int(line[0:2], 16): print("checksum mismatch") else: print("all good") import numpy as np imageSize=10000 with open("./file.txt", "w") as out: buffer = [] for x in np.random.randint(0, 10, imageSize): buffer.append(x + ord('0')) for c in buffer: s = out.write(chr(c)) checksum = np.sum(buffer) & 0xFF print(f'checksum: {hex(checksum)}') #include "xparameters.h" #include "xuartlite.h" #include "stdlib.h" #include "xil_printf.h" const u32 imageSize = 10000; int main() { u8 *imageData; u32 receivedBytes, totalReceivedBytes=0, sentBytes, totalSentBytes=0; XUartLite_Config *myUartConfig; XUartLite myUart; u32 status; imageData = malloc(imageSize); myUartConfig = XUartLite_LookupConfig(XPAR_AXI_UARTLITE_0_DEVICE_ID); status = XUartLite_CfgInitialize(&myUart, myUartConfig, myUartConfig->RegBaseAddr); // start python script after starting app while (totalReceivedBytes<imageSize) { receivedBytes = XUartLite_Recv(&myUart, imageData+totalReceivedBytes, 1); totalReceivedBytes += receivedBytes; } u8 checksum = 0; for (u32 i = 0; i < imageSize; i++) { checksum += imageData[i]; } xil_printf("%02x\r\n", checksum); XUartLite_Stats stats; XUartLite_GetStats(&myUart, &stats); if (stats.ReceiveOverrunErrors > 0) { xil_printf("%d overrun errors\r\n", stats.ReceiveOverrunErrors); } }