Jump to content

artvvb

Technical Forum Moderator
  • Posts

    1,063
  • Joined

  • Last visited

Posts posted by artvvb

  1. Hi Ellile,

    If the other end of your resistor is grounded, that should be correct - the "Energy through C1 100R C2" example, which seems to be what you're basing this on, calculates power from the current through the resistor multiplied by the voltage at the top of the resistor. Current is calculated as the voltage difference across the resistor divided by the resistance in ohms - so, if C2 would measure 0 by the other end of the resistor being grounded, the modified example is fine. Energy is calculated by integrating the power - summing it all up, with each sample multiplied by the amount of time between samples.

    There might be a little bit of error from the digitization process, but that's what having a sufficient sample rate is for.

    image.png

    Thanks,

    Arthur

    Edit: Moved the thread to the T&M subforum, which is more appropriate for this topic.

  2. Apologies for the delay. I haven't been successful in reproducing your setup. Some additional settings that might help are 1. the constant values applied to the CONFIG interface of the XFFT IP - I assume the tlast port is tied to a constant one. 2. XFFT settings - both the Configuration and Implementation tabs include settings that affect what values are provided to the CONFIG interface.

    I'd also be curious about why the XFFT S_AXIS_DATA interface's tlast port seems not to be connected - in simulation, not asserting tlast at the expected time causes the XFFT core to assert either an event_tlast_missing or event_tlast_unexpected error.

    If you haven't, please review the product guides for both of these IP cores:

  3. Personally, I would try to use AXI GPIO to push data into a shift register and try to do as much of the design as possible in an RTL module - using Microblaze to handle the UART interface and GPIO and not much else, with a single RTL module included in the block design at the top level. Saving writing and reading data from the BRAM until after you have a functional UART -> GPIO bridge would be appropriate, after which you could implement that BRAM in RTL instead of using IP for it. A first step would be to get a project set up that can receive a single UART character, then use an AXI GPIO to forward it to an RTL register that drives some LEDs.

  4. Hi @pepeok

    So I'm not sure about AXI BRAM, it may be possible, but I recall running into some issues (quite some time ago) with trying to control the same AXI BRAM from an HDL module and by PS through an AXI BRAM controller at the same time. If going this route, I'd assume the AXI BRAM would be configured as a true dual-port RAM. Using an AXI interface to write to block RAM is still a good approach though - I'm just not sure about how well the IP in block design would handle the use case. The first lab in this series might help if you're using this approach though - it at least shows wiring up the PS -> BRAM part of this communication path: https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga.

    200 ms is plenty of time for any number of different interfaces. Controlling a custom module with an AXI GPIO ought to work, though you need a way for the module you're controlling to tell when new data is available - using a second GPIO channel to toggle a bit back and forth whenever new data is available on the first GPIO channel would work fine.

    Hope this helps,

    Arthur

  5. Hi Razvan1203,

    BRAM and DDR memories are available on the board and can be used to store data until it's requested by some external system. BRAM provides less storage space compared to DDR but is easier to use - both how often events occur that need to be stored and how many bits you need to store per event are relevant for determining the amount of memory necessary. There are various ways of connecting to the board to offload data, but UART communication might be enough for your application - it would be reasonably straightforward to put together a system that allows software on a host computer to request X number of bytes from the board via UART, and for the board to reply with that many bytes. Apologies if this is overly vague, it's a pretty open-ended question.

    Thanks,

    Arthur

  6. Apologies, I haven't had a chance to take a look at your project yet, and may not tomorrow either.

    11 hours ago, Mamatchai said:

    Recently an expert suggested to me that there might be a conflict occurring during function calls due to the similarity in the names of TCP and ZmodADC interrupt flags(IF). However, I haven't confirmed this yet.

    This is interesting, I would expect to see some kind of "multiply defined" error indicating that the same definition occurs more than once. It's still possible that there could be issues like this that don't generate that specific error though.

  7. Hi Jeff,

    Welcome to the forums.

    There's no board file support or connection automation for the Zmod controller IPs. They're provided through the vivado-library repository on Github, but it's expected that you would base your designs on existing demo projects. I'd refer you to the following demos:

    Hope this helps,

    Arthur

  8. If you have multiple ethernet connectors on your computer, you might try each of them, updating an IP through the network and sharing center, like in step 11 here https://digilent.com/reference/programmable-logic/guides/zynq-servers#testing_the_server_without_a_dhcp_router, corresponds to one of them rather than all.

    The DHCP timeout is expected - there's no router there to handle DHCP. Based on the mention of RTL8211F in the printouts, did you update xemacpsif_physpeed as described in the prereqs section? https://digilent.com/reference/programmable-logic/guides/zynq-servers#update_ethernet_support_boards_with_rtl8211f_chip. I'm not sure what happens when the fix isn't installed, but will check with a colleague.

  9. There's a utilization report that tells you where BRAM is being used, Implementation -> Open Implemented Design -> Report Utilization, in the Flow Navigator. Cutting the AWG output hardware from the design would get you some BRAM back that could be used in the Scope inputs. There might be some other places where BRAMs are being used, like in FIFOs for clock domain crossings. If you need substantially more record length, you'll need to switch to a different architecture that doesn't rely on BRAMs or downsample in hardware.

    This is an example utilization report from another project, 15 out of 16 BRAMs are being used by an ILA, out of the total 140 available:

    image.png

  10. 9 hours ago, Oscar O. said:

    So there is a UDP sever and client. Does the echo server use both a client and server or just a tcp server to do receive and send back data to the host computer via ethernet? In other words do I use both the udp server and client or just the server???

    I believe the echo server just implements a server - the serial console or python script acts as client.

    9 hours ago, Oscar O. said:

     

    Which microSD card size do you recommend and class do you recommend... do you have a preferred brand?

    A board at my desk uses an SDC10/8GB Kingston microSD card, formatted as FAT32, which works fine. It's likely the equivalent of this one on our site: https://digilent.com/shop/microsd-card-with-adapter/.

    9 hours ago, Oscar O. said:

    You said: "you can check the linker script (lscript.ld) to confirm."  Are the lines below the ones that define the buffer area?

    All sections of program memory are placed in DDR. The LWIP sources should be using malloc under the hood, which allocates memory in heap. A related question was answered here: https://support.xilinx.com/s/question/0D52E00006iHli2SAC/raw-lwip-memory-management-zynq?language=en_US.

    image.png

    9 hours ago, Oscar O. said:

     

    So when the Vitis project is compiled it understands the hardware it is dealing with and sees that there is a DDR3 memory it can use to store information... is that a accurate description?

    Yes. The linker script defines what parts of the compiled project get placed at what addresses.

    9 hours ago, Oscar O. said:

    Going back to the audio project, I see that the block that interfaces with the external codec (d_axi_i2s_autidio) hooks up to the DMA block using the axi..the axi_interconnect block then is hooked up to the ZynQ7 via the S_axi_HP0 port. How does the dma know where the microphone sound buffer resides in the DDR3 memory (location)? Is this a parameter that gets programmed to it?? Just trying to see how it all fits together. Sorry for all of the questions I have never done a project with Zynq processor and Vitis.

    The AXI DMA has a register that the processor writes in order to specify the buffer's memory address. Using the xaxidma API, this is done through a call to XAxiDma_SimpleTransfer. The same call also sets the length of the memory buffer so that the hardware knows when it might overflow the buffer and corrupt things if it continues writing. See here: https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/audio/audio.c#L383 - the function call specifies that the DMA should transfer into a buffer located at MEM_BASE_ADDR, which is five times the number of samples bytes long.

  11. 2 hours ago, bpwilliams said:

     

    'zmodadc1410.cpp' (perhaps a mistake here?)

        uint16_t ZMODADC1410::channelData(uint8_t channel, uint32_t data)
        {
        //return (channel ? (data >> 2) : (data >> 18)) & 0x00003FFF;
        return (channel ? (data >> 2) : (data >> 18)) & 0x00007FFF;

        }

    The mask here represents pulling out one of two 14-bit values packed into a 32-bit word, so it should stay 3FFF.

    2 hours ago, bpwilliams said:

    Any idea what I missed? Are there any changes necessary to the DMA structure?

    For the DMA, please confirm the width of buffer length register setting is large enough, it's an IP setting in the block design.

    I'm not sure where else to look, it looks like the window position register width in the AXI controller is also controlled by kBufferSize in the VHDL source, and the corresponding definition in the C++ sources defines it as up to 26 bits wide: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/ZmodADC1410/zmodadc1410.h#L49C9-L49C40. Same for the S2MM length register width in software: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/Zmod/zmod.h#L46C9-L46C45.

    I would also consider adding an ILA to the design (if possible, it also requires BRAM...), to take a look at the AXI stream signals going into the DMA.

    Thanks,

    Arthur

  12. The idea is that folks would use development boards to start testing out IP that might be included in a design on their own boards while those boards are still being designed - verifying that some algorithm written in RTL will work, or that a firmware architecture concept is viable. That said, we're potentially interested in this kind of custom work and I've reached out internally.

  13. Hi Paul,

    32 minutes ago, pdw said:

    Is that about right?  In particular, have I understood you correctly that I could potentially use the MicroBlaze to provide flash memory access?

    Yes, though to reiterate, I'm hedging about whether writing VHDL might be harder than a MicroBlaze design - if I was doing the design, it's what I'd personally look at first, but I have my own biases.

    35 minutes ago, pdw said:

    We don't yet know the first thing about processor-based FPGA design here -- is this something to do with the "Vitis" tool that I see in Vivado? -- but it sounds like it will pay off in flexibility once we've gotten into it.  I've found several "Getting Started with MicroBlaze" guides on the Digilent website that I'll try out.

    Do you have any other basic "MicroBlaze for Complete Beginners" guides you can recommend?

    This guide would be the recommended starting point within stuff Digilent hosts: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi. Avoid DDR if possible, which would also mean avoiding some larger drivers or C libraries like stdio. You also need a way of moving data between the processor and the rest of your design. For low speeds, AXI GPIOs work (https://forum.digilent.com/topic/28261-qol-script-for-vivado-block-design-and-ps-pl-communication/) - I think I mentioned earlier, but latency and throughput for a microblaze based system will probably be fairly poor relative to a pure-VHDL-based solution, so the amount of data you need to move matters.

    When typing out an @, a dialog pops up with usernames, clicking on the user adds in a button, which sends the person a notification. It's helpful in case the person isn't subscribed to the thread.

     

    image.png

    Thanks,

    Arthur

  14. 4 hours ago, Oscar O. said:

    On the server project if instead of a terminal to send one character at a time I have a piece of python code that could send a block of data...would that block be echoed back or this only works one character at at time?

    The block should be echoed back. If the TCP example receives a block of characters at once, it sends them all back at once. To confirm, you could print p->len in the recv_callback function.

    4 hours ago, Oscar O. said:

    I take it the characters or block of data are being received are put into a buffer?? is that buffer in the DDR3 mem?

    Yes, the echo server includes an internal buffer, which is located in DDR - all buffers and variables in the software application should be in DDR, you can check the linker script (lscript.ld) to confirm.

    4 hours ago, Oscar O. said:

    Reading through some of the code I keep seeing tcp_*** is the ethernet protocol being used to send and receive data above a TCP protocol? If it is....is there a server example using UDP? Or how can I change it to UDP?

    I don't have personal experience with the UDP API. There are several template applications that should use it, but potentially no echo server example.

    image.png

    4 hours ago, Oscar O. said:

    Also, if I wanted to have the server application (or any other) without having to have the board hooked up to the programming uart port can the fpga boot off the SD card? If yes, what are the steps to get the files into an SD card.

    Please review this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot.

  15. Hi Paul,

    If it was me, I'd likely try building out a microblaze system first, just because there are more drivers and example sources available. If too many FPGA resources are used, or if the latency involved in the processor receiving a request from hardware, reading data from flash, and forwarding it to the hardware, is too much, then I'd look into building out a custom controller or AXI master. In either case for custom RTL, there would be a fair amount of time spent with either the flash datasheets or AXI QSPI datasheets and simulating the design before going to actual hardware. I'm not sure which would be easier between the AXI design and SPI design - SPI itself is straightforward, but the complexity is in understanding the flash device's command set. I also admittedly have a bias towards processor-based designs.

    Thanks,

    Arthur

  16. 42 minutes ago, engrpetero said:

    The function merely updates a single bit in the XSM_SEQ_04_OFFSET and XSM_SEQ05_OFFSET registers.

    Looks like it updates a bit in SEQ04 and two bytes in SEQ05. This probably corresponds to the VP/VN channel and sixteen aux channels. The XADC documentation is a little bit frustrating, as it's typically talking about the DRP interface rather than AXI. Quote below is from the "Automatic Channel Sequencer" section of UG480.

    Quote

    ADC Channel Analog-Input Mode ( 4Ch and 4Dh )

    These registers are used to configure an ADC channel as either unipolar or bipolar in the automatic sequence (see Analog Inputs, page 21 ). These registers also have the same bit assignments as the channel sequence registers listed in Table 4-1 and Table 4-2 . However, only external analog input channels, such as the dedicated input channels (V P and V N ) and the auxiliary analog inputs (VAUXP[15:0] and VAUXN[15:0]) can be configured in this way. Setting a bit to logic 1 enables a bipolar input mode for the associated channel. Setting a bit to logic 0 (default) enables a unipolar input mode. All internal sensors use a unipolar transfer function.

    Offsets and addresses seem to be different for the AXI interface than DRP though, so those "4Ch and 4Dh" don't necessarily apply.

    It looks like PG019 is the actual document to be referencing: https://docs.amd.com/v/u/en-US/pg019_axi_xadc. I'm still reading, but haven't spotted if it details exactly what is in the SEQ04/SEQ05 registers yet.

  17. Hi @stc Leuven

    Branch names in git are case sensitive - try the following for the out-of-box demo:

    Quote

    git clone https://github.com/digilent/eclypse-z7 --recursive -b OOB/master eclypse-z7-oob

    Docs for it including setup instructions are here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/oob.

    Same for demos for the AWG and Scope 1410 Zmods: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-awghttps://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. See the "setting up the baremetal projects" dropdowns.

    Thanks,

    Arthur

  18. Hi @pdw

    1 hour ago, pdw said:
    • Add an AXI Quad SPI flash IP core to my design, because that’s a thing that knows how to talk to SPI flash.
    • Wire up that core into my VHDL logic.

    For your outline as presented, in terms of complexity level, these steps concern me as they'd require building a custom AXI-lite master. If you're dead-set on using AXI Quad-SPI instead of a custom SPI controller, I would first put together a MicroBlaze design that uses it with the xspi drivers, so that you can build an understanding of what the IP's registers are doing and how you need to access them. It's currently undocumented on our reference site, but this demo was put together last year to write and read data from flash on a Nexys Video:

    Thanks,

    Arthur

×
×
  • Create New...