Zmod ADC Acquisition Problem

[ebaser]

 

Hello,

I'm trying to validate my design which I produce 1MHz sine wave using a DDS compiler through Zmod DAC, connected to Zmod ADC with a cable, and capturing the data with Zmod ADC, then sending the data through UART to MATLAB to check if a continous sine wave is coming at 1MHz. 

Unfortunately, I get sine wave pulses width of 4096 samples at some points, not a continous wave form. Results below show the plotted result of 100000 samples. 

I ran the MATLAB script several times, but the result doesn't change. There are always a 4096 samples of RF pulse, rest is noise. I'm not sure if it is related the length of FIFO buffers used in ZmodADC IPs. I tried changing the length of the buffer I use in PS but it didn't change anything. 

Any advices?

Thanks in advance.

[zygot]

Well the answer is in your implementation detals.

Have you looked at this: https://forum.digilentinc.com/topic/20153-capture-4-channels-of-120-million-adc-samples/ ?

OR this: https://forum.digilentinc.com/topic/17006-resolving-chronic-itch-with-the-ethernet-phy/ ? 

Let's start with your design requirements. Ignore the DAC for now because there are a number of ways to produce a sinewave, depending on the quality of the signal. At a particular Fs what is the maximum time that you need to collect contiguous ADC samples? What kind of post=processing can be done in the PL?

 

 

[Pavel]

On 3/10/2021 at 11:48 AM, ebaser said:

Any advices?

I think that UART isn't the most suitable interface for this kind of applications. Since you use the Eclypse Z7 board, its Ethernet interface is the most suitable one. It is not much more difficult to use than the UART interface.

If you are interested in collaborating, I could try to help you with this project.

[ebaser]

2 hours ago, zygot said:

Well the answer is in your implementation detals.

Have you looked at this: https://forum.digilentinc.com/topic/20153-capture-4-channels-of-120-million-adc-samples/ ?

OR this: https://forum.digilentinc.com/topic/17006-resolving-chronic-itch-with-the-ethernet-phy/ ? 

Let's start with your design requirements. Ignore the DAC for now because there are a number of ways to produce a sinewave, depending on the quality of the signal. At a particular Fs what is the maximum time that you need to collect contiguous ADC samples? What kind of post=processing can be done in the PL?

 

 

My aim is producing a chirp using DAC periodically and get the reflected wave back through the ADC and send this data directly to the PC for post processing. In this design, I put the DDS data to DAC using the DMA in PS side. DMA reads from the DDS at first, then it sends back to the DAC Controller Module. One thing I noticed at first is fnIsDMATransferCompleted returns always zero when I try to move data from DDS to DMA. Maybe that is one of the causes of the problem. The only additional feature for the FPGA part is synchronizing the DAC and ADC. What I mean is, when the chirp is started to being generated, ADC should also start eventually and I need to get those samples only. For example, if I'm producing chirps with a frequency of 0.5KHz, I have to collect 0.6-0.7ms of continious data from the ADC which equals to 60-70K samples. Triggering I want to achieve is like in the graph below.

[zygot]

What you want to do is certainly doable. If you use the current Ecypse-Z7 high level support the maximum number of contiguous samples is 16383. It's also very hard to work through.

ZYNQ reflects a small portion of my working expertise so I'm probably not the best person to comment on using that platform. Personally, your project would be a LOT simpler on a non-ZYNQ platform like the XEM-7320. This is especially true if for a stimulus/response post-analyze on a PC kind of application. Opal Kelly makes collecting samples to DDR and uploading/downloading to the DDR through a USB 3.0 interface about as easy as one could hope for. An all HDL project is as easy as one could do. This is, of course my personal perspective. @Pavelmight have a different perspective. More perspectives are better then fewer perspectives but ultimally you have to do your project according to what makes sense to you. I encourage you to look at his recent post in the Project Vault.

The Z7020 PL is similar to an Artix A75 device. You can certainly use the Digilent low-level ZMOD supporting source to connect the SYZYGY converters to  your HDL and there's plenty of BRAM to store 1 channel of 64K samples. The problem for the platform is getting data off the board and into your PC application. Personally, I'd rather do some HDL, write one PC application using the free version of VS2019 that configures the FPGA, controls xmit and rcv processes in the HDL and collects the resulting ADC samples. In my world I like to do as little work as possible because that lets me do more projects.

