Xband

See this response, I didn't change any port definitions from the baseline DDR project though, I think mine has more to do with the AXI stream perhaps, let me know....

@artvvb, Realize its the holidays, throwing this out whenever you can have a look or anyone else following. I"m still trying to diagnose. Synthesis and implementation pass. Quite a few ip upgrade errors. Bitstream failed to generate, Thanks, ERROR: [DRC NSTD-1] Unspecified I/O Standard: 171 out of 171 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: beat_count[31:0], error_count[31:0], m_tdata[31:0], miss_count[31:0], s_tdata[31:0], clk, decouple_streams, idle, m_tlast, m_tready, m_tvalid, resetn, s_tlast, s_tready, s_tvalid... and (the first 15 of 16 listed). ERROR: [DRC UCIO-1] Unconstrained Logical Port: 171 out of 171 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: beat_count[31:0], error_count[31:0], m_tdata[31:0], miss_count[31:0], s_tdata[31:0], clk, decouple_streams, idle, m_tlast, m_tready, m_tvalid, resetn, s_tlast, s_tready, s_tvalid... and (the first 15 of 16 listed). WARNING: [DRC ZPS7-1] PS7 block required: The PS7 cell must be used in this Zynq design in order to enable correct default configuration. INFO: [Vivado 12-3199] DRC finished with 2 Errors, 1 Warnings INFO: [Vivado 12-3200] Please refer to the DRC report (report_drc) for more information. ERROR: [Vivado 12-1345] Error(s) found during DRC. Bitgen not run. INFO: [Common 17-83] Releasing license: Implementation 19 Infos, 2 Warnings, 0 Critical Warnings and 3 Errors encountered. write_bitstream failed ERROR: [Common 17-39] 'write_bitstream' failed due to earlier errors. INFO: [Common 17-206] Exiting Vivado at Tue Dec 26 12:21:30 2023... [DRC NSTD-1] Unspecified I/O Standard: 171 out of 171 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: beat_count[31:0], error_count[31:0], m_tdata[31:0], miss_count[31:0], s_tdata[31:0], clk, decouple_streams, idle, m_tlast, m_tready, m_tvalid, resetn, s_tlast, s_tready, s_tvalid... and (the first 15 of 16 listed).

@artvvb Just as a proof of concept now I would replace the "channel 2" data signal with the Accumulator sum for testing. I've tried to configure the sum as 16 bit so the concat'ed data is 32 bits, so it should fit back into the AXI stream. 1. Sum and original ADC value for channel 1 should be 32 bits, 2. For the final project there are a couple of options, the Accumulator data is needed, it would be nice to be able to store up to 10 pulses for each channel. The pulses could be buffered into memory. Cannot seem to find an instruction for entering data into the axi stream. This seems pretty basic. Most of the tutorials are regurgitation of Xilinx documents without examples of actually doing this. Even in the DSP examples they all end up using it fancy IP that has the AXI out. Looking at the code it almost seems like some are connecting the data bitstream to the AXI clock signal, maybe this is an obvious solution to more experienced users. Now I'm looking screen mining IP looking for the axi_td_data in signal which seems like it would be the correct input. Thanks,

@artvvb thanks, I figured that out immediately after I posted the question, my next struggle is appending the accumulated data into the Axi stream. I would like to arrange the data (ch1value, ch1 integrated , ch2 data, Ch2 integrated). I’ve concat’ed these values into a bit representation but cannot figure out how to insert/ replace this into the existing AXI stream. I’ll post a block diagram screenshot when I can, I’m a bit concerned this will cause problems with the existing code, will need to adjust Axi stream bit address in downstream I’m guessing. Should I greate a separate AXI stream for this appended data?

Similar names were causing problems, have RTL pulse extender added now. I've done this multiple times and it seems that every time I create this source it turns out to be a "hidden incompatible module". Cannot figure out what I"m doing wrong, have looked up multiple examples it does not seem to work. Did you mean for me to do a simulation? I was working under the impression that your sim should be good. I've tried creating it as Verilog and VHDL (from Adding Sources) with the same problem. Any idea?

This is a basic representation of the signals to capture. The integration will take place over multiple pulses typically at 30Hz.

If you're at all interested by this Labview implementation of FPGA this IP look at this link where Labview spawns the Vivado custom IP windows, they give a decent explanation of whats goin on and the example vi shows 3 different fifo's. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001E0NFCA0&l=en-US

@artvvb After looking at this issue more it would seem that a DSP Accumulator should do the job of integrating the data from the ADC in a timely manner. I've tried finding examples that I can relate to the project but I cannot figure out where exactly to place the Acummulator Ip nor is it clear what type of data should be fed into this thing. I'm not sure where to connect a wire from the Axi4 Fifo created for the other method, the bit structure does not match and I cannot change it from 16 bits in the accumulator ip. ( I actually figured out how to change the input bit width since posting, you have to move a slider from Automatic to manual) Do I need to use a slice function and perhaps another accumulator for the second channel? The best example I found that this should work was from Labview FPGA (sorry) it seems that for an array it is adding even or odd values every other clock cycle. I couldn't find anything on the Xilinx site that shows a block diagram connection for these. https://www.ni.com/docs/en-US/bundle/labview-fpga-module/page/lvfpga/ht_accumulator.html Trigger level high: I'll also need a digital level that stays high for the entire acquisition of ADC trigger. Perhaps there is one coming out of the trigger generator that you could suggest. I'll probably need to create a variable to extract the accumulator result, perhaps I could put it in the level trigger software in vitus and send the result out instead of or along with the ADC sample result. Sorry to change horses again before getting to far into the stream but it is implied that this should be a fast way to integrate the data, implied by FFT results using the DSP. Thanks,

