Open Paul-T-pdx opened 10 years ago
ghost
commented
10 years ago Yes I agree; from what I read these extra extensions are necessary only for supporting higher speed master and slave devices. There is still a possibility that there are certain optional extensions that we may end up needing to implement in order to bridge from the PCIe endpoint, but I still don't know enough to say for sure one way or the other.
Paul-T-pdx
commented
10 years ago Here is what the entire thing is: it is FSM (state machine) on OCP side which basically sets or clears those signals of OCP interface. And for now, to interact with OCP FSM we simply implement a loopback (a dummy) for Flash, as follows. Master OCP socket (or interface, or wrapper, or port - whatever anyone wants to call it) of Bridge sets MCmd to non-zero, which means there is command from master OCP socket (from Bridge) for Slave (flash). We simply write that command and corresponding address from OCP bus to the buffer of our dummy flash (loopback) and sent back command SResp as "accepted". Master OCP socket of Bridge sees this "accept" and sets MCmd to zero. That's it. We instantiate an array in our loopback (dummy Flash, aka "loopback"), Address vs. Data, where we store the data to be kept by our dummy Flash, so that it can be retrieved later on demand. That's our FSM on OCP protocol side. The entire thing now looks to me now like our Cache project in previous class. It is only later, when we get this Flash loopback (dummy array) working, we can study Flashes and how the write data to actual flash hardware and return data from it. But Woodruff gave us invaluable hint during our very fist meting, to use "loopback" for flash initially. I am eternally grateful for that tip.
ghost
commented
10 years ago Well the flash memory is going to be on the OCP bus so as you stated it's just going to issue commands that follow OCP. Since we have the general idea about interaction with the bus we should maybe start looking in to the block diagram. Our OCP wrapper is going to be an asynchronous network interface for PCIe endpoints, but the PCIe endpoints themselves are synchronous and I would argue high-speed. I know this will take some communication with the PCIe guys for implementing techniques such as out of order transaction management and the like, but as you stated previously about just getting a simple memory write to happen lets try to get a diagram with all the blocks we think we need at this point.
Paul-T-pdx
commented
10 years ago It even looks to me that we mostly do NOT even need any Xilinx to accomplish 99% of our work! We only need Verilog simulator which we already have, as follows: We crate a dummy PCIe request (TLP packet) on PCIe side of simulation, it should go though the Bridge module (Verilog FSM), and is received by our Flash Loopback (Flash dummy) and written to its Address_vs_Data array. So, Xilinx or Altera and such tools should only be helping us now to establish what those TLP packets or whatever that is used to interface FPGA cores (such as our bridge).
ghost
commented
10 years ago Yeah we should be able to stay technologically agnostic for a large part of the project as long as we make sure that the PCIe core created by the Xilinx tools is properly interfaced to. If you haven't already though the Xilinx PCI coregen documentation does have a test bench that has been written and verified to generate PCIe packets in order to verify their coregen module. Hopefully we can reuse what has been done there to create our PCIe validation data, but I imagine going through the research to generate our own can be beneficial for the sake of getting experience the protocol. At least we do have verified working sources as a reference though.
Paul-T-pdx
commented
10 years ago Posted a mini-overview of Flash with OCP socket design, in OCP directory, per last week's meeting request. OCP seems straight forward and simple, but perhaps I do not "get" something else. I am switched to PCIe's TLP interface research: will scan through a lot of PCIe bridges or interfaces examples, at TLP level.
kharthik
commented
10 years ago Can i get the architecture for OCP bridge
boula-guest
commented
10 years ago Do you mean you would like block diagram to see what modules make up the bridge? If so you can look through the report and find out just about everything you need to know. At least that is where I would look first. On Sep 23, 2014 12:10 AM, "kharthik" notifications@github.com wrote:
Can i get the architecture for OCP bridge
— Reply to this email directly or view it on GitHub https://github.com/spesialstyrker/boula/issues/6#issuecomment-56483155.
ghost
commented
10 years ago Yes the information is in the wiki repository under doc/Design/Report. Please let me know your questions/feedback after having read the report!
Sent from my iPhone
On Sep 23, 2014, at 8:10 AM, boula-guest notifications@github.com wrote:
Do you mean you would like block diagram to see what modules make up the bridge? If so you can look through the report and find out just about everything you need to know. At least that is where I would look first. On Sep 23, 2014 12:10 AM, "kharthik" notifications@github.com wrote:
Can i get the architecture for OCP bridge
— Reply to this email directly or view it on GitHub https://github.com/spesialstyrker/boula/issues/6#issuecomment-56483155.
— Reply to this email directly or view it on GitHub.
kharthik
commented
10 years ago Ya got it..thanks. Similary may i get for Avalon to OCP.?
ghost
commented
10 years ago This project only implemented PCI express to OCP; the Avalon interface is not handled sorry.
Sent from my iPhone
On Sep 23, 2014, at 10:37 AM, kharthik notifications@github.com wrote:
Ya got it..thanks. Similary may i get for Avalon to OCP.?
— Reply to this email directly or view it on GitHub.
kharthik
commented
10 years ago Hi thanks for your reply.
On Tue, Sep 23, 2014 at 11:20 PM, spesialstyrker notifications@github.com wrote:
This project only implemented PCI express to OCP; the Avalon interface is not handled sorry.
Sent from my iPhone
On Sep 23, 2014, at 10:37 AM, kharthik notifications@github.com wrote:
Ya got it..thanks. Similary may i get for Avalon to OCP.?
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/spesialstyrker/boula/issues/6#issuecomment-56560890.
Regards Kharthik 7299934271
I finished OCP book. The actual relevant stuff for our project was only about 1/4 or even 1/5 of entire book: the beginning, the basic signals. The rest of the book was description of optional things like threaded transfers, tagged transfers, caches and cache coherence, etc. My preliminary conclusion: to implement the OCP side of the interface, we only need three mandatory signals: Reset, OCP clock and MCmd (master command), and MData (data from Master, to write to Flash) and SData (data from Slave / flash, to return to Master (PCIe), and SCmdAccept (slave acceptes command from master flag), SResp (slave accepts data from master). This would be page 23, "Non-posted write with response enabled". OCP book was very theoretical, no examples were given there on how to implement the actual FSM (controller, arbiter) of OCP side, etc. I would like to find some practical perspective books or web sites about OCP. PS: Now, I am turning my attention to finding examples of PCIe core interfaces with other cores of FPGA, by TLP interface or such. Setting up Xilinx, generating cores, and looking at code of those interfaces between cores. I could have started doing it on OCP side, but it should be much easier to find examples based on PCIe cores. Once we see it, the rest is just cloning the idea of such interfacing to OCP side.