Table 2-9 in SPRUGW1A (Oct 2011)

Brandy Jabkiewicz

Hello,

I think there is a typo in this table and I am not sure which is correct.

The equalizer bits are 20-18 but it is 4 bits wide. Does it span 21 to 18 or 20 to 17?

Additionally LOS is two bits and not 3.

Please clarify. I suspect LOS is actually supposed to be 3 bits and then everything gets shifted left leaving just 3 reserved bits and not 4. I suspect this becuase the srioChiptoChip example sets the register to this value:

CSL_BootCfgSetSRIOSERDESRxConfig (0, 0x00440495);

And if I don't do it that way, the EQ bits are invalid.

Thanks,
Brandy

over 13 years ago

0 Derek Brown over 13 years ago

TI__Intellectual 1880 points

Brandy,

The EQ field should span bits 20-18 (3 bits)

The CDR field should span bits 17-15 (3 bits)

The LOS field should span bits 14-12 (3 bits)

So the bit locations are correct, but some of the field descriptions are wrong. I will notify the owner of the user guide so that this issue can be corrected.d

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Ok, if that is the case then the entire Table 2-10 is incorrect as well considering it explains the EQ field as 4 bit options.

Please confirm that this table is also wrong. In addition, what would the correct table be?

0 Derek Brown over 13 years ago in reply to Brandy Jabkiewicz

TI__Intellectual 1880 points

Brandy,

Yes, table 2-10 is also incorrect. This will also be resolved when table 2-9 is fixed. These values typically do not need to be changed, so the values provided in the example code that you are referencing should be correct. If you are facing an issue with these values, then please let me know.

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Unfortunately my problem is with the equalizer. TI has told me in various phone calls that my switch might be over powering the receiver and that I need to change the EQ value.

Please provide me with the correct tables ASAP.

0 Derek Brown over 13 years ago in reply to Brandy Jabkiewicz

TI__Intellectual 1880 points

Brandy,

Here are the correct details for the equilizer:

000b - No equalization. The equalizer provides a flat response at the maximum gain. This setting may be appropriate if jitter at the receiver occurs predominantly as a result of crosstalk rather than frequency dependent loss.
001b - Fully adaptive equalization. The zero position is determined by the selected operating rate, and the low frequency gain of the equalizer is determined algorithmically by analysing the data patterns and transition positions in the received data. This setting should be used for most applications.
010b - Precursor equalization analysis. The data patterns and transition positions in the received data are analysed to determine whether the transmit link partner is applying more or less precursor equalization than necessary.
011b - Postcursor equalization analysis. The data patterns and transition positions in the received data are analysed to determine whether the transmit link partner is applying more or less postcursor equalization than necessary.
1xxb - Reserved.

When EQ is set to 010b or 011b, the equalizer is reconfigured to provide analytical data about
the amount of pre and post cursor equalization respectively present in the received signal.
This can in turn be used to adjust the equalization settings of the transmitting link partner,
where a suitable mechanism for communicating this data back to the transmitter exists.
Status information is provided via SRIO_SERDES_STS EQOVER and EQUNDER bits for each lane, by using the following method:

1. Enable the equalizer by setting EQHLD low and EQ to 001. Allow sufficient time for the equalizer to adapt
2. Set EQHLD to 1 to lock the equalizer and reset the adaption algorithm. This also causes both EQOVER and EQUNDER to become low
3. Wait at least 48UI, and proportionately longer if the CDR activity is less than 100%, to ensure the 1 on EQHLD is sampled and acted upon;
4. Set EQ to 010 or 011, and EQHLD to 0. The equalisation characteristics of the received signal are analysed (the equalizer response will continue to be locked);
5. Wait at least 150×103UI to allow time for the analysis to occur, proportionately longer if the CDR activity is less than 100%;
6. Examine EQOVER and EQUNDER for results of analysis.

 - If EQOVER is high, it indicates the signal is over equalized;

 - If EQUNDER is high, it indicates the signal is under equalized;

