TLK10232: TLK10232

Hi Marcel,

For XAUI-to-SFI/XFI operation, you will need to configure the device for 10GBASE-KR mode and disable the features specific to backplane Ethernet like Clause 73 auto-negotiation and 10G link training.
To do this, follow this procedure:
1. Reset device (write a 1 to 0x1E.0000 bit 15 or assert RESET_N pin)
2.　Make sure the reference clock selection (156.25 MHz or 312.5 MHz) is correct – this is done through register 0x1E.001D bit 12 (default is 156.25 MHz).
3. Disable auto-negotiation by writing 1’b0 to 0x07.0000 bit 12
4. Disable link training by writing 16’h0000 to 0x01.0096
5. Write 16’h03FF to 0x1E.8020. This allows the link settings that would
normally be configured through KR training to be configured manually instead.
6. Depending on the link conditions, you may need to change the default configuration of 0x1E.0003 and 0x1E.0004. For optical connections, we typically recommend changing HS_ENTRACK (0x1E.0004 bit 15) to 1’b1 and HS_EQPRE (0x1E.0004 bits 14:12) to 3’b101.
This can be a starting point, but you may need to do some BER testing to optimize the values.
7. Issue a data path reset by writing 1’b1 to 0x1E.000E bit 3. (At this point the device should be properly configured).

AUTO-ZERO CALIBRATION:
• Process variations can lead to small differential input offsets at the front end of the TLK10xxx receiver. The device provides a calibration routine to compensate for these offsets.
• During auto-zero calibration, the differential receiver inputs are isolated from the application PCB and shorted together to produce a known zero voltage.
• This known-zero voltage is used to calibrate the compare thresholds of the input sampler.
• Once auto-zero calibration completes, the receiver inputs will work normally
– The calibration takes about 250,000 UI, and indicates completion by setting the AZDONE field to 1 in the MDIO register map.

• By default, the auto-zero calibration is performed at start-up (once the receiver is enabled and PLL is locked). However, control over when calibration is initiated is given by the HS_AZCAL parameter:
– 00: Auto-zero calibration initiated when the receiver is enabled (default)
– 01: Auto-zero calibration is disabled
– 10: Auto-zero calibration is manually forced (triggered by rising edge on bit 1 of HS_AZCAL), and will automatically update whenever receiver is enabled and PLL achieves lock
– 11: Auto-zero calibration is manually forced (triggered by rising edge on bit 1 of HS_AZCAL), and will not update automatically

• The auto-zero calibration is beneficial to the receiver performance, so in most cases it is best to leave HS_AZCAL at its default value of 00.

Best Regards,
Luis Omar Moran
High Speed Interface
SWAT Team

Hi LUIS,
Thanks for your reply. I'm checking your reply but don't understand your answer under point 5 because I cannot find register 0x1E.8020 in the datasheet. Is this a typo?

Regards,

Marcel

Hi Luis,

We have implemented above register settings (especially  writing16’h03FF to 0x1E.8020) in the TLK10232 but our problem is not yet solved. We have performed a number of tests with the following test setup:

1) We have connected our node (DUT) with 10G optical SFP module (AFBR-708SMZ)  to a CISCO 500XG-8F8T switch.

2) We have used the register settings as shown below including writing16’h03FF to 0x1E.8020

void Tlk10232Init(TMdioHandle mdio)

{

    if (!tlkMutex) {

        tlkMutex = xSemaphoreCreateMutex();

    }

 

    // disable auto negotiation

    Tlk10232Write(mdio, 0x07, AN_CONTROL, 0xA000);

    Tlk10232Write(mdio, 0x07, AN_CONTROL, 0x2000);

 

    // disable link training

    Tlk10232Write(mdio, 0x01, LT_TRAIN_CONTROL, 0x0000);

 

    // Disable AGC control

    Tlk10232Write(mdio, 0x1E, HS_SERDES_CONTROL_2, 0x78C8);

 

    // Change RX; disable ENTRACK and move equalizer (Enabling ENTRACK makes things worse)

    Tlk10232Write(mdio, 0x1E, HS_SERDES_CONTROL_3, 0x5500);

 

    // Reset

    Tlk10232Write(mdio, 0x1E, RESET_CONTROL, 0x000E);

}

4) We have connected also a PC to the 1G ethernet port of the ethernet switch where also our DUT is connected to. The PC send thernet messages via the switch to our node. When our node receives the PC message than our node resets and that means that the complete power of our node is switched off. After 10 seconds the node is automatically switched on and the sequence is repeated.

