FPC401: can our part support laser off QSFP28 within 50ms

Hi Kelly,

What SPI speed is used to access the FPC401?  What I2C speed does the module use?

Is there any chance that you might be able to probe the SPI and I2C lines to see how much time is used for just communications?  I'd like to better understand if there is an unexpected delay somewhere in the communications or if this is just a result of the communication speed.

Also, is laser off achieved through an I2C write to the QSFP module, or is this controlled through a pin like OUT_A on the FPC401?

Thanks,
Drew

Drew.

Below is some of the answer.

SPI speed is set 800khz, We didn't set I2C speed yet, It seems default 100khz~1000khz from spec.I will double check.

We didn't add delay on SPI setting yet.

From our timestamp check on fpc sdk api "fpc401_downstream_write", It seems some time will be 100ms, some times <50ms.

Laser off is achieved through an I2C write not pin.

Any other thing need check, Let us know.

Regards!

Paul.

Hi Paul,

Thanks for the response.  Is prefetch enabled on the FPC402?  Besides this, I think it would be helpful to know exactly where the 100ms or 50ms is going when turning the laser off.  A logic analyzer could help with this.  Once we determine this, we can better understand if this delay is inherent to the communication speed and/or sdk or if it's just inherent to the device.

Thanks,
Drew

Drew.

Today we tried with prefetch_config with below parameters

prefetch_config: port 16 device 0 offset 0 with data(prefech bytes:32, period:1,gate reset:0,broadcast:1 )

But I still can get the API fpc401_in_get execute time  more than 50ms one time after tried 20 times.

Another I noticed scheduled Write API schwr_config from datasheet, Is it useful on this case? I would like to try.

Any other suggestions, Let me know

Regards!
Paul.

Hi Paul,

If possible, I think it may be worth trying to implement this as a scheduled write.  It seems like scheduled writes are given priority over other I2C operations.  I would recommend looking at the programming guide for guidance on how to implement this

Thanks,
Drew

Drew.

We checked the Datasheet, During the laseroff action, We will first check the QSFP port present with fpc401_in_get in_get then write related port through fpc401_downstream_write. 

fpc401_in_get access through pin OUT_B, Current We noticed that it will waste more time.>50ms.

Prefetch and schedule write only cover I2C access, It seems not work on the PIN.

Any other comments on this?

Regards!
Paul.

CFpc40x16p200.CI attached the basic spi_read and spi_write in our software for reference.

Hi Drew:

i am Paul team member. Following the topic mentioned above. 

we just use prefetch config and scheduled write to enhance performance. some questions for you and looking forward reply.

Q1. about prefetch config.

the FPC401 chip has four CLs. QSFP28 breakouts four 10G port  connected to FPC401 each CLs.

if we work 100G mode and want to laser off QSFP28, do we need set QSFP_TX_DIS mask with 0xF or with any mask bit 1, such as 0x8/0x4/0x2/0x1 ?

if we work 10G mode and want to laser off port1, can we do set QSFP_TX_DIS with mask 0x1 ? port2 with mask 0x2, port3 with mask 0x4, port4 with mask 0x8 ,right ?

Furthermore, if we want to laser off  port1 10G and set mask with 0xF, does this impact other 10G ports laser ?

Q2: about scheduled write.

we want to laser off four 10G ports concurrently. does broadcast need set with 1 in API schwr_config ?

if we set port1 with broadcast 1 and also set port2 with broadcast 1,does this operation permit because port1/2/3/4 is connected one FPC401?

Q3: about broadcast application.

can you give us more example help us better understand this application ?

Levin wang

Best regards!

Hi Levin,

Can you clarify what register QSFP_TX_DIS is?  I don't see this referenced in our datasheet or programming guide.  If this is part of the QSFP module, can you share a reference containing information on the registers?

Enabling broadcast in schwr_config would allow the scheduled write to occur on all ports and all FPC devices.

The broadcast functionality enables all FPC devices to be written to through the use of a single I2C address.

Thanks,

Drew

Hi Drew,

