artvvb

Awesome! This means it's the newer board file version, which is good, don't need to suggest that readers revert to the old version or update the clock period setting. Should be able to have some links up in the next few days. I confirmed today that the test project I'd put together based on the tutorial functions in hardware, with a simple software app running out of DDR. Cheers, Arthur

I'm really sorry, I was caught up with several other tasks today. The trigger outputs stay high for one stream beat (one clock cycle). Additional hardware that could handle this would be a register that gets set when the trigger output is high, paired with a counter that counts until it reaches a predefined value at which point the register clears, functionally a pulse extender/stretcher.

Hi XBand, I'm actively taking a look through this and will have some more comments later this afternoon. Trying to break down the problem in a way that steps back a bit from the context of the DDR streaming demo, since I think that it is making things more complicated than needed. That said, some of the material in the demo project is still extremely necessary. The LabVIEW material looks interesting. A colleague also mentioned MATLAB, Simulink, and Model Composer as an option for this kind of DSP, but I have not used it myself, and it requires some licenses that you may or may not have access to. An accumulator will be able to perform the integration - this IP looks reasonable for it. Note that the output width probably needs to be large enough to fit the number 0xffff * 700 (assuming 700 us at 100 MS/s), so minimum 26 bits. Yes, it will be easier to treat each channel separately. Slicing off one of the channels so you can focus on designing the system for only one of them would also be appropriate. Also, you can treat tvalid on the AXI stream interface as an enable pin for downstream logic, as long as that logic needs to be run once every cycle - if you don't need extra control logic for the accumulator, maybe it's clock enable could just be tied to tvalid, for example. Would getting those scope captures of what a pulse looks like be possible? The paint diagrams below illustrate how I'm currently thinking about the shape of the pulses and timing: Charge threshold and voltage threshold would be specified separately. Thanks, Arthur

Hi Viktor, Thanks for posting this guide, it looks really clean and you've clearly put in a lot of work. So far I've followed as far as generating a bitstream, with a couple of minor deviations, in that I specified no buffer in the clocking wizard and did not use the real-time preset. It seems to have built great (other than a hiccup where I initially capitalized the name of the CLK100MHZ port wrong, simple user error) and I'll be testing the project further. The same steps and design should be applicable to any Digilent board with a 100 MHz system clock and a DDR interface, including Nexys A7, Arty S7, Nexys Video, USB104 A7. Some comments and a couple of questions follow: It is possible to connect the external clock to the MIG, but still requires manually creating the clock port and adding a constraint like you do for CLK100MHZ in order to override the 2.5 V logic standard that the MIG tries to set. That said, it looks like your approach is better than wiring the clock port directly to sys_clk_i, for reasons described below. I've updated the 35T's template constraints on GitHub to use the correct naming convention. This should be the MIG's sys_rst port. Do you set the clocking wizard input clock source to No Buffer? I might be missing where this happens in the guide. Not positive if the setting is ignored in this case, but warnings or errors can crop up on Zynq devices if a clocking wizard is fed by an fclk pin and the input source is left as a single-ended clock-capable pin. Which version of the Arty A7 board files did you work with? I imagine that either 1.1 or 1.2 will be fine with the guide since you change the MIG configuration. On the off chance that someone uses v1.1, they will need to manually set the clock period to 3077 ps on the "Options for Controller 0 - DDR3 SDRAM" page of the MIG configuration. It's also notable that having a clocking wizard fed from a "clean" 100 MHz signal should make it easier to generate a 25 MHz clock for the Ethernet reference clock when attempting to follow the Microblaze servers guide. The approach recommended by this guide, https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi, a "loopback" configuration where the PLL inside of the MIG is used to generate the reference clock, isn't quite able to do this the same way - the frequencies for the clocks output from the MIG are calculated based on the 3077 ps period, rather than on the 325 MHz frequency. This leads to weird rounding errors in how the clock frequencies are displayed in the block design, and can make it look like a 25 MHz clock generated off of the "324.99 MHz" clock is out of spec for the Ethernet PHY, at something around 24.8 MHz. It's more complex than what I've just described, since some displayed frequencies are derived from periods and some periods are derived from frequencies, and the MIG wizard doesn't seem to tell you what the underlying representation is. Post-implementation clock reports will show that the frequencies are actually okay, but the UI is misleading until you've nearly finished generating a bitstream. This is all to say that your implementation looks great since it lets you divide more clocks that show their frequencies correctly off of the 100 MHz system clock. For reference, this is what the alternate approach looks like after the MIG clocks are wired up (image comes from the baremetal software guide, linked above): Do you mind if we link to your guide from the reference site to help point others in the right direction? Thanks! Arthur

Hi @aceblen Please check this guide: https://digilent.com/reference/programmable-logic/guides/getting-started-with-vivado. Any top-level ports in your design can be wired to a Pmod port by constraining them to the associated FPGA pins. The section of the guide on adding an XDC file to your project will cover how to do this. The guide presents Verilog, but the process is the same for VHDL - add a template constraint file, take the name of a top-level port in your VHDL source, and replace the name of a Pmod pin in the get_ports call on the line that corresponds to the Pmod pin, and uncomment the line. Thanks, Arthur

