1 Interposer & VXR Board Updates

First, some brief updates on our display system:

1. Display Interposer finished. We have finished our right-eye Display Interposer Board, and are working on mirroring the board to the left eye. This basically involves rotating the existing design and changing some minor details.

2. VXR Boards Arrived. 14 VXR boards have arrived for our upcoming review units:

We still need to have a PCBA affix components onto the board (e.g., the actual VXR chip and so forth).

2 Simula's FPGA System

In addition to the display boards (VXR Board + Display Interposers), our final headset design will also incorporate a front-facing camera system for Simula's AR Mode. This necessitates incorporating the following components into our design:

• Front-facing camera lenses (x2).
• Camera boards (x2) We plan to attach camera boards (which contain IMX547 camera sensors) to our Display Interposers, directly behind the camera lenses.
• FPGA. We will use an onboard FPGA to efficiently transmit camera data from the image sensors to the host. The FPGA will also be used to debayer the image data.

Note that since our upcoming Review Unit is a stripped down version of our headset, it won't actually include these parts. Nevertheless, we've still had to make decisions about how our design will work around these components, even at this early stage. This has included things like:

• Determining the attachment points of the cameras. We've recently outfitted our Display Interposer with camera attachment points.
• Adding power supplies to Interposer board. We've also added an extra PSU to our Display Interposer to feed power to the attached cameras.

How the preceeding components will be connected to our existing system can be visualized in the following schematic:

Notice how the camera boards are directly attached to the Display Interposers, and are fed into our FPGA via the SLVS-EC protocol. (While this schematic continues to include our I/O board and Intel RealSense for tracking, it is likely in our final release these components will be replaced with something better).

2.1 What will the FPGA do?

The responsibilities of our FPGA are as follows:

1. Camera processing. Our FPGA will primarily be responsible for processing image sensor data before it is sent to our host. This includes "image demosaicing", which basically interpolates missing color data into raw camera images.
2. Positional & orientation tracking. Our FPGA will also help process tracking data. (For now we are using an Intel RealSense for our Review Units, but will switch to a better solution before final release).
3. Eye sensor processing. The Simula One's eye sensors (used for automatic IPD adjustments) will send data to the FPGAs as well.

The FPGA will not be compositing images. In theory, we could also use the FPGA to composit images for the VR displays more efficiently. This offloading would reduce camera latency significantly, and free up resources on the host associated with VR compositing. Due to time & resource constraints, however, we are unable to implement this for the Simula One.[1]

[1] Example: this would require us to do things like implement a DisplayPort to MIPI bridge (similar to the VXR) on our FPGA board. This alone would take several months with our current team size, which wouldn't be worth the effort against our current release schedule.

2.2 Why use an FPGA at all?

The main benefit of using an FPGA is that it allows us to offload and parralelize the aforementioned computations that our onboard host would otherwise have to perform. In addition, FPGAs are good for sending large amounts of data to our host via high-bandwidth PCIe Gen 3 (instead of, e.g., a USB Gen 2 link). More on this below.

In principle, we could also use an ASIC instead of an FPGA to help out with all of our parallelized data processing.[2] In theory, ASICs are the better choice for mass produced products in terms of price and performance. In our case, however, it's best to stick to stick with an FPGA:

1. Early design flexibility. FPGAs are software updatable, which makes them easy to iterate on (both during development and after headsets are shipped). If we figure out how to implement something better after release, users can still update their Simula One's over the cloud if desired.
2. Less upfront costs. ASICs = more time + more money.

[2] For a good overview of ASICs vs. FPGAs, check out this video.

2.3 FPGA Evaluation Criteria

The things we've evaluating for our FPGAs:

1. Maximum bandwidth. Our FPGA needs lots of bandwidth available to send its high-resolution camera images to the host. This minimizes AR camera latency (recall our target: ≤ 20ms per camera frame).

   • PCIe Gen 3+. PCIe Gen 3 is table stakes on this front; PCIe Gen 4 would be nice to have.

   • SLVS-EC. We require SLVS-EC protocol support to route images from the camera sensor to the FPGA. This protocol is faster and uses less wires than SLVS or MIPI-CSI.

   • Power draw. We expect our FPGA to draw 6W of power with AR mode on running at full resolution. Here is how this compares to other parts of our system:

     System	Power Draw
     Detachable computer	15W-28W
     VXR+Displays	3W
     Cameras	2.5W

2. Minimum size. Ideally our FPGA is on the smaller side. The current option we're looking at (see below) measures out to 11.5mm x 9.5mm (as opposed to other models which are more than twice the size).

3. Availability. Unfortunately we are seeing lead times as high as 52+ weeks in the ecosystem (unacceptable for us), though the Lattice board we're looking at below has a ~12 week lead time with reasonable price.

2.4 FPGAs under consideration

FPGA models under our consideration:

This last model in particular is the one we're currently testing. It is available at a reasonable price with ~12 week lead time. We are currently looking at the 8-lane model (4 lanes for incoming camera data; 4 lanes for PCIe outward data). Here's a picture of its evaluation board: