SD Card Memory on Eclypse Z7

[atown622]

So I'm running into an issue with processing speeds of the following function:

value[i] =  sqrt(-2*log((rand() % MAX_RAND_VAL)/(MAX_RAND_VAL+1.0)))*cos(TAU*(rand() % MAX_RAND_VAL)/(MAX_RAND_VAL+1.0)) * sigma;

I am generating a random number of gaussian distribution for my output voltage.  I need to be able to do this and still output speeds of 10MHz.  However it seems that this formula takes roughly 100-200us to calculate, no where near the speed at which I need.

Would it be possible to generate all my possible data points into an absolutely massive array before hand?  I would need the write the program to the SD card so that I can have a multiple gigabyte array.  

Is this possible?  And how would I go about programming to the SD card such that the program runs on power up?

I see there is a jumper pin for QSPI/SD/JTAG but I am relatively unfamiliar with these kinds of things, so I am not certain how to program to the SD card (like would I have to call memory addresses there and just further complicate the system?)

Edited June 10, 2022 by atown622
Tags

[Richm]

This is maybe a good application for hardware acceleration?

 

[zygot]

Perhaps you can better explain what it is that you want to do, or perhaps believe that you need to do. Figuring out how to implement something that seems to be impossible has been a the heart of embedded software design since the first microprocessors were first used. Sometimes one over estimates or misinterprets the requirements. Usually something "close enough" will do. Solving the wrong problem might be impossible. Finding the correct problem to solve might be the key.

What I'm imagining is that you want to produce a very long duration analog pulse using a DAC. An unsigned 16-bit DAC has exactly 65536 possible output values. Would you expect that the voltage at the output of the analog buffer that the DAC drives will maintain a value over long time periods to Vmax/65536? Keep that in mind as you ponder your design approach ( and the fact that you are using a signed 14-bit DAC. Time is relative. Defining what exactly it is that one needs to do isn't always easy.

