[USRP-users] Changing FPGA Code in USRP N210
johnathan at corganlabs.com
Fri Feb 15 10:01:01 EST 2013
On Fri, Feb 15, 2013 at 1:31 AM, Jinu Jayachandran <
jinujayachandran at gmail.com> wrote:
> 1) The building of the fpga image took around 30 minutes in my machine. So
> whenever I edit the FPGA code I should wait for 30 minutes before I want to
> test if it is working properly. Is this the normal time it takes to build
> ?. Can I reduce the time to build image in some way?
This is about right. Currently, make does a full synthesis and
place-and-route each time. It is theoretically possible to implement
incremental synthesis using the Xilinx tools, but that would be a large
amount of work and the current code organization would need to change
For this reason I recommend creating a Verilog testbench around the portion
of the logic you are modifying and do as much development and verification
in simulation as possible before going to synthesis. At synthesis time you
are then usually focused on debugging timing closure issues but not
correctness of function.
> 2) I would like to know where to put by FFT verilog code for the receiver
> in the FPGA?. From the code review I have done, my understanding is to put
> the code in /usrp2/top/N2x0/u2plus_core.v. And I need to get the sample_rx0
> value and strobe_rx0 values from the ddc_chain block as input to my FFT
> block and give the output to vita_rx_chain. Is my understanding correct ?.
> (I tried to implement a simple code by taking the sample_rx0 from
> ddc_chain, modify it and sent to vita_rx_chain. Then i used the narrowband
> example in the gnuradio to check if there is any change in data. But there
> is no change and sometimes the receiver doesn't receive at all).
This is a good place to do it. Alternatively, you can modify ddc_chain.v
to add your logic to the end of the RX processing. Either way, however, it
is important to understand the function of the 'run' input from the
rx_control module. This is directly controlled by the UHD logic to gate
when to stream samples over sample_rx0/strobe_rx0, and acts as a sort of
enable for much of the ddc_chain logic. If you modify the logic you will
have to ensure that anything inserted between ddc_chain and rx_control
manages this properly, and also accounts for any pipeline delay within your
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users