Jump to content

Capture 4 channels of 120+ million ADC samples


zygot

Recommended Posts

Capture 4 channels of 120+ million ADC samples per channel. As a proof of concept project I just completed a design using the Opal Kelly XEM7320 with 2 Digilent ADC14010 ZMODs in a direct to DDR 4-channel ADC 100 MHz Fs application.

Opal Kelly has a unique approach to  FPGA development that generally appeals to software developers. For me they do a few things that usually are show stoppers. For one most boards have a closed configuration/PC interface. The only way to use their boards is with pre-compiled encrypted netlists. For another they don't provide schematics, or even partial schematics. Their price point for hardware verses say Digilent or Terasic is substantially higher. Still, I've had success with their products which allows me to overlook the bad stuff.

It's great that Digilent has gotten into the SYZYGY game with two very good converter ZMODs. Not so great is their inability to make an FPGA platform product that showcases the potential for what amounts to as an opportunity to use Xilinx Series7 Select IO in all of it's glory. SYZYGY isn't the only way to go, though it is a worthy attempt at a plug and play cross-platform cross-vendor standard. Any board vendor can make an FPGA board that allow users to explore the full value of the Xilinx Series7 devices, they just have to want to and then design board that allows it. Don't let marketing people design boards, hire an experienced FPGA guy person and let him them design boards. Trust me it'll all work out in the end and everyone will be happy. You'll make money and you will have a broader customer base buying your stuff.

The XEM7320 is the only non-ZYNQ board the Opal Kelly offers. It has an Artix 75T device and is priced competitively with the Eclypse-Z7. The XEM7320 has 2 standard ports and 1 transceiver port verses the Eclypse-Z7 2 standard plus 2 PMOD ports. The XEM7320 has a USB 3.0 PC interface and the tools for configuring the device from within the software application. The important feature that the XEM7320 has with respect to SYZYGY is a 1GB DDR device that ZMOD ADC samples can be written directly to. 

I was able to bootstrap the Opal Kelly RamTester demo C++ and HDL code to make an application that can capture 128M 16-bit samples on 4 channels using 2 ADC1410 ZMODs. It's an all HDL mixed VHdl/Verilog design. No MicroBlaze. No board design. (almost) no vendor tool version issues. No SDK or Vitas, just VS2019, which is free these days. I used the Digilent ADC1410 low level controller code as a first cut though I will be replacing that with a more appropriate approach later. The DDR is essential just a very large FIFO.

The whole design resource useage:

LUTS   <20%

LUTRAM 5%

FF  8%

BRAM <10%

DSP 2%

The VS2019 application configures the device and saves all data to an ascii file for use with SCILAB to OCTAVE.

The only big issue at this point is viewing large 4 column matrices in a waveform rendering. I'm open to suggestions. How is the best way to render a plot of this:

d = [

float4, float3, float2, float1, //sample 0

...

...

float4, float3, float2, float1] //sample 1048575

Thanks Digilent for bringing 100 Ms/s ADC/DAC options to the general Xilinx user audience. It's been a long time in coming.

[edit] Apologies to anyone reading the first version of this post where I got the sample count wrong. If I had a marketing guy writing this the title would have read " Capture over 1/2 Billion ADC samples". I hate it when the details deflate the high expectations of the attention grabbing headline, even if over half a billion samples is technically correct. I should point out that so far I've only capture and uploaded 1*1024*1024 sample for all four channels. The reason being that I don't have a way to verify more data than that. I did start of with a 100 MHz 64-bit counter written to DDR and that I was able to confirm. Even with a very fast USB 3.0 interface converting bits to mV and formatting even 10*1024*1204 samples and printing the data to a file takes more time than I want to spend at the moment.

[edit2] Gender and skill are not correlated at all. Don't select books or talent by the appearance of the cover.

Edited by zygot
Link to comment
Share on other sites

@zygot,

This sounds like a fun and perhaps even a nicely well paid task.  Nice.

