From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-07-2017 08:44 AM
Hi,
I have been using the LTE portion of the LTE/WIFI Coex framework. I've noticed that it was designed based off the 40 MHz LTE AFW design.
Are there any consequences to running this on a 160 MHz USRP?
If I try to run it, it does run without issue. However, I worry that the 20 MHz LTE signal isn't actually 20 MHz. I worry about some of the clock rates being different such as "Data Clock." I know that in the 160 MHz version of the LTE AFW this runs at 200 MHz. Here, it is just labeled as Data Clock, and so I'm not 100% sure what rate it is running.
I tried to alleviate my concern by generating my own 160 MHz design bitfile. In the System Designer view, I replaced the USRP that was included with my 2954, 160 MHz USRP. I set everything up and generated the bitfile. After 3 hours and 48 mins, it failed do to timing.
A 2.50 ns requirement (400 MHz 2x Data Clock) was missed by 0.02 ns mostly due to the fractional decimator block (0.77 ns) and "Optimized or Non-Diagram Logic" (1.18ns).
Also, a 5.21 ns requirement (191 MHz Clock) was missed by 0.25 ns. due to the Sync Algorithm Switch (0.22 ns) and "Optimized Or Non-Diagram Logic" (5.06 ns).
Are there any thoughts as to helping to meet timing, particularly with regard to the Optimized or Non-Diagram Logic" when generating a 160 MHz version?
Thanks,
Chance Tarver
07-07-2017 09:13 AM
These can sometimes be tricky to meet timing on. Without looking into the details the first thing I would try is to compile it several times. The Xilinx tools have slight variations from run to run that you can take advantage of to try to close timing. I would try 4-5 more compiles and see if one works. If not you'll have to dig down into it and fix timing problems in the source.
07-07-2017 09:41 AM
Thanks for the reply!
Each compile takes 4 hours on the NI Cloud Compile server. My computer sometimes doesn't like it when I have too many projects open at once, so I'm not sure how many I can actually compile at a time. So it could take all day just to hope that I get a design that works.
In normal Xilinx tools I think you can set optimization goals. Is it possible here to set NI to optimize for timing?
Also, what I described was just an unaltered NI design (Except I changed the target to a 160 MHz USRP). I'd hate to have to really dig into their work and start trying to optimize. I'd like to be able to focus on the modifications I need to make.
Still, I'm curious about the clocking of the 40 MHz version of the LTE/Wifi Coex framework and if there are any consequences to running this on a 160 MHz USRP. Any thoughts here?
Thanks,
-Chance
07-07-2017 12:51 PM
@ctarver wrote:
Thanks for the reply!
Each compile takes 4 hours on the NI Cloud Compile server. My computer sometimes doesn't like it when I have too many projects open at once, so I'm not sure how many I can actually compile at a time. So it could take all day just to hope that I get a design that works.
In normal Xilinx tools I think you can set optimization goals. Is it possible here to set NI to optimize for timing?
Also, what I described was just an unaltered NI design (Except I changed the target to a 160 MHz USRP). I'd hate to have to really dig into their work and start trying to optimize. I'd like to be able to focus on the modifications I need to make.
Still, I'm curious about the clocking of the 40 MHz version of the LTE/Wifi Coex framework and if there are any consequences to running this on a 160 MHz USRP. Any thoughts here?
Thanks,
-Chance
Chance,
You should be able to kick of multiple compiles from a single project when you have automatic numbering set:
07-07-2017 12:53 PM
Cool. Thanks!
I forgot that I could do that.
07-12-2017 01:13 PM
I've provided ctarver with a copy of the latest version of the Coexistence code base that supports the 160 MHz BW version of the USRP RIO.
10-17-2017 07:21 AM
Hi
My name is Mohith a student at TU Darmstadt. I am very new to the field of LTE. I have been give a reference design of LTE Design USRP Rio v2.0.1 and labview communication 2.0. I have created an instance of the design and am trying to analyze the reference code, but not making any progress in getting the exact idea the code is intended to do. So do you have any documents explaining this reference design clearly stating the usage of these blocks. Do reply to mkacahr4493@gmail.com
10-17-2017 09:21 AM
Hi Mohith,
Thank you for your question. I have replied to your personal email address. Please let me know if you have any additional questions.
Best regards,
Doug
10-17-2017 12:04 PM
Hi Mohith,
My attempt to email you failed. Can you confirm that the email address below is correct?
10-17-2017 12:50 PM
Im sorry for the typo. My email id is mkachar4493@gmail.com