Performed tests:

With above setup the test is started. During the test a lot of times we observe that the node is correctly reset and that the 10G ethernet link between switch and our node is operational. After 30 minutes (the time is not fix), our node is not longer reset and the link between node and ethernet switch hangs. During hang-up we see that the port LEDs (link and 10G) on the switch are both off. Via the serial interface of our node we have made a dump of all TLK status registers (see attachment) for a correct working node and a node in hang-up. We also have checked the SFP status registers but no errors are found. When we remove, after a hangup, only the fiber optic cable between node and ethernet switch and after 30seconds we reapply the optic cable (while our node is still powered-on even as the ethernet switch) then the link is restored and ethernet messages can be transferred between ethernet switch and our node. We also see that the LEDs on the switch side goes on as expected. After different power cycles (e.g. after 25 min) the link hangs again. 

Another test with the same setup shows that when a hangs-up occurs and we only remove the optical cable from the transmit site of our node that the ethernet link is also restored.

From the test we have performed it seems that the ethernet switch doesn't now that there is something wrong on it's ethernet link. Only after removal of the optical cable the switch knows that the link is broken and that the switch decides to reset its link. Probably our node sends garbage.

In the attachment you can find the status log information of the TLK10232 during a hangup state, after unplugging the fibre and after reapply of the fiber. We have the following questions:

1) Can you check the status registers of the TLK and do you see something that's wrong?

2) Are there other status register that I have to check to tackle this problem?

3) In our node we have connected the TLK to a FPGA and inside the FPGA we use a commercial available XAUI IP core from Altera. Can we do something wrong on the XAUI interface (e.g there is a long gap between messages on the XAUI interface) that could result in a hangup of the HS side of the TLK?

4) Is there special equipment or support from TI avaible to tackle this problem?

5) Do you have hints how we solve above problem?

Regards,

10G_problems.docxMarcel

Hi Marcel,

First of all, when you power up the device please perform a Global Reset:

1. Reset device (write a 1 to 0x1E.0000 bit 15 or assert RESET_N pin at least 10us)

2.　Make sure the reference clock selection (156.25 MHz or 312.5 MHz) is correct – this is done through register 0x1E.001D bit 12 (default is 156.25 MHz).

3. Disable Auto-Negotiation - OK according your current procedure.

4. Disable Link Training - OK according your current procedure.

5/6. Write 16’h03FF to 0x1E.8020. This allows the link settings that would  normally be configured through KR training to be configured manually instead.

This point is very important, since, the user must configure the device manually (HS_SERDES_CONTROL_2 & HS_SERDES_CONTROL_3). You would need to try different combinations for these registers since every system is different (AC losses, length of traces/cables, etc.) In backplanes applications this process is done by the Link Training feature, unfortunately this feature is for Clase 73 not applicable to interface with SFP+ modules.

HS_SERDES_CONTROL_2: please try different values for HS_SWING.

HS_SERDES_CONTROL_3: please try different values for ENTRACK, EQPRE, CDRFMULT, CDRTHR, PEAK_DISABL, H1CDRMODE & TWCRF

Attached you will find a brief app note with some recommended values for some of these parameters.

7. Issue a data path reset by writing 1’b1 to 0x1E.000E bit 3. When a new configuration is desired the user must perform a data path reset to configure the device properly. (At this point the device should be properly configured).

I know that this procedure to sweep several parameters (equalization of device) is exhaustive but is the only way to get the best combination of parameters for every system to avoid errors in transmission data. By the way, please verify the device is in 10GBASE-KR mode.

I hope this helps.

5557.TLK10034_link_training_app_note (10).doc

Best Regards,

Luis Omar Moran

High Speed Interface

SWAT Team

Hi Luis,

Thanks for your respsonse. I can confirm that point 1 to 5 and 7 are correct implemented. You can also verify this by the register settings I sent earlier to you. I hope that you can confirm this. The only thing I can do is to change HS_SERDES_CONTROL_2 and HS_SERDES_CONTROL_3 but I'm not sure that the settings in HS_SERDES_CONTROL will solve my problems. How can I verify that another setting in HS_SERDES_CONTROL will solve my problem because with the current used settings the node operates correctly for a number of power cycles? I also don't understand why a wrong setting in HS_SERDES_CONTROL results in a lot of correct power cycles while I expect that when the settings are not correct that a link never comes up. A lot of tests also have shown that once a node is powered up and can transfer ethernet messages that this link stays in tact for days and probably for weeks. So why do I see the ethernet link hang-up relative fast during power cycling and not once we do not power cycling? Can you also answer my 5 other questions as described in my previous mail.