@zygot I'm happy that they are producing this hardware as its performance fills a gap in what is available otherwise. I can't blame Digilent for not providing basic Xilinx FPGA training, they have basic documentation that not any worse than what Xilinx has to offer. The Xilinx documentation seems to be written to "have something" which is a common ideology but might not actually produce much help. For me I"m struggling with basic issues when trying to add or modify the diligent code, my main accomplishment has been being able to change the sample rate on the ADC, which is instructive. I'm not in a position to be able to reproduce the code that's available so that is how I must learn at this point.

Ok, double clicked ZmodScope and see the trigger now, 🙄

Chose that view since the default becomes illegible.

@artvvb here is a copy odesign_1_x.tclf the block design if it helps.

@zygot well, it is a bit of a nightmare for me, novice at this and trying to do something that seems kind of simple/obvious but I cannot seem to make anything work smoothly. Switched computers and am rebuilding previous efforts again and its not smooth either. Seems like I should be able to find where the corresponding project file would live in github but i've downloaded zips of these directories and subdirectories are empty. I've gotten the Z7 hw to run the application but something changed when I changed computers or upgraded to 2023 as the block design doesn't match visually. I'll keep pounding my head on the wall. Its a result of me trying to minimize effort and produce results. This hardware fills a gap in performance that isn't available elsewhere so its worth it to me to keep slogging through the mud. It will eventually work I'm confident. You should play tennis if you enjoy watching others suffer. :)

@artvvb, the block design I have is quite different. This is what I unzipped from the DDR page. 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. I loaded the top level hw.xpr, I'll dig through the other designs to see if I can find the matching project. I upgraded to 2023.2, maybe it changed some things and doesn't look quite the same now.

@artvvb, in your video you’re connecting the fifo to the stream between the trigger modules ( which are not in my DDR stream example block design) Shouldn't I be connecting the AXI stream from the ADC?

@artvvb, Which hardware project are you starting with? I've downloaded the DDR streaming from the link below but it does not contain your level trigger IP. https://digilent.com/reference/lib/exe/fetch.php?tok=42351c&media=https%3A%2F%2Fgithub.com%2FDigilent%2FEclypse-Z7%2Freleases%2Fdownload%2Fddr-streaming%2F2021.1.1-prerelease%2FEclypse-Z7-DDR-Streaming-hw.xpr.zip Thanks,

@artvvb I could probably dig up some similar oscilloscope waveform data files I don't have any "simulations," only real data. Or I could produce a similar waveform from a waveform generator. The structure is the 5us pulse coming in at 30Hz, maybe 1V peak, this is a good enough approximation.

@artvvb, 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. Thanks, Xband, (I've aslo created a separate profile RT_biker, so thats also me)

@artvvb Hi, thanks for following up on this. The signal is a current monitor looking at an approximate 5us pulse. The sample rate needs to be pretty fast to get good resolution on the signal and the full window should capture at least 1us on either side of the pulse to be safe. The source is an electron beam from an accelerator. At this point the processing is just integrating the signal and multiplying or dividing by a calibration factor. The processing needs to be fast enough to produce a digital interlock once the required amount of current is produced, or provide the interlock before the limit is met. I'm currently only trying to address the basic acquisition and calculation at a high speed, and then hopefully expand the application with the Pmod output. It would be very useful to trigger the acquisition with an external trigger into a Pmod. 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/ Thanks,

@artvvb Thanks for the information. I'll start trying to absorb this so I can ask better questions. The "reaction" should be in the form of a digital output, maybe the PMOD would work, or some other line on the board. The timing can be either a few clock cycles, 20ns'ish or 10ms. The faster one would be preferred. Thanks,

Here is another article from EE Times https://www.eetimes.com/the-basics-of-fpga-mathematics/

@artvvb, My thought process on this subject is influenced by work I've done in Labview FPGA. The concept of "High Throughput Math Functions in a Single-Cycle Timed Loop (FPGA Module)" to do what I"m trying. My guess is that there are lower level FPGA concepts underlying the Labview implementation layer. I need to understand this at a lower level somehow so see if this ADC integration could be done on the FPGA possibly, though I could be delusional. :) https://www.ni.com/docs/en-US/bundle/labview-fpga-module/page/lvfpgaconcepts/ht_math_single_cycle.html

@artvvb, Looking at the code it seems that the entire buffer is captured and then output as individual lines. My goal is to integrate point to point and react to a level that is reached over multiple 5us pulses in a 30Hz train. I"m not sure how do do this yet, can we estimate the total time required for 1 triggered acquisition? If I need to trigger and read the buffer each time what is the effective sample rate I can achieve? How many pulses could I read and then react to over a 10us period? For normal sampling rate of 100Ms/s it should be about 1000 points in the normal buffer. Thanks,

@artvvb Ok, I found the column structure in the code, and had changed that buffer length. Increased my signal to 50KHz and can see the oscillation in the data. Can you change the sampling rate by uncommenting these lines? I would think the sampling rate is set in the HW IP with the clock? // Define the acquisition window // const u32 SampleRateMegaSamplesPerSecond = 125; // const u32 SamplePeriodNanoseconds = 1000.0 / SampleRateMegaSamplesPerSecond; // fails at bufferlength=0x100 const u32 BufferLength = 0x2000;//0x400000; // 0x400000 / 125 MS/s = 3.3 ms // 0x1000 / 100 MS/s = 40.96 us => ~10.4 kHz const u32 TriggerPosition = 0;//BufferLength / 4;

Ok, I found the column structure in the code, do not see a sine wave oscillation in my data