Help me understand an overview here ... was that 4 ADCs of 100Msps coming in on each ADC?  How many bits per ADC?  (16'bits) How wide is the SDRAM you are working with?  Stored into DDR3 SDRAM via a virtual FIFO, right?  and then, you came off the board onto USB3 did you say?

Can you give me any indication of  how close you came to the throughput limits of either the SDRAM memory or the USB3 offboard transport you used?  Just trying to understand how much of a challenge it was to achieve your objectives here.

Were you using Xillinx's AXI crossbar, or was the virtual FIFO the only component that accessed memory?

Looking forward to hearing more of this fun project,

Dan

Link to comment
Share on other sites

Two ADC ZMODs each with a dual 14-bit (sign plus 13 bits) ADC. All four ADCs sampling at 100 MHz. This is an Artix 75T and is comparable to the PL in a XCZ020 device. No AXI anything. No processor cores. Just a couple of FIFOs, a DDR read/write controller, a Mig DDR soft controller, and some control logic. The ADC data is gain and offset calibrated so some of the bits can be thought of as fractional. But the DDR data write rate for 4 channels is 100 million 64-bit words/s. The DDR has a 32-bit data path. It sure would be nice if the Artix had a hard DDR controller like the Spartan6 it replaces as the Spartan6 DDR controller is both higher performance and more flexible. Unfortunately, the Mig is stuck with a 4:1 controller/DDR clock ratio, but it all works out. The DDR, for this application, is essentially a giant FIFO. A small state machine controls how many words are are captured and after capture the host application reads out the contents of the DDR. If you want to capture 128M samples per channel you could just write the DDR and use it as a circular buffer though this would complicate the design a bit. As I mentioned this is just a proof of concept design at the moment. This shows the possibilities for the boards involved. The SYZYGY is capable of demonstrating Series7 Select IO and each SYZYGY port could support a quad 16-bit ADC though the DDR would have to be beefier for 8 channels. Then there's the limitations of a small FPGA board and its power supplies. The FPGA never got above about 50C as measured with a infrared temperature sensor and has no heat sink. I'll probably add one at some point. The USB interface is vendor provided encrypt netlists and somewhat odd to work with but can do sustained 350+ MB/s data transfers befitting such a platform. The application was written in C++ using VS2019. As I mentioned I used as much vendor supplied code as possible to get off and running quickly. I had to do a few preliminary projects to create the Mig so the early ones were all Verilog. Once things came into place I copied the Mig and instantiate all of the Verilog into my VHDL toplevel entity. The USB interface allows for changing gain and offset calibration coefficients on the fly as well as analog front end gain and coupling options. It's all a lot cleaner and uses way less resources than AXI IP. Because the ADC data is aggregated into a 64-bit data word and written to an asymmetric FIFO (64-bit write, 1024 bit read) the application has to do some additional formatting to take 8-bit chars and create scaled real data in Volts.  The ZMODs are nicely thought out and well implemented. A nod of appreciation to the design team responsible. Great job!  It's really an adaption of the Analog Explorer ADC design beefed up for a higher performance platform.

The only Xilinx IP are the native MIg and FIFOs and an MMCM.

The thing that should impress people is the low resource utilization for the entire design. Try that with a Microblaze tricycle design approach!  In the real world no one uses MicroBlaze because it takes up most of the resources and leaves the designer with little left to work with.

I'm still looking for that FPGA board that let's Series7 really shine. Take the Genesy2. Remove the FMC connector. Add 2-3 standard SYZYGY ports and a 4-lane SYZYGY transceiver port. Make the DDR with a 64-bit data path, keep the mDP as is, call it Genesys3 and now we're talking business**. TI makes some nifty Ultrasound AFE devices that could work with a double-wide standard pod arrangement. Actually, there's a lot of possibilities. As I pointed out earlier SYZYGY isn't necessary but is a nice format that allows for a wide range of FPGA design applications. For too long now students and experienced engineers on a budget have had to make do with hardware that doesn't allow them to make use of the resources of the FPGA devices they are paying for. That's more than a shame.

I could have done a similar 4 channel ADC design with the Cyclone V GT development board and two DDC HSMC mezzanine cards and used the PCIe 4-lane Gen2 as a PC interface though it would be messy since that board isn't really designed to sit in a PC properly. I have used a PCIe extender cable with that board. It's just nice to be able to do this with a Xilinx device and tools. The PCIe data rate is high enough to stream data directly into the PC memory.

 

** [edit] If you are going to make a nice platform like this it should have at least a USB3.0 interface for interaction with a PC and these days most boards that aren't the lowest end should have at least 1 high quality programmable clock module. Designing a good FPGA board is hard work. Why waste the effort by doing something half baked?

Edited by zygot
Link to comment
Share on other sites

An additional thought. It took me a lot less time to make use of the ZMODADC1410 for this application than it did trying to work out the overly complicated and poorly thought out Eclypse-Z7 supporting code... and I'm not close to being done with that as I write. Compare the two approaches. Compare the usability. with this platform I can write a PC application that configures the target FPGA, executes an application and quickly gets data to a PC for analysis or storage. The Eclypse-Z7 can't do any of that. At this point it can't do anything without an SDK or Vitas support.

[edit] I'm still hopeful that Digilent has the will to at least make the Eclypse-Z7 live up to its potential. It's flawed but still worth the investment in development time to allow users to do interesting things with. 

Edited by zygot
Link to comment
Share on other sites

11 hours ago, D@n said:

was the virtual FIFO the only component that accessed memory?

If this was a ZYNQ platform and I was using the AXI Virtual FIFO I wouldn't be able to capture more than 4 channels of 32K samples each as there is a limit of 256KB with the core.

My philosophy is that pipes that just move data around should be as simple and fast as possible. The complexity should be in the logic. For ARM based FPGA devices the hard ARM complex is best suited to handle complexity that end. For the PL this is where your logic resources are. There's absolutely no design justification for putting AXI busses between the ARM complex and the PL. A simple bus with address, data and a handful of simple gating controls is ideal. Instead of 4-8 AXI pipes connecting the PS to the PL, and perhaps an application only using 1 or 2 of them,  there should be one or two really wide fast pipes letting the user can decide how to best use them for their application. I mean customized application specific logic is the reason for being for an FPGA. It sure can't compete with non-programmable logic. Now if you are designing a ARM CPU without programmable logic I could see where you might want to expose complicated AXI or AMBA busses to the user who might want to hang a number of all sorts of peripherals with a combination of low speed low throughput and high speed high throughput. For an FPGA with an embedded hard ARM core complex this makes no sense to me.

Link to comment
Share on other sites

@zygot,

If you just want to move from an AXI interface to a simpler interface, you can convert it to either AXI-lite or WB without too much hassle.  I just might have some bridges to handle that conversion lying around--bridges that will keep the entire bus running at 100% capacity.  That would handle your criteria of "a simple bus with address, data, and a handful of simple gating controls".  It's unfortunate that AXI-lite is a second class citizen in Xilinx-land.  The AXI-lite protocol is quite capable, but many of the AXI peripherals that use it are not (cough, like the AXI BRAM controller that'd drop AXI-lite throughput to 25%).  Thankfully, the MIG core doesn't seem to mind one way or another.