Regards,

Marcel

Hi Luis,
Have you received my email yesterday?
Regards,

Marcel

Hi Marcel,

I've received your e-mail. Could you clarify these points?

1. Why are you disabling AGC control?
2. Could you try the AGC control by default?
3. What is your current configuration for ST and MODE_SEL pins, Register 0x1E.0001 bit [10]? As you know you need to force the device in 10GBASE-KR mode.
In my experience when the device is interfacing with optical modules, the user needs to follow the procedure that I mentioned before and be careful to adjust the HS_SERDES_CONTROL_2 & HS_SERDES_CONTROL_3 to optimize the link conditions. As well, I suggest to perform a quick loopback in the TLK10232 to discard another issues.

Thanks,
Luis

Hi Luis,

Thanks for your mail.

1) We had disabled the AGC because we have seen problems in the past

2) Today we have set the AGC control to default and performed a test but we have still hangups.

3) In the hardware we have set ST via 1kOhm to GND (so ST=0) and we have also set  MODE_SEL via 1kOhm to GND (so also MODE_SEL=0). We haven't program register 0x1E.0001 bit [10] so it has the default value 0x0B00 (bit 10=0)

With above settings including the other register settings you adviced in the previous mails, we have performed a test but we still have hangups after power cycling and HS errors. Once our node is applied to the ethernet switch and it operates correct after power up then the links stays operational for at least 3 days (we have not longer tested).

We also have seen that once a node link is in hangup mode and we put the TLK10232 in loopback mode (bit 3 in LOOPBACK_TP_CONTROL is set to 1) to this doesn't solve the problem (the node stays in hangup).

w.r.t. the HS_SERDES_CONTROL_2 and HS_SERDES_CONTROL_3 settings I can tell you that we have connected two nodes together while a BER test is done and varied the register parameters until the BER is the lowest.(as described according 10GBASE-KR Link Optimization with TLK10034 and TLK10232).

Can you advice us what to do now and please can you also answer the questions below:

1) Can you check the status registers of the TLK and do you see something that's wrong?

2) Are there other status register that I have to check to tackle this problem?

3) In our node we have connected the TLK to a FPGA and inside the FPGA we use a commercial available XAUI IP core from Altera. Can we do something wrong on the XAUI interface (e.g there is a long gap between messages on the XAUI interface) that could result in a hangup of the HS side of the TLK?

4) Is there special equipment or support from TI available (engineers on our site) to tackle this problem?

5) Do you have hints how we solve/isolate above problem?

6) Why do I see the ethernet link hang-ups relative fast during power cycling and not once we do not power cycling? 

7) Must the register for the TLK10232 be set in a special sequence?

Regards,

Marcel

Hi Marcel,

1. I've checked the status registers of your current configuration, basically you got decode/encode errors, loss of signal, errors in low and high speed sides.

2. Could you try changing LS_SERDES_CONTROL_2 & LS_SERDES_CONTROL_2 to adjust the low speed side (XAUI)? I suggest try different values for LS_SWING, LS_DE and LS_EQ.

3. As I mentioned before, I suggest adjust the RX settings for the low speed side (XAUI) since it seems the LS side is not receiving the data properly.

4. Do you have the TLK10232EVM or are you using your own board for the TLK10232? If you do not have the TLK10232EVM (Evaluation Module) you could request it at www.ti.com . Even, the GUI of this evaluation module is very useful since has several options to optimize the settings in a matrix to reduce the BER (High Speed Link Optimizer).

5. Please try another value for LS_SERDES_CONTROL_2 & LS_SERDES_CONTROL_3. As well, try force alignment in low speed, write 1b'1 to 0x1E.000C bit [2].

6. This is very strange, if the settings are not ok you would not have a link between the device and the system, please try my recommendations and let me know your results.

7. In this case I suggest use the same procedure, only add the low speed side equalization between 6 and 7 steps:

1. Reset device (write a 1 to 0x1E.0000 bit 15 or assert RESET_N pin)
2.　Make sure the reference clock selection (156.25 MHz or 312.5 MHz) is correct – this is done through register 0x1E.001D bit 12 (default is 156.25 MHz).
3. Disable auto-negotiation by writing 1’b0 to 0x07.0000 bit 12
4. Disable link training by writing 16’h0000 to 0x01.0096
5. Write 16’h03FF to 0x1E.8020. This allows the link settings that would
normally be configured through KR training to be configured manually instead.
6. Depending on the link conditions, you may need to change the default configuration of 0x1E.0003 and 0x1E.0004. For optical connections, we typically recommend changing HS_ENTRACK (0x1E.0004 bit 15) to 1’b1 and HS_EQPRE (0x1E.0004 bits 14:12) to 3’b101.
This can be a starting point, but you may need to do some BER testing to optimize the values.