The solution to finding an implementation to such problems usually starts off with a prototype, often done in MATLAB or OCTAVE starting with any available canned functions. Plot it out to visualize it. Then implement a second prototype using only keywords and structures that you know how to implement in logic or code ( you've already figured out how long a particular implementation takes ). Think about a way to implement something similar that still works for your ultimate design goals. The design loop gets closed when you collect output data that matches, within acceptable limits, to the prototype simulations. Usually hardware simulation is an intermediate step. When hardware involves a combination of logic and software it might be easier to just skip the hardware simulation. Sometimes that step has to be done even when it's hard.

Sometimes the brute force approach works. Sometimes it doesn't.

[edit] My answer mentions that "Usually something "close enough" will do.". As a matter of perspective, this isn't quite true. Actually, every design solution that humans or even "Mother Nature" creates is an approximation. Sometimes we forget to keep that in mind. So, any engineering solution really involves correctly identifying a level of precision and accuracy in our solution. It's often useful to start at the end product, in this case a DAC output voltage and work backwards to establish reasonable design specifications. Embarking on an engineering effort without good specifications is a recipe for failure. Edited June 11, 2022 by zygot

[atown622]

2 hours ago, zygot said:

Perhaps you can better explain what it is that you want to do, or perhaps believe that you need to do. Figuring out how to implement something that seems to be impossible has been a the heart of embedded software design since the first microprocessors were first used. Sometimes one over estimates or misinterprets the requirements. Usually something "close enough" will do. Solving the wrong problem might be impossible. Finding the correct problem to solve might be the key.

What I'm imagining is that you want to produce a very long duration analog pulse using a DAC. An unsigned 16-bit DAC has exactly 65536 possible output values. Would you expect that the voltage at the output of the analog buffer that the DAC drives will maintain a value over long time periods to Vmax/65536? Keep that in mind as you ponder your design approach ( and the fact that you are using a signed 14-bit DAC. Time is relative. Defining what exactly it is that one needs to do isn't always easy.

The solution to finding an implementation to such problems usually starts off with a prototype, often done in MATLAB or OCTAVE starting with any available canned functions. Plot it out to visualize it. Then implement a second prototype using only keywords and structures that you know how to implement in logic or code ( you've already figured out how long a particular implementation takes ). Think about a way to implement something similar that still works for your ultimate design goals. The design loop gets closed when you collect output data that matches, within acceptable limits, to the prototype simulations. Usually hardware simulation is an intermediate step. When hardware involves a combination of logic and software it might be easier to just skip the hardware simulation. Sometimes that step has to be done even when it's hard.

Sometimes the brute force approach works. Sometimes it doesn't.

[edit] My answer mentions that "Usually something "close enough" will do.". As a matter of perspective, this isn't quite true. Actually, every design solution that humans or even "Mother Nature" creates is an approximation. Sometimes we forget to keep that in mind. So, any engineering solution really involves correctly identifying a level of precision and accuracy in our solution. It's often useful to start at the end product, in this case a DAC output voltage and work backwards to establish reasonable design specifications. Embarking on an engineering effort without good specifications is a recipe for failure.

Ive already completely simulated this in both matlab and c coding and it does work.  Im just having issues getting that to translate over to this DAC.

 

I am trying to send DC voltages for different amounts of time into this DAC, but I am having issues controlling the speed of this DAC.  For example, I want to output a voltage value for 30ns and then immediately after that a different voltage value for 1000ns.  

[zygot]

2 hours ago, atown622 said:

Ive already completely simulated this in both matlab and c coding and it does work. 

I think that what you mean to say is that looking at a plot of the output of your MATLAB and C simulation appears to look like what you want. Perhaps the situation is better than that, I don't know.This level of simulation represents a mathematically optimal representation of your algorithmic output, not necessarily what your hardware is capable of performing. This is a good student project ( don't be offended as we are all students, or should be ).

I supposed that you've read the Zmod1411 reference manual. It provides good guidance as to what you can expect out of that pod.

You've only presented a bit of information about what the parameters of your objectives are, and that's fine, but limits the efforts of anyone trying to answer your queries.

The manual suggest to you what the analog bandwidth of of the pod is at the output connector. A bit harder to work out are the maximum slew rates and settling rates to an acceptable precision of the desired output voltage. The example that you just provided suggest that you are already thinking in terms of sample periods. Perhaps, you want to be thinking in terms of sample periods representing Fs/2?  What is the minimum realistic dwell period for any output sample? If sample n = Voutmax/2 and has a dwell of 100 Fs/2 periods, and sample n+1= Voutmax and has a dwell of 1 Fs/2 periods, and sample n+2 = -Voutmax and has a dwell of 1000 Fs/2 periods what would expect to see on a high bandwidth scope?

This should be pretty easy to try out. Create a design that doesn't use the PS. It would have a small BRAM filled with Vout values and dwell periods that your design would send to the DAC low level controller. BRAM can be implemented as a PROM or just a regular RAM with a default contents such as a table that you create in a spreadsheet. Add a couple of counters and a bit of control logic and you are in business. Use one of the GPIO inputs to control the design. See what comes out. Trigger your scope with the start signal and capture the DAC output. If you really like the extra work and challenge of doing PS programming you can use an AXI GPIO for control. I haven't read anything that makes me think that your project needs a processor. It's a place to start. There's no harm in experimenting.

 

 

Edited June 11, 2022 by zygot

[atown622]

1 hour ago, zygot said:

I think that what you mean to say is that looking at a plot of the output of your MATLAB and C simulation appears to look like what you want. Perhaps the situation is better than that, I don't know.This level of simulation represents a mathematically optimal representation of your algorithmic output, not necessarily what your hardware is capable of performing. This is a good student project ( don't be offended as we are all students, or should be ).

I supposed that you've read the Zmod1411 reference manual. It provides good guidance as to what you can expect out of that pod.

You've only presented a bit of information about what the parameters of your objectives are, and that's fine, but limits the efforts of anyone trying to answer your queries.

The manual suggest to you what the analog bandwidth of of the pod is at the output connector. A bit harder to work out are the maximum slew rates and settling rates to an acceptable precision of the desired output voltage. The example that you just provided suggest that you are already thinking in terms of sample periods. Perhaps, you want to be thinking in terms of sample periods representing Fs/2?  What is the minimum realistic dwell period for any output sample? If sample n = Voutmax/2 and has a dwell of 100 Fs/2 periods, and sample n+1= Voutmax and has a dwell of 1 Fs/2 periods, and sample n+2 = -Voutmax and has a dwell of 1000 Fs/2 periods what would expect to see on a high bandwidth scope?