One of my own criteria when building my AXI data movers was that they should be able to handle 100% throughput even across burst boundaries.  Judging from Xilinx's spec, Xilinx's cores don't do this, and so there is a throughput difference between the two implementations.  A second difference is that I never limited the transfer to 256kB ... :D  Of course, I don't have a virtual FIFO to offer.  Never thought of building one.  If I did have to hack something together in an afternoon, it'd be a WB FIFO that then used a WB to AXI conversion (while maintaining 100% throughput ...)  Indeed, I did manage to build a fully verified WB stream to memory converter in a single morning, whereas the AXI equivalent took several days to get right.  Yes, there's a cost for all this added complexity.

I think I might disagree with you about CPU design being one potential or even necessary user of such a complex bus structure.  It doesn't need to be so.  Indeed, IMHO AXI is waaayyy over designed--but that's another story.  That said, I've been burned with cache coherency issues, so I can see a purpose for a protocol that would help the CPU maintain cache coherency.  It's just that ... AXI isn't that.

Dan

Link to comment
Share on other sites

38 minutes ago, D@n said:

If you just want to move from an AXI interface to a simpler interface, you can convert it to either AXI-lite or WB without too much hassle.

I think that our wires are crossed.

Except for some potential ZYNQ designs where it's unavoidable, I don't want to see or touch anything AXI. Even with ZYNQ I can usually step around them employing BRAMs or AXI FIFO streaming interfaces where I'm not worried about efficiency or data throughput. I don't see much use for all the hassle of incorporating an ARM into an FPGA design except for rare applications. For something like making a mid to high performance FPGA platform a ZYNQ solution is just going to get in the way. Now, it's possible to design a ZYNQ board that lets users do advanced IO designs. You just have to be willing to put enough PS DDR on the board to support it's OS and room for some large data buffers that might connect to the PL. You also have to provide the PL with its own DDR so support those advanced IO applications. Unfortunately, finding a moderately priced ZYNQ platform that does that is a rarity... off hand none come to mind.