[ebaser]

16 hours ago, zygot said:

What you want to do is certainly doable. If you use the current Ecypse-Z7 high level support the maximum number of contiguous samples is 16383. It's also very hard to work through.

ZYNQ reflects a small portion of my working expertise so I'm probably not the best person to comment on using that platform. Personally, your project would be a LOT simpler on a non-ZYNQ platform like the XEM-7320. This is especially true if for a stimulus/response post-analyze on a PC kind of application. Opal Kelly makes collecting samples to DDR and uploading/downloading to the DDR through a USB 3.0 interface about as easy as one could hope for. An all HDL project is as easy as one could do. This is, of course my personal perspective. @Pavelmight have a different perspective. More perspectives are better then fewer perspectives but ultimally you have to do your project according to what makes sense to you. I encourage you to look at his recent post in the Project Vault.

The Z7020 PL is similar to an Artix A75 device. You can certainly use the Digilent low-level ZMOD supporting source to connect the SYZYGY converters to  your HDL and there's plenty of BRAM to store 1 channel of 64K samples. The problem for the platform is getting data off the board and into your PC application. Personally, I'd rather do some HDL, write one PC application using the free version of VS2019 that configures the FPGA, controls xmit and rcv processes in the HDL and collects the resulting ADC samples. In my world I like to do as little work as possible because that lets me do more projects.

For a non-zynq platform like XEM-7320, is it easy to interface Zmods with them using only the HDL? I can afford to change the board if it becomes easier as you said. I couldnt make it work from PS to write and read at the same time for DDS and Zmod DAC Controller. DMA Transfer completed flag always return zero even I manage tlast on HDL and insert it at the end of sweep. I'm trying to solve this all day long but no results.

[Pavel]

16 minutes ago, ebaser said:

I couldnt make it work from PS to write and read at the same time for DDS and Zmod DAC Controller. DMA Transfer completed flag always return zero even I manage tlast on HDL and insert it at the end of sweep.

It's not a good idea to send the data from one FPGA module to other FPGA module via the CPU. DDS and DAC should be directly connected inside the FPGA. If you're interested I can send you an example showing how it should be done.

The XEM-7320 board has almost the same FPGA as Eclypse Z7 only without the CPU. So, it'll enforce you to connect the FPGA modules directly.

If you want to change the board, then I'd suggest switching to ADALM-PLUTO. ADALM-PLUTO has an on-board GHz transceiver that would simplify the analog part of your radar project.

[zygot]

4 hours ago, ebaser said:

is it easy to interface Zmods with them using only the HDL?

I've done a few XEM7320 ZMOD projects including this one: https://forum.digilentinc.com/topic/20331-more-fun-with-phasors/

 

I happened to use the low-level ZMOD control VHDL provided by Digilent for the Eclypse-Z7 for a number of reasons. If I were to do a design for a customer I'd write my own HDL... and probably will anyway at some point when it bubbles up the ToDo list in priority. Pavel is pushing me to reassess my Eclypse-Z7 interest which basically disappeared a while ago.

4 hours ago, Pavel said:

The XEM-7320 board has almost the same FPGA as Eclypse Z7 only without the CPU. So, it'll enforce you to connect the FPGA modules directly.

This is an interesting point. I tend not to use Xilinx IP like the DDS compiler for a number of reasons. One is that I can generally do better writing my own IP that uses fewer resources and is more finely tailored to my needs for a particular project. The other is Xilinx support over time. I don't fixing projects broken by new tools releases. Also, you never know when free IP will change to not free. It's complicated. The most compelling reason to write your own IP, other than as an educational exercise, is that there are never encrypted sources and I can understand what I designed easier.

Opal Kelly does things differently and if I didn't have past experience using their boards and support I'd choose not to use them. They don't provide schematics. They provide netlists for IP necessary to connect a Software Application to the you HDL. What a board like the XEM7320 does offer is a decent sized DDR and Opal Kelly provides demo code to allow users to make use of it, unlike other many other FPGA board vendors. They provide good support for connecting your HDL application to a variety of PC applications. For me, writing an FPGA HDL application ( with DDR this is mixed as the external memory controller has to be Verilog ) and one PC software application is as good as it can possibly get. I have (almost) full control over the source. Of course, for many projects I can do this without Opal Kelly. Digilent makes two nice platforms with FMC connectors so I can add my own USB 3.0 Super-speed connectivity to a PC application using only HDL and C/C++ with familiar tools and no cross-compilation hassles. For SYZYGY there just aren't that many platforms to choose from. I do hope that this will change.  I've been begging for a Genesys2 ( or Genesy2 class ) spin with SYZYGY ports. I'm very keen on SYZYGY. All FPGA development boards should allow the user to take full advantage of FPGA devices that they are buying. 