***Try different values for low speed side as I mentioned before (LS_SERDES_CONTROL and force alignment)***
7. Issue a data path reset by writing 1’b1 to 0x1E.000E bit 3. (At this point the device should be properly configured).

I hope this helps, If not I would need help from the design team to solve this issue.

Thanks,

Luis

Hi Luis,

Today I had no time to try your register settings but my colleague has set HS_SERDES_CONTROL_3 bit 6 to '1' resulting from coincidence and it seems that the number of high speeds errors is reduced. Can you confirm that this could be a solution for the high speed errors we have and can you explain we what this bit is doing?

Regards,

Marcel

Hi Marcel,

It's not a coincidence. Even for optical links we suggest focus first on HS_ENTRAK, HS_EQPRE, HS_PEAK_DISABLE & HS_H1CDRMODE. Basically the HS_PEAK_DISABLE control allows the user to make adjustments to the AC response of the receiver's analog input stage. When this bit is set to '0' (default), the transfer function gives a small amount of equalization and allows for the 3-dB bandwidth roll-off to occur at higher frequency. When is set to '1', the input stage will have a flat AC response with a lower bandwidth.
In general, it is good to disable peaking for serial input rates below ~6Gbps and leave it enabled it for higher rates. However, in some cases it may be useful to disable peaking even at higher rates:
This will introduce a bandwidth reduction similar to the HS_ENTRACK control. For a low-loss channel, this may help the CDR determine the lock point.
This can also be used if interfacing to transmitters with a fixed de-emphasis level (i.e. some optical modules) if the de-emphasis value is too large for the channel loss.

Best Regards,
Luis

Hi Luis,

We have tested different nodes for about 3 hours where the HS_PEAK_DISABLE is set to 1 and see that the HS errors are nearly disappeared. When we set the HS_PEAK_DISABLE to 0 then we show a lot of HS errors (several hundreds within a minute). The same test (with HS_PEAK_DISABLE is set to 1) on another ethernet switch (Dell) also show no HS erros. But when we repeat the same test on a third ethernet switch (Radisys) then the HS errors are back again. There seems be dependency between the HS errors and which ethernet switch but I don't understand why. We haven't change the nodes (still the same SFP modules in the nodes are used). Do you have any idea what happens here?

Remark: changing the HS_PEAK_DISABLE setting results still in a link hangup, so this problem is not yet solved.

Regards,

Marcel

SFP module reconstructie

Een 5G SFP module is opengemaakt en daarbij zijn de volgende onderdelen gezien:

1) Controller Silabs type C8051F413

2) Laser transmitter TI ONET8501V

Block diagram ONET transmitter

EQUALIZER

The data signal can be applied to an input equalizer by means of the input signal pins DIN+/DIN–, which provide on-chip differential 100Ω line-termination. The equalizer is enabled by setting the EQENA = 1 (bit 1 of register 0). Equalization of up to 300mm (12”) of microstrip or stripline transmission line on FR4 printed circuit boards can be achieved. The amount of equalization is digitally controlled by the two-wire interface and control logic block and depends on the register settings EQADJ[0..7] (register 3). The equalizer can also be turned off and bypassed by setting EQENA = 0. For details about the equalizer settings, see Table 16.

LIMITER

By limiting the output signal of the equalizer to a fixed value, the limiter removes any overshoot after the input equalization and provides the input signal for the output signal waveform shaping.

OUTPUT SIGNAL WAVEFORM SHAPING

The output signal waveform shaping provides two paths for the data signal. The delay buffer ensures that both paths have the same transit time. The over- and undershoot peaking width and height are controlled through the two wire interface and the peak driver linearly amplifies the signal. The resultant waveform shaped signal is then added to the output of the main driver. The overshoot width is controlled by register 5 settings OSW[0..3] and the overshoot height is controlled by register 6 settings OSH[0..3]. The undershoot width is controlled by register 7 settings USW[0..3] and the undershoot height is controlled by register 8 settings OSH[0..3]. The peaking current is disabled by setting both over- and undershoot height registers to zero. The peaking current is also disabled when the DIS pin is set to a high level or during a fault condition if the fault detection enable register flag FLTEN is set (bit 3 of register 0).