7. Set EQHLD to 1;
8. Repeat items 3 - 7 if required;
9. Set EQ to 001, and EQHLD to 0 to exit analysis mode and return to normal adaptive equalization.

Note that when changing EQ from one non-zero value to another, EQHLD must already be 1. If this is not the case, there is a chance the equalizer could be reset by a transitory input state (i.e. if EQ is momentarily 000). EQHLD can be set to 0 at the same time as EQ is changed.

As the equalizer adaption algorithm is designed to equalize the post cursor, EQOVER or EQUNDER will only be set during post cursor analysis if the amount of post cursor equalization required is more or less than the adaptive equalizer can provide.

The SRIO_SERDES_STS register can be found at address 0x02620154. The 

Bit 27: Lane 3 EQOVER
Bit 26: Lane 3 EQUNDER

Bit 20: Lane 2 EQOVER
Bit 19: Lane 2 EQUNDER

Bit 13: Lane 1 EQOVER
Bit 12: Lane 1 EQUNDER

Bit 06: Lane 0 EQOVER
Bit 05: Lane 0 EQUNDER

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Thanks Derek! I will try to get to verifying this today.

0 Brandy Jabkiewicz over 13 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Derek,

Where can I find the description of the SRIO_SERDES_STS register. SPRUGW1a points to the device specfic data sheet, which I assume is SPRS691b8. Then this points to a table with all the related TI docs. I have opened and searched many of them and cannot find a description of the register.

Can you send me the link?

Thanks,

Brandy

0 Derek Brown over 13 years ago in reply to Brandy Jabkiewicz

TI__Intellectual 1880 points

Brandy,

The SRIO_SERDES_STS information is not contained in the datasheet and should be shown in the SRIO user guide. I have brought this to the attention of the SRIO user guide writer, and he is planning to make updates to add the SRIO_SERDES_STS register and fix the incorrect bit definitions in the SRIO_SERDES_CFGRX registers. I cannot provide a timeline of when these updates will be made.

To reiterate the details from my previous post, here are the details for the SRIO_SERDES_STS register:

The SRIO_SERDES_STS register can be found at address 0x02620154 (this information is located in the data manual).

Here are the bit definitions for the SRIO_SERDES_STS register (these should be in the SRIO user guide, but are currently not available).

Bit 27: Lane 3 EQOVER
Bit 26: Lane 3 EQUNDER
Bit 20: Lane 2 EQOVER
Bit 19: Lane 2 EQUNDER
Bit 13: Lane 1 EQOVER
Bit 12: Lane 1 EQUNDER
Bit 06: Lane 0 EQOVER
Bit 05: Lane 0 EQUNDER

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Thank you Derek,

Also, what is bit zero? in the sample code it is polling this register for bit0.

while (1)

