Jump to content

JColvin

Administrators
  • Posts

    6,650
  • Joined

  • Last visited

Posts posted by JColvin

  1. Hi @jenga,

    The record mode (I'm presuming that is what you are meaning by streaming) bottleneck for the ADP3450 is limited by the connection to the host computer; either the USB 2.0 connection or the Ethernet connection, depending on which configuration you chose.

    As both communication options are packet based, data is transferred in chunks. Because of the on-board DDR memory, the streaming of data in chunks is largely mitigated since the device can continue to capture data and store it in the DDR memory while some subset is transferred over to the computer (presuming you aren't attempting to capture data faster than you can transfer it over anyways). The WaveForms Help tab has typical values for transfer rates and latency:

    image.png

    In terms of other numbers, each analog input is stored in a 16-bit (2 byte) format, as well as the 16 digital channels being represented in a 2-byte format, so you'll correspondingly be limited in what maximum sample rate you can achieve based on how many channels you have enabled.

    There are several built-in Record mode examples in Python that should be of help:

    WaveForms SDK location.png

    image.png

    USB 2.0 with its overhead tends to top out at around 40 MByte/s, so with 3 two-byte channels acquiring data over USB, this ends up capping you at a sampling rate a bit over 6.5 MHz (best that I can tell, the screenshot from record to file is showing 13.1 MS/s // 26.2 MB/s for the measured rates because it is not taking into account the remaining third of the 6 bytes per sample bandwidth portion that the digital data is taking up):

    image.png

    With a gigabit Ethernet connection, you'll of course then be able to achieve the faster rates:

    image.png

    If you are wanting to have faster streaming, I would instead point you towards the ADP2230 with its USB 3.2 Gen 1 connection:

    Let me know if you have any questions.

    Thanks,
    JColvin

  2. Hi @Kevin.C,

    I am uncertain on the public key for WaveForms; that will be answered by the WaveForms developer (Attila) on the https://forum.digilent.com/topic/28525-digilent-adept-runtime-package-header-is-not-signed/. I saw you pinged him on it yesterday and that he got another ping from the Adept developer today, so I hope to hear some details on this once his European timezone is in normal business hours to confirm if the key is different than the Adept key and if the 3.22.2 release will be back-updated.

    The public GPG for Adept (you need to get Adept Runtime installed first on Linux prior to WaveForms) can be found here: https://cloud.digilent.com/myproducts/Adept?tab=2.

    Let me know if you have any questions.

    Thanks,
    JColvin

     

  3. Hi @Ayesha Zaman,

    It is the buffer size of the Analog Discovery analog input/scope (as that is what you are using) that needs to be kept under the value.

    For example, if you are wanting to acquire 10 us at 100 MS/s, that would be 1000 samples (1*10^-5 x 1*10^8). Correspondingly, the maximum amount of time for a single acquisition at 100 MHz for the AD2's 8192 sample buffer size would be 81.92 us.
    If you wanted to acquire data for a longer period of time, then the sample rate has to decrease to 50 MHz (or lower, depending on the length of time) for the 8192 sample buffer to be "spread out" enough to encompass the full desired time frame.

    Thanks,
    JColvin

  4. Hi @jcanion,

    The Network Analyzer instrument has a Bode plot as its default view. The Help tab has built-in documentation on all of the different settings:

    image.png

    There is also a tutorial version on using the Network Analyzer on the Digilent Reference site here: https://digilent.com/reference/test-and-measurement/guides/waveforms-network-analyzer, which is also listed on the Analog Discovery 3 Resource Center here: https://digilent.com/reference/test-and-measurement/analog-discovery-3/start#tutorials.

    Let me know if you have any questions.

    Thanks,
    JColvin

  5. Hi @mmessuri,

    I'm glad to hear you are having much more success.

    To be honest, even after I had added the twisted wire pair (I also used the high speed pair, I didn't check to see if I could accomplish the same thing with just random breadboard wires that don't have the embedded resistor), I would also receive an occasional lone "Leftover bit" error, but it was far less egregious than when I was getting the errant CS spikes.
    I'm not sure off-hand if these remaining bits are a remaining errant spike or a quirk in the CardInfo example (since I seem to recall that the leftover bit was in a somewhat consistent location); I haven't done further debugging to determine the root cause.

    Regardless, let me know if you have any questions.

    Thanks,
    JColvin

  6. Hi @Kevin.C,

    There is no repository for the beta versions; that one Forum thread started by the WaveForms developer is where all users, including myself, are able to get any of the beta versions.

    In terms of release versions (again, no release signed Linux variants at time of writing), the official location to get the latest release is within the My Products section of the Digilent website: https://cloud.digilent.com/myproducts/waveform?tab=2.

    Otherwise, in terms of a slightly more repository-like version, you can also get the previous release versions of WaveForms from here: https://digilent.com/reference/software/waveforms/waveforms-3/previous-versions.

    Let me know if you have any questions.

    Thanks,
    JColvin

  7. Hi @Nevermnd,

    The Nexys 4 DDR and the Nexys A7 are identical products for all intensive purposes (there might be transparent changes that I am unaware of that aren't branding related). There are a couple of threads on this topic here and here, though clearly this never actually made it into the Resource Center(s), or as a comment into the board files, .xdc, or other HDL materials. I will see about getting that clarified.

    For what it's worth, my FPGA also has the Nexys 4 DDR silkscreen label and have never encountered an issue using materials labeled for Nexys A7 instead.

    As for why the product branding changed at all for Digilent (or any other company; see Xilinx AMD or National Instruments NI / Emerson), that's because stakeholders with the power said to make the change and the rest of us said 'yes boss'.

    Regardless, I'm glad to see you are willing to try out the board while being in Data Science. It's probably an easier climb than coming from Chemical Engineering like I did.

    Thanks,
    JColvin

  8. Hi @DBT,

    Unfortunately, Digilent does not have any plans to distribute the programming files for the Power Supply ICs on our various boards.

    I'll I'm able to offer is the public schematic, https://digilent.com/reference/_media/reference/programmable-logic/genesys-zu/genesys_zu-5ev_sch_public.pdf, and the Reference Manual, https://digilent.com/reference/programmable-logic/genesys-zu/reference-manual#power_supplies, though I have no doubt you have already combed through those.

    Let me know if you have any questions.

    Thanks,
    JColvin

  9. Hi @shaur,

    I was told a couple of days ago (April 10) that one of the engineers migrated both uboot and Petalinux as well as the Genesys ZU OOB projects for the 3EG and the 5EV to their 2023.1 versions.

    However, they wanted to test all of the updates on real hardware, so that is currently in process. I will reply back once I hear that the updates have been tested and pushed live.

    Thanks,
    JColvin

  10. Hi @Nevermnd,

    I apologize for the delay. I don't know if it was a typo on your part, but I think the main problem you ran into is that you have the Nexys 4 DDR (now known as the Nexys A7), but, at least based on the link you provided, you were working with the "Nexys 4" which does not have the on-board DDR memory.

    The correct link for the Nexys 4 DDR / Nexys A7 OOB demo (also accessible from it's Resource Center) is here: https://digilent.com/reference/programmable-logic/nexys-a7/demos/oob. The more recent releases, including 2023.1, give you a completed project that will already have the correct .xdc included, and only need you to click "Generate Bitstream", rather than making you go through the whole create_proj.tcl process.
    On my machine at least, I was able to generate the bitstream without errors.

    Feel free to let me know if you have any additional questions or feedback about the process at large.

    Thanks,
    JColvin

  11. Hi @bobql,

    The built-in AnalogIO_DigitalDiscovery.py example should cover everything that you are looking for; the main detail is that the AnalogIO functions handle power supplies, reference voltages, voltmeters, on-board temperatures, etc for all devices.

    Section 14.4 (Digital Discovery) and the Section 7 (AnalogIO) within the WaveForms SDK reference manual have some additional documentation.

    image.png

    Let me know if you have any questions.

    Thanks,
    JColvin

  12. Hi @jostikas,

    I suspect that this is a software bug rather than a hardware one (I verified your experience was also present on the 3.16.3 release) since, as far as I understand, all DIO pins for both the Analog Discovery 2/3 are implemented identically on the PCB side of things.

    Regardless, thank you for bringing this up since I do not recall anybody mentioning this before on the Forum or otherwise.

    I'm not personally don't have any further information, but am hoping that Attila will have some further insight when it's no longer the weekend in his timezone.

    Thanks,
    JColvin

  13. Hi @mmessuri,

    The breakout setup I have uses the Pmod TPH2, https://wiki.digilent.com/reference/pmod/pmodtph2/start, which is just a dedicated test point header module, and the SD card adapter I am using is the Pmod SD, https://wiki.digilent.com/reference/pmod/pmodsd/start, but I anticipate there will be effectively zero difference between the Digilent branded SD adapter and the mikroElectronika one you have.
    Maybe the breadboard setup is contributing to the crosstalk happening on the CS line, but having extra long pins on the SD card to extend on both sides should take care of that.

    As for why the other Logic Analyzer is giving better/more consistent results, it looks like from the photo where I can see the Logic Analyzer, it appears to run at 24 MHz (or at least that is what it has labeled on the shell) and ends up missing (or maybe filtering via software? Not certain what options it has) the tiny cross talk pulses.

    This is what I see with the ADP2230 (has 50 MHz bandwidth oscilloscope inputs) when I probe the CS line and also treat use the Scope to Digital functionality to interpret the Scope Channel 1 as part of the SPI bus.

    example of spurs that I see:

    image.png

    zoomed in on a spur:

    image.png

    Or at least that's my theory of what the Digital Discovery also operating at a high sample rate is detecting.

    I'm hoping @attila may have some more insight into this when it's a more reasonable timezone hour for him.

    Thanks,
    JColvin

  14. Hi @bobql,

    I believe you'll only be able to get up to 40 bits wide:

    but otherwise I believe the protocol tool itself is limited to 32 bits per word. I haven't tried outside of direct loopback, but I believe you should be able to send 32-bit words at a time. Splitting up the transaction into multiple 8-bit words would be the way to proceed for samples larger than that though.

    Let me know if you have any questions.

    Thanks,
    JColvin

  15. Hi @Kevin.C,

    I believe the latest beta versions (3.22.14 onwards) of WaveForms are now signed as per this thread from last month:

    The beta versions are freely available here:

    The next release version of WaveForms will be signed as well, but I am not certain when the next release will be; it usually coincides with a compatible product release, but Digilent does not have anything to announce as of yet.

    Let me know if you have any questions.

    Thanks,
    JColvin

  16. Hi @mmessuri,

    None of my co-workers in my timezone had the hardware to replicate my setup, but I think got it working, including getting rid of the excessive leftover bits. I have attached the WaveForms workspace that I am using. 

    To be honest, I'm not exactly certain what changed in terms of software, since all I had done was roll back to an older version of WaveForms to test out the SPI MOSI triggering, found it was working, and then could not get it to fail to trigger again despite having repeatedly seen it fail all morning and the fact that I had not made any hardware changes yet. I tested multiple two different Digital Discoverys and multiple versions of WaveForms (20.1 release, 22.2 release, and latest beta 22.16) and multiple known MOSI transaction values (h40, h51, h02).

    The main hardware change that I did was to use a twisted wire pair for the Chip Select signal with a ground signal wrapped around it, as recommended by the WaveForms developer for this thread on the same CS spikes that I was seeing:

    I happened to use the high speed twisted wire pair to accomplish this, which I believe I saw you also had from your photos.

    Otherwise the wiring is all the same. 3.3 V supply, ground, and regular SPI pins from the Arduino Uno to the SD card; DD using DIO 24 for Select, DIO 25 for Clock, DIO 26 for MOSI, and DIO 27 for MISO.
    I put the ground for the twisted CS pair wire on the ground line for the 3 boards and the other end into DIO 28 (since I didn't want to split that wire apart) and had DIO 28 and 24 pulled low in the Supplies instrument.

    image.png

    Let me know if it this works for you, and I'll be more than happy to continue debugging if you are still not able to get the expected results.

    Thanks,
    JColvin

    DD-SPI-SD-analyzing.dwf3work

  17. Hi @mmessuri,

    Your wiring looks correct to me (thanks for clarifying that the ground between the 3 devices are normally all connected since only 1 out of 3 photos shows the DD ground connected), and I understand your frustration about not getting the SD card to work.

    I located an Arduino Uno around my office and am now in the process of debugging the built-in CardInfo example with the Digital Discovery.

    I can manage to get the Protocol SPI Spy to report recorded data (it reports a number of leftover bits) before each transaction, and can get the Logic Analyzer to capture data when I set the trigger to an individual pin. But attempting to trigger on a SPI MOSI value of h40 (which I can see repeatedly comes up early on in the transaction) never fires, even though if I open the Events view, I can see and have WaveForms jump to the h40 event on MOSI just fine.
    Interestingly, if I set the Logic Analyzer to trigger on SPI MISO, then it catches whatever trigger just fine.

    The clock signal also does not appear to be free running and I seem to occasionally catch a spurious(?) positive edges on the Chip Select line, which I suspect is causing the leftover bits. I half wonder if this is because the Uno runs at 5 V logic, but the Digital Discovery uses 3.3 V CMOS (albeit 5 V compatible) but that corresponding lower threshold is getting tripped. Regardless, that doesn't explain why the SPI MOSI trigger value isn't being caught as it is the second one in.

    I will continue to do more debugging today to get a better answer for you as, indeed, one of the primary purposes of the Digital Discovery is to debug and view different protocol transactions.

    Thanks,
    JColvin

  18. For what it's worth, I personally consider beta versions of WaveForms to be functionally equivalent to release versions. Main reason that they are called "beta versions" is because having frequent new releases would end up being confusing with regards to messaging (and a drain on psyche with needing constant updates, but maybe that's just me) and also because the other engineers tasked with testing the new releases (usually coinciding with new products) and updating external documentation can't keep up with Attila. He's too powerful.

  19. Hi @mmessuri,

    I don't have a SD card set up on hand to readily test this out for myself, but lets see if I understand your description correctly (a screenshot and a picture of the physical setup would help).

    When using either the Protocol Analyzer with the SPI Spy tab or just the Logic Analyzer with no trigger condition (or just on Auto which, as you saw, will start capturing data after a timeout period), you can still see the various lines being toggled in their expected locations. (I am presuming that you have double checked the physical connections considering that you are not using the default IO pins).

    I have found with the Digital Discovery that if you are not the the Spy tab and instead on the Master or Custom tab, even with the Debug with Logic Analyzer selected, the digital input lines still seem to be driven so that data reception cannot occur.

    If I have the Protocol tool open to Spy and then either Debug with the Logic Analyzer or use only use the Protocol tool, then I can receive and trigger on a value as expected:

    Digital Discovery WaveForms screenshot:

    image.png

    Digital Discovery sniffing out the SPI data being sent between an Analog Discovery 3 communicating with a random Pmod. Probably should have not had a bunch of random other stuff underneath everything else for a cleaner picture but oh well.

    image.png

    Let me know if you have any questions or are still experiencing problems and I'll see how I can help.

    Thanks,
    JColvin

  20. Hi @joinhairn,

    I do not think the Pmod BT2 can handle multiple connections as it does not support the Bluetooth 5.0 (iirc, this is the version of Bluetooth that allowed multi-pairing, at least in the sense of remembering multiple connections without having to re-authorize different pairing every time. Caveat that I'm not fully immersed in the Bluetooth technology capabilities). Regardless, for your setup with one FPGA receiving and communicating to different boards, it would need two separate Pmod BT2s on it, which of course is more hassle and more expensive.

    The Pmod BLE or the Pmod ESP32 may be able to support the simultaneous connections, but both of those modules would likely require firmware updates (as they came out before BT 5.x was ubiquitous) and I imagine that the host controller to properly handle the simultaneous connection would need to be created, neither of which Digilent has support for.

    I do not know if wireless communication is a requirement on your end, but sending data over physical wires (such as UART) between the FPGAs would almost certainly be easier and faster communication than the overhead of managing a wireless stack on an FPGA. If you are needing to do wireless communication, I do not have any specific recommendations from Digilent that will nicely meet your needs.

    Thanks,
    JColvin

  21. Hi @DaniS,

    I verified that the workspace you attached causes WaveForms to crash while attempting to open it in 3.22.2 on my Windows 10 machine.

    I don't know what might have changed on the software side of things, but I have been successfully running the attached workspace without apparent issues for several minutes on the latest beta version of WaveForms:

    Please let us know if you still encounter any issues.

    Thanks,
    JColvin

  22. Hi @gcb,

    I think I understand what your confusion is and will do my best to help clear it up.

    "Continuous digital play is not available with any device". -- It is not possible on any Digilent device / through WaveForms to have an existing file of digital data on your host computer and then stream/play back ("reverse digital recording") that data on the 16 Digital I/O channels (or however many Digital I/O signals on a Digilent device).

    There are three potential alternatives that partially resolve the above inherent limitation and might help you.

    1. One is the Play function exclusive to the Digital Discovery where you can take previously captured digital data and play that captured digital data back out on different digital lines. But as you are not working with recorded data, this will not help you.
       
    2. The second potential work around is to use the Arbitrary Waveform Generator/AWG/Analog output channel. The AWG does support the streaming of data from a file stored on a host computer. This (in my limited understanding of the backend of WaveForms with poor terminology) loads/buffers the file into the WaveForms application which then feeds the data to whatever Test and Measurement Device output buffer in a circular manner.
      There are two catches with this method. The biggest one is that because you are using a single analog output channel, that is equivalent to only using a single digital channel / 1-bit digital data (on/off). The second catch is WaveForms feeds the file data to the device's analog output buffer over USB; if the device's buffer is small and the USB connection is slow, you may be at risk to lose/miss some samples while streaming the data.
      Regarding that second catch, the AD3 only has a 32k device buffer size and supports up to 4 MS/s for streaming out analog output data. The ADP3x50 and the ADP2230 have much larger buffers thanks to their on-board DDR memory.
      The 2230 also uses USB 3.0 to further help out with the streaming of data, letting WaveForms rapidly stream large chunks of data into the big buffer, putting you at far less risk of losing samples while any USB overhead/handshaking occurs before the next chunk of data is streamed over. This does not get around the fact that you are working with only a single channel output though, which might be a deal-breaker if you are wanting to stream multi-bit digital data in parallel.
       
    3. Third workaround is to simply load the entire custom data into the device's on-board memory for analog output or digital output. You won't have the risk of missing any samples as you are not streaming, but are, of course, limited to the buffer size for how much data you can pack in.

    Let me know if you have any questions.

    Thanks,
    JColvin

    P.S.

    Quote

    How does the memory map to each byte of the buffer? If there are 16 playback channels, each sample would use 2 bytes?  So a buffer of 128MB would be 64M samples?

    For my application I want to output at a rate of 1M. So 64M samples would be 64 seconds of playback?

    If digital data streaming was supported, your math principle is correct. Technically you would get more samples and seconds of playback out of the deal because the all of the MS values are rounded down from MiS, meaning 64 MS is actually 67,108,864 samples, but you have the right idea regardless. There are a couple of lines in the various specification documents mentioning this, but it's definitely one of those "another sentence in a big block of text" situations.

×
×
  • Create New...