Working Design plans for interface and eBPF processor

[andrewgillis95]

Below are some of the block diagrams that we are currently basing the design on. Please let us know if there are any concerns or inaccuracies, as we are still wrapping our heads around the interface, and DMA portion of things a bit.

Overall view:

More detailed view of the CPU and predicted memory interface:

[kellurs]

Thanks, @andrewgillis95.

The native eBPF CPU design is looking good. I have a few questions:

1. How do you plan to handle errors in the CPU (e.g., Invalid opcode, Address out of range, etc.)?
2. The diagram shows multiple busses between the Data Memory Interface and the DRAM, depending on the DRAM section accessed. Is that the case? Could you provide some additional detail on that part of the design?

Can you provide a "theory of operation" section to go along with your top-level view? It would be good to show how the system handles the steps described in the "sample execution" section here.

A few other minor points:

• The diagrams should reflect a system with multiple eBPF accelerators to show which parts are duplicated or scaled up as you add accelerators.
• Could you color code or otherwise indicate which parts of the design are implemented as standalone Xilinx IP and which parts are custom logic done by you and your team?

This is an excellent start, and I'm excited to see you and your team bring this design to life over the coming months.

[Spencer-Comin]

@kellurs, to address your questions,

1. Thanks for the question on error handling. We've put some thought into this, and it should be included in the next iteration of the CPU block diagram in the coming weeks. Invalid opcode and arithmetic errors (overflow, divide-by-zero, etc.) should be pretty simple to catch within the CPU itself, while memory errors (address out of range, unauthorized write attempt, etc.) rely on the memory interfaces, which we haven't focussed on designing fully yet.
2. Each CPU will need to have access to three separate sections of Data Memory: (1) Input Data Memory, for user input data, i.e., the data that the program is operating on, which only needs to be read from (2) Temporary Internal Data Memory, which is the 'stack', memory for the program to read and write from during execution, and (3) Output Data Memory, to output results to the user, which only needs to be written to.

[iomartin]

@spensicus,

Regarding the memory model, the design we had in mind was actually simpler than what I think you're proposing. I'm not sure we need the three sections of memory you are describing.

The Hermes memory is partitioned into N program slots and M data slots, and then we send a command to "run program X with data slot Y". Then program X has total freedom to use slot Y as it see fits (read/write anywhere). The device then only has to enforce that there are no out of bounds accesses.

[Spencer-Comin]

Here is the updated design of the processor incorporating error handling and a simplified memory model. At the moment the newly added Controller block is quite vague in concept. It is included here to represent a system that reports the error from the CPU back to the driver, and also to represent a system of pointing the CPU to the first instruction in a program.

[Spencer-Comin]

Just a quick clarification, stating that the Controller block is vague in concept is not quite correct. As the diagram I posted is intended to show everything from the CPU's point of view, the controller block here doesn't require much detail. The Controller block, along with the memory interface blocks, represents the interface between the CPU and the rest of the design, shown in more detail in the first diagram posted by @andrewgillis95