Jump to content

artvvb

Technical Forum Moderator
  • Posts

    1,073
  • Joined

  • Last visited

Posts posted by artvvb

  1. 51 minutes ago, Xband said:

    Do you have a link to the project in Git?  I can find the DDR directory but do not see a "hw.xpr" file for the project.  I'll dig some more to try and find it. 

    Working with the project from git requires using scripts in the hw/scripts folder. You would recursively clone the branch, "git clone --recursive https://github.com/Digilent/Eclypse-Z7 -b ddr-streaming" in a command line, then use the command "source <path to repo>/Eclypse-Z7/hw/scripts/checkout.tcl" to create the XPR and open it in the same Vivado window you ran the script from. If not using the recursive flag, the entire hw folder is empty, same goes for the scripts folder. These scripts usually have to be run in the same Vivado version as they were created for though, so downloading the XPR is cleaner if you really want to use a 2023 version. It's also very common for a project to work in one version but not another, since IP used in these designs can change between versions.

    In your screenshot, the "interfaces view" changes a lot of what renders in the block design - it only shows the AXI interfaces and similar, instead of also showing clocks and individual signal nets. 

  2. Hi @Suprith

    The reset button on the Arty Z7 is not directly connected to the FPGA PL. Reviewing the schematic, the reset button, connected to the PS_RST net, triggers the PS side of the chip to reset and drives a reset on the CK_RST net, which is connected to the shield header reset pin. CK_RST is also connected to PS MIO12, however, this would not allow the PS to read a reset button press, since the upstream PS_RST will be applied.

    Reset signals within the FPGA can alternatively be driven by resets associated with the FCLKs.

    Thanks,

    Arthur

  3. The level trigger is instantiated a couple of levels down in the ZmodScope hierarchy - see the screenshot below:

    image.png

    The screenshot is taken from the project from the release download you linked. The hierarchy blocks expand/collapse with the plus/minus buttons. The video was instead using sources checked out from git from the tip of the demo branch, but there are not substantial changes in the block design that would affect things - there are some bugfixes in individual files though.

  4. Thanks for the additional info, it definitely sounds like this is doable in hardware. 

    On 11/16/2023 at 1:14 PM, Xband said:

    It would be very useful to trigger the acquisition with an external trigger into a Pmod.  

    Does the hardware you're using provide a 3.3 V external trigger? Wiring it to a Pmod pin, getting it synced to FPGA clocks, and routing it into trigger detect logic should also be fairly straightforward.

    Quote

    I found an external example of custom ip to create a math coprocessor in the AXI fifo stream.  This is the link, at least is seems possibly, though the tutorial may not be seamless. 

    https://www.mehmetburakaykenar.com/creating-custom-axi-stream-ip-tutorial-with-vivado/397/

    So I haven't worked through that specific tutorial, but at a glance, it looks reasonable for creating IP with AXI streams, and should have some decent info about how to write the logic for these modules. It's also possible to skip the IP packager, and use Verilog or VHDL files directly in the block design. As long as the ports of a module have a common prefix and the correct tready/tvalid/tlast suffixes, it'll even bundle those ports together as interfaces for you. That said, the approach of using IP like in that guide automates some things that are easy to mess up otherwise (setting clock frequencies for the bundled interfaces for example). A short recording of what it looks like to connect a module into an existing stream is attached (do make sure that all of the signals represented in the streams and things are connected up - the video is just to show the tool flow). Once you've created an IP using that guide, and made sure it's included in the IP repo, the process of changing the block design to include that IP follows a very similar process.

    On 11/16/2023 at 1:35 PM, Xband said:

    I'm also trying to reproduce the streaming DDR example on another computer.  The code I downloaded does not include your "level_trigger.v" ip.  Does this need to be added after?  I had it working on the other machine but forgot how I got there. 

    It should be in there. It's possible that the file isn't being displayed at the top level of the Sources tab's Design Sources group. It could still be in the project, just hidden. You could check by opening up the block design and expanding down into the ZmodScope_PortA/TriggerGenerator hierarchy.

  5. Hi @name9006

    There's a PIC24 microcontroller on the board that handles the USB interface to the keyboard and emulates a PS/2 interface for the FPGA. There is communication that can occur with keyboards or other devices outside of just the commands sent by the FPGA. It reaches out to identify USB devices and handles communication over USB. Also, the PIC24 firmware source code is closed source.

    The statement in the manual about input-only ports refers to the FPGA design / Vivado project. Either tri-state inout ports can be used, which would allow the FPGA to send commands to the device - like to set a caps lock LED or to request a mouse position - or input ports can be used if this is not necessary. It's not relevant for whether the demo is working on your board though - the demo uses input-only ports and does not implement any features that would require sending commands back.

    Does the same behavior appear with other keyboards? Functionality may depend on the keyboard used. For example, if a keyboard included an integrated USB hub, it would be unlikely to be detected by the PIC24 in the first place, due to lack of hub support in firmware. I've personally had success using a Logitech K120, but not with a Varmilo VA108M. There's more information in this thread about the Nexys A7, which features the same style of microcontroller to handle the USB HID interface:

    Thanks,

    Arthur

  6. Digilent does not provide a full programming manual for this device. The demos linked above are the main example code we provide for the use of the Pcam 5C and they only support the RAW10 format. The best resource for information needed to potentially modify the examples for other data formats will be the OV5640 datasheet, which can be found here. Unfortunately, it also does not include all register settings used and such modifications could be involved, potentially requiring changes to the video pipeline hardware in addition to the software. Similar changes have been discussed in this thread: 

    This forum is the primary support channel, such that other users can benefit from any questions received. I've reached out internally to see if we have any additional information that we may be able to provide on using other data formats.

    Thanks,

    Arthur

  7. Hi @Xband,

    I was talking to a colleague about this today. There are potentially a lot of different approaches to do this kind of thing, writing HDL as I was describing before is one option. It also should be possible to use the FIR filter channels in the WaveForms image for Eclypse to do a rolling average, perform a level trigger on the filter output, and then use the trigger to trigger the Wavegen or Pattern Generator to output a logic high signal on a Pmod pin. The catch with this approach is that the average would only be able to be performed over a 16-sample window, so the sample rate used would need to be low.

    Would you be able to share where the pulses would be coming from in the proposed system, as in what device the Eclypse would be connected to? Also, do you have some form of mathematical model for the processing you are trying to do, like in Python or MATLAB?

    Thanks,
    Arthur

     

  8. The Edge Zynq isn't a Digilent product, so I am less able to help. Check the Analog Input section of their manual: https://allaboutfpga.com/edge-zynq-soc-fpga-development-board-user-manual/#AnalogInput. I can't find a schematic to see what VP/VN is connected to, but you likely need to be using aux channels 2 and 10 instead, through the XADC sequencer. The aforementioned Cora demo sets up a set of channels to be sequenced through, the Xadc_Init implementation may be of some help: https://github.com/Digilent/Cora-Z7-SW/blob/d35d836848fed00dec917ff0784f6232862220f5/src/Cora-Z7-10-XADC_SW/src/main.c

    Thanks,

    Arthur

  9. Hi @T106A81

    What board are you using, Cora or Zybo? External pins may be connected to different aux channels depending on the board - VP/VN should be the same for either, but there might be some other IP configuration changes to apply. For tutorials, the Cora XADC demo is the only one Digilent provides that uses the XADC with an AXI interface: https://digilent.com/reference/programmable-logic/cora-z7/demos/xadc.

    Thanks,

    Arthur

     

  10. Hi @jarvis

    A couple of thoughts:

    1. Check the Run/Debug Configurations to make sure that the intended elf file is being loaded. There's a screenshot below from 2023.1. The UI differs between versions, but is where a lot of the specifics can be selected - like under "target setup", you can specify whether to reset the FPGA and put a new bitstream in when you click run. I think in older Xilinx SDK versions, you would pick a specific ELF file instead of picking a system project.

    2. Whether you are building the ELF under a Debug or a Release build configuration could matter.

    image.png

    Thanks,

    Arthur

    image.png

  11. Digilent-provided Petalinux material for the Arty Z7 is pretty out-of-date. I'd take a shot at running through Adam Taylor's or Whitney Knitter's posts on the topic:

    Note version numbers though, I'd expect 2023.2 to have some changes.

    Thanks,

    Arthur

  12. Thanks for sharing your solution - the "Rev B demo image" text indicates it's booting from flash. There's also some concern that the C sources provided in the baremetal software tutorial need to change for 2023.2, since the way that xparameters passes information to device drivers has changed, but it sounds like that's not the case in the Classic UI.

    Thanks,

    Arthur

  13. Hey @bloggins666,

    No worries. I've never touched FreeRTOS personally, and am only just seeing this kind of cmake error for the first time, but I'll take a stab at providing some suggestions on directions to look in. The exception in the migrate-error log 'Error in adding domain.'freertos10_xilinx' is an invalid os for the given platform.'' implies there's an incompatibility between the platform project and the software you want to run on it. Potentially missing required peripherals. CMake Error at libsrc/freertos10_xilinx/src/freertos10_xilinx.cmake:330 (message): A53, R5 or A72 FreeRTOS need a TTC in the system without it cannot work is weird, the ARM processors it mentions are not the A9, which feels like it implies that the error may be firing unnecessarily - if you've used FreeRTOS in previous versions, I assume this error or an equivalent does not appear there?

    Speculation aside, your best bet is to contact AMD/Xilinx support.

    Thanks,

    Arthur

  14. Hi @Yatharth Gupta

    As Jcolvin mentioned, mig.prj files are only to be used with a memory interface generator IP, which is intended to be used with FPGA IO pins connected to DDR memory. The Arty Z7 doesn't have DDR memory that is connected in this way, so a MIG and mig.prj file cannot be used.

    You may be able to access Zynq-connected DDR via the Zynq PS's high-performance (HP) AXI slave ports - this would involve AXI buses in the RISC-V design normally connected to the MIG to these ports. That said, this is not a use case we support or have actively tested, so you may run into various unforeseen issues. I would anticipate needing to run some software in the PS to make sure that it is configured correctly, including running the DDR interface and its associated clocks. You will also need to ensure that there are not memory conflicts between the program running in PS and the RISC-V processor. Normal access to other peripherals, like a UART serial connection may also need to be forwarded through the Zynq PS.

    Lab two in this coursework put together by a third party (https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga) goes over how to instantiate a MicroBlaze soft-core processor in Zynq fabric, and some of the concerns involved, though it does not touch accessing DDR. Still, it may be helpful.

    Best of luck,

    Arthur

  15. Quote

    I"m not sure how do do this yet, can we estimate the total time required for 1 triggered acquisition?

    We don't currently have a blind time benchmark or estimate for how long it would take for the demo to rearm a trigger. Fully resetting the DMA may be required, due some potential bugs - if I recall correctly, this would be on the order of tens or hundreds of milliseconds between acquisitions.

    Quote

    My goal is to integrate point to point and react to a level that is reached over multiple 5us pulses in a 30Hz train. 

    Changes to the hardware design could accomplish this but would require designing your own modules to add to the design. Some kind of component sitting between the Scope Controller and trigger mechanism might be able to do it, but would get tricky - an additional trigger mechanism to limit data flowing to the DMA module, a buffer to hold data that arrives before a trigger, summing consecutive samples as they arrive and storing them in a register, then potentially passing the contents of that register to the DMA via AXI stream once the entire trigger has come through. Some documentation on the functionality of the hardware in the existing design can be seen in this page: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/eclypse_platform_manual#trigger_detector. Also, this is the source code for the level trigger mechanism, for reference: https://github.com/Digilent/Eclypse-Z7-HW/blob/ddr-streaming/src/hdl/level_trigger.v.The trigger detector section might be most helpful, though do note, the doc is incomplete. It might also be just as easy to start working from the Low-level Low-pass Filter example instead.

    When you say that you want to react to a level, how quickly do you need to react, and how what form does that reaction take? Messaging the host PC via serial, or by setting an AWG level or digital output?

    One additional note, once it's in the FPGA, data flows through the AXI stream interface, shown in orange in the below, reading up on AXI streams might be handy. AXI streams are probably what a lot of the LabVIEW material is based on, at least for how it handles inputs and outputs. I'm not familiar enough with LabVIEW FPGA to really comment though.

    image.png

     

×
×
  • Create New...