Jump to content
  • 0

Pmod DA3 on Eclypse Z7


Brogli

Question

Hi everyone

I'm pretty new to the entire FPGA developpment. I have a basic understanding of how VHDL works and I have managed to set up a blinking light with the current setup I have. But my project is a bit bigger than just blinking the onboard LEDs. The goal is to have three analogue inputs (read via Zmod Scope 1410-105s), one analogue output (Pmod DA3), do some signal processing and send the data to a computer. 

I found out how to use the Scopes. I have not yet connected it to a signal generator, but I have a general understanding on how to proceed. But when it comes to the signal output I'm a bit clueless. I think the ideal place to add the DAC is at the PMOD port A or when we look at the .xdc file it would be labeled Pmod Header JA. Is there an IP I can use or some sample project or do I have to program it myself from ground up?

Thank you for your assistance.

Edited by Brogli
Typos and clarrifications and tags
Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0
2 hours ago, Brogli said:

The goal is to have three analogue inputs (read via Zmod Scope 1410-105s), one analogue output (Pmod DA3), do some signal processing and send the data to a computer. 

What you don't mention is the FPGA platform that you intend to use. I imagine that you are using the USB104 with one SYZYGY port.  The 3 PMOD headers are low data rate interfaces ( < 10 MHz ). connecting a PMOD DAC that works at 100 MHZ Fs isn't going to happen.

If your DAC sampling bandwidth is below the 500 KHz or lower range then you might have a fighting chance. I guess that it all depends on what you are trying to capture with an ADC and what you want to see out of your DAC.

 

Edited by zygot
Link to comment
Share on other sites

  • 0

@Brogli

Welcome to the forum.

Digilent doesn't provide an IP or reference code for the DA3. The resource center points to an old demo project, which might require ISE. Interface timing diagrams and requirements in the AD5541A datasheet would be the best starting point for writing a custom controller.

Either JA or JB would be the connection point. On the point of sampling rate, the AD5541A's settling time is 1 us, so a 1 MS/s DAC sampling rate would be expected as the maximum possible out of the DA3. The Eclypse uses some SN74CBT3384C bus switches, so the Pmod ports should be faster than other boards like the USB104 A7, but the actual max frequency hasn't been characterized; SCLK could be a limiting factor.

You should also make sure that there's going to be enough clearance to use the Pmod and Zmods at the same time. With the Eclypse, the Pmod's SMA connector will be facing upwards while the Zmods SMA's will be facing out, potentially colliding.

Thanks,

Arthur

Link to comment
Share on other sites

  • 0

Hello @artvvb 

Thank you for the explanation.

Thank you for the reference to the demo project. In the meantime I looked a bit at the datasheet of the AD5541A and I think the effort of viewing that demo project is too big compared to the effort of reading the relevant timings from the datasheet. When I wrote that comment I lost myself a bit in the documents searching for a proper IP. 

Physically the Pmod and the Zmod do not collide. I already tested that. 

When it comes to the maximum timing I will have to figure it out. But that is something I will look at after I come back after my vacations. 

Thank you too, 

Philipp Brogli

Link to comment
Share on other sites

  • 0

Hello @zygot

I use the Eclypse Z7 which has a clock of 125MHz. And there two SYZYGY™ Ports which are built for the Zmod Scopes. Sadly it only has double ADC or double DAC extension cards and no card with one ADC and one DAC.  So I have to use a DAC over the PMOD port. 

My inputs should be at 10MHz and the output at 1MHz. I'm not sure yet how strong the requirement is when it comes to the number of needed bits. But I assume they are pretty lax with the output and might be a bit higher in the inputs. Based on the comment from Arthur I assume that I will need to replace the DAC for a faster one. But first I want to make it run. When it comes to the prototype it does not matter if the device is a bit too slow as long as I get the proof of concept running. The final implementation will be different anyways and not an islotated system like mine is currently. 

Do you see any possible conflicts when it comes to bandwidth? 

Thank you too, 

Philipp Brogli

Link to comment
Share on other sites

  • 0
3 hours ago, Brogli said:

I use the Eclypse Z7 which has a clock of 125MHz. And there two SYZYGY™ Ports which are built for the Zmod Scopes. Sadly it only has double ADC or double DAC extension cards and no card with one ADC and one DAC.  So I have to use a DAC over the PMOD port. 

Yeah, it's a shame that the Eclypse-Z7 only has 2 standard SYZYGY ports ( and 0 transceiver ports ), and that no one makes a SYZYGY pod with 1 ADC and 1 DAC. The single width pods are pretty small for stuffing all of the features of the ADC and DAC ZMODs into 1 combined pod. I would expect that a double-wide pod could do this. The Eclypse-Z7 is capable of using a double-wide pod but no one makes such a thing to my knowledge.

Your references to MHz and bandwidth are a bit confusing. If you need 3 ADC channels with an analog bandwidth of 10 MHz, then 2 dual-channel ZMODs would do that. Note that the analog bandwidths of the ADC ZMODs are substantially lower than half of the preferred sampling rate of 100 or 125 MHz for the ZMOD ADCs. At Fs = 100 MHz you can decimate samples by 4 down to a 25 MHz sample rate to ease data management. I assume that you mean that your analog input signal bandwidth of interest is between 0 and 10 MHz. IF you need ADC samples at exactly a 10 MHz rate then you will either have to do rate conversion in software ( if possible ) or come up with an ADC sample clock frequency that supports a different decimation strategy.

If you want to use Digilent's higher level sources, you will have your work cut out for you. This depends on how much storage you need for ADC and DAC samples. If you can fit all of your storage into the PL resources then things will be a lot easier.

