Abstract

The scope of this project is to develop a set of ruggedized, expandable and configurable multiradio cognitive radio systems. The platform will facilitate experimentation so that new algorithms can be tested and validated on a real hardware platform.

Testing and verification have been performed using Bus Functional Model Simulation.

Home



The wiki pages to the project:

CRKit

Poster for the project, to be presented on 19 Aug, 2011:

poster

Slides to be presented on 12 Aug, 2011:

presentation

Bus Functional Model Simulation


Enables verification of hardware components connected to a bus (Ex: PLB, OPB)
Involves :
Bus Functional Models(BFMs) : hardware components (provided as hdl files) that model a bus interface.
Bus Functional Language(BFL) : high level language to describe the behavior of a BFM. User can create a .bfl  file which describes  the required bus transactions.
Bus Functional Compiler(BFC) : Software that translates BFL code to commands that actually program a BFM.
                   

IBM CoreConnect Toolkit


Provides tools for simulation of PLB, OPB and DCR systems
Contains:
PLB Master
PLB Slave
PLB Monitor - samples all PLB signals in every clock cycle and checks for violations of the PLB architectural specification during simulation. Reports error, warning conditions to the user with a display message.
PLB Core/Arbiter
BFM Synchronization Bus - inter-communication bus for event and transaction synchronization among the models, consists of non- PLB I/O signals or signals used for testing purpose. Ex: Processor interrupt, Simulation start pulse ;

The BFM System



Bus Functional Model Use Cases


There are two main use cases for Bus Functional Models: IP verification and speed-up simulation.

IP Verification

When verifying a single piece of IP that includes a bus interface you concern yourself with the internal details of the IP design and the bus interactions. It is inefficient to attach the IP to a large system only to verify that it is functioning properly.

Speed-Up Simulation

When verifying a large system design, it can be time consuming to simulate the internal details of each IP component that attaches to a bus. There are certain complex pieces of IP that take a long time to simulate and could be replaced by a Bus Functional Model, especially when the internal details of the IP are not of interest. Additionally, some IP components are not easy to program to generate the desired bus transactions.

Cognitive Radio Kit, Revision-4


Architecture

The BFM system

Steps taken to test the transmit path


Path tested using BFM Simulation


Internal details of the Memory Management Unit (MMU)


Note : The memory allocation was done using the memory map given below :

Initial Configuration


1. The board IP and MAC addresses are configured.
2. The Stream ID and the MAC ID look up tables are populated
3. The various interrupts are enabled: IPIF, packet interrupts, PCore Interrupts.

Run Time (per packet) Configuration


1. Payloads are written to the PCORE outgoing mail box.
2. Commands with the appropriate port ID, size, ptr are wirrten to the PCORE cmd fifo.
3. At an interrupt, the PCore status register is read. If the packet interrupt is high, the PCore interrupt register is read. The command count and the port ID are verified by visual inspection.
4. Clear all the interrupts.

People



Khanh Le                      Prasanthi Maddala                    Tejashri Kuber