Open bhunt2 opened 10 years ago
At least one more week past next weeks meeting. We will be researching:
"Inputs and Outputs of Core that will be used by our bridge", aka the Interface: contains TLP packet (signals) and possibly additional signals from Xilinx's PCIe core which is AXI interface. Yes, this is the major and probably the only major task that everything else pretty much depends on. I am working on establishing the PCIe's interface, at TLP level, for our Bridge. But with PCIe the research will be easier I think because there are a lot of PCIe to pretty much Anything bridges on the web (except to OCP). I discovered that we both were correct about Xilinx's suggested wrappers for TLP layer, either TRN or AXI, as follows. The Virtex-6 has documentation that refers to both TRN and AXI interfaces (wrappers) for TLP layers. For example, document v6_pcie_ug517.pdf titled "Virtex6 FPGA Integrated Block for PCIe", at http://www.xilinx.com/support/documentation/user_guides/v6_pcie_ug517.pdf refers to TRN on page 32 as its "Transaction Interface" (or, as TLP's wrapper). But as we know other Virtex 6 documentation uses AXI interface (wrapper) as Transaction Interface. So, I conclude Xilinx created both wrappers for its PCIe cores, for PCIe TLP layer and both are available for generation. When I looked at TRN wrapper, it looked easy or much easier than AXI signals (interface): looked like only few additional signals were there (in addition to TLP packet signals). So, I was inclined to use TRN wrapper, to expedite the learning curve, but now I am thinking that there are a lot of AXI to OCP, AMBA to OCP bridges examples, it will be easier to use AXI bridges examples (better learning curve).
The TRN wapper for the TLP is being phased out and is not supported on many of the more advanced and newer boards so it is necessary that we use the AXI-4 Stream to develop our bridge. This is not just because we are developing something for future use after TRN is completely phased out, but also because our bridge will eventually be moved to a Vertex 7. The Vertex 7 only offers AXI-4, so that is what we will be using.
The last diagram, in Wiki section titled "Xilinx PCIe Core Gen Notes" is a Mapping of 32-bit wide TLP packet onto 64-bit bus. The one before last diagram is 32-bit wide TLP packet representation. (These are standard academic high level descriptive statements of what the diagrams represent). Both diagrams are much greater than their simple sum: both represent MOVEMENT from pure theoretical TLP packet description to PRACTICAL sending of that TLP on 64-bit bus! The shaded area in the left part of the packet is the AXI signals bundle. Now, the TLP is beautifully mapped onto 64-bit wide bus, but there is some AXI "appendage" on the left which is not on 64-bit width. It appears that in order to transmit TLP packet, some wrapper must be used (AXI or TRN): page 99, 100, etc, "Figure 5-3: TLP 3-DW Header without Payload": http://www.xilinx.com/support/documentation/ip_documentation/v6_pcie/v2_4/ug671_V6_IntBlock_PCIe.pdf TLP packet is traveling on s_axis_tx_tdata[63:0] wire (actually "bus", because it has more than one wire). Document and diagrams show those AXI signals and the timing diagram. Timing diagrams are what is used to design FSM(s). In Vertex 5, the PCIe used some other weird wrapper for TLP: http://www.xilinx.com/support/documentation/user_guides/ug197.pdf, page 28, 29: TLP packets are wrapped in some LLKTXDATA wrapper, for the purposes of signalling TLP transmission start, end, errors, wait, etc. Comparison of these various Xilinx's documents leads to realization that some wrapper is likely always used to transmit TLP packets across FPGA fabric or bus.
Must not forget about error signaling to the core when we receive an unsupported packet into our bridge.
Coregen todo:
Need to figure out bit width & depth of base address registers for PCIe coregen module Determine capabilities register Determine BRAM configuration Do we want slot clock configuration for link register?
From page 100 of the Virtex6 PCIe integrated block document: "If the user deasserts m_axis_rx_tready during the middle of a transfer, the core stalls the transfer of data until the user asserts m_axis_rx_tready again. There is no limit to the number of cycles the user can keep m_axis_rx_tready deasserted. The core pauses until the user is again ready to receive TLPs."
The same applies for throttling on the transmit interface. The user can deassert the valid signal if there is not yet valid data to present and the core will ignore it.
After meeting together we found that we will not be able to meet the assigned time for having everything updated on the wiki pages. We have some items that came up that will require additional research before we can move forward.