Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file removed doc/platform/cpo-file-structure.png
Binary file not shown.
34 changes: 22 additions & 12 deletions doc/platform/port_mapping_for_cpo.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,8 +136,8 @@ We can achieve modeling of complex multi-device topologies via the **platform.js
"device_type": "optical_engine",
// The number of CMIS banks associated with this device.
"max_banks": 4,
// The overall number of physical lanes available in this device.
"lanes": "41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,...",
// The ASIC lanes this device is responsible for
"asic_lanes": "41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,...",
// If a vendor needs to encode I2C mapping information, that information
// can be included here. However, this is platform dependent and may be
// achieved via other mechanisms.
Expand All @@ -148,8 +148,8 @@ We can achieve modeling of complex multi-device topologies via the **platform.js
// Number of individual lasers this device provides.
"lasers": 8,
"max_banks": 1,
// laser_to_lane_mapping provides a mapping of laser to which lane it is powering.
"laser_to_lane_mapping": {
// laser_to_asic_lane_mapping provides a mapping of laser to which ASIC lane it is powering.
"laser_to_asic_lane_mapping": {
Comment on lines -151 to +152

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of lane does asic lane want to distinguish?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

asic_lane in this file refers to the ASIC SerDes lanes that interface with the on-package optical engine.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I think no need to add 'asic' since when we mention lane it does mean serdes lane.

"1": "41,42",
"2": "43,44",
"3": "45,46",
Expand Down Expand Up @@ -295,20 +295,20 @@ class ChassisBase:
...
def __init__(self):
...
# List of SfpBase-derived objects representing all sfps
# List of CpoBase-derived objects representing all CPO ports
# available on the chassis
self._sfp_list = []
self._cpo_list = []
cpo_data = device_info.get_cpo_data()
if cpo_data:
self.construct_sfp_list_for_topology(cpo_data)
self.construct_cpo_devices(cpo_data)

def construct_sfp_list_for_topology(self, cpo_data):
"""Subclasses should implement this method to create sfp objects based on topology data in cpo.json"""
def construct_cpo_devices(self, cpo_data):
"""Subclasses should implement this method to create CPO objects based on topology data in cpo.json"""

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please clarify what cpo.json is? Is it another name for optical_devices.json?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, optical_devices.json was renamed to cpo.json everywhere based on feedback in the original HLD PR. It is now named cpo.json everywhere.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this is only a naming change, right? The content remains the same as before.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, the content remains the same. The only changes are:

  • optical_devices.json has been renamed to cpo.json
  • fields referencing lanes have been renamed to asic_lanes to make it clear these are the ASIC SerDes lanes.

raise NotImplementedError

class VendorCpoChassis(ChassisBase):
...
def construct_sfp_list_for_topology(self, cpo_data):
def construct_cpo_devices(self, cpo_data):
for interface in cpo_data.interfaces:
assert len(interface.associated_devices) == 2, "We expect 2 devices per interface on this CPO hardware platform"

Expand All @@ -325,10 +325,20 @@ class VendorCpoChassis(ChassisBase):
# Create a CpoBase-derived object to represent this interface
assert oe, "No optical engine found for this interface"
assert elsfp, "No ELSFP found for this interface"
# VendorCpoSfp would be a subclass of CpoSfpBase here.
self._sfp_list.append(VendorCpo(hardware_id=self.hw_id, oe=oe, els=elsfp))
# VendorCpo would be a subclass of CpoBase here.
self._cpo_list.append(VendorCpo(hardware_id=self.hw_id, oe=oe, els=elsfp))
```

Additionally, CPO devices will be stored separately to traditional `SfpBase`-derived objects on a Chassis object in `self._cpo_list`. Accessors like
`get_num_cpos`, `get_cpo` and `get_all_cpos` will be implemented on `ChassisBase`, the same as are available for accessing `self._sfp_list`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you plan to integrate the get_cpo() api into xcvrd, given that xcvrd currently relies on get_sfp() for all transceiver operations?


Any non-CPO ports will contain `None` at the index in `self._cpo_list` corresponding to the physical port -- the inverse is true for
`self._sfp_list`. For example, on a device that had the following port layout:
```
[cpo, cpo, cpo, cpo, sfp, sfp]
```
`_cpo_list` would be `[CpoObject, CpoObject, CpoObject, CpoObject, None, None]` and `_sfp_list` would be `[None, None, None, None, SfpObject, SfpObject]`

##### 7.3.3 CPO Joint Mode
There is a mode of operation for CPO hardware called "joint mode" where a single I2C device called an "MCU" handles all reads/writes, redirecting them to the optical engine EEPROM or the ELSFP EEPROM appropriately.

Expand Down