This should be pretty easy to try out. Create a design that doesn't use the PS. It would have a small BRAM filled with Vout values and dwell periods that your design would send to the DAC low level controller. BRAM can be implemented as a PROM or just a regular RAM with a default contents such as a table that you create in a spreadsheet. Add a couple of counters and a bit of control logic and you are in business. Use one of the GPIO inputs to control the design. See what comes out. Trigger your scope with the start signal and capture the DAC output. If you really like the extra work and challenge of doing PS programming you can use an AXI GPIO for control. I haven't read anything that makes me think that your project needs a processor. It's a place to start. There's no harm in experimenting.

 

 

I actually have figured out a way around my issues, I just now have to implement it in code.  (some timing diagrams works wonders.)  Thank you for your responses.

 

In short I figured out that the DAC needs 5us to update its output, so I will just be writing 10us worth of data to it at a time, giving it plenty of room for calculations and updating.

[zygot]

6 hours ago, atown622 said:

In short I figured out that the DAC needs 5us to update its output,

What would make you think that? I'm confused. Is this the DAC that you want to hold a voltage for 30 ns before progressing to another voltage?

[atown622]

Sending data to the DAC in a buffer of data is what I am doing.  However the DAC will not let me update that buffer once its sent until roughly 5us had passed.  The dac would just repeat the entire buffer until 5us had passed and then would finally update to a new value.  I am still having issues with it not updating and forcefully repeating multiple cycles of the same buffer data before it is allowing those values to change.... That 5us was just how long I had sent the orignal length of a buffer of data to be.  Now that I am creating 40us of data, it is repeating the same buffer of data every 40us until 1ms+ later when it eventually changes the buffer value. 

Essentially I am having issues clearing out the buffer of voltage values immediately after sending them.

Edited June 12, 2022 by atown622
More explanation of issues

[zygot]

My suggestion is not to keep trying to do what you've been doing; that is modify one of the demos for the board.

The Ecypse-Z7 is not a good platform for someone without good HDL design and development flow skills. I've done quite a few for the platform. It's complicated for even seasoned programmable logic developers. To my way of thinking, the board design and supporting code exposes the basic problem with the IPI design flow, which is especially problematic for a ZYNQ platform.

If you can't create a fairly simple toplevel VHDL or Verilog source file, connect it to the Digilent low level DAC code, simulate it, and get satisfactorily results, then you are in for a very frustrating experience. This involves basic programmable logic skills and is about as simple as it can get. I urge you to take the time to try that approach.

Personally, I created and tested on hardware no less than 15 projects for the Eclypse-Z7 just to evaluate the platform's capabilities and suitability for the kind of things that I'd want to do with such a platform. Taking the time to experiment with intermediate designs can shorten the time to get to where one intends to be, especially if struggling with the basic operation.

[edit]
So, if you choose to accept my advice, you have two things to work out before your project can move forward. For now abandon the Digilent Eclypse-Z7 demos. Abandon the ZYNQ PS. Execute a basic HDL design that instantiates the low level DAC code from Digilent as a start and complete a proper simulation.
1) Figure out how to replace a complicated problem with a simple problem.
2) Figure out if your project project goals are compatible with the hardware that you are using.

If you do this, then a solution to completing your project will become clearer.

You might gain some good feedback as to what your FPGA development skills and competency are. As simple as driving a DAC might seem, this involves a lot more knowledge than a lot of people would suspect. If you have the basic sklll set this shouldn't take more than a day or two. You might struggle with how to initialize BRAM in simulation verses hardware if you haven't done this before. You might struggle a bit with signed binary math if you haven't worked with it before. You'll have a very hard time completing your project without these skills. Edited June 13, 2022 by zygot

[Richm]

One also needs knowledge and experience with DSP since that's what you're doing.

It took me a couple of years of Sundays to finally get comfortable with Verilog, AXI and Vivado including taking a bunch of Xilinx on-demand classes. Learning how to use the simulator and knowing how to interpret the results is perhaps the most critical part.