Yes, I can see using a well designed AXI Master packaged in a way that's suitable for the Vivado flow so I can quickly build a standalone SDK application in the SDK or Vitas. Got one of those?

No I have no interest in experimenting with lots of 'bus adapter' IP that involves busses that I want to avoid like the plague.

Really I just want a nice non-ARM FPGA platform that doesn't prevent me from using all of that nice Series7 Select IO to its fullest capability.. and a 1gE or better yet 1,2.5,5,10 gigabit port, and a usable PCIe or USB 3.x platform/PC interconnect. The old Z7000 is really not ideal for a nice Linux/FPGA development platform. In theory the UltraScale ZYNQ families now have the processor horsepower to keep up with a Raspberry Pi 4 but the IO requires too much additional hardware to use the PL with most existing stuff that you might want to use it with. So you can get a cheap UltraScale board for less than a decent Z7020 board but you can't afford to connect it anything without a lot of expense and effort building you own adapter boards. I suppose that this is the price of technical advancement. 

One point of this exercise is that using only HDL and even a low end plain old FPGA platform that has been reasonably well designed can do a lot more than a comparable ZYNQ platform  with a lot less pain with a shorter design time using far fewer logic resources and be reusable in a different project using some future version of Vivado without spending weeks of resolving broken IP instantiations and code depreciation.

"I think I might disagree with you about CPU design being one potential or even necessary user of such a complex bus structure.  It doesn't need to be so."

My reference here is to a standalone general purpose microcontroller IC that a customer might use on a PCB. Even then I'm not advocating for it, just possibly willing to concede that it might serve a useful purpose. I'd still rather have a simple external data pipe to deal with.

Link to comment
Share on other sites

I did figure out a way to scroll though 4M samples in a text file and plot 16K  sample segments at a time using OCTAVE. Not pretty but usable. SCILAB is, unfortunately, just unable to handle matrices larger than about 64KB. No doubt an issue with how they handle memory.

I have a few things to clean up before getting moving on developing a ZMOD demo project that lets them be useful and avoid the dreaded storage closet where old and useless things sit hoping for a second chance...

Link to comment
Share on other sites

40 minutes ago, D@n said:

Any special reason you aren't using a binary file?

Yeah, because I'm a salmon in a bathtub when it comes to writing software. Frankly, hopping back and forth between HDL and C doesn't seem to be getting easier with time.

I tend to like text based data files for debugging or development because for one, I can usually spot most things that are wrong in NotePad++, and two because I don't have to write a GUI application to render data into a visual format. With graphics application software I'm more of a toad in the toilet.... Of course when it becomes necessary I can put in the effort to do all of that if it becomes an important tool that I can reuse. Otherwise, I tend to make do with what I have readily available.

If this project was a full blown complete application I'd have to either format my data to be used with scope waveform viewers or write my own application to handle somewhat large datasets involving plotting, scrolling, zooming etc. Not today.

OCTAVE is pretty well written and current so it turns out that, while it might take 20 seconds to read in a 13 MB text file into memory, slicing the matrix and plotting manageable segments is both quick and a workable solution... for now.

Edited by zygot
Link to comment
Share on other sites

If I forget to set the ADC gain calibration to something other than 0 I remind myself of a really quick and fast way to initialize 1 GB of DDR to all zeros. Sometimes this is helpful and sometimes not so much...

Link to comment
Share on other sites

Geez, I forgot that the baremetal DAC demo only drives one channel of a two channel DAC. It's not encouraging when a product vendor can't even figure out how to demo their own products satisfactorily... perhaps buying another DAC ZMOD isn't such as swell idea after all. There are easier ways to get the job done.... SIGH!

Link to comment
Share on other sites

An update. I did manage to get the Eclypse-Z7 to put out 4 DAC channels. Again, I used the low level controller HDL provided by Digilent to jump start the design. Instead of using the Digilent AXI and SDK support code I re-purposed a previous Eclypse-Z7 test project using BRAM to communicate with my PL HDL. Instead of waveform lookup tables to drive the 4 DAC channels I used my own NCO IP. With the NCO I can get nice sinewaves from a few hertz to a few MHz by writing 1 32-bit word to the IP.

But, I got what I needed in about a day's worth of effort instead of wasting weeks trying to unravel the mystery that is the official Digilent ZMOD repository.

As anxious as I am to create a few interesting demos for the Eclypse-Z7 I'm hesitant because the product has such poor support. There is still no way to control the FPGA fan from a bare-metal application and the Linux support still can't do basic things like configure the PL and run an application....

