You are not logged in.
We are currently trying to develop a WiMAX based PHY layer. In order to get the bandwidth we need as well as meet part of the standard we are looking into increasing the OFDM symbols.
Is there any documentation or suggestions that could guide us, that would be a great help.
Thanks!
-KJ
Offline
You want to increase the number of OFDM symbols (i.e. the length of the packet) or the number of subcarriers? The first is easy; the PHY supports very large packets (4000 OFDM symbols, I think). The second is harder. A lot of the PHY's control system is designed for 64 subcarriers. Extending it to more is certainly possible, but will definitely require careful tracing of control signals in the blocks that interact with the FFT cores.
Offline
We were looking to modify the number of sub carriers that the system uses.
Is there any documentation that could help us with increasing the number of subcarriers.
thanks,
KJ
Offline
We haven't designed an OFDM system with more than 64 subcarriers, so we no documentation to offer about how to do it. My only suggestion is to spend some time understanding the architecture of the current PHY model to figure out which processing and control blocks depend on the number of subcarriers.
Offline
We've been going through the blocks and making some changes.
We hit these two variables and we're not too sure how you guys came up with these values.
They are:
max_num_baseRateSymbols = 31;
max_num_trainingSymbols = 15;
Everything leading up to this point we feel we understand. Can you please explain your reasoning for selecting these values?
Thanks!
Offline
These values are used to define the bit-widths of constants and registers in PHY control systems (i.e. the register that holds the actual number of base rate symbols has datatype UFixN_0 where N=ceil(log2(max_num_baseRateSymbols)) ).
The current values are pretty arbitrary- I figured we would never use more than 15 training symbol periods or 31 base rate symbols in a packet.
Offline
I'm new to the WARP system, and I'm trying to determine what the overall capacity of the WARP Virtex II board is, that is, exactly how full-featured can a modem implementation be on this platform ? Is there an block diagram available of the OFDM Reference Design, and is there any documentation that woudl indicate how much of the Virtex-II device is used by this reference design.
I downloaded the 12.21 design zip, but didn't see any overview documentation as such.
Thanks,
Ryan
Offline
You can see the resource usage details in the log file '<refdes folder>/implementation/xflow.log'. The relevant section for v12.1 is:
Number of MULT18X18s 132 out of 328 40% Number of PPC405s 2 out of 2 100% Number of RAMB16s 231 out of 328 70% Number of SLICEs 21580 out of 33088 65%
Our documentation is (as always) a work in progress. The reference design page and workshop slides are the best docs we have at the moment.
Offline
Chris,
I am a little bit confused about the resource allocation you specified above. I beleive there is statement somewhere indicating that there is ample processor availability for the user to add substantial networking capability and to add more advanced MAC features. So what does it acutally mean that the PowerPc cores are used at "100%"
1) Could you please give a more meaningful estimate of how much processor capability is "available" for additional functionality added to reference design (in both MAC and PHY => is it correct that MAC and PHY use different Power PC cores)?? (both with Virtex-II and Virtex-4)
2) In relation to this, could you give some examples of needed functionality or capability that would require linking a second FPGA board (via high speed bus) to the main board.
Thanks
Offline
The FPGA has two PPC405 cores. This resource usage is reported by the Xilinx place-and-route tools, indicating that both PPCs are "in use". This does not correspond to the actual utilization by code. Our designs only execute code in one core, though we're exploring ways to use the second core in more advanced designs.
1) The PHY is implemented entirely in the FPGA fabric. MAC processing is split between C code (in the PPC) and fabric.
2) Significant extensions to the PHY would require extra FPGA fabric. For example, adding a big FEC decoder could require splitting the datapath across two chips.
Offline