Hello
I’m trying to replicated the work by university of strah
for RFSOC 2x2
here: GitHub - strath-sdr/rfsoc_ofdm: PYNQ example of an OFDM Transmitter and Receiver on RFSoC.
it seems the block of decimator and interpolator are missing! The IP is generated using sysgen, however just HDL coder block are available in MATLAB simulink. It seems a lot of details are missing,
2 Likes
Hi @mnaghshvarian,
I hope the RFSoC-OFDM model was helpful, and apologies for the confusion.
The OFDM design no longer requires System Generator (for all development boards, not just the RFSoC2x2). This change was made to reduce the number of design tools required to rebuild the system. Also, it allows others to simulate the baseband OFDM models in Simulink with better performance, as there are no longer multiple rate changes.
The integration and decimation cores are now implemented using Vivado FIR Compiler blocks that are instantiated using a VHDL wrapper. You can find them in the IP folder, and they are implemented as IP Cores that integrate into the Vivado block design.
I hope this clears up this problem for you. You mention that other details are missing. Can you let me know what these are? I will do my best to answer your questions.
Thanks,
David.
2 Likes
Hello David,
Thank you for your response. We really appreciate the RFSoC-OFDM model you provided on GitHub. It has been incredibly helpful for our work and learning technically. But, in terms of presentation, it assumed people have already knowledge, and replicating work is extremely hard to learn due to small details missing but it’s important! We have found OFDM example to be more useful compared to other examples we have come across.
I wanted to address a few issues we have noticed while working with the model (Please see attached figures also
). Firstly, the generated IP by sysgen appears to be different. In the MATLAB model, the output ports of the Interpolate and Decimator blocks are labeled as M_SYMBOL_AXIS and M_OBSERVE_AXIS, respectively. However, these ports are not defined in the Vivado implementation.
Additionally, the Inspector for the MATLAB ports seems quite different from the one in Vivado. Specifically, the Inspector for the constellation plot differs from the Inspector for other parts of the model.
While having a constellation plot is helpful, we believe it would also be beneficial to have information on how to compare transmitted symbols or bits with received symbols or bits in order to calculate the Bit Error Rate (BER) or Symbol Error Rate (SER). This aspect is not described well in the current documentation.
Another issue we encountered is regarding the Generation Clock Hexadecimal value. Although it is provided for some clocks, the details on how to generate it, especially for different boards or new generations like DFE, are not described.
Finally, we noticed that the RF_Convertor in Vivado seems to perform some automatic Sample Rate Selection (SSR) functionality. However, in the accompanying book, it is mentioned that SSR is necessary at high data rates. We are confused as to why we would need SSR when the RF_Convertor already includes it.
It would be greatly appreciated if you could address these concerns and provide some clarification on each of these points.
Thank you once again for your assistance.
Best regards,
1 Like
Hi @mnaghshvarian,
See some responses to your questions below. I have tried to answer each of these and perhaps just want to mention a few things generally. The purpose of the RFSoC OFDM design is to demonstrate a simple OFDM system on RFSoC. Please note that this is not a definitive implementation for RFSoC and should not be treated as such. It is assumed you have MathWorks HDL Coder experience, knowledge of Vivado, and an understanding of GitHub. You should also be familiar with digital electronics design and RFSoC-PYNQ. As a general note, RFSoC and OFDM are very advanced topics, and any researcher or engineer (even advanced and senior developers) will need to take their time studying these topics.
Firstly, the generated IP by sysgen appears to be different. In the MATLAB model, the output ports of the Interpolate and Decimator blocks are labeled as M_SYMBOL_AXIS and M_OBSERVE_AXIS, respectively. However, these ports are not defined in the Vivado implementation.
This repository no longer uses the System Generator IP Core design. We no longer support this, and I cannot address this problem. Please only use the most recent release of RFSoC OFDM (which does not include System Generator IP), and I will attempt to help you further.
Additionally, the Inspector for the MATLAB ports seems quite different from the one in Vivado. Specifically, the Inspector for the constellation plot differs from the Inspector for other parts of the model.
The MathWorks HDL Coder design is not a one-to-one mapping with what you can see in Vivado. There is quite a bit of improvising here to obtain similar functionality. This improvising is why the ports don’t match directly. The data inspector subsystems in Vivado use the axis_packet_controller IP and an AXI DMA to move data packets from the RFSoC’s PL to the PS. This data transfer technique is a simple mechanism that allows us to inspect data without creating challenging architecture designs. The axis_packet_controller IP Core is a VHDL design that you can find in the IP folder.
While having a constellation plot is helpful, we believe it would also be beneficial to have information on how to compare transmitted symbols or bits with received symbols or bits in order to calculate the Bit Error Rate (BER) or Symbol Error Rate (SER). This aspect is not described well in the current documentation.
This observation is good, and we believe it would be beneficial too. However, the scope of this design was simply to demonstrate an OFDM transceiver on RFSoC with synchronisation. The design was also rapidly produced using MathWorks HDL Coder in a short time (a little under 2 weeks and with the OFDM knowledge of a senior engineer). Therefore, we haven’t attempted to perform BER and SER measurements, and we open this design to others that wish to modify it to do so.
Another issue we encountered is regarding the Generation Clock Hexadecimal value. Although it is provided for some clocks, the details on how to generate it, especially for different boards or new generations like DFE, are not described.
This question isn’t related to the RFSoC OFDM repository and is a more general RFSoC question. I would suggest asking the forums this question instead.
Finally, we noticed that the RF_Convertor in Vivado seems to perform some automatic Sample Rate Selection (SSR) functionality. However, in the accompanying book, it is mentioned that SSR is necessary at high data rates. We are confused as to why we would need SSR when the RF_Convertor already includes it.
Super Sample Rate (SSR) is a digital electronic design technique that allows us to trade the number of samples per clock period with the clock frequency of a digital architecture. SSR is very useful for high data throughput systems, such as an FPGA, which currently struggle to achieve timing closure at very high clock frequencies, i.e., over 1 GHz.
For instance, consider an RF ADC sampling at fs = 1GHz. An FPGA will struggle to meet timing closure using an equivalent clock frequency of fclk = 1GHz as this is very fast. Instead, we can stream data through the FPGA logic fabric using two samples per clock cycle, which reduces the value of fclk to 500MHz. Reducing the clock frequency is useful for FPGAs as it improves timing closure performed by the Synthesis and Implementation tools and reduces power consumption (and many other advantages). However, SSR architectures often use more FPGA resources, so this is something to watch out for.
The RF Data Converters interface to the FPGA logic fabric using SSR design techniques, which allows them to transfer several samples per FPGA clock cycle. Additionally, we can exploit SSR design techniques in the FPGA logic fabric to reduce the required clock frequency of FIR filters, FFT designs, and other digital architectures.
Thanks,
David.
2 Likes