frameworkcomputer / expansionbay Goto Github PK

I have attached two screenshots showing the discrepancy, along with a PR with KiCad templates and the updated pinout list but the .pdf provided by the manufacturer still has some signals with # and no hash to signify P/N polarity which I have changed in the readme but not in the .pdf as I cannot. #5

this is my first time using Kicad and I would like to try and make something for the 16in framework but don't know how to open these files in Kicad

Does it go to the internal display (thus bypassing the need to route the video signal over PCIE), to the IO (to attach external displays) or somehow to the CPU/integrated GPU?

Or is it the output coming from the iGPU?

What can it be used for?

Need the dimensions and details of not just PCBA but the housing. Planning to start development work on an industry-specific expansion module, but I need to at least know the rough dimensions to determine feasibility.

In the Framework announcement, it was stated thickness can be whatever, but I'm sure the PCBA will need a connection port to "slot in" the mainboard.

Another point that I need clarification on is will the housing be all the way at the back of the laptop for potentially additional port additional ports, etc.

Tx and Rx are not useful names for pins, since whether it is Host->Card or Card->Host. A note should be added to the electrical documentation clarifying this. Note that commonly, the pins are named HSO and HSI to signify it is the Host's Input and Output.

Can we assume both DisplayPort and PCIe TX lanes have AC coupling capacitors on the motherboard, or does the design assume we use the 3V/5V given as a power supply for the receiver?
From quick research they could have been omitted if that assumption was made.
The reason I am asking is because I plan to route the PCIe lanes outside the chassis using OCuLink, so the receiver will obviously use a different power supply. Having to place them myself this far after the transmitter would add a lot of reflections to my knowledge.

The last commit to this repo was in August and the documents still say that the designs are "pretty early" and subject to change. But mainboard production started almost 2 weeks ago, which implies that (at least the electrical) designs have been locked.

Are the documents here still subject to change? Has anything changed since the last commit?

Hello,
Looking at the SSD Reference Design, you employ the PI6CB33202 PCIe Clock Buffer.
By default it is in PLL Bypass mode (so both outputs are always on, with the input clock being passed through), however it could in theory be used to disable or re-drive the clock signal for each port using the SMBus/I2C interface.
Is this actively used in modern OSs by default? I have not found any information on default I2C drivers for adress 0x6C, which indicates the clock buffer is by default only a vehicle for the clock termination resistors.

Additionally, the pinout specifies that if the board uses two ports, it should use two separate CLKREQ and REFCLK for them (sacrificing DP AUX lanes), which the reference design does not. This should in theory eliminate the need for the clock buffer entirely, correct?

Can I assume the clock buffer is a remnant from a time when the Expansion Bay Interface did not yet include the alternate pinouts for two separate PCIe ports?
And/or do future Frameworks contain firmware that expect to be able to turn disable each individual port using the PI6CB33202 PCIe Clock Buffer with I2C adress 0x6C?

Thanks for any information. For now I will assume the alternate pinouts are valid and sufficient

PS: I believe the PEX_REFCLK signal being marked as output is wrong, it should be input (to the expansion board)

PS 2: I noticed both SSDs use the same CLK_REQ signal, indicating that one SSD requesting a low-power state would disable both SSDs REF_CLK. This makes me assume the alternate pin assignment was introduced later and is the only solution to use, meaning the current Dual SSD reference design is out of date. Correct?

I'd like to verify the dimensions and shape of the PCB.

First, the given PCB has cutouts when it is not obvious why they are there - e.g. the large retreating edge where the interface slot in the shell casing should be, as well as the cutouts next to the bottom edge hole cutouts (where the GPU shell does allow for PCB according to earlier videos and photos).
Can you confirm the shell allows for the following additional PCB space to be used?

Especially the top edge is important. In addition to what the shell back end will look like in regards to distance to the specified PCB edge. From videos I already inferred the removable backend for ports likely spans the entire 118.65mm - is that also correct?

Thank you for the help