artvvb
-
Posts
1,067 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Everything posted by artvvb
-
Digilent doesn't currently provide mechanical dimensions for the faceplate directly, but I reached out internally to request them. If you haven't yet, please also review the Zmod and Eclypse mechanical diagrams, as they should help with some of the required dimensions: https://digilent.com/reference/programmable-logic/eclypse-z7/start#additional_resources https://digilent.com/reference/zmod/scope/start#additional_resources https://digilent.com/reference/zmod/awg/start#additional_resources Thanks, Arthur
-
Yes, that's correct.
-
Both need to be enabled simultaneously for data to flow through the AXI stream interface. There is a small FIFO in the data path, but if both of these signals are high, at least some data should be moving. If ready is held low and enable is held high, I would expect that the overflow pin would assert. So I would recommend tying both of these pins off to '1', at least until you have something working. A scenario that could cause all zeroes to be read is if external calibration coefficients aren't disabled or connected to anything (and thus tied off to zeroes) and test mode is not used to bypass calibration. This would cause all incoming data to be multiplied by zero. If this is happening, disabling external calibration coefficients in the Scope controller would solve it.
-
With the jumper disconnected, C18 is functionally just another button input to the FPGA, it's not tied to any circuitry that resets the FPGA itself or the power supply. The jumper just connects an FTDI output pin to the same FPGA input as the button. User designs need to connect the input to logic inside the FPGA - it's just intended to reset soft-core processors. If pin 3 of the ethernet shield's power header accepts an active low reset, the button might already just work to trigger a reset without affecting the Arty.
-
Hi @Fadi Both CCLK_0 and EMCCLK are connected to the QSPI SCK pin. E9 is used during boot, while L16 can be used after a bitstream has been programmed in to access Flash without using special primitives. Quoting the manual's QSPI section: Thanks, Arthur
-
decutil for bare metal applications?
artvvb replied to connoisseur_de_mimi's question in Add-on Boards
Hi @connoisseur_de_mimi See example code here: https://github.com/Digilent/Eclypse-Z7-SW/blob/b42fb15a8ab4c52a38db2c15918cd7263e84f65e/src/calibration_reader/src/main.c Thanks, Arthur -
It depends on how you want to store data - if you want to grab and manipulate a frame in DDR, since the frames are already moving through DDR, this is possible with minor software changes only. You could also potentially dump image data out to an external application for further processing using UART (which would be slow) or ethernet. Writing an image from DDR to a file system, on, for example, an SD card, would also be possible - it requires having software access to the file system, which could potentially be done using additional libraries in baremetal, or by replicating the entire system using PetaLinux. Thanks, ARthur
-
Digilent doesn't provide a verilog-only HDMI example. The IPs relied on by this and other examples were developed using VHDL. Thanks, Arthur
-
Hi @connoisseur_de_mimi Yeah, the issue is likely that it's a differential buffer. Manual instantiation of the IO buffers isn't necessary. You could just make the entire I2C interface external and constrain the two pins. Vivado will automatically add tristate buffers as appropriate. You can also add pullups through an XDC file with "pullup true" constraints like here: Also, port names for the below screenshot would be "IIC_0_scl_io" and "IIC_0_sda_io". Thanks, Arthur
- 2 replies
-
- 1
-
-
- vivado
- eclypse-z7
- (and 3 more)
-
Yep, the Zybo Z7 doesn't have an I2C EEPROM, inside the FPGA chip or otherwise. If you want EEPROM functionality that isn't based on I2C, look at the QSPI flash. If you need it to be I2C, look for external modules you can connect.
-
For a start on ethernet, check out this guide for using TCP with Zynq: https://digilent.com/reference/programmable-logic/guides/zynq-servers. That said, 100 MBps is likely too much data for this setup, I'm not certain. In addition to the LwIP example, Xilinx also provides some examples for checking performance. AXI ethernet is not required - it's for interfacing with PHYs that are connected to the PL, whereas the Arty Z7 makes use of the PS ethernet controller, which is enabled by default in the Zynq config. As for interfacing between PL and PS, there are many ways of going about it, depending on throughput requirements. Connecting the IOs of an RTL module to Zynq EMIO pins or an AXI GPIO would be an easy first step, but both have significant data throughput limitations. Creating an AXI interface for the frequency counter is an option, but would be a lot for a beginner. Putting data into an AXI stream interface which forwards data to DDR via an AXI DMA would be the most straightforward solution if you need to move a lot of data, or move data nearly every clock cycle, but again, there's quite a bit involved - DMA audio demos for other Zynq boards, like this one, might be a decent starting point, but would still require quite a bit of learning to implement. Thanks, Arthur
-
Responded over in another thread, but the gist is that we're unfortunately not able to help much. The SiFive repo that the guide depends on was archived back in 2021, so they may not be much help either.
-
Hi @shreyash Unfortunately, we can't provide much support for this guide anymore - the sources it clones from were archived as read-only by the third party who created it some time ago. We're looking at either taking down the guide or strengthening the warnings at the top so that others don't run into the same issues you have. Apologies, Arthur
-
ZedBoard Zynq-7000 Custom Porting
artvvb replied to Sunny's topic in Technical Based Off-Topic Discussions
Unfortunately, Digilent generally doesn't provide this kind of consulting service. Thanks, Arthur -
Hi @Stefanski881, Interesting. Does the design meet timing? An intermittent failure like this might mean that data doesn't have enough time to make it to the next register. Any related critical warnings and warnings would be helpful. There are likely various small optimizations that could help. Thanks, Arthur
-
Hi @tew, Apologies for the delay, I reached out to our manufacturing folks and they indicated that the electrical contacts are copper and the plastic is polypropylene. Thanks, Arthur
-
These connections look plausible for a PS-PS loopback, but the AXI IIC is fundamentally a peripheral of the processor, and the processor is still controlling it. How is your EEPROM instantiated in the FPGA, would it be controlling the AXI IIC S_AXI interface? At that point, it would just be easier to implement an AXI slave that the processor can use to read data from the EEPROM. The EEPROM ought to either be written in HDL and added as an RTL module, or encapsulated in an IP. It could have an I2C interface and connect to IIC_1 on the PS block, but it needs to be represented in the project first.
-
Oh - that's the HDMI input DDC, not the output. If using that connection, the AXI IIC needs to act as an I2C slave that can provide EDID information to computers connecting to the board, instead of as a master on the bus. Please confirm what physical connection you are trying to make between the board and the outside world. Thanks, Arthur
-
It looks like HDMI DDC interfaces use one of a couple of different fixed slave addresses, depending on the version of the standard that the particular display implements: https://en.wikipedia.org/wiki/Display_Data_Channel. The block design is likely functional, but I'd need some configuration settings from the IIC IP and maybe Zynq PS to confirm. Constraints also matter, presumably the DDC interface is connected to the correct pins on the HDMI source/TX port. If possible, archiving the entire Vivado project would be ideal. See the attached screenshot That particular IIC software example writes to an EEPROM and reads back to verify. You definitely don't want to be writing to the monitor's EDID. Look for something that only reads. Thanks, Arthur
-
Hi @Niranjana Please review the section of the reference manual on QSPI flash: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#quad-spi_flash This memory can be used both for boot and for user data. Thanks, Arthur
-
Hi @oldViking Yes, providing clocks, resets, and some logic to control the XADC DRP interface is required from the user. Digilent doesn't provide VHDL for it, but you can see equivalent Verilog in this demo: https://digilent.com/reference/programmable-logic/arty-s7/demos/xadc. The source for the top module is here: https://github.com/Digilent/Arty-S7-HW/blob/9904101ccd8f35003e4a6760a2d500f814d21b73/src/hdl/XADCdemo.v. In the case of this demo the reset is tied low. Thanks, Arthur
-
Hey Bill, Zynq-7000 is little endian, so the first byte in memory is treated as the least in a u32. The best way to fix it would just be to declare the data to be transferred as the same width you are using in the QSPI, so "u32 buffer[1] = {0xDEADBEEF};". Note that you can see the same effect happen if you print the u8 buffer after casting to a u32 pointer: "xil_printf("status: %08x\r\n", *(u32*)buffer);". Best guess, an 8 MHz sampling rate is insufficient. Run the analyzer faster, and potentially at an integer multiple of the SCLK frequency. At least 4x or ideally 10x the signal's 3.125 MHz. Thanks, Arthur (Edited an incorrect code snippet)
-
The Zynq preset included in the board files includes all necessary DDR configuration settings, clock settings for the PS, and MIOs. It's applied when you run block automation with the board files installed. This preset is also applied in both of the demos linked previously, one of them could be adapted with different PL IP and constraints modified as needed. Some changes to the Zynq config may be necessary depending on the specifics of the project, like enabling the AXI HP slave ports or setting different FCLK frequencies - AXI HP ports would be necessary for PL access to DDR through DMA, for example.
-
Yes, I have an AD3 hooked up to some Pmod pins with a different FPGA board - there aren't any fundamental differences between 7-series boards that would affect the IP in this case. This is what a single-shot capture looks like, using the code I sent previously, triggering on protocol start (chip select falling edge). Works on the first pass, using the Vitis debugger to step through the code and only perform one transfer. I don't have personal experience with Saleae devices, so I'm not certain how it is decoding the data, or how it triggers, but make sure that the SPI mode it uses to decode the protocol matches your expectations. Mode is configured in AXI QSPI by setting the XSP_CLK_ACTIVE_LOW_OPTION and XSP_CLK_PHASE_1_OPTION bits via XSpi_SetOptions. By default, clock is active high, and the slave should sample on the rising edge, so SPI mode 0.
-
Hi Omer, Please refer to https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope or https://digilent.com/reference/programmable-logic/eclypse-z7/demos/oob. Thanks, Arthur
