Jump to content

artvvb

Technical Forum Moderator
  • Posts

    985
  • Joined

  • Last visited

Community Answers

  1. artvvb's post in PCAM interfacing with zedboard was marked as the answer   
    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
  2. artvvb's post in Zmod Faceplate mechanical drawings was marked as the answer   
    Hi @connoisseur_de_mimi
    An STP file for the enclosure kit is now available here: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse_Z7_Enclosure.stp
    Thanks,
    Arthur
  3. artvvb's post in Basys3 7 segment lights up with no apparent reason. was marked as the answer   
    Hi @Anthocyanina,
    The same seven-segment behavior can be seen here:
    The config voltage warnings are unrelated, but you could include the following lines from the Basys 3 template XDC file for completeness:
    Thanks,
    Arthur
  4. artvvb's post in decutil for bare metal applications? was marked as the answer   
    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
  5. artvvb's post in What VHDL code is needed to operate the XADC after configuring the wizard was marked as the answer   
    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
  6. artvvb's post in [BD 41-238] Port/Pin property POLARITY does not match between /clk_wiz/reset(ACTIVE_HIGH) and /processing_system7_0/FCLK_RESET0_N(ACTIVE_LOW) was marked as the answer   
    Hi @Xband
    I gather from other threads that the particular connection here is from Zynq FCLK0_resetn to a clocking wizard reset input. There are a couple of options for handling the reset polarity after it enters PL:
    1. The utility vector logic IP can be used to implement a one-bit not gate for the reset. Vivado will automatically use this IP to invert the polarity of an external reset if the reset polarity param in a clocking wizard preset associated with an external system clock doesn't match the reset's polarity. Vivado doesn't automatically do the same for Zynq reset pins, but it could be inserted manually.

    2. The processor system reset IP, usually added by connection automation to ensure proper timing of resets for interconnects and peripherals, provides polarity settings that let it invert all of its inputs and outputs.

    3. Easiest, in my opinion: The clocking wizard reset polarity can be configured.

    It's also worth pointing out that many of the other IP in your design (all of the AXI stuff, for example) will require active low resets.
    The issue you are looking at from AMD support is only relevant if you're trying to use the device without any software running in PS. Is this the case?
    Thanks,
    Arthur
  7. artvvb's post in Zmod Scope Calibration and Sample conversion was marked as the answer   
    Hi @Stefanski881
    Per the calibration section (on page nine) of the ZmodScopeController manual:
    This means that data passed through into the DMA is effectively the full 16 bits, instead of just the lowest 14. The same shift is applied in test mode, where the incoming raw data is padded with two zero bits at the bottom of the vector. In both cases, this means the 14 bits you want to treat as the sample are the top 14 of your `number` variable, not the bottom 14.
    There's a baremetal application in this under construction demo that uses dpmutil to read calibration coefficients out of DNA, which may also be helpful: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming
    Thanks,
    Arthur
  8. artvvb's post in A couple of questions regarding Arty A7 was marked as the answer   
    This has been cut from the page, thanks for the report. We've also removed the same incorrect feature callout from the USB104 A7 page. The I/O slices entry has also been cut from both, as it was a meaningless spec when looking at an FPGA board with all of the I/O pins routed (or not) to specific peripherals. They were likely due to a misreading of the 7-series product selection guide (https://docs.xilinx.com/v/u/en-US/7-series-product-selection-guide).
    As for the first question, I'm not sure and have passed it on to a coworker who might know more.
    Cheers,
    Arthur
  9. artvvb's post in Save Baremetal Software Projects to Flash Tutorial was marked as the answer   
    Check the linker script in the Vitis project source files, lscript.ld. Memory regions for each executable section can be assigned there. It will list either MIG or local memory for each section, if local memory is selected for all, should be good.
    In addition to associating the elf, the Vivado project needs to enable the Master SPI x4 programming mode in order to boot directly on power-up. I think currently, without it enabled, you can still boot the project by pressing the PROG button. See steps 2.3 - 2.7 here: https://digilent.com/reference/learn/programmable-logic/tutorials/arty-programming-guide/start - the guide is written for an older board and older versions of the tools, however, the process is largely the same in recent versions.
    Thanks,
    Arthur
     
  10. artvvb's post in PMOD maxsonar was marked as the answer   
    Hi @Stanislav, welcome to the forum!
    ASCII character 13 in this case refers to the carriage return character '\r', rather than the string "13". The most significant digit should be transmitted first so that a straightforward UART passthrough to a serial console prints the data in human-readable form.
    Thanks,
    Arthur
  11. artvvb's post in Zybo Z7 20 DDR change to Zentel was marked as the answer   
    Hey @fenixzhang,
    The Zentel and Micron parts are effectively drop-in replacements that don't require any changes to Vivado projects, so you can use existing materials like the Zynq preset in the board files as-is. That either part might be loaded isn't mentioned in the reference manual and we'll be sure to add some text to call it out. Apologies for the confusion.
    Thanks,
    Arthur
  12. artvvb's post in Yet again Waveforms is download is broken (albeit eventually works) was marked as the answer   
    Hi @matterbury
    Thanks for the feedback, I've passed it on to our web team.
    -Arthur
  13. artvvb's post in Pmod AD1 IP on cora-Z7-10 was marked as the answer   
    Hi @K.K
    Whether the IPs work depends on which version of Vivado you're in. At least in 2021.1, it looks like you can just make the Pmod_out port of the IP external and manually create some constraints for it (like below) and get a bitstream, rather than using the board tab automation. The latest vivado-library sources still get the drivers into Vitis, and are compilable, but this hasn't been tested with many recent versions of the tools.
    Additionally, at least in the case of this specific Pmod, you can pull sources out of the IP core to use them separately in a design. The modules copied out can be added to a block design through the "Add Module" function and wired up - still need to make ports external and manually write constraints.
    Thanks,
    Arthur

  14. artvvb's post in Arty s7-50 won't connect to PC and Vivado ML Standard via micro usb was marked as the answer   
    Hi @jglodde
    Welcome to the forums!
    Drivers are installed when you install Vivado, through a fairly easy-to-miss checkbox. See the fourth screenshot ("This screen provides more detailed options for the customization of the installation.") here: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis
    You can relaunch the installer via the Help -> Add Design Tools and Devices menu in Vivado.
    If the USB cable you are using is one that didn't come with the Arty S7, it might not be capable of delivering data. Some charging cables that ship with cell phones are like this. Try another cable or check the cable with another device.
    Thanks,
    Arthur
  15. artvvb's post in I think the MOSI and MISO signals incorrect in the in the Board Files for the ADXL362 on the Nexys-A7 100T was marked as the answer   
    Welcome to the forums!
    Good catch, the issue has now been corrected in version 1.3 of the board files. Here's a link to the updated version of the board.xml file: https://github.com/Digilent/vivado-boards/blob/master/new/board_files/nexys-a7-100t/D.0/1.3/board.xml
    Thanks!
    Arthur
     
  16. artvvb's post in Can't find vivado project file for Zybo-Z7-HW was marked as the answer   
    Hi stevers,
    Yes, the names of the checkout and checkin scripts were shortened. Functionality should not be affected.
    Thanks,
    Arthur
  17. artvvb's post in Pmod AD1 was marked as the answer   
    Yes, as long as you are using make external, you need to use two AD1 modules to control two Pmod AD1s, and you are able to constrain the each module's ports to the pins of a single Pmod port. The Pmod pins you use for each port in this case are arbitrary - you can map whatever module port to whatever physical location using the XDC - so top row and bottom row is doable.
    Thanks,
    Arthur
  18. artvvb's post in Fan was marked as the answer   
    Hi @Udayan Mallik
    The code block below is a snippet of the comment header that goes with the function definition of dpmutilSetFanConfig in dpmutil.c (pulled from here: https://github.com/Digilent/dpmutil/blob/master/dpmutil.c).
    More information about the specific capabilities of the Eclypse's PMCU can be found in the PMCU specification: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf
    ** Description: ** Modify one or more field of the Platform MCU (PMCU) ** FAN_n_CONFIGURATION register. The FAN_n_CONFIGURATION register is ** used to specify the settings of the associated fan. This may include ** the enable state of the fan, the fan's speed, and the associated ** temperature probe. Please note that not all fan ports support ** enable/disable, fixed speed control, or automatic speed control ** (temperature based). Changes to a FAN_n_CONFIGURATION register ** will be restricted to the be within the supported capabilities of ** the port and take effect immediately after the register is written. ** Additionally, the FAN configuration is written to EEPROM and will ** restored each time the PMCU is reset or power cycled. ** ** The "fanid <0...3>" parameter must be used to specify ID of the ** fan configuration to be modified. ** ** The "enable <fTrue,fFalse>" parameter can be used to enable or disable the ** associated fan. ** ** The "speed <0...3>" parameter can be used to specify the speed of ** the associated fan. Please note that not all fans support this ** functionality and some ports that do support this functionality ** may not support automatic fan speed control. ** 0 - minimum ** 1 - medium ** 2 - maximum ** 3 - auto ** ** The "-probe <0...4>" parameter can be used to specify the ** temperature probe associated with a fan if that fan supports automatic ** speed control. ** 0 - none ** 1...4 - probe[1...4]  
    Thanks,
    Arthur
  19. artvvb's post in Eclypse Z7 Trigger on ZMOD was marked as the answer   
    Hi @orenderj
    The intended case would be to be able to use LevelTriggerAcquisition (&Pipe, GainTestRelays, 0b00010, 0x0000, dont_care);, as an example, to trigger an acquisition on a rising 0 V level on channel 1. The third argument, the trigger enables, is used to mask out unwanted triggers in hardware, so the manual trigger shouldn't be happening when it's disabled - I'm currently investigating this.
    There is currently a bug where the trigger generator incorrectly treats the stream data bits 0 to 15 as channel 1 and bits 16 to 31 as channel 2 instead of vice versa. I'm working on fixing this in hardware. A software workaround should be to switch the trigger enable bits and trigger levels being passed to LevelTriggerAcquisition.
    The trigger enables are ordered as follows:
    bit 0: manual bit 1: ch1 rising bit 2: ch1 falling bit 3: ch2 rising bit 4: ch2 falling Note the level triggers use a signed comparison to check whether the level is between two consecutive samples (or equal to the most recent sample). A code snippet from the sources: `ch1_rising  = (ch1 >= ch1_level) && (ch1_prev < ch1_level)`.
    In the meantime, I've added some state diagrams here which may help to explain the mechanism: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/eclypse_platform_manual#trigger_detector
    In terms of when to set configuration regs, assert start, and wait for idle, the main thing is to start the detector last of all the modules in the input pipeline, since it acts as a final gate in front of the DMA. In general, set the config regs for the entire pipeline, start up the stuff upstream of the trigger detector, start the DMA transfer, start the detector. Then, wait for the trigger to fire, indicated by the DMA transfer completing and the detector going idle. Also, the "trigger enable"s should be considered config regs for these purposes.
    Thanks,
    Arthur
  20. artvvb's post in zybo DAC through mcp4725 was marked as the answer   
    Hi @suung33
    You need to modify the data being sent to the device. Currently, in the posted code, a 132-byte-long buffer filled with the sequence 0,1,2,3,... is being sent. You should refer to the I2C Serial Interface Communication section of the MCP4725 datasheet to determine what bytes you should be sending (https://www.microchip.com/en-us/product/MCP4725). Both the buffer contents should be changed to match whatever you need to send to the device and the buffer size argument passed the XIicPs_MasterSendPolled function should be modified to match the number of bytes you want to send. For example, from an initial skim of the datasheet, a general call reset should be able to be issued with the following snippet (though I haven't tested it), which sends two bytes, a 0x0 followed by a 0x6.
    u8 SendBuf[2]; SendBuf[0] = 0; SendBuf[1] = 0x6; XIicPs_MasterSendPolled(&Iic, SendBuf, 2, IIC_SLAVE_ADDR); Arduino sources can't be run directly on the Zybo, but you might use those projects to figure out what bytes you should be sending and receiving.
    Thanks,
    Arthur
  21. artvvb's post in Basys 3 7 segment display on while not used in configuration was marked as the answer   
    Hi @Anthocyanina,
    From the FPGA's perspective, the seven segment anodes and cathodes are active low. By default, when the FPGA is configured, Vivado applies a weak pulldown to each of the unused I/O pins - pulling the outputs to ground while allowing an external pullup resistor to override it if necessary. It might have been possible when designing the board to avoid the 7seg illuminating in this situation by including pullup resistors on the nets connecting the FPGA pins to the display, but these were not included.
    Before programming the bitstream into the board, the IO pins are left floating - no pull up or down - so there's no path to push current through the display.
    The default after configuration can be changed, either by including ports for the anodes or cathodes and pulling them high, or by setting the default pull for unused pins to either pullup or pullnone (which could make other stuff happen, like illuminating unused LEDs, since doing so affects everything). See here for more info: https://support.xilinx.com/s/question/0D52E00006hpZVASA2/what-is-the-pin-state-if-i-didnt-use-them?language=en_US
    Thanks,
    Arthur
     
  22. artvvb's post in GeniCam and GigE Vision was marked as the answer   
    Hi Udayan,
    We haven't created any examples demonstrating how to set up a system with GeniCam or GigE Vision. They might exist elsewhere on the web, however it's unlikely that anyone has done it with the Eclypse before. There's more of a chance there's something out there for the Zybo. You might be able to port some other example that uses another board with a Zynq-7000 part to Eclypse, but I don't have any recommendations on where to start. This sounds like a big project.
    Thanks,
    Arthur
  23. artvvb's post in ADC and DAC clock speed was marked as the answer   
    Hi Udayan,
    The Zmod ADC in this bundle is equivalent to the -105 variant (max 105 MS/s) of the (since-renamed) Zmod Scope. The Zmod DAC is equivalent to the AWG 1411, which runs up to 100 MS/s.
    Thanks,
    Arthur
  24. artvvb's post in Zmod ADC Sampling Clock period was marked as the answer   
    Yes. The IP uses the sample clock period parameter internally to compute parameters for an MMCM (the primitive generating the differential clock), if they do not match, DcoClkOut may fall out of spec. The "sample clock" referred to in the IP GUI is ADC_SamplingClock, so for example, a 40 MHz ADC_SamplingClock requires a period of 25000 ps be specified.
    Thanks,
    Arthur
  25. artvvb's post in Eclypse z7 with zmod awg and scope , problem with calibration was marked as the answer   
    Hi @vasilistheodo, welcome to the Forum!
    It looks like the data output stream from the AWG is wired directly to the Scope input stream, without any additional DSP happening?
    The Scope's high gain input range is ±1V and the AWG's low range is ±1.25V.
    Thanks,
    Arthur
×
×
  • Create New...