You are not logged in.
Hi,
I am going through the complete 'ofdm_txrx_mimo' SIMULINK-SYSGEN model to understand the the timing constraints and opb-DSP core inerface for each of the blocks. In the following I am writing down my understanding of the model via points (a-d). Kindly correct me if my understading is wrong.
a) Simulink DSP-core interacts with ppc405 using opb. Regarding opb-DSPcore interface, all input output controls are pased via ''Memory Mapped Interface'' blocks. Required shreared memory interfaces are mapped using either 'From Register' or 'To Register' blocks in the unconverted model. These blocks intern maps to appropriate 'Xilinx Register' inside 'mem_if_in' or 'mem_if_out' blcoks after conversion using sysgen2opb tool. A detailed list of these input/output registers are given in WARP repository @http://warp.rice.edu/trac/wiki/OFDM/MIMO/Docs/ModelRegisters.
b) These memory mapped registers are the only interfaces for the OFDM module. One can start modifications to the OFDM model for required functionality without affecting the MAC or higher layer model by keeping this register interface same.
c) Timing control of the PHY layer functionality (block activations) are done using TxControl and Control_&_Registers Simulink blocks. These controls can be performed using "State Flow" model within simulink.
d) Required change in PHY processing time, for example if PHY requires more time to process one OFDM frame will not affect the higher layer.
Kindly suggest me if something I am missing.
Regarding timing, I can remember last WARP workshop @IITM, WARP team was explaining the required timing constraints while building the OFDM model in simulink. Could you please provide an roungh idea of how to consider timing constraints while building an new OFDM model?
Thanks
Atanu
Offline
a) Correct. You can go through the sysgen2opb lab exercise to step through the process yourself.
b) Yes, provided the changes don't affect some of the "magic numbers" that are written to the WARPPHY control layer (numbers that are dependent on delays in the system, for example). Also, it should be noted that there are also interrupt lines that feed out of the PHY and into the INTC peripheral, which in turn are fed into the non-critical exception input on the PowerPC. A graphical representation of all of the system inter-connects can be seen here.
c) I'm not familiar enough with this area. I'll look into it and post another reply.
d) As I said in part b), there are a few parameters written by the very low-level WARPPHY control layer that depend on timing. As long as the behavior of WARPPHY is modified (if necessary) to account for any changes, the MAC layer will be unaffected by the changes.
Offline
Thanks for the comments.
In the OFDM Core Hardware System Requirements diagram (http://warp.rice.edu/trac/wiki/OFDM/MIM … quirements), there are direct connections (without going through OPB bus) between "MIMO OFDM Core", "Packet Detector" and "AGC" blocks. Are they interrupt related direct connections between the blocks? If yes, kindly provide the link in the simulink model where they are modeled.
Offline
The way to think of it is that the direct connections between the cores are top-level ports of the peripheral. These signals include, but are not limited to, PowerPC interrupts.
The direct connections are suitable for "fast" data like I and Q samples from the AGC core, which corrects DC offsets from the raw I and Q samples from the radio bridge. As another example, there is a 1-bit connection between the packet detector and both the AGC and the OFDM receiver that tells those blocks to begin executing when sufficient energy is detected on the medium. These are important cross-peripheral signals that aren't suitable to OBP transactions. They aren't, however, interrupts. A special kind of direct signal is an interrupt, which is exclusively a 1-bit signal used to trigger code execution for a particular hardware event. These are things like "good packet" and "bad packet," which tell the MAC layer when a packet has been received that passed or failed a checksum respectively.
Unfortunately, these inter-peripheral signals are tricky to simulate. A very helpful tool in the process is the Xilinx Chipscope Pro program. With this program and associated hardware core, you can create a sort of virtual logic analyzer directly in the FPGA. So, for example, we were able to record actual raw RSSI and I/Q data directly from the radio, and then feed them into the packet detector and AGC in order to refine their behavior.
Offline