RCB
-
Posts
16 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by RCB
-
-
On 9/21/2021 at 1:42 AM, msamirh said:
@RCB Can you please give a clear idea on what all blocks are there before FFT and how you configured those. If you are documenting those steps here others can also try from their side and update the design.
Sorry, I missed email notification of your question. I have done something slightly similar to the fft implementation in http://web.mit.edu/6.111/www/f2015/projects/mitchgu_Project_Final_Report.pdf - they have documented it pretty well. I'm sure you can figure other details on the configuration - Xilinx documentation would be of good help too.
-
19 hours ago, zygot said:
I love hearing about projects done for personal edification. The best engineers like doing engineering because they are curious and love the challenge.
I don't know of any add-on boards for doing what you want to do using analog circuitry. But perhaps I could give you an idea or two to ponder without spoiling the adventure. Perhaps there are multiple paths to explore.
Let's say that you have two 5 MHz sine signals with a fixed phase offset between them. Thinking about them, as two separate signals suggests a straight-forward time domain analysis for phase detection using direct analog to digital conversion and some mathematical magic. But what if you choose to think about them as the product of a sine-wave generator driving a variable impedance load? One representing voltage and the other current at the load. If you think about them in that context, the thought of considering power as it relates to magnitude and phase offset might lead to an interesting approach. As long as you don't have to deal with instantaneous phase offset that 1 MHz Fs isn't looking so inadequate. Can the XADC and some analog manipulation get you phase detection to within +/- 1 degree? I doubt it, but I doubt that the brute-force approach and a pair of 100 MHz "14-bit" ADCs will either. But you can come up with a rough estimation of what it would take. Instead of expecting to hit the target on the first cut I'd suggest starting out with lower objectives and seeing how different approaches go. This is why, when doing experiments because you want to learn, the journey really can be more valuable that finding answers. Usually, along the way you find more questions to answer. Sometimes, these are more interesting than the original problem. Almost certainly the result of constructing experiments to solve problems makes your conceptualization of what's going on in the hardware less naive.
That's just one thought. I'm sure that you can come up with others.
There's always a brute-force approach to solving puzzles but sometimes the way that you think about them can lead to an elegant solution using low cost hardware. The point is that the obvious way to approach problems can involve considerable hardware complexity and cost but often there are ways to get around the expensive requirements and still get good enough results to meet your requirements. That's the joy and beauty of embedded design; doing in logic or with limited computational power what a computer does with MATLAB or expensive custom libraries.
I don't want to discourage you from taking the ADC route as there is a lot to learn about converters and fixed point math using logic. But, we all have budgets to consider. I'm assuming that 5-10 MHz is a fungible criteria. You can almost always scale down the initial specifications to fit a low hardware budget and still come up with an implementation to prove a solution concept. Two audio frequency sine waves would certainly require cheaper hardware.
If you want to try building you own add-on circuitry to convert analog measurements to digital data the De0 Nano and Express PCB are easy to use to do almost anything. The De0 Nano has two 40-pin headers for expansion and while not the cheapest way to do you own PCB designs Express PCB, once you get used to its peculiarities, is pretty painless. It just doesn't work well for really high speed connectors and really small parts. You can get some decent ADCs from distributors that work in the 5-10 MHZ range, or perhaps used components to take an alternate route.
Thank you for the thoughtful reply @zygot! _/\_
I'm really impressed with the idea of Tayloe detector for IQ demodulation when I learned it first. Your suggestion in a similar line of thought appears equally impressive. Thanks for the recommendation and for the push to keep looking for simpler answers!
Yes, I will first try a small scale experiment with the Zybo I have - to get an idea on the resources required. I'll keep looking up for answers! Thank you so much!
-
9 hours ago, zygot said:
I would certainly agree with you that the 1 MHz XADC, or equivalent, found in modern FPGA deices is inadequate in terms of Fs.
Unfortunately, there aren't any low cost ( under $200 ) FPGA boards that support ADC or DAC conversion in the 100 MHz and higher Fs range. The Digilent ZMOD1410 dual ADC alone costs more that $200, but is the best low cost ADC module that you are likely to find. The question is what SYZYGY compatible FPGA platform do you want to use. Digilent offers two of them and Opal Kelly a couple as well.
Unless you are specifically required to implement the entire project as an embedded solution you don't need a ZYNQ based FPGA board. I would suggest that the non-ARM based FPGA platforms are the preferred choice, depending on your HDL skills. Certainly I'd go with something like the XME7320 and a ZMOD 1410. But, this isn't cheap. Terasic's DDC dual ADDC/DAC board on an Intel platform is a decent alternative and could be used with a number of HSMC equipped FPGA platforms. For low Fs applications I'd recommend staying away from the cheaper Terasic ADC boards because they aren't setup for dealing with low speed signalling.
Since you mention unspecified additional calculations to be performed I'm guessing that direct signal conversion to digital is an imperative. Given the lack of low cost educational quality hardware available you might consider an FPGA board that isn't limited by 12-pin PMOD interfaces and designing you own ADC add-on board. That would certainly be an impressive implementation, but be careful as the circuitry between your ADC input pins and your signals can easily subvert accurate phase measurements. Seems like an expensive project requirement for a student funded exercise.... If this isn't an educational exercise then I'd be asking about the accuracy/resolution of the phase measurements as this could dictate hardware choices. Designing a solution to a problem that has poorly defined specifications is often a fool's enterprise.
[edit] I'm assuming a few things here; mostly that this is a student project. I can think of a few potential alternate ways to do this in the analog domain. Of course this depends on your measurement specifications. But it would simplify your signalling interface work and expense. For a student project you generally have to show some understanding of coursework preparation.
[edit2] I forgot all about FPGA instruments like the AD2 and RedPitya. In the latter case this is an open system that allows for real custom FPGA application development. It also happens to be ZYNQ based, if that's what you want. There are affordable versions with 2 channels of ADCs that might be suitable, though sample depth is limited. You might not require a lot of samples per cycle if you are smart about how you do you detection. Be prepared for a significant amount of software effort. If you can figure out how to integrate the hardware and software frameworks into your project this is probably the most cost effective platform available... at least to my knowledge. You'll need to be proficient in Linux, Verilog and System Verilog to complete a project in any sort of reasonable time frame.
I'm carefully reviewing your comments. Thank you for the wonderful support. This is not a coursework oriented project but a personal one but still as a student.
I am looking at resources that would contain details on interfacing external ADCs (zmod) - to analyze its complexity. RedPitaya board appears like an attractive choice too.
" I can think of a few potential alternate ways to do this in the analog domain. Of course this depends on your measurement specifications. But it would simplify your signalling interface work and expense." - Can you share your suggestions on any daughter boards for doing it in the analog domain? (plus, reading their o/p to the FPGA dev board for additional processing). Measurement test specifications - I would like to create two sinusoids (5 MHz, phase differed) and compute their phase difference to the order of a degree. At this point, I am being childish and considering only the logic side of the implementation. Accuracy-wise I'd be happy with a degree rounded-off values for now.
-
3 hours ago, zygot said:
Could you be a bit more generous in describing the goals of this project? Are the input signals related, and if so how? Are the input signals sinusoidal, clocks, digital..?
Input signals (2) are 5 MHz analog sinusoids - phase shifted. Project requires me to identify this phase difference between them + do some additional computations later.
I am open to suggestions. Here are two main paths that I focused my search toward -
1) if there are daughter boards (RF, analog) that can do phase detection and give a digital output to read to the FPGA - would be ideal
2) if I need to interface high-sampling ADCs to sample the 5 MHz analog input and write phase detection logic on the FPGA - involved but I can try - most resources I looked online point FPGA for phase detection in digital domainI currently have a Zybo 7020 board with sampling rate of 1 MSPS and on-board clock of 100 MHz - insufficient resources (workaround available with this board?). I am familiar with Xilinx environment and prefer to stick with it but open to options that meet my project goals. I would really appreciate your kind suggestions.
-
I am working towards a phase difference detection project to be developed on FPGA. I have Zybo Z7020 board. ADC sampling rate of 1 MSPS. My input signals are of frequency 5 MHz to 10 MHz. Zybo, unfortunately, is not equipped to sample such high frequency signals. I am unable to find external pmods or evaluation boards that can do phase detection (be it analog RF side or digital). Does anyone here have any suggestions for me to look up for?
I'm also wondering if there could be any daughter boards that handle high frequency analog signals (ADC + mixers + filters (or) just ADCs) and hand over the digital data at a (programmable) lower frequency to the Zybo board. If none of the options work, I might painfully move on to a different FPGA evaluation board (Terasic + Intel) and development software (Quartus). Any suggestions/thoughts on different development board specifications with such support would also be really helpful! Thanks!
If anyone here worked with NI PCI 5640R - how difficult is it to understand its programming for my application?
-
On 4/1/2020 at 3:00 AM, petriggg said:
Hi @RCB!
I read that article from Levi's blog. According to it I customized DDS compiler and get the 25 MHz sine wave. Now I try to tune up the FFT Core.
Thank you for source files (I sent a request for access), but I work in a Vivado 2015.4 and, probably, will not open files from Vivado 2019.1.
Can you share some screenshots with your FFT IP customization window and part of blockdesign with FFT core? Only screenshots will enougth.
Especially I interesting about input data. Where need to place phase factor, I guess that in a least significant bits, right?
And one more question. How you get the signal on magnitude_tdata? It's just a sum of real and imaginary components of FFT result? How you get this, by Adder/Substracter IP?FFT IP: 4096 point, Fixed point, non-real time, unscaled
Yes, you may populate the least significant bits with the DDS output. I tried square root operation for handling the FFT core output.
-
-
On 1/22/2020 at 10:01 AM, D@n said:
@RCB,
Why are you converting things to sign magnitude form, vs just leaving them in twos complement again?
I'm not certain what's going on. Were this my own project, I'd use an FFT I'd be able to "see" inside of so that I might debug the problem. Specifically, I'd look for overflow problems within the FFT--at least that's the only thing I can think of that might cause the bug you are referencing above. It doesn't make sense, though, that you'd have overflow with one FFT and not with an identical FFT that only differed in output ordering. You might wish to compare the .xml files of the two FFT's to see if they are truly the same as you believe. You might also wish to try dropping the amplitude by a factor of 4x or perhaps even 64x to see if that makes a difference. It might be that you have the scaling schedule messed up and that things are overflowing within. It might also be that you aren't looking at all of the output bits with your bit-cut selection above--I can't tell by just looking at it from here.
Dan
P.S. I don't work for Digilent, and do not get paid for answering forum posts.
Hi @D@n
I think I got the design right after some experimentation. My mistake was about handling the real and imaginary components. Thank you for your suggestions. I'll document the steps and post it here hopefully soon. Appreciate your help.
I would move on with replacing DDS synthesizer with XADC to test external signals with a function generator.
- Ram
-
On 1/16/2020 at 9:58 PM, D@n said:
@RCB,
Did you notice the glitch in your source signal in the second plot? It's in both data[] and frame_data. You'll want to chase down where that glitch is coming from.
After looking at that source signal, I noticed that the incoming frequency of your first image didn't match the 1MHz frequency you described. At 1MHz, you should have one wavelength inside of 1us. In your first plot, it appears that one wavelength fits in 20us, for a frequency of closer to 50kHz?
Further, I don't get your comment about holding config_tvalid = 1. If you have created an FFT that isn't configurable ... then why are you configuring it? It's been a while since I've read the book on the configuration --- did you hard code the scaling schedule into the FFT, or are you configuring that in real time? I can't tell from what you are showing. You also weren't clear about what config_tdata is. Was that the all zeros value you were sending?
Finally, the difference you are seeing between natural order and bit-reversed order is not explained by the simple difference between the two orderings. There's something else going on in your design.
Dan
Hi @D@n
I still am facing issues with the design and request your help. I think the problem is with how the xfft core handles the input (32 bit) data.
Some information on my input data:
1) Output of DDS compiler: 16 bit sine wave (DDS input 100 MHz clock, output: sine 100 KHz)
2) 16 bit o/p from DDS compiler is converted to signed magnitude form (dds_output - 1<<15) and is concatenated with 16'b0 (MSBs).
Alternately, earlier I tried with DDS compiler output as is with 16'b0 concatenation.
FFT details: 100 MHz clock, 4096, natural order, pipelined streaming and unscaled.
FFT magnitude output with signed 32 bit input
FFT magnitude with unsigned 32 bit input:
magnitude: mag_data[23:0]
Dout0[15:0] and Dout1[15:0] are real and imaginary output slices from FFT.
Real: 15:0 sliced from 64 bit FFT output
Imaginary: 47:32 sliced from 64 bit FFT output; magnitude being sqrt(real+imaginary)
-
On 4/3/2019 at 8:41 AM, FR said:
Dear Sir
Thanks again for your suggestions. I tried to answer your questions first. Then I tried to put my data and assumptions regarding this design.
You mentioned that your FFT and FIFO are both running at 100MHz. May I assume that this is your system clock rate?
I have used the this FIFO for clock domain crossing. FIFO's input clock is running at 61Mhz and output clock is running at 100Mhz. I'm passing the data from FIFO output to FFT core input. My FFT core is running at 100Mhz.
Looking at your image above, it appears as though you have a much lower data rate than 100MHz. Can you tell me what your data rate is?
Yes my data rate is 61MSPS. My FIFO outputs valid signal at the frequency of data rate so i connected this valid signal at FFT s_axis_data_tvalid signal. I also connected FFT out s_axis_data_tready to FIFO's m_axis_data_tready signal. You can see in screenshot that fft_s_axis_data_tready is asserted and util_fifo_m_axis_valid is toggling at the rate of 61MSPS. (ILA is running at 100Mhz)
I notice that you are using a FIFO. Can you explain the purpose of this FIFO within your design? If the data rate going into the FFT is at 100MHz, then the FIFO really only makes sense if you have bursty data at a rate faster than 100MHz.
I used the FIFO for clock domain crossing. Actually my data rate (61MSPS) is slower then my system clock(100Mhz). So if i lowered my system clock to 61Mhz, I would hurt my system's performance.
Indeed, is your TLAST generation done at the rate of your incoming data? Or is your counter independent of incoming data samples?
yes TLAST is being generated at incoming data rate (61Mhz).
Here is how i'm calculating bins and indices. (Please correct me if i'm wrong.) My FFT size 65536 and FFT core is running at 100Mhz. So
bin size -->100M/65536=1525.87890625Hz
--Input 1Mhz signal
expected index-->1M/1525.87890625 = 655
actual index = 1068 @FR @D@n how can I check/verify the index number from the waveform? In the waveform attached to this point, @FR got a peak at 31,344. What information I can extract from this about the bin number as well as the expected add value?
offset =413
--input 2Mhz
expected index-->2Mhz/1525.87890625=1310 (2*655)
actual index =2135 (2*1068)
offset = 825 (2*413)
This calculation shows that output has a fixed offset. I'm not using square root while calculating magnitude. My multipliers and adders are all combination so they won't add extra latency.
-
On 1/16/2020 at 9:58 PM, D@n said:
@RCB,
Did you notice the glitch in your source signal in the second plot? It's in both data[] and frame_data. You'll want to chase down where that glitch is coming from.
After looking at that source signal, I noticed that the incoming frequency of your first image didn't match the 1MHz frequency you described. At 1MHz, you should have one wavelength inside of 1us. In your first plot, it appears that one wavelength fits in 20us, for a frequency of closer to 50kHz?
@D@n I am sorry! The frequency is 50 kHz. My FFT resolution would be (100*10^6)/4096 about 24.5 kHz. X[3] would be the frequency bin with spike.
QuoteFurther, I don't get your comment about holding config_tvalid = 1. If you have created an FFT that isn't configurable ... then why are you configuring it? It's been a while since I've read the book on the configuration --- did you hard code the scaling schedule into the FFT, or are you configuring that in real time? I can't tell from what you are showing. You also weren't clear about what config_tdata is. Was that the all zeros value you were sending?
No scaling and no runtime configuration. I think I tested with s_axis_config_tvalid with both 1'b0 and 1'b1 but I did not find changes in the output waveforms (of magnitude data). I'd check this again. Yes, config_data is all the zeros.
Finally, the difference you are seeing between natural order and bit-reversed order is not explained by the simple difference between the two orderings. There's something else going on in your design.
QuoteAppreciate your help.
-
Hi @D@n @FR can you please help me with my FFT design?
Here are the details:
I am testing the design with sine wave input from DDS compiler: Frequency 1 MHz.
100 MHz System clock driving DDS compiler, BRAM for storing frame data from DDS 16 bit output and transferring the same data to FFT core.
FFT IP core: 100 MHz clock, 4096 point, pipelined streaming, no run time configuration (8'b00000000) & config_tvalid(1'b1), unscaled and testing both bit reversed and natural orders.
Block design contains FFT IP core with register slices (64 bit M_AXIS_DATA from FFT is sliced for real and imaginary components as real:15:0 & imag: 47:32) -> multipliers -> add/sub -> CORDIC IP for square root magnitude generation.
frame_tlast signal is generated by a 12-bit counter in a bram_to_fft module for frame data transfer.
Simulation through a test bench and analysis via vivado waveform viewer. Vivado version 2019.1
I could see that the output of DDS compiler and the input of the FFT module match (image attached). I do not understand the FFT output (the real and imaginary components) and the magnitude data that follows it. Can you point what changes I need to carry out for a correct output?
FFT ouput in reverse bit order configuration:
I see that the magnitude data (and x_slice_0(real part), x_slice_1(imaginary part)) have bands of waveform of high magnitude followed by lower magnitude values. I was expecting only one spike in the magnitude output. What do you think has gone wrong here? Also, how can I verify this result with regard to expected FFT bin number (on a time based x-axis) and the magnitude value?
Output in the natural order (option in FFT IP core) is something like this:
I could not make anything of this result.
Requesting your help.
- Ram
Zybo Z7 compatibility with zynq XC7Z030
in FPGA
Posted
Hey!
Zybo Z7010 is a popular device with very good support here in the forum. I started with Zybo Z7020 over 7010 predominantly because of additional capabilities that I would like to be available for future projects. I have not faced any problems with the board because Digilent has the board support tools for z7020 and the hw/embedded programming experience is similar to the 7010.
For hardware design, specific builds target specific boards. It will be very apparent if you are juggling between different boards with Vivado tool. Internal code might be good for building on different devices but if the logic would be compatible for implementation across devices cannot be guaranteed.
But Z7010 is a good board to start with. If the whole project is not entirely compatible with your future boards, it at least guides you through logical errors.