HIGH SPEED OUTPUT DRIVER

The modulation current is sunk from the common emitter node of the output driver differential pair by means of a modulation current generator, which is digitally controlled by the 2-wire serial interface. The collector nodes of the output stages are connected to the output pins MOD+/ MOD–, which include on-chip 2 × 50Ω back-termination to VCC. The 50Ω back-termination together with an optional off chip series resistor helps to sufficiently suppress signal distortion caused by double reflections for VCSEL diodes with impedances from 50Ω through 110Ω. The polarity of the output can be selected with the output polarity switch POL (bit 4 of register 9).

MODULATION CURRENT GENERATOR

The modulation current generator provides the current for the current modulator described above. The circuit is digitally controlled by the 2-wire interface block. An 8-bit wide control bus, MODC[0..7] (register 1), is used to set the desired modulation current. Furthermore, four modulation current ranges can be selected by means of MODRNG1 (bit 1 of register 13) and MODRNG0 (bit 0 of register 13). The modulation current can be disabled by setting the DIS input pin to a high level. The modulation current is also disabled in a fault condition if the fault detection enable register flag FLTEN is set (bit 3 of register 0).

De ONET heeft een I2C bus om diverse registers in te kunnen stellen en uit te lezen. De I2C bus is verbonden aan de Silabs controller en niet beschikbaar aan de buitenzijde van de SFP module.

Figure 6 laat een SFP MSA compliant input stage zien van een laser driver zoals deze in een SFP module zit. The function of the data path is to buffer the input data and then modulate the laser diode current according to the input data stream.  The operating temperature range for telecommunications covers -40°C to +85°C. Over this range, the required threshold current for laser diodes will vary significantly. It is not uncommon for the laser's threshold level to move by more than 40mA between -40°C and +85°C (Figure 2). 


Figure 2. Laser diode threshold vs. temperature. 

Typical long-wavelength, Fabry-Perot-style laser diodes require forward bias voltages on the order of 1.2V. This forward bias requirement is a function of the energy gap associated with the laser diode and can be greater than 1.6V. The forward voltage drop, together with a +3.3V ±5% supply, means as little as 1.5V could be all that remains for the laser driver output stage.The laser driver must provide both a bias current (IBIAS) to set the laser diode above threshold and a modulation current (IMOD) to transmit the data. If pulses are to be transmitted, the turn on delay should be short compared to the pulse duration, requiring a bias current Ioff (which yields the optical output power Poff) larger than the threshold current for fast modulation.  Bias current requirements as high as 60mA are typical and, depending on the distance requirements, modulation currents could exceed 60mA. At the same time, the output signal must be fast enough to meet the stringent jitter generation requirements as well as the transmission eye diagram of SDH/SONET.

Figure 3 shows a laser diode and the inductance associated with the package. In this configuration, a total current of IBIAS + IMOD must flow through both the laser diode and the inductance. 


Figure 3. DC-coupled laser. 

The total voltage drop at the output of the laser driver is 1.6V + LΔi/Δt. For 622Mbps applications, optical edge speeds of less than 600ps (electrical) are typical, resulting in an additional voltage transient across the inductor as high as: 



This results in an output voltage requirement for the laser driver of +3.1V - 1.6V - 0.5V = 1.0V. 

The traditional bias current output stage is a simple current source capable of operating within such a tight operating voltage. On the other hand, the modulation current output stage is typically a switching differential pair, requiring more than two VBE (base emitter voltage) of headroom and making it impossible to operate with such low output voltage requirements.

Hi Luis,

We have tested different nodes for about 3 hours where the HS_PEAK_DISABLE is set to 1 and see that the HS errors are nearly disappeared. When we set the HS_PEAK_DISABLE to 0 then we show a lot of HS errors (several hundreds within a minute). The same test (with HS_PEAK_DISABLE is set to 1) on another ethernet switch (Dell) also show no HS erros. But when we repeat the same test on a third ethernet switch (Radisys) then the HS errors are back again. There seems be dependency between the HS errors and which ethernet switch but I don't understand why. We haven't change the nodes (still the same SFP modules in the nodes are used). Do you have any idea what happens here?

Remark: changing the HS_PEAK_DISABLE setting results still in a link hangup, so this problem is not yet solved.

Regards,

Marcel

Hello Marcel,