Sorry about reply later.

we just have meet prefetch issue. With your former suggestion, we have configured prefetch function on initializing stage. The prefetch config API parameters is below:

pFpcDevice->pfetch_config(*pFpcDevice, port, device, offset, bytes, period, gateRst, broadcast)

device:0,offset:0,bytes:32,period:1,gatRst:0,broadcast:0

About port parameter, we have two connect methods in our system.

the first one is 4 10Gbit QSFP+ module connect to one FPC's 4 lanes. In this connect way, the pfetch_config port parameter is fixed value(ie. 16). that is 4 ports QSFP+ with same pfetch_config port parameter 16.

the second one is 100G QSFP28 module connect to another FPC chip A. the pfetch_config port parameter is 20. Furthermore, the second 100G QSFP28 module also connect to this FPC chip A. with pfetch_config port parameter is 21.

questions:

1. prefetch config operation must after QSFP module ready. right?

2.any incorrect parameters in our pfetch_config ?

3.on period mode, do we need prefetch stop or start?

we meet QSFP28 issue:

we found 100G QSFP28 LOS signal didn't correctly send to FPC memory using prefetch config. when we clear or raise QSFP28 LOS, the LOS status didn't change in time. if we do prefetch stop/start operations, memory value seems changed, but it is not our expected state.

attach QSFP28 register LOS addr:

Hi Levin,

Thanks for the update.  I'm looking into this and can get back to you tomorrow with more details.

Thanks,
Drew

Hi Drew:

we check FPC401 datasheet and found Interrupt-Driven Prefetch mode can get modules LOS status. But it is not apply to QSFP.

additional questions:

Q4: does QSFP RX_LOS status do not have solution both on Interrupt-Driven Prefetch mode and periodic prefetch mode?

Q5: Besides QSFP RX_LOS status, do you have any other limitation both on SFP and QSFP modules?

thanks again!

Levin

Hi Levin,

Thanks for your patience on this.

Levin wang said:

1. prefetch config operation must after QSFP module ready. right?

2.any incorrect parameters in our pfetch_config ?

3.on period mode, do we need prefetch stop or start?

1) Yes, the QSFP module should be ready before attempting to interface with it.

2) Looking at the sdk, it appears that the period is in units of ms but is only adjustable in units of 5 ms.  Setting the period to 1 ms would essentially set the period to 0 ms.  Because of this, I would recommend setting the period in multiples of 5 ms to avoid any rounding confusion.  I would also recommend that the period is at least as long as the length of time it takes to read 32 bytes in your system, if not longer.

3) You can use prefetch start/stop to enable/disable prefetch.

Levin wang said:

Q4: does QSFP RX_LOS status do not have solution both on Interrupt-Driven Prefetch mode and periodic prefetch mode?

Q5: Besides QSFP RX_LOS status, do you have any other limitation both on SFP and QSFP modules?

4) I think a key difference is that SFP LOS has a dedicated pin, while QSFP LOS is observed in a register.  However, the FPC is also able to generate an interrupt based on prefetched data.  See below.

5) I'm not aware of any additional limitations between SFP and QSFP, but I'm also not aware of all of the differences between them.

Does the QSFP LOS clear upon reading, or will it be set while there is a LOS condition?  If it's set as long as there is a LOS condition, it's strange that the LOS status is not updating in time.  Can you provide some more details about your testing with this?

Levin wang said:

we found 100G QSFP28 LOS signal didn't correctly send to FPC memory using prefetch config. when we clear or raise QSFP28 LOS, the LOS status didn't change in time. if we do prefetch stop/start operations, memory value seems changed, but it is not our expected state.

Thanks,

Drew

Hi Drew:

Just as your suggestion, we adjust the period parameter with more length of time than reading bytes time on periodic prefetch mode. The RX LOS alarm received correctly now.

another question:

when QSFP module init done, we will configure periodic prefetch. Do we need prefetch start?

How to use prefetch config/start/stop three APIs? can you explain them with some cases?

thanks again.

Levin wang