|
|
For now this is a scratch space for defining how the extensions will be
|
|
|
structured.
|
|
|
*For now this is a scratch space for defining how the additions to the
|
|
|
WR code will be structured.*
|
|
|
|
|
|
Part of the code should be contained in one or more separate submodules,
|
|
|
to make it modular
|
|
|
This document describes design ideas of how to design the SFP+ libraries
|
|
|
such that they are:
|
|
|
|
|
|
\- Compact (code size)
|
|
|
|
|
|
\- Modular/intuitively structured
|
|
|
|
|
|
\- Simple to use
|
|
|
|
|
|
\- Cross-architecture
|
|
|
\- (Reusable)
|
|
|
|
|
|
## Software modules
|
|
|
|
... | ... | @@ -70,12 +79,19 @@ Since SFP transceivers also have GPIO signals like TX\_FAULT and |
|
|
RX\_LOSS, so a GPIO abstraction should also be required.
|
|
|
This layer knows nothing specific about SFP modules. Its just an
|
|
|
I2C/GPIO abstraction. It also knows nothing about other I2C components.
|
|
|
Some OS specifics functions, like the mutex, may also be exposed in this
|
|
|
layer.
|
|
|
|
|
|
The implementation of this layer is architecture dependent. That is, the
|
|
|
headers are generic, but most of the code is platform specific.
|
|
|
|
|
|
### B - Low level component drivers
|
|
|
|
|
|
This is optional since we could do without. I2C access for SFP modules
|
|
|
is not that complex. This modules would only make sense if we would
|
|
|
create a soft of generic hardware abstraction layer.
|
|
|
This modules would only make sense if we would create a sort of generic
|
|
|
hardware abstraction layer on top of module A. This layer could contain
|
|
|
drivers for reading EEPROM, various sensors, and controls DACs and ADCs,
|
|
|
for example. This is optional since we could do without. I2C access for
|
|
|
SFP modules is not that complex.
|
|
|
|
|
|
### C - Low level SFP abstraction
|
|
|
|
... | ... | @@ -95,9 +111,9 @@ Address spaces can be accessed through generic enumerated type, like: |
|
|
status_t sfp_mod_read(sfp_mod_t * mod, sfp_as_t as, uint8_t offset, uint16_t length);
|
|
|
|
|
|
Write operations transparently take the 8 byte pages into account. I.e.
|
|
|
a write operation may start at any index in the address space. When B
|
|
|
has been implemented this may call EEPROM read/write operations from
|
|
|
module B.
|
|
|
a write operation may start at any index in the address space. It does
|
|
|
not validate checksums though. When B has been implemented this may call
|
|
|
EEPROM read/write operations from module B.
|
|
|
|
|
|
Reading of the SFP IO lines is done by querying the status, like this:
|
|
|
|
... | ... | @@ -106,23 +122,72 @@ Reading of the SFP IO lines is done by querying the status, like this: |
|
|
#define SFP_STATUS_TX_FAULT 0x04
|
|
|
sfp_mod_status_flags_t sfpmod_status(sfp_mod_t * mod)
|
|
|
|
|
|
When using modules A and B, this layer will not call any platform
|
|
|
specific functions, however, it will need to know which GPIO's belong to
|
|
|
which I2C ports, and what the generic board architecture is. So, no
|
|
|
hardware specific code, but it will contain platform specific
|
|
|
configurations.
|
|
|
|
|
|
When not using modules A and B, this module may contain a subset of
|
|
|
these inside C.
|
|
|
|
|
|
### D - High level SFP access
|
|
|
|
|
|
Provides access on a high level to the SFP module. Either data can be
|
|
|
accessed directly though functions:
|
|
|
This module povides generic accessor functions, which must be supplied
|
|
|
with a field identifier. Each field identifier must be defined in a
|
|
|
header file. An example field identifier may
|
|
|
be:
|
|
|
|
|
|
sfp_set_wavelength(sfpmod_t * mod, uint32_t);
|
|
|
//! SFP temperature, encoded as fixed point 7.8. To get the real temperature divide by 256
|
|
|
#define SFP_FIELD_TEMP SFP_DEF_SCALAR(SFP_AS_A2_LO, SFP_VAL_TEMP_OFFSET, SFP_TYPE_I16)
|
|
|
|
|
|
Or generic control functions are provided:
|
|
|
Which can than be accessed using the following function:
|
|
|
|
|
|
// something like
|
|
|
#define SFP_PARAM_WAVELENGTH DEF_SFP_PARAM(FP_AS_A2_PAGE2, SFP_VAL_WL_OFFSET, U32)
|
|
|
// signed 16 bit integer accessor method.
|
|
|
int16_t sfp_i16_get(sfpmod_t * mod, param_desc_t param);
|
|
|
|
|
|
And invoked like this:
|
|
|
|
|
|
int16_t wl = sfp_i16_get(mod, SFP_FIELD_TEMP);
|
|
|
|
|
|
Note that this may not be very efficient for reading the entire EEPROM,
|
|
|
but larger structures can be defined, if these are often read. E.g.
|
|
|
|
|
|
typedef struct vendor_info_s {
|
|
|
char[16] name;
|
|
|
uint8_t _reserved;
|
|
|
uint8_t oui[3];
|
|
|
char[16] part_no;
|
|
|
char[4] vendor_rev;
|
|
|
} vendor_info_t
|
|
|
|
|
|
#define SFP_FIELDS_VENDOR_INFO DEF_SFP_STRUCT(SFP_AS_A0, 20, vendor_info_t)
|
|
|
|
|
|
vecntor_info_t vendor_info;
|
|
|
|
|
|
uint32_t sfp_get_u32(sfpmod_t * mod, SFP_PARAM_WAVELENGTH);
|
|
|
sfp_struct_get(mod, SFP_FIELDS_VENDOR_INFO, &vendor_info);
|
|
|
|
|
|
Note that this may not be very efficient for reading the entire EEPROM.
|
|
|
The advantage of using generic accessor functions is that it does not
|
|
|
need a code path for each field. When using a specific function for each
|
|
|
property, i.e. sfp\_get\_temperature(), each getter and/or setter called
|
|
|
will required program space. On the other hand, generic accessors do not
|
|
|
have this disadvantage, albeit it be a bit less intuitive.
|
|
|
|
|
|
### E - Application
|
|
|
|
|
|
TODO
|
|
|
*TODO:** Here must be described how the data from the SFP+ layer is
|
|
|
used in the WR PTP Core fabric.
|
|
|
|
|
|
## Discussion
|
|
|
|
|
|
1. It seems that it would be useful to have a WRPC-wide hardware
|
|
|
abstraction layer, which hides platform/architecture specific
|
|
|
control, such as I2C and GPIO access, but may also be extended with
|
|
|
other inter-chip communication protocols such as SPI, etc... It may
|
|
|
even provide a subset of OS functions, i.e. the mutex), not provided
|
|
|
by the standard library. However the roll-out of such an abstraction
|
|
|
will be a huge effort. This HAL would preferably be a submodule of
|
|
|
the WRPC SW it self, and not of the SFP library. At first we can of
|
|
|
course implement the HAL as a submodule for libsfp.
|
|
|
2. .. more?
|
|
|
|