This leaves your 1 MHz DAC output to be implemented. I don't know of any PMODs with DACs that support 1 MHz analog bandwidth. In theory, if you only need a 500 KHz analog output bandwidth, then perhaps you can use one of Digilent's PMODs. Before deciding on how you want to implement your DAC using the PMOD headers ( you might need to make your own DAC circuit ), be sure to read the datasheets for the SN74CBT3384 FET switch. You will be on your own for figuring out how to implement that. If it doesn't need to be connected to the ZYNQ PS then things will be a lot easier. There are a lot of unspecified details that haven't been discussed, like the relationship between your ADC Fs and your DAC Fs.

Digilent's vision for SYZYGY is pretty limited. A long time ago they asked for suggestions on what users want to see for future products, but I haven't seen any new ZMOD pods that seem designed to fill customer's needs since then. Actually, I'm a bit disappointed that the SYZYGY standard hasn't be as enthusiastically adopted as I thought that it would be.

Edited by zygot
Link to comment
Share on other sites

  • 0

Thank you again for our response. I'm sorry for writing in a confusing manner. Part of it certainly is because I'm new to designing my own FPGA control system. But I could give more attention to write in a clear manner anyways. 

I do have 2 Zmod Scope 1410-105s, so I'm pretty sure I got all three of the analogue inputs covered. Also for our first implementation I've learned that the guy responsible for the electronics accidentally did a cutoff of 1MHz instead of 10MHz and I don't think they see the need for increasing that in the next milestone. Another thing is that they failed to measure 2 out of the 3 signals. Their newly designed sensory circuit is considerably more sensitive, so I assume they will bring it up to 2 out of 3 sensors being useable at the end of the milestone, but no tests have been done yet. Also apparently the only goal for the next milestone is to just observe with no closed loop control yet, so the output is not necessary for now. I still want to implement it though so that my effort later on will be smaller. The improvement to the target specifications will happen in a later iteration. And if I notice that this hardware has some non-solvable limits I can probably buy a new one when the time comes. 

You got it correct that my analog input signal bandwidth of interest is between 0 and 10 MHz. Based on what I've heard, a 500 KHz analog output bandwidth should work well enough too. At the moment I'm still in the proof of concept phase and I don't see any problems with being off by a factor of only 2. I don't think it makes sense to make my own DAC circuit. 

The goal of the control system is to take noisy input signals and based on that do some simple controlling of an output signal. The device to be controlled can take a new command signal every 1μs. As the sensors who observe the system are very noisy I want to oversample the input signals. The oversampling is there purely for noise reduction. So theoretically the two don't have to by synchronous at all. I can have two entirely seperate systems, one for signal analysis and one for the control system, and they communicate with an asynchronous "virtual port". I'm aware, that if I needed just a simple first order low pass filter with a cuttoff frequency of 1MHz, then that oversampling would not be needed and a hardware lowpassfilter would suffice. But one step in that controll circuit needs to have a very fast reaction time. We do not know yet if a first order low pass filter is fast enough for that. I have the hope that with a smart way of signal control, it is possible to shorten my reaction time in case it is needed. I have to talk with other people from the school about that aspect of the task. But for the current milestone this is not yet relevant. 

 

On 7/7/2023 at 6:48 PM, zygot said:

If you want to use Digilent's higher level sources, you will have your work cut out for you. This depends on how much storage you need for ADC and DAC samples. If you can fit all of your storage into the PL resources then things will be a lot easier.

I do not know enough about the storage needs of my control system and the storage capabilities which Eclypse Z7 can offer. Also I have not used any of Digilent's higher level sources. With higher level sources do you mean petalinux? For my first milestone petalinux is not needed. For later steps of the project it will be needed, but I have someone I can contact who knows about that aspect of the development. In the end my project might be integrated into his project. So I don't worry about this for now. 

Link to comment
Share on other sites

  • 0

I've had discussions with people about whether it's better to do top-down system design or bottom-up system design. My approach is both. You need to start with the top level to get a sense of what's required to meet your project goals and establish reasonable specs. Then you need to start identifying black boxes for the tasks that you haven't already figured out. After that you kind of bounce back and forth between thinking about the project from a top-down viewpoint and bottom-up viewpoint as you decisions and progress make everything clearer and options get eliminated. I say all of this because you seem to have a lot of known system requirement that you aren't dealing with until you resolve the lower level design. For one thing you aren't going to be using any normal use of the tools to run the Eclypse-Z7 on Linux if your tools are installed on a Windows host; something to consider now, rather than later. 

As for low-level Digilent support for the Eclyspe-Z7; low-level is the VHDL source that controls the ADC or DAC. Higher level would be the AXI bus IP that connects the PS memory to the converter data. All of that is the same whether the platform is running a version of Linux or the Xilinx standalone kernel. What's different is that for Linux, you have to make the PL hardware available to user space for your PS cores. Also, there will be a lot more burden on the PS external memory, if that's where converter data is buffered because that's where the PS cores will be getting instructions/data as well. While you are taking a break from what you are working on, spend some time thinking about the high level design.

Once you start making commitments to design choices early in development things get difficult if you have to start changing those early decisions.

Edited by zygot
Link to comment
Share on other sites

  • 0
Very often what we think is the problem is really a symptom of a more complimented problem. Sometimes trying to figure out how a design source is supposed to work is instructive, perhaps even usable for the current project. Sometimes it's just quicker to write your own source. I find this to be true even when using my own IP from past projects.

There are a lot of levels of complexity to figure out for even modestly complex designs. Experience is the best teacher when it comes to FPGA development.
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...