WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Nov-21 08:42:17

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

.

.

Last edited by gmkim (2020-Aug-17 20:05:49)

Offline

 

#2 2016-Nov-21 19:36:20

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: .

Modifying the w3_warplab_buffers core is a good starting point. This core implements the Tx and Rx interfaces for the WARPLab reference design.

The Rx path connects to the ADC I/Q signals and routes them to on-chip buffers (BRAM blocks outside the w3_warplab_buffers core). The Tx path does the reverse, connects on-chip buffers to the Tx DAC I/Q interfaces. The w3_warplab_buffers core also implements the state machines for Tx and Rx. These state machines are started via the trigger input and handle transfer of samples between the ADC/DAC interfaces and sample buffers. These state machines also assert interrupt outputs when the on-chip sample buffers are ready for transfer to/from DRAM. The MicroBlaze processor monitors these interrupts and issues DMA commands to handle sample transfers to/from DRAM.

For your application I would suggest adding logic to the w3_warplab_buffers core that monitors the Rx I/Q inputs. Your logic can consume the I/Q sample stream in real time without affecting the normal operation of the Rx state machine. Then when your Rx PHY logic detects an event it can assert the Tx state machine's trigger, executing a normal WARPLab Tx event. This hybrid approach (real-time Rx and pre-configured Tx that is triggered by Rx) can reuse most of the WARPLab ref design, which should save you a lot of time.

Offline

 

#3 2016-Nov-24 07:35:27

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2016-Dec-22 01:42:56)

Offline

 

#4 2016-Nov-24 09:50:11

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2016-Dec-22 01:43:09)

Offline

 

Board footer