The XEM7320 doesn't force me to connect the FPGA modules or ZMODs directly, it lets me do that. For me the most important objective in choosing a platform for a particular project is this: doe it let me meet my objectives working the way that I want to work or not? Does it offer a path to shorten my project timeline by providing support for the platform interfaces and features or do I have to add extra sub-projects to develop my own IP for them?

I can do ZMOD designs a lot easier and quicker on the XEM7320 than on the Eclypse-Z7. I can also do things that the Eclypse-Z7 just can't do because of its design. A complication for the Eclypse-Z7 is the way that they implement they SYZYGY DNA functionality. It just gets in the way of development and makes things more complicated. But I can say that the ZMODs do work on platforms by other SYZYGY vendors, mostly if you ignore a few things.

What's good for me isn't necessarily good for someone else so I can't counsel anyone about what they should buy. I can offer experiences and personal perspectives.

[edit] SYZYGY aims to offer "Plug and Play" connectivity for the FPGA universe. In theory FMC could do that as well as they have an EEPROM to provide the same basic service as SYZYGY DNA. The problem is of course that every FPGA platform has not only a unique FPGA device but a unique PCB design. This means that users have to assign pin location assignments for a particular board. This involves a certain amount of tedious work tracing signal flow through tow or more schematics. I've always said that for FPGA design using new external hardware this exercise should be done. Recently, I was victim to bad assignments for the Genesys 2 master xdc file that's been around for years ( and recently corrected ). So you can't even trust vendor constraint files. The schematic is the only true guide... and Digilent's are better than most. So my point is 'easy' is a relative terms, especially when talking about FPGA development.

 

[zygot]

I suspect that Pavel and I can agree that we disagree on one thing. Pavel seems tho think that an FPGA with embedded ARM cores are always better than an equivalent FPGA without the ARM cores. I think that when an application demands an embedded FPGA processor then yes, choose that device. When it doesn't, then you are much better off without it. Digilent, seems to be with Pavel and if you look at the next wave of Xilinx high end families they seem to think this as well.

I espouse the idea of simpler is better, less complex is better, more control is better. If I get to choose the development tools and platform that I use them on that's better than if I can't. If I can design an application and then choose the FPGA vendor to suit other considerations after the fact then that's better than if I'm tied to one vendor and one development flow. To me, for programmable logic development, this means all HDL project sources.

I love ZYNQ. I don't love having to use the AXI bus because I happen to believe that it's too complicated for the use cases that I have for a Processor/FPGA desing and that there is no technical reason why such a general purpose bus should be a requirement for my development. There could (should) be a simpler data pipe between the ARM complex and closely coupled programmable logic on a device. I just need a simple hose to squirt data through because my HDL can work out the details on its end. ZYNQ could be optimized for the customer's interest rather than for the vendor's interest. I'd estimate that perhaps 10% of the projects that I do or would want to do can be done easier or better with ZYNQ. There are other options for combining the power of programmable logic to processor based platforms.

To accomplish a goal do what make sense, not what vendors tell you is good for you.

[Pavel]

52 minutes ago, zygot said:

Pavel seems tho think that an FPGA with embedded ARM cores are always better than an equivalent FPGA without the ARM cores.

Not at all. My point is that @ebaser has already Eclypse Z7 and I try to help him understand how to use it more or less optimally.

Otherwise, I use a lot FX2LP+MAX10, but it's not the subject of this thread or even of this forum. So, I apologize for this short off-topic.

[zygot]

Well, I suppose that I should be the one making the apology for misinterpreting Pavel's comments, and worse yet speaking for him.

