You are not logged in.
Hi Rice,
In the Data Buffer/BER Calc (receiver part), I found two signals- Byte Addr and Rx Byte WE arrive BER scope 2 cycle earlier than the rest of 6 signals. Should we add 2 delay blocks for each of these two signals to make all 6 signals arrive at BER scope at the same time? I think this may affect the accuracy of simulation...
Also, in the BERCalc/BER PKt Buffer, what is regRx_FlexBERMode for? It belongs to a bit of RX control bits; however, I can't find the description in the register mapping (http://warp.rice.edu/trac/wiki/OFDM/MIM … lRegisters).
It seems used to choose the golden data in either PKt Buf IF or Sim Only PKt Buff for BER calculation. But which buffer is actually used to provide the golden data for CRC?
Two more detailed questions:
1) In PktBuffer_CRC1/Packet Buffer, what do you mean by "Tx/Rx" is half-duplex, so sharing the logic is no problem in real hardware"?
2) In Packet Buffer/Auto Tx Header Translation, there is an comparator to compare regTxRx_numHeaderBytes and ByteAddr. Since numHeaderBytes is 24 (in the init script) and ByteAddr starts from 1, should it be a>=b instead of a>b considering that ByteAddr=24 is the last header byte?
3) Also, in the Tx Registers/Control Bits Slices, different bits which indicate different control signals are mapped to different memory addresses(for example, 0x1 0x2...). Those addresses are not continuously allocated. Why is that? Could you kindly point out how to integrate them with PPC and which file in XPS project indicates the actual register mapping?
Thanks a lot.
Tan
Last edited by tan (2010-Jun-12 13:30:37)
Offline
1) That logic is related to a real-time BER calculation mode supported by the PHY. In this mode, the Rx doesn't actually write its received bytes to the packet buffer. Instead, it reads the bytes from the packet buffer and compares them to the received bytes on the fly. This requires both the Tx and Rx nodes receive a common packet over Ethernet and write it to the appropriate buffers before the Tx node transmits it.
2) The byte address starts at 0.
3) Every register in the PHY is 32-bits. For some registers, each bit is used separately (like the Tx Control Bits register). Masks for each bit are in warpphy.h and are used during initialization in warpphy.c.
Offline
Ok, I understand them.
But I have three more questions.
1) For the register address mapping, I've looked at the memory map in EDK processor. The strange thing is that some of from register and to register pairs with different names are mapped to the same address. For example, in Rx Registers, Rx_BER_TotalBits(To Register) and Rx_Constellation_Scaling_w(From Register) are mapped to the same address:0x80004004. Also, when I look at Rx_ControlBits under the mask, it has Rx_ControlBits_w(from register) and Rx_ControlBits_r(to register). Could you explain why do you use these two registers as a single register? I think the value in From Register comes from PPC, is that correct? Also, Rx_ControlBits_r is useless, right? Based on the help document of from/to register, they should use in pairs. Since Rx_ControlBits_w and Rx_ControlBits_r are different, they should represent two different registers, right? Why are they mapped to the same memory address? What is the other halves for to/from register?
2) If I want to modify the packet buffer and divide it into three chunks to store different frames from the MAC, could you tell me which part I should modify? I think I should modify Pkt Buffer Addressing in PKt Buffer BRAM Interface instead of PLB Pkt BUffer because this addressing logic will provide the address to the external RAM and PLB PKt Buffer will not be synthesized, right? Also, I should modify BER Cal in the data buffer at the receiver...
3) In your entire design, you didn't use advanced design flows like importing m-function or Verilog(mcode or black-box). I think they are more efficient. Is there a specific reason you didn't use that? for example, some problems for synthesizing the design...
Thanks a lot,
Tan
Last edited by tan (2010-Jun-23 14:12:15)
Offline
1) Sysgen has From and To registers. When used to realize a PLB slave interface, From registers are write-only (from software), and To registers are read-only. You can optionally enable register readback in the EDK Processor block to make all From registers read-write. This feature was broken in Sysgen 10.1.01, so the PHY uses explicit pairs of From/To registers wherever we needed a read-write register.
2) The packet buffer is already divided into 32 subbuffers of 2K bytes each. The buffer itself is not included in the Sysgen model, but is realized as a bram_block in XPS. The Sysgen model implements a BRAM interface which is connected to this bram_block pcore in the XPS project.
3) The efficiency of the generated HDL depends much more on the architecture of the design than which flow is used to realize it. We avoided black boxes mostly for convenience; dividing the design between an .mdl and many .v files would make maintaining/extending it even harder. Black boxes also require invoking ISE's HDL simulator every time the Sysgen model is simulated, which slows things down.
Offline
Ok. That's the reason why you used some mcode blocks instead of Verilog blocks for intense signal processing in some part of your design. Thanks a lot for your reply!
Tan
Offline