Jump to content

artvvb

Technical Forum Moderator
  • Posts

    1,063
  • Joined

  • Last visited

Posts posted by artvvb

  1. Hi @Julii

     

     

    If I understand correctly: The HLS IP reads data from the ZmodScopeController until either of the two channels exceeds a threshold. Once that occurs, it sends a pulse to the ZmodAWGController. It also forwards the next 2000 samples from the input to the PS via DMA. The data to be forwarded is buffered inside the HLS IP in a 2000-or-so-word-deep FIFO, which is used to ensure that backpressure from the DMA doesn't cause samples to drop. Is that accurate? I don't quite follow why functions called in episode_processing are called N_STEPS times.

    Couple ideas for debugging:

    1. Inspect the DMA status register while it's sitting in the loop - maybe there's an error bit set. I'd use an expression in the debugger dereferencing a pointer to the register address for this. The Memory view could also work but has some bugs with the DMA.

    2. Confirm that the HLS IP doesn't start until after the DMA is ready to receive - the ready signal is not enough to rely on, as it's asserted when the DMA comes out of reset.

    3. Get software access to all of the AWG and scope controller status pins - reading sDataOverflow could give some more info about stream pressure in the system for example.

    I would also consider having the HLS IP read from the input stream from the scope continuously - waiting until the AWG controller is also ready means that if the AWG comes up later, the scope controller's internal fifo will overflow.

    Thanks,

    ARthur

     

     

  2. Hey amna,

    The block memory generator IP accepts coefficient files (.coe) for initialization: https://vhdlguru.blogspot.com/2010/10/how-to-use-coe-file-for-initializing.html. Converting a bin file into the proper format is reasonably straightforward in something like Python. There are even some open-source repositories that look like they might be able to do it. This is an example (I can't speak to how well this particular one works): https://github.com/anishathalye/bin2coe.

    Thanks,

    Arthur

  3. 2 hours ago, Viktor Nikolov said:


    The project is for Cora Z7-7S, but it can be easily re-generated for Arty-Z7 (the constraints file may need a modification, though).

    One note to add, Zynq PS settings also differ, which can cause trouble when porting a project between boards. There are some options for how to do the port, but the easiest is usually to rebuild the block design from scratch in a new project. Alternatively, it may be possible to export a Zynq preset after doing block automation in a new project, and apply that preset to the project targeting the original board.

  4. Below are my current results for two runs using the numbers you suggest. This is with an Eclypse Z7, using the hardware project previously linked (upgraded IP to 2023.1, rebuilt, and reexported hardware), and the main.c file attached below (modified slightly from the previous version to log the sizes used). I used Run As -> Launch Hardware to ensure that debug breakpoints wouldn't affect timing. There's clearly something different between our setups, but I'm unclear on what it could be. I've also exported my workspace in case it shows some kind of difference, or if it's somehow caused by an issue with the physical hardware.

    main.cvitis_export_archive.ide.zip

    image.png

  5. Hey @SpinWizard

    9 hours ago, SpinWizard said:

    PC's these days almost always come with some sort of "Sound Card", I'd like to see these used via another instrument that is always available and can handle basic oscillator duty.   In fact you can literally call it an Oscillator instrument though most sound cards can do better.   Now I realize that we have the WaveGen Instrument but I look at this as additional capability and frankly parallel capability that does not interfere with the channel to the Analog discovery.

    This is actually supported out of the box, not as a separate instrument, but as a separate device that works with most of the non-digital instruments like Scope and Wavegen as-is. It's at the bottom of the device manager list:

    image.png

    Thanks for the feedback!

    Arthur

  6. On 4/22/2024 at 12:22 AM, RATHNA said:

    can I program the arm cortex a9 processor alone without FPGA programming? If so what are the DSP functionalities Zybo board's ARM cortex A9 providing?

    Yes, you can program the PS alone without loading a bitstream, but you still need to export a hardware project from Vivado to get the correct set of PS initialization settings, even if the project only contains the Zynq PS in a block diagram.

    There isn't much in the way of dedicated DSP features in the PS - this section of the Zynq TRM provides a feature overview: https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Processing-System-PS-Features-and-Descriptions.

  7. 20 hours ago, Michael Bradley said:

    Can I just use the PMOD ports for this purpose and alter the constraints/xdc file to map to whatever name I give them in the verilog code?

    13 hours ago, dpaul said:

    I have not taken a look for a long time into the Zybo Z7 pin mapping file. But I can tell you from memory that the PMOD connections are generally connected to the FPGA GPIO pins, so that you can control them as as you like.

    So the answer to your question would be a yes!

    Yep, Pmod I/Os are generally general purpose. Just make sure that whatever circuit you're connecting to shares a ground with the board.

  8. Hi @loser

    Try pushing some known points in and see what the result is - change the testbench input and see what happens. Below is a testbench that just counts through all bit values that phase could be, using your IP settings:

    image.png

    module cordic;
        reg clk;
        initial begin
            clk = 0;
            forever #0.5 clk = ~clk;
        end
        reg [15:0] din;
        wire [31:0] dout;
        wire dout_valid;
        
        initial begin
            din <= 0;
            forever @(posedge clk) din <= din + 1;
        end
        
        cordic_0 dut (
            .aclk(clk),
            .s_axis_phase_tdata(din),
            .s_axis_phase_tvalid(1'b1),
            .m_axis_dout_tdata(dout),
            .m_axis_dout_tvalid(dout_valid)
        );
    endmodule

    Waveform Style -> Analog Settings for dout:

    image.png

    Radix -> Real Settings for dout:

    image.png

    Thanks,

    Arthur

  9. The Nexys A7 only supports 5 V power at the barrel jack input. You might be able to use a DC-to-DC converter to step your input voltage down to 5 V. That said, we don't have any particular converters that we've tested to recommend.

  10. Hi @VictorV

    Please use Vertical Scale: Decibel instead of expressions:

    image.png

    Using expressions to convert from a ratio to decibels is unnecessary, and as seen, produces incorrect results. We were told that this is due to the fact that the underlying representation of Vout and Vin is a complex number rather than just the magnitude. The same odd result of trying to calculate a ratio by dividing complex numbers like this also occurs in other SPICE-based simulators. You could calculate the magnitude with an expression of "Mag=sqrt((real(Vout))^2+(imag(Vout))^2)" and produce the expected high-pass plot (as seen below), however, there's not much reason to when the dB scale exists.

    image.png

    Thanks,

    Arthur

  11. After applying that fix, I'm also seeing the last five bytes of the last packet be corrupted and need to look into it some more. At least with RECV_BUFFER_SIZE 200000, words_per_packet, 50000, packets 4. Updated main.c is attached.

    image.png

    main.c

  12. Hi @tato0316

    Welcome to the forum.

    MIO pins are not accessible through PL I/Os and don't get constrained - each MIO maps to a specific physical I/O on the chip. The Zybo's SD interface also doesn't have alternate paths on the PCB to FPGA I/O pins. You would need to access the SD card by using the PS, or maybe by controlling PS peripherals from fabric through the PS's AXI slave ports (assuming they're even addressable from there...).

    Depending on the end goal, maybe you could load the text file data into a BRAM instead, or even a couple of versions of the data, and bake it into the bitstream?

    Thanks,

    Arthur

  13. Hi @Viktor Nikolov

    500000 should be fine for a packet length - it fits within the 26-bit max of the DMA. I imagine you're also increasing the RECV_BUFFER_SIZE, since it doesn't sound like it's reporting errors - adding a return to the check in main would help debug:

    Quote

        if (words_per_packet * packets > RECV_BUFFER_SIZE) {
            xil_printf("error: receive buffer too small\r\n");
            return 1;
        }

    With fresh eyes, there's a bug in the code where the cache is handled - the ranges should be RECV_BUFFER_SIZE * sizeof(u32) bytes, rather than RECV_BUFFER_SIZE words. This would be obscured unless large enough values for the packet length and count are tried...

    Thanks,

    Arthur

  14. 36 minutes ago, Viktor Nikolov said:

     

    The XADC Wizard IP can output measurement data as an AXI Stream, which is a pretty simple protocol. In the HW design I mention here, the AXI stream is fed into the AXI-Stream Subset Converter IP (to divide the stream into chunks of 128 records by setting the tlast signal) and then into AXI DMA IP to load it into memory accessible by Zynq ARM core.

    Using the subset converter as a small packetizer is nice, I didn't realize it had that feature, great tip!

  15. Good to hear you're making progress!

    5 minutes ago, pdw said:

    My console tab doesn’t appear to have a serial terminal: how do I enable that? None of its icons had any obvious options for it.  (I'm running Vitis IDE v2022.1.0 on Ubuntu 20.04 if that helps.)

    I'm on Windows and typically use Tera Term or PuTTY for talking to COM ports, rather than the built-in serial terminal. Either PuTTY or something like Minicom might be appropriate.

    8 minutes ago, pdw said:

    And, in anticipation of the next step: on my Genesys 2 board, should I expect this serial output to come back along the JTAG cable, or will I need to connect another cable to the separate ‘UART’ USB socket?

    Yes, you will need to use both ports. This section of the manual describes the USB UART circuitry: https://digilent.com/reference/programmable-logic/genesys-2/reference-manual#usb_uart_bridge_serial_port.

    Thanks,

    Arthur

  16. It's odd that the heap is overflowing the local memory by the same number of bytes. Feels like it might indicate that it's still out of sync with the updated spec somehow, but I'm not sure - the instructions you found for switching out the XSA are the correct ones. I'd be curious whether a new application project with the same source files and the new XSA still presents the same bug.

    You could also potentially try reducing the heap size in the linker script. It doesn't solve the problem of the updated address map not getting applied, and could lead to overflows, but to just get something working initially... The screenshot below is from a Zynq project with DDR, so yours will look a little different, but this is where to find the heap size setting:

    image.png

    If you end up uploading the Vitis project, please use the File -> Export menu instead of zipping the folder in Explorer, as there are a bunch of absolute paths in various files that the software needs to update when the workspace gets moved or copied.

    image.png

     

  17. Hi @jmckinney

    I'm largely not familiar with FreeRTOS, but is there a chance that the data cache could be messing with the ability of the DMA to pull block descriptors from memory? https://www.freertos.org/FreeRTOS_Support_Forum_Archive/May_2016/freertos_Zync_UDP_TCP_with_DMA_IP_f531ef1cj.html seems potentially relevant. Caching issues are a pretty standard problem with non-scatter-gather DMA, where it just makes data unable to be seen by either side unless you flush or invalidate as appropriate. Pointers in block descriptors that aren't coming through as expected could cause all sorts of issues. If that's the cause, might be worth trying to disable the caches entirely, though I'm not sure how this affects the FreeRTOS setup.

    If you haven't, I'd also try putting an ILA on the DMA's AXI4-full master interfaces.

    Thanks,

    Arthur

  18. 1 hour ago, Oscar O. said:

    When I export the .xsa file it is in the directory where the .xpr file is for Vivado. But looking at the property of the .xsa file in the vitis environment it is down projext.sw/design_1_wrapper\export\design_1_wrapper\hw\design_1_wrapper.xsa so wondering if that is the problem (it does not see the new dma block in the schematic).

    You would think Vitis would see that it changed and copy??? it to the correct directory. Nevertheless I copied the .xsa to that directory and it still gave me an erorr.

    You should manually update the hardware specification: https://digilent.com/reference/programmable-logic/guides/vitis-update-hardware-specification. Vitis generally won't see changes to the filesystem. When just overwriting the copy of the file buried in the platform project, I'd be concerned that Vitis might need to extract other files from it, which it might not happen automatically during a build - I expect it won't see the copy without the manual update.

    One common issue that could come up after this (though I don't think you'll run into it here) is that if your XSA file has a different name, the extracted bitstream name changes. In this case, you'd need to go into the system projects Run/Debug Configurations, and change the path to the file to reflect the name of the new XSA.

    image.png

    image.png

×
×
  • Create New...