@ebaser, if you take the time to implement the project that Pavel has so generously posted to the Project Vault and look through what's there I believe that you can use that as a guide to making your project work on the platform that you have. Digilent, doesn't provide the high level support that you need... but with enough effort the platform can certainly accomplish your objectives. Pavel provides some good AXI examples but you'll have to do some reading between the lines to make the connection to his use of the ZMODs and the way that you are likely to want to use them. Think of his code as a high level prototyping guidebook, more like a Rosetta Stone, rather than a set of building blocks that can be used as is to build anything that you could want. He is showing you how to do ZYNQ development for a poorly supported platform and keep your sanity. The fact that he was able to port a code base for a different ( yes still a Z7020 device ) platform with relatively minor modifications speaks volumes.

I have all three of the SYZYGY FPGA platforms that I know of, so choosing one over the others is easier for me. If I were to do what you want to do I'd select the XEM7320 because it's be quicker, less complex and easier to expand on for similar projects. Of course I've already gone through the pain of learning how to use Opal Kelly's supporting code to my advantage. Pavel's code doesn't support the many user controllable features of the ZMODs because his goal was to demonstrate a development concept... and he did that spectacularly. Regardless of how you proceed you will need to do some HDL design. As I've mentioned before the Eclypse-Z7 is a platform for seasoned FPGA developers for now. I do hope that this will change in the near future. What they can do immediately is make that clear in their marketing.

[edit] Actually, for a project where I'd use an FPGA platform for waveform generation and capture but want to do post-processing on a PC I'd use a PCIe board that has connectivity to converters and reasonable driver support. Such a path does exist. As of today no such board exists that lets me use the excellent ZMODs that Digilent has available. But there are other considerations for practical digital signal processing platforms like the availability of external Fs clocking, etc. Every application has its own necessary criteria that needs to be met.

[edit] Ignore the scratched out ignorant statement as it's been pointed out to me that it's an exaggeration  ( to the point of being false ). While I'm correcting misstatements I know of 5 platforms with some kind of SYZYGY and I've used 3 of them. For now, having 1 SYZYGY port seems a bit underwhelming given the small selection of SYZYGY pods available. If you want to develop your own SYZYGY pod then choose a platform carefully.

[Pavel]

1 hour ago, zygot said:

Pavel's code doesn't support the many user controllable features of the ZMODs

I might be missing something, but I've tried to implement most of the user controllable features of Zmod ADC and Zmod DAC. The signals for the relays are implemented, the SPI commands are also implemented, the dpmutil program is present. Maybe they're not implemented in a way as you would have done, but that does not mean they are missing. I can only think of one or maybe two small features that I haven't implemented, but I think they're insignificant. Anyway, when you're writing "many", I think you're exaggerating.

Please let me know what is missing.

[zygot]

@Pavel

My comments were based on my perusal of your code... but obviously I wasn't digging deep enough to see support for the relays or other features ZMOD modules. Uh... that's two apologies in 1 day.  I'm keeping count because I don't like putting myself in a position where I owe anyone an apology. I'll be less hasty before writing opinions. One nice thing about Verilog is you can write terse code. One bad thing about Verilog is that you can write terse code.   I've been in and out of your project when not working on other stuff and evidently I'm pretty bad at multi-tasking. You code is clean but quite terse.

I scratched out the offending comments.

 

[Pavel]

Thank you for clarification and for updating your comment.

[zygot]

1 hour ago, Pavel said:

Thank you for clarification and for updating your comment.

I do occasionally make incorrect statements. I not only welcome anyone who spots such faux pas to post a challenge but rely on it. 

I'm gone back over your source and yes, you are correct that this isn't how I'd do it. That's a partial explanation, though certainly not an excuse, for how I arrived at the wrong conclusion. After reading posts to this site for many years I'd say that most readers will be scratching their heads trying to figure out how it's all connected. I don't intend that as a slight in any way. In general the code posted to the Digilent Project Vault is written to be accessible to less sophisticated developers for instructional purposes. This is just my observation. Your coding preferences don't detract from the worth of the effort. It just might not be as helpful to a large span of reader skill levels. By and large most people posting here with questions want to follow the development flow used by Digilent's demo projects. Again, none of this is a criticism, just a comment. And I could be getting this wrong as well. On the other hand I am sure that there are a few people who have been reading our running dialog on multiple thread and should be talking about how what it means for their bottom line.

But, thanks for not using System Verilog. That's still on my (quite expansive) list of things to learn... still working on basic Verilog. R is also on that list so thanks for the code sample.