Edited by zygot
Link to comment
Share on other sites

@zygot,

So ... I got to thinking, a virtual FIFO sounds like a really easy core to design--especially with an application like this one in mind.  Unlike many AXI cores, a virtual FIFO should be able to hold it's AXI burst length constant.  It should also be able to maintain alignment with the memory it's working with--unlike other cores which have to worry about crossing that 4kB boundary when handling transfers with sizes determined at runtime.  Even better, there's no end--so you don't have to check for transferring too much.  That just really simplifies the AXI master by quite a bit.  So ... I got distracted.

Here's what I came up with.  You can see a generalized trace below--it's what you'd get from dropping the burst size from 256 down to 8, but at least it makes a decent picture.

axivfifo.thumb.png.10a208d86a9807c1f1368ac07c7f734b.png

Xilinx declares that their design depends upon their S2MM and MM2S cores.  That seemed a bit heavy-weight to me.  Those cores require an interface, a programmable data length, a length that might end up different from the programmed rate, a lot of TLAST processing and more.  If you just want a FIFO, you can dump all of that junk and make things simple.

Thank you for pointing out the utility of something like this.  It was a fun diversion to design.

Dan

 

Link to comment
Share on other sites

9 hours ago, D@n said:

So ... I got to thinking, a virtual FIFO sounds like a really easy core to design--especially with an application like this one in mind.

What's better than an AXI Master Virtual FIFO for moving large quantities of data from an interface, like say 64 bits of 100 MHz ADC data , into DDR? No standard busses. Which is what I did for this project. It's just straight-forward HDL. There can be a case made for AXI, AMBA, Wishbone, or whatever but if I don't need any of the complexity of such a bus what good is it? Why would I want to worry about beats, bursts, boundaries, and a lot of other details if all they represent is unnecessary complexity and obstacles to achieving the best solution for my particular design problem? I wouldn't is the correct answer.

If my target platform was ZYNQ based, like the Eclypse-Z7, I might want to experiment with your virtual fifo master AXI design; but only if I could use it with the FPGA vendor's SDK tools to write the PS software end of the application. Since you don't know how to do that I'm having a hard time convincing myself that the reward is worth the effort for me to figure out how to do that. But I do respect that you worked out a good answer to one question on a three question test.  What is that.. a C- on the curve? [whenever a prof gives a three question test in which you only get points for a completely correct answer you know that the purpose of the test is to convince most of the class to find another major]

But your post does suggest the need for revisiting a few issues of why ZYNQ isn't always the best platform for FPGA designs. The purpose of this project is to capture lots of data for post-event analysis. If the application was for an embedded self-sufficient device sitting on some mountain collecting and analyzing specific data I'd probably** want to use a ZYNQ device. For this project that certainly isn't the case. Though this was a 'proof-of-concept' project just to prove that it could be done, it turns out to be a pretty useful tool that can be used or modified easily for other projects. By the time you are waiting for Vivado to start up the SDK and update the workspace I can execute a single program on my PC that configures the FPGA and captures all fo the data, and save it to my HD. Well, not you since you don't use those tools.

So, it is possible to create a ZYNQ HW/SW application that uses the Ethernet port, as a user and data interface and can do a partial configuration of the PL to support one of a number of different PL specific applications, and execute it. If you want to run multiple of these applications simultaneously that becomes a harder problem to solve. If you want to make your life easy and use a lot of generic open source code to reduce your software design burden you will likely try using a Linux based OS. For something like the Eclypse-Z7 this is problematic for a number of reasons:

  • Since you only have 1 DDR memory attached to the PS your AXI pipe(s) between the PL and the DDR has to compete with the PS for access.
  • Your OS wants to use a significant about of the DDR leaving little for large quantities of data.
  • running your fancy multi-core ARM code out of a relatively low speed SD card is problematic.
  • Developing and maintaining ZYNQ HW/SW Linux applications is complicated and hard to do.

The first problem to resolve is finding the ZYNQ platform that is designed in a way that allows you to do what you want. This is certainly not impossible. Finding one that's affordable might be. Instead of thinking about AXI when you read this post you should be thinking " Hey using very little resources and using no embedded processor development at all with easily verified and maintainable HDL code can do some interesting things!"