Hi @bobvogt1961, There aren't many directly equivalent boards - the microprocessor line was EOL'd some years ago - however, there might be some other products that would be suitable. Digilent and Measurement Computing got merged together still fairly recently. There are various dedicated DAQ and data logging products that might be suitable - this page has an overview: https://digilent.com/shop/about-mcc-daq/. I asked some colleagues, and it sounds like depending on your application (particularly your channel count and specific sample rate requirements), there are various things that could fit. Raspberry Pi HATs (like MCC 172) and the E-1608 both came up. Cheaper FPGA boards might also work, but it would be a lot more of a pull to get running, and likely be overkill for your sample rates. Thanks, Arthur

I'm not familiar with SpaceWire. The Pmod ports won't successfully recover a 100 MHz signal. The top speed hasn't been characterized, but is likely less than 25 MHz and north of 10 MHz. 1. It will negotiate for 100/1000 Mbps links, but I am unsure if it can sustain data rates close to this. 2. Yes, TCP/IP, though the library should also support UDP. 3. I believe telnet only. There's some more info in XAPP1026, here: https://docs.xilinx.com/v/u/en-US/xapp1026. Also in the template application project's README. Other examples that use the lwIP library may also be helpful (though Digilent has not tested them): If the data rate is over 100 Mbps, DMA is probably required. The DMA Audio demo for the Zybo Z7 might be a starting point. It takes data coming in from the audio codec, puts it into an AXI stream, and then uses an AXI DMA controller to send data from that AXI stream to PS-accessible DDR memory - there're all sorts of finicky details about how this transfer works under the hood. There are also plenty of other approaches for PS/PL data transfer, depending on the specific data rate needed, and on how "bursty" the data is. Thanks, Arthur

Hi @Reckon1ng The NERP_demo_top module instantiation is missing the ground_touch input. Assignment of signals in a module instantiation using an ordered list instead of explicitly using the names of the module ports is an easy way to introduce errors. In this case, the clock is being connected to the logic associated with the ground_touch input which causes something that doesn't meet the FPGA architecture's requirements to happen. Try this in XADCdemo.v: NERP_demo_top flap1 ( .jump_btn (up), .down_btn (down), .enable_btn (enable_btn), .rst_btn (rst_btn), .jumprate1 (c1), .jumprate2 (c2), .jumprate3 (c3), .ground_touch (), // Not driven, tie high or low (1'b1 or 1'b0 inside the parentheses), or connect to some other signal .clk (CLK100MHZ), .clr (clr), .seg (seg), .an (an), .dp (dp), .red (red), .green (green), .blue (blue), .hsync (hsync), .vsync (vsync) ); Edit: For debugging purposes for catching this kind of thing, reviewing the design in Vivado's RTL Elaboration -> Schematic view can be helpful. Thanks, Arthur

This is correct, both can be used with just these cables and no additional external hardware - the cable Digilent stocks is p/n 310-053. Drivers come with a Vivado installation. Thanks, Arthur

Hi Chris, The Ethernet PHY on the Zybo Z7 is connected to Zynq PS instead of the PL (the subsystem IP would potentially be used if it was on the PL side). This means that there are very few steps required to get a Vivado project that will support Ethernet - the board preset applied during block automation already enables Ethernet. This tutorial for running Xilinx's LWIP TCP echo server example was recently updated: https://digilent.com/reference/programmable-logic/guides/zynq-servers, and this blog post extends off of it to do pretty much exactly what you are talking about with streaming bytes back up to a host via a Python script: https://digilent.com/blog/getting-out-of-the-echo-chamber-transferring-data-over-ethernet-using-zynq/. Thanks, Arthur

Hi @Razvan1203 This isn't an application anyone at Digilent has tested. That said, it looks like there is some information in the RN4871 user guide on establishing a connection between two modules (section 4.3, page 61): https://digilent.com/reference/_media/reference/pmod/pmodble/rn4871_user_guide.pdf. To connect on power on, you'd either need to run an application on the host that communicates with the BLE module over a serial interface at startup to establish the connection, or use a power-on event to trigger embedded scripts on the BLEs themselves that can establish the connection (section 3.1, page 53). Thanks, Arthur

As detailed further in this thread, Digilent-provided materials for the Pcam 5C only support the RAW10 format. I've reached out internally to update our store page to this effect. Apologies, Arthur

No loops or reduced jogs may help somewhat with the interface routing mess. No loops makes it harder to tell at a glance what pins/interfaces are inputs and which are outputs. The regenerate layout button will also shuffle everything around to try to fit it on screen, which is a blessing and a curse.

This is the selection menu for different views, I think what you're seeing as differences in block design are based on having interfaces selected:

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.

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

Hi @Jonathan20 No, Digilent doesn't provide any Pmod -> Pcam adapters. The options are either a Zybo Z7 or a host board that supports the FMC Pcam Adapter. Thanks, Arthur

The level trigger is instantiated a couple of levels down in the ZmodScope hierarchy - see the screenshot below: 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.

Thanks for the additional info, it definitely sounds like this is doable in hardware. 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. 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. 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. Untitled Project.mp4

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

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

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

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

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

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. Thanks, Arthur