artvvb

Technical Forum Moderator
  • Content Count

    342
  • Joined

  • Last visited

2 Followers

About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @Aditya Shandilya, You probably need some kind of serial interface connecting the Arduino and fpga so that the Arduino can issue commands and send data to the fpga and for the fpga to return data. UART or SPI would be fairly typical. Thanks, Arthur
  2. The syncs and pixel data might be misaligned, depending on the constants used in the compares. There are a different number of register stages in the sync and color data paths, and a redundant extra output stage. Data arrives from the counters (through combi logic in the case of the sync data path) to the first set of registers "at the same time", assuming that timing is met. Refer to the attached screenshot of the RTL analysis schematic view in Vivado. Thanks, Arthur
  3. Hi @engi Have you tried another monitor and/or VGA cable? Edit: I highly doubt this is a power issue. Your design is quite small, and the Pmod VGA does not provide any power to the monitor. The iostandards for all banks relevant to the design are applied in the xdc file and all of the power rails on the Arty run at fixed voltages. -Arthur
  4. Hi @wolfgang6444and @engi The A0/A1 pins are connected to XADC channels 4 and 5 rather than channels 0 and 1 (edited). The mapping between the XADC channels and the arduino header pins can be seen in the master XDC file on github (here is line 120 of the 100T XDC). You can also see the mapping in the board's XADC demo: https://digilent.com/reference/programmable-logic/arty-a7/demos/xadc. You ought to be able to confirm this is the case with your current design by taking a measurement through the A5 pin, which is connected to aux channel 0. I'm looking into getting this clarification
  5. Hi @ilovefpga, Pmod port JF is connected to the Zynq PS and is controlled via the xgpiops driver, as you have seen. The other Pmod ports are all connected to the Zynq PL and need to be controlled through the FPGA fabric and constrained in an xdc, as you have seen. If you use an AXI GPIO or Pmod GPIO IP core (as seen in the thread you linked), you need to use the xgpio drivers (written for the PL IP) instead of the xgpiops drivers. Alternatively, you could configure the Zynq PS to provide an 8-bit GPIO EMIO interface, make that interface external, and constrain it in the xdc. The EMIO opti
  6. Hi @GlenW, Yes, the Eclypse follows the SYZYGY mechanical specifications for double-wide standard pods. Thanks, Arthur
  7. Hi @NithinA From software, short of decimating/averaging data captured at 100 MS/s down to some lower sample rate, there is not. It may be possible to reduce the clock frequencies in hardware, however we don't have an example or documentation detailing this, and the effectiveness of the calibration may be affected. The latest hardware-only demo release (https://digilent.com/reference/programmable-logic/eclypse-z7/demos/low-level-low-pass-filter) works with the ADC 1410 and runs it at 40 MS/s with a new release of the Zmod IPs, but these are incompatible with the currently-released AXI con
  8. Hi @msamirh You will need to use the XADC wizard IP to configure the XADC and get an interface to pull data from it - likely a DRP interface if you don't want to use the Zynq PS. For a starting point to see how this works, I'd recommend checking out the Zybo Z7's xadc demo: https://digilent.com/reference/programmable-logic/zybo-z7/demos/xadc Thanks, Arthur
  9. Hi @Nico89 The Pmod CAN IP encapsulates Xilinx's AXI QSPI IP and AXI GPIO IPs (looks like versions 3.2 and 2.0, respectively, in the latest vivado-library release). Each of it's AXI interfaces connects to these and provides direct access to one of these IP's register spaces. The AXI GPIO is connected to the bottom row of the Pmod connector, to provide software interrupts and the ability to trigger a reset. The Pmod IP is intended to be used through C code and the software drivers provided with the IP - the drivers for the encapsulated Xilinx IP are wrapped by an additional software layer
  10. Hi @skinnypanda Take a look at the "Language Templates" menu in the tool. There's both some example code for inferring BRAMs as well as some templates for instantiating BRAM primitives directly. Thanks, Arthur
  11. The voltage provided by a microphone tends to be quite low. You could potentially amplify the signal before it reaches the I2S2, multiply it up in the FPGA (resulting in a poor quality signal, since you are only effectively using the lowest couple of bits), or try out your project with a cable connected to a computer's audio out. I'd recommend the latter if you happen to have a 3.5mm-3.5mm cable lying around. Getting a bunch of samples dumped into block RAM and then potentially out over UART or into the ILA in a burst could be a good way of looking at more than just one sample at a time.
  12. @Jan Kager It looks like the constraints for the top and bottom row of the Pmod port are swapped. I don't have a Pmod I2S2 to test with at the moment, but was able to get the transceiver core running with your constraints and a Pmod I2S (which uses the same CS4344 chip used in the I2S2's line-out) connected to the bottom row of port JA. I've attached the Verilog module I used to generate the audio output data for testing, as well as a screenshot of the block design. Please also check that your MST/SLV jumper is in the SLV position, since the transceiver core generates the clocks for
  13. Hi @rmccormack1 Something in the project is misconfigured. Undefined reference to main implies that either the "int main (void)" pattern of the definition isn't the one that the tools are looking for - maybe the application was created using a C++ template, or some other template that doesn't work for your code. It's also possible that the source file isn't in a directory that the tools are looking in for sources. Console logs and/or a project archive would help me to figure out what exactly is going on. Thanks, Arthur
  14. Hi @rmccormack1 This error message means that the project's build outputs don't exist; either the project hasn't been built, or it failed to build. The processor exists (probably), but the file that its supposed to run doesn't exist. Either way, there is nothing to be run on the device. If you can provide either the Vitis console logs or an exported ZIP archive of the project, I might be able to determine why the required ELF file is missing. Thanks, Arthur
  15. Hi @rmccormack1, Can you export your projects to a ZIP file and post it here? Errors that appear as makefile errors like this one may indicate that something in the board support package is failing to build properly, which would imply either a problem with the Vivado project and XSA, or with the configuration of one the software projects. It could be missing stdin, or it could be one of a couple other potential issues not directly related to the posted source code. Alternatively it might be down to xil_printf.h not being included, though I haven't managed to reproduce your error mess