Please let me verify this behavior with the team, ASAP I will be back with a solution. I'd like to verify if there was a similar issue in the past.

Thanks,

Luis

Hi Marcel,

Sorry for my delayed response. I had a talk with the team to find out a similar scenario in the past. Basically, the nature of the Copperfield/HS SERDES in the TLK10232 is to require tuning specific to the entire link, including the remote node and the medium (optical switch AND optical cable or direct attach cable, or across copper backplane). So yes I can believe that the settings could be different for the Radisys switch (unfortunately). We had a potential customer try to use our devices in a router but they could not find a common setting across all switches, optical modules and FO cables. Radisys switch must be tuned separately. Of course this may not be a viable solution for the customer, but that's just the way it is.

Thanks,

Luis

Hi Luis,

Thanks for your mail and sorry for my late response but I was busy with other things. We have performed different tests with HS_PEAK_DISABLE set to 1 where we change bit 14:12 of HS_SERDES_CONTROL_3 to different values and we have verified the HS errors with each setting. We have done this with different nodes (10 pieces) and ethernet switches (4 types) to find out if there is a good common setting for all cases. In the attachment you can find the results. The conclusion of the test is that we have found a common setting (we use HS_SERDES_CONTROL_3 = 1560hex) for all ethernet switches and nodes where the number of HS errors is 0. With this setting we have repeated the test for in totally 15 nodes during a test duration of 3 days and now we see a lot of nodes with HS error count 0 and some with a maximum HS error count van 10. This is much better we had in the past and it seems that the problems w.r.t HS errors is solved.

Although we are happy with the results we also don't understand some points we have seen during the tests. These points are:

1) In the attachment you see that for HS_SERDES_CONTROL_3 values 0x0560 to 0x3560 the HS error count is 0 for all ethernet switched and nodes and that for higher HS_SERDES_CONTROL_3 register settings the number of error increases. But you can also see that when the HS_SERDES_CONTROL_3 resister settings are further increased that the HS error counts suddenly decreases to 0, then increases, decreases, etc. My expectation is that there can be an area where the HS error count is low while ouside this area the error count is higher but now I see more non adjacent areas where the error count is 0. Can you explain why this happens?

2) We also have seen that the number of HS errors decreases when a longer fiber optic cable (up to 206m) is used. Please can you explain us why a longer cable has impact on the HS_error count?

2) W.r.t. point 1 I want to know how I can determine the correct setting for HS_SERDES_CONTROL_3. Is e.g. HS_SERDES_CONTROL_3 = 1560hex the correct value?

3) In the test results I see that there are more areas where the error count is 0 but what is the correct register setting for HS_SERDES_CONTROL_3 (we use 0x1560 but we can also use 0x2560)?

4) We also don't understand why another ethernet switch has impact on the settings of HS_SERDES_CONTROL_3. Please can you clarify this?

5) We still have problems with the ethernet hangup situation when we power cycle our node. Is it possible that we do some wrong thatcould cause wrong messages on the HS (10G) side of the ethernet switch and how can I analyse this?

Regards,

Marcel

HS_error_test.xlsx

Hi Luis,

W.r.t. my previous mail we have found a interesting remark from Cisco about auto-negation for the ethernet switch we use and where we have found a 10G hangup situation during power cycling of our node.

The remark from Cisco is:

"On fiber-only ports, negotiation is always enabled; however, the show command displays negotiation as disabled. If the link partner’s negotiation is disabled, the link might not come up (see link http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf_sg250/release_notes/R_2_1_0_RN.pdf see debug ID nr CSCuu65593)"

Above remarks suggests that auto-negotiation on our side must be enabled. Either I thought that auto-negotiation for 10G-SR links was not necessary. Is this true and please can you tell us if and how we can enable the auto negotiation option in the TLK10232?

Regards,

Marcel

Hi Marcel,

Generally for SFI/XFI, AN and LT are disabled. To interface with optical modules Link Training MUST be disabled since this feature is not reliable. The Auto-Negotiation can be enabled writing 0x2000 to 0x07.0000 since is enabled by default.

Best Regards,

Luis

 

Hi Luis,
Can you confirm that the TLK supports auto negotiation for 10G-SR links? I ask this because I thought that the TLK doesn't support AN for 10G-SR links

Regards,

Hi Marcel,

The TLK device supports Auto-Negotiation for 10G-SR links. Basically, if the partner enables this feature our device should be enable it too.

Best Regards,

Luis

Hi Luis,

Thanks for your answer. Please can you also answer my questions on March 21?

Regards,

Marcel