Back to the Eclypse-Z7, assuming that this is the target. It doesn't matter how good your AXI virtual FIFO is, it isn't going to compete with my VHDL/Verilog Artix A75T implementation. And this was a lot easier to do, even with having to figure out a lot of Opal Kelly specific stuff. It's also a lot easier to use. If you absolutely need ARM cores and AXI then you have to put up with the extra hassle. Most of the time, for desktop or lab projects you don't.

[edit] ** Emphasis on probably because there would have to be compelling reasons to justify using an ARM based approach. I would certainly do a cost/benefit analysis first. ZYNQ is great for some applications that require an embedded processor with floating point hardware. It's an impediment for those that don't.

 

Edited by zygot
Link to comment
Share on other sites

Stay tuned to the Project Vault forum. Now that Digilent lets me play with well designed modules that do conversion between the analog and digital realms with a reasonable bandwidth on Xilinx hardware there are all sorts of fun ideas to explore.

Edited by zygot
Link to comment
Share on other sites

  • 3 months later...

@Greatzwall, @JColvin

I think that there's some confusion that needs to be cleared up.  I didn't publish the 4 channel XEM7320 ADC design as it doesn't use a Digilent FPGA platform, and because the design requires proprietary Opal Kelly pre-compiled HDL net-lists for the configuration/USB interface. Also, the software application was based on an Opal Kelly DDR test demo. 

The stay tuned reference I made in this post does relate to a project that I posted in the Project Vault here:  https://forum.digilentinc.com/topic/20331-more-fun-with-phasors/

This also uses the XEM7320 with one DAC ZMOD. It was posted as an alternate implementation of this project: https://forum.digilentinc.com/topic/20299-fun-with-phasors/

which is Eclypse-Z7 based. Functionally, those 2 projects do the same thing. The XEM7320 is different in that the entire user experience involves running one software executable ( windows only at the moment ). The Eclypse-Z7 project involves a somewhat unusual configuration process and waveforms can be changed form within an OCTAVE script. Neither  project includes the complete HDL code but both include enough information to serve the purpose of the projects. There were a variety of reasons for doing this.

I'd be happy to answer specific questions to anyone who wants to duplicate any of the projects mentioned here or in the Project Vault. 

 

 

Link to comment
Share on other sites

  • 2 years later...

Here's the original ( from 2 years ago! ) toplevel entity.

It likely isn't going to make any sense unless you've used Opal Kelly's FPGA boards before. The component ddr3_test is a modified version of supporting code to test external memory provided by Opal Kelly. I did it this way to shorten the spin-up of my first effort with the ZMOD/XEM7320.

This is an all HDL plus Windows/Linux software project. Compare that to the mess that is the Eclypse-Z7 repository; it doesn't matter if you are using the Standalone or Linux software tools. I have no problems with the 2 track HW/SW development flow of ZYNQ; everything is just a lot simpler, easier, and faster when you understand all of the text source code and minimize time spent battling the tools and vendor IP and software libraries that you have no control over. I spent a LOT more time just running experiments with the Eclyspe-Z7 than it took to get this project working. There are plenty of things to complain about with the Opal Kelly boards and support. But what might make them a reasonable choice for real world FPGA project development is that you can, once you get past the learning curve, create a functional application with very fast and stable USB 3.0 connectivity to a PC software application. Since it all HDL, maintaining projects over years of development and tool versions is a reasonable endeavor. For anyone wanting to do ADC/DAC FPGA based projects using the AMD/Xilinx tools the XEM7320, even after 2 years, is the best platform that I know of. This doesn't make me happy, by the way.

Someone has got to create a SYZYGY FMC mezzanine card that works with the Genesys2. Forget the SYZYGY transceiver port, hook up the MFC transceivers to a 4-lane iPass connector ( $12 in small quantities ).

ADC_ZMOD1410.vhd

Edited by zygot
Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...
  • 4 weeks later...
6 hours ago, Ben Jonson said:

For rendering the plot of the large 4-column matrices, you might consider using dedicated data visualization tools like Matplotlib in Python or other specialized data processing software that can handle large datasets efficiently. Breaking the data down into manageable chunks for rendering or utilizing hardware acceleration for data processing might also alleviate the visualization challenge.

Good point. I suspect that trying to display 1 GB of interleaved 16-bit signed data might be pretty painful using interpreted Python. Ideally, it would be nice to mimic what the renderer of my scope when it displays 70 Million data samples covering 4 channels of digitized data. My question was more about hoping that someone would have experience doing this that I didn't have at the time.

Edited by zygot
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...