{

uint32_t status;

/* Get the SRIO SERDES Status */

/* Uses CSL_FEXT which extracts the status register. It expands to a macro with a mask and shift.

* in this case it returns the whole register, no mask and no shift.

* CSL_IDEF_INLINE void CSL_BootCfgGetSRIOSERDESStatus (Uint32* srioSERDESStatus )

{

*srioSERDESStatus = CSL_FEXT (hBootCfg->STS_SRIO, BOOTCFG_STS_SRIO_STS_SRIO);

}

* Register explanation is pending TI response.

CSL_BootCfgGetSRIOSERDESStatus(&status);

if (status & 0x1)

break;

}

0 Brandy Jabkiewicz over 13 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Hi Derek,

In case you can't tell, I am trying to understand register by register the sample program srioChipToChip_Producer :)

I have a few more questions:

1. What is the purpose of these lines? i understand by the context that they are clearing the interrupt pending registers. What I don't understand is the value being passed for ICCR[0]. Why is it a decimal number 1 to 8? What good does that do - doesn't it set the register multiple times to duplication values? I mean it sets bit zero, the bit 1 then bits zero and 1 etc. And then why is setting ICCR[1] to 0xff over and over again?

/* Clear the LSU pending interrupts. */

/* CSL_IDEF_INLINE void CSL_SRIO_ClearLSUPendingInterrupt(CSL_SrioHandle hSrio, * Uint32 lsuInterrupt1, Uint32 lsuInterrupt2)

{

hSrio->LSU_ICSR_ICCR[0].RIO_LSU_ICCR = lsuInterrupt1;

hSrio->LSU_ICSR_ICCR[1].RIO_LSU_ICCR = lsuInterrupt2;

}

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 1, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 2, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 3, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 4, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 5, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 6, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 7, 0xFF);

CSL_SRIO_ClearLSUPendingInterrupt (hSrio, 8, 0xFF);

2. The specification says that the ASBLY_ID and ASBLY_INFO are not writable. Why is the program trying to write them?

/* Set the Assembly Information */

CSL_SRIO_SetAssemblyInfo(hSrio, DEVICE_ASSEMBLY_ID, DEVICE_ASSEMBLY_VENDOR_ID, DEVICE_ASSEMBLY_REVISION, DEVICE_ASSEMBLY_INFO);

3. Where are these bits defined for the processing element? They are marked resevered in the speciifcation Also, the specification also indicates this register is read only. True or false?

peFeatures.isMultiport = 0;

peFeatures.isFlowArbiterationSupported = 0;

peFeatures.isMulticastSupported = 0;

peFeatures.isExtendedRouteConfigSupported = 0;

peFeatures.isStandardRouteConfigSupported = 1;

4. there are also alot of undefined features in the source operations and the destination operations. Is there an updated table for those? What does "defined by the device implementation" mean? How do I know how they are defined?

CSL_FINS (value, SRIO_RIO_DEST_OP_G_READ, ptrDstOp->gsmRead);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_IREAD, ptrDstOp->gsmInstrnRead);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_READ_OWN, ptrDstOp->gsmReadOwn);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_DC_INVALIDATE, ptrDstOp->gsmDataCacheInvalidate);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_CASTOUT, ptrDstOp->gsmCastout);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_DC_FLUSH, ptrDstOp->gsmDataCacheFlush);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_IO_READ, ptrDstOp->gsmIORead);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_IC_INVALIDATE, ptrDstOp->gsmInstrnCacheInvalidate);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_TLB_INVALIDATE, ptrDstOp->gsmTLBInvalidate);

CSL_FINS (value, SRIO_RIO_DEST_OP_G_TLB_SYNC, ptrDstOp->gsmTLBSync);

CSL_FINS (value, SRIO_RIO_DEST_OP_DS_TM, ptrDstOp->dataStreamingTM);

CSL_FINS (value, SRIO_RIO_DEST_OP_DS, ptrDstOp->dataStreamingSupport);

CSL_FINS (value, SRIO_RIO_DEST_OP_IMPLEMENT_DEF, ptrDstOp->implnDefined);

5. What is the HOST_BASE_ID_LOCK register? What does it mean "write once/resetable"?

6. Why are there some many different IDs to be set? What is the difference between them and it looks like we keep setting them all to the same value?
BASE_ID

HOST_BASE_ID_LOCK

DEV_ID

ASBLY_ID

DEST_ID

SRC_ID

Thanks for your help!

Brandy

0 Derek Brown over 13 years ago in reply to Brandy Jabkiewicz

TI__Intellectual 1880 points

Brandy,

Below are the answers to your question that I have been able to determine so far. I am continuing to investigate your questions, and will respond to the remaining questions as soon as possible.

The first bit of the SRIO_SERDES_STS is the PLL lock bit for the SRIO SERDES PLL.

2.  The specification says that the ASBLY_ID and ASBLY_INFO are not writable.  Why is the program trying to write them?

This field is writeable while BOOT_COMPLETE bit is set in the PER_SET_CNTL register is low. This field is and is read-only when BOOT_COMPLETE=1.

5. What is the HOST_BASE_ID_LOCK register? What does it mean "write once/resetable"?

The host base device ID lock CSR contains the base device ID value for the
processing element in the system that is responsible for initializing this processing
element. The HOST_BASE_DEVICEID field is a write-once/reset-able field which
provides a lock function. Once the HOST_BASE_DEVICEID field is written, all
subsequent writes to the field are ignored, except in the case that the value written
matches the value contained in the field. In this case, the register is re-initialized to
0xFFFF. After writing the HOST_BASE_DEVICEID field a processing element must then
read the Host Base Device ID Lock CSR to verify that it owns the lock before
attempting to initialize this processing element.

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Hi Derek,

i am going to trust the example code on this one, but since we are making a list of typos - I ask you about this one too :)

In the RX Flow configuration (table 4-38) the description of the "type of descriptor" seems incorrect. The example project says it is using Host descriptors and sets bits 26 and 27 to 1. However in the Table, 1 is a reserved value. Is this correct?

Table:

Rx Descriptor Type: This field indicates the descriptor type to use:

0 = Host

1 = Reserved

2 = Monolithic

3 = Reserved

Code:

/* Configure the Receive Flow */

appCfg.u.appManagedCfg.rxFlowCfg.flowIdNum = -1;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_qnum = queueInfo.qNum;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_qmgr = queueInfo.qMgr;

appCfg.u.appManagedCfg.rxFlowCfg.rx_sop_offset = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_ps_location = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_desc_type = 0x1; /* Host Descriptor. */

appCfg.u.appManagedCfg.rxFlowCfg.rx_error_handling = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_psinfo_present = 0x1; /* PS Information */

appCfg.u.appManagedCfg.rxFlowCfg.rx_einfo_present = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_tag_lo = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_tag_hi = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_src_tag_lo = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_src_tag_hi = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_tag_lo_sel = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_dest_tag_hi_sel = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_src_tag_lo_sel = 0x0;

appCfg.u.appManagedCfg.rxFlowCfg.rx_src_tag_hi_sel = 0x0;

0 Derek Brown over 13 years ago in reply to Brandy Jabkiewicz

TI__Intellectual 1880 points

Brandy,

I assume that you are now talking about the Multicore Navigator user guide (sprugr9d) instead of the SRIO user guide (sprugw1a).

Table 4-38 in the Multicore Navigator user guide and the SRIO LLD example code are both correct. The confusion is that the field in the data structure does not directly match up with register field. What is being done in the SRIO LLD example is it is using the Cppi_RxFlowCfg data structure provided by the CPPI LLD. If you reference this data structure in the documentation for the CPPI LLD, you find that in this data structure 1=Host descriptor and 2=Monolithic descriptor, which does not match up directly with Table 4-38. What is happening is the CPPI LLD is doing some translation to get from 1=Host Descriptor and 2= Monolithic descriptor to program the RX Flow register with the values that correspond to Table 4-38.

If you are interested, the CPPI LLD documentation can be found under <PDK_INSTALL_DIRECTORY>\packages\ti\drv\cppi\docs\cppilldDocs.chm

If you then select the "data structures" tab, then click on "Cppi_RxFlowCfg", followed by clicking on "rx_desc_type" then it will take you to the description for this field.

I am not sure if you are familiar with these documents or not. If not, there is another one that exists for the SRIO LLD under <PDK_INSTALL_DIRECTORY>\packages\ti\drv\srio\docs\srioDocs.chm. This document can address some questions that you may have about the SRIO LLD.

0 Brandy Jabkiewicz over 13 years ago in reply to Derek Brown

Mastermind 6325 points

Hi Derek,

Of course, you are correct. I did mean the Navigator specification - sorry I guess it should have been a different post :) I understand what you are saying, thanks for the clarification.

I will try to look at the docs you suggested, sometimes the amount of documentation is overwhemling and I forget where to look for all my resources.

Thanks,

Brandy

Processors

Processors forum

Table 2-9 in SPRUGW1A (Oct 2011)