[prev in list] [next in list] [prev in thread] [next in thread] 

List:       usrp-users
Subject:    Re: [USRP-users] RFNoC for Software Defined Radar Core
From:       Martin Braun via USRP-users <usrp-users () lists ! ettus ! com>
Date:       2016-10-28 20:47:01
Message-ID: bbd0f814-e3cc-eec8-ce79-83e9febc3096 () ettus ! com
[Download RAW message or body]

Sam,

these are all good questions.
I would recommend you go a different route, and write a separate radar
block that you then connect to the radio blocks. You will still get the
full clock rate, and a more modular design. That might also clear up
your issues; plus, you can nicely testbench your design before loading
it onto hardware.

Cheers,
Martin


On 10/27/2016 02:21 AM, Samuel Prager via USRP-users wrote:
> Hello Ettus Team,
> 
> I have an X300 and am using it as an experimental radar platform. I
> have been working for a few weeks now on migrating a previous
> kintex-7 based  design to fit within the rfnoc framework.
> 
> I have essentially replaced the noc block radio core with with a new
> 'noc block radar core' that accepts waveform samples and pulse
> schedules as inputs rather than real time samples.
> 
> I am using a modified version of the noc_blocks_radio_core_tb for
> simulation and have been seeing an unexpected deassertion of o_tready
> (and thus rx_tready) that is causing rx samples to drop. This occurs
> after a successful register read backs and a few successful pulses
> My design requires that samples must be collected (in short bursts)
> at the full 200 MHz clock rate. I will need to collect at least 4096
> samples continuously without interruption.
> 
> I have placed a 1024 deep fifo in-between and am still having issues
> with o_tready being deasserted prematurely in simulation. My initial
> plan was to connect this block to the dma fifo block in order to
> buffer high bandwidth pulsed samples so that they can be slowly
> offloaded to the host. However,  I am now thinking that perhaps it
> would be best to buffer these samples into memory with my own virtual
> dram fifo before presenting them to the rfnoc infrastructure.
> 
> My question is then about whether this is a limitation on the rfnoc
> infrastructure? Or simply one caused by the noc_block_export_io
> block? Could you please provide guidance on the maximum sustainable
> data rate that rfnoc should be able to achieve when implemented in
> fpga fabric?  Also, are there any unforeseen problems that will arise
> with initiating rx/tx commands from within the fpga independently
> from the host? From my understanding this is not supported currently
> in rfnoc, correct?
> 
> I apologize if anyt of my questions are unclear. I would be happy to
> provide source and additional info.
> 
> Thank you,
> 
> Sam
> 
> 
> 
> 
> 
> _______________________________________________ USRP-users mailing
> list USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[prev in list] [next in list] [prev in thread] [next in thread]