WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2012-May-03 16:37:52

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

OFDM Reference Design v17.0

We just posted a new OFDM Reference Design. This is our first design using the Xiliinx 13.4 tools. Unfortunately it only supports WARP v2 hardware (Virtex-4 FPGA Boards), as Xilinx no longer supports Virtex-II Pro devices in the ISE tools. The MAC and PHY designs are unchanged- this design will interoperate over-the-air with OFDM Ref Design v16.1 running on v1 or v2 hardware.

The updated ref design is structured as an XPS project (encompassing the hardware design) and two SDK projects (NoMAC and CSMAMAC). The functionality of the MACs is unchanged from v16.1, but the development environment is entirely new (Xilinx SDK 13.4 vs. XPS 10.1.03).

We're still learning the Xilinx 13.4 tools. We have discovered the Xilinx SDK imposes some design portability challenges. This design is our first attempt at distributing a project for others to use.  Please review our notes about the design structure and how to use it.

We're very interested in feedback on this- if other WARP users have ideas for better packaging of XPS/SDK projects, streamlining the setup processes, etc. Please post any feedback (or other questions) in this thread.

Edit: the .zip file is now downloadable (there was a permissions problem before; sorry)

Offline

 

#2 2012-Aug-22 08:53:48

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Hi,
I am trying to run v17.0 on a Xilinx 13.4 installation on Ubuntu. Apart from several hacks to make 13.4 run on Ubuntu the makefiles contain references to some old windows paths when importing the design which breaks the compilation process. Changing the paths manually helped to pass the elf-check when invoking make on command line and even debugging on the board was running once or twice. However, the Eclipse-GUI is not working correctly on the modified files. Can you give me some advice on how to create a new Xilinx-C project from scratch and include the CSMAMAC code?

Regards,
Thomas

Offline

 

#3 2012-Aug-22 10:48:14

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

Re: OFDM Reference Design v17.0

Interesting- we'll have to investigate the portability of SDK projects. It's frustrating that any paths are hard coded. We'll get a Linux ISE/SDK installation setup and look into it.

In the meantime I just posted the full howto for creating the OFDM ref design SDK workspace from scratch. I kept these notes while creating the v17 project, figuring we would need to re-learn the process for future designs. See SDK_Project_Creation.

Offline

 

#4 2012-Aug-23 12:52:19

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Hi murpho,
thanks for your quick reply. I tried to create the SDK Project from scratch however I am again facing problems. When creating the BSP project I can't change the driver version for the OFDM cores. At some point it also was complaining about not finding the file "system.mhs." when creating a renamed copy of system.mhs it stops complaining however I still can't change the drivers versions.

Neglecting this problem and continuing to create the C-Project results in missing header files.

radio_controller_basic.h
radio_controller_ext.h
radio_controller_adv.h

Solved this by adding a manual include to WARP_Repo/edk_user_repository/WARP/drivers/radio_controller_v1_22_a/src

However it is still reporting missing constants:

XPAR_OFDM_TXRX_MIMO_PLBW_0_MEMMAP_RX_PKTDONE_INTERRUPTSTATUS
XPAR_OFDM_TXRX_MIMO_PLBW_0_MEMMAP_PKTDET_STATUS
XPAR_OFDM_TXRX_MIMO_PLBW_0_MEMMAP_PKTDET_THRESHOLDS
XPAR_OFDM_TXRX_MIMO_PLBW_0_MEMMAP_RX_PKTDONE_INTERRUPTSTATUS

Anything of this sounds familar to you?

Thanks,
Thomas

Offline

 

#5 2012-Aug-23 13:22:15

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

Re: OFDM Reference Design v17.0

If you open the BSP settings dialog and go the drivers window, what driver and version options are available for the ofdm_txrx_supermimo core?

Offline

 

#6 2012-Aug-24 04:09:52

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

driver: none and generic
version for generic: 1.00a

Offline

 

#7 2012-Aug-24 09:36:37

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

Re: OFDM Reference Design v17.0

Well that's one problem- the ofdm_txrx_supermimo core needs to be assigned the ofdm_txrx_supermimo driver. Without this none of the register address macros will get defined.

Did you do the step of adding the XPS project as a repository in the SDK (step 2 in "Creating the Workspace")? This is what allows the SDK to find the drivers for the Sysgen-generated pcores, which live in the <xps_proj>/pcores/<each pcore> folders. The SDK assigns the generic driver when it can't find a better match.

Offline

 

#8 2012-Sep-05 05:54:59

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Hi Murpho,
I finally found time to double check that. Maybe I missed that step, I repeated the whole process of creating the SDK project and now it is compiling fine even on my Linux machine.

Unfortunately I am running the CSMAMAC code and the boards are not transmitting anything. They react to key presses and generate the usual UART output. In the debug mode they break on key presses but neither wireless packet reception nor wired packet reception. Breakpoints on emacRx_handler() do not get triggered. The 100Mbit led however is glowing and Rx leds are flashing. Any Idea on this?

Offline

 

#9 2012-Sep-05 07:57:23

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1194

Re: OFDM Reference Design v17.0

The only way that I can think that emacRx_handler() isn't being called is that a backoff timer in CSMAMAC is never finishing. That only happens if the node is perpetually carrier sensing and thinks that the medium is always busy. From line 412 in warpmac.c, you can see that the TEMAC's FIFO is completely ignored if the "controlStruct.enableDataFromNetwork" flag is set to zero. You might want to print that field out to UART to check this theory (if its zero, then emacRx_handler won't be called).

Second, it might be worth trying the NOMAC project. It doesn't do any carrier sensing, so it shouldn't have this problem. Obviously that's not a long-term solution, but it should help narrow down what the problem is if we see that it works fine.

Offline

 

#10 2012-Sep-06 12:51:02

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Ok I checked that. The result is the same for NOMAC and CSMAMAC. It seems that enableDataFromNetwork is normally set to 1. However the call to XIo_In32(EMAC_FIFO_BaseAddr+XLLF_RDFO_OFFSET) on line 432 is always returning zero. I am strongly suspecting this to be caused by the fact that most of the non-custom pcore drivers (including llfifo and lltemac) have a newer version than specified in the mhs file... and I am again not able to select the right version for them. Do you know that problem? Did I miss a step again?

Offline

 

#11 2012-Sep-06 15:33:59

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1194

Re: OFDM Reference Design v17.0

tomekk wrote:

I am strongly suspecting this to be caused by the fact that most of the non-custom pcore drivers (including llfifo and lltemac) have a newer version than specified in the mhs file... and I am again not able to select the right version for them.

The versions you see in the BSP (which wraps the MSS file) should be different than the ones you see in the MHS. The BSP contains the driver versions and those can be completely different than the core versions specified in the MHS. Case in point, in the WARPLab Reference Design I have open right now, I have an xps_ll_temac with an IP version of 2.03.a in my MHS. For the software project, the driver version for the lltemac is 3.00.a and everything is working great. It's totally fine that you can't select other versions of the driver.

Back to the problem at hand, I'm a bit perplexed why the board doesn't seem to be responding to anything over Ethernet. Have you tried one of the prebuilt bitstreams (.bit or .ace) for CSMAMAC or NOMAC? That would help rule out your network setup as a potential issue.

Offline

 

#12 2012-Sep-07 04:04:21

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Well ok. I have got the same configuration for the lltemac driver as you. What is your driver version for the llfifo driver? Mine is 2.01.a. Am I right that the call on warpmac.c line 432 reads some memory from this fifo core? Maybe I should do some reading about the driver stuff, I still don't get what exactly is happening there.

All my v16.1 designs are running fine on the setup. Do you have any v17.0 CSMAMAC/NOMAC bit files available? The system.bit file included in the v17.0 zip is not doing anything (as it is missing the software project, I guess).

As far as I can see in the debugger the problem is that the condition in warpmac.c line 432 never becomes true (reading wrong memory address?). If I turn one of the nodes into auto packet generation mode it even starts transmitting and the second board successfully receives the packets (debugger triggers on phyRx_goodHeader_callback).

Offline

 

#13 2012-Sep-07 04:46:57

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

Re: OFDM Reference Design v17.0

The system.bit file included in the v17.0 zip is not doing anything (as it is missing the software project, I guess).

system.bit is only the hardware design. Only download.bit (in <xps_proj>/implementation in ISE 10.1, in <SDK_Workspace>/<hw proj>/ in 13.4) includes both hardware and software.

Am I right that the call on warpmac.c line 432 reads some memory from this fifo core?

Yes, it's checking whether the xps_ll_fifo has any packets available. The ll_fifo automatically retrieves new packets from the TEMAC, then holds them until retrieved by user code. When XIo_In32(EMAC_FIFO_BaseAddr+XLLF_RDFO_OFFSET) returns zero, the FIFO is empty.

What link speed is your Ethernet connection? I think the v17+ designs default to 1Gb for the TEMAC on WARP v2 and v3 hardware.

Offline

 

#14 2012-Sep-07 08:41:25

tomekk
Member
Registered: 2012-Feb-21
Posts: 21

Re: OFDM Reference Design v17.0

Ok I found the problem. The new TEMAC defaults to 1Gb and the boards are still connected to the old 100Mb equipment I use for v16.1... in fact I was sure I would be using at least one Gb capable device but obviously I wasn't. Now emacRx_handler() is getting called just as it should.

Murpho, Chris thanks a lot for your patience.

Offline

 

#15 2012-Sep-07 08:42:40

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1194

Re: OFDM Reference Design v17.0

Ah, that will do it. Great, I'm glad everything is working!

Offline

 

Board footer