C6678 SRIO PLL Configuration

Alpaslan Lorasda���� said:

Q1. Form the value of configPLL, the MPY value =00110010. But this value is seemed to be inaccurate according to SRIO UG table.3.7. 

C6670 and C6678 Serdes settings will be identical, but you need to use Table 3-4 through 3-8 to determine your settings because it will depend on desired data rate and also port configuration (In the case of MSYNC).  I'd recommend looking at the following post for details on setting VRANGE and MSYNC. 

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/255031.aspx

What datarate are you after?

Alpaslan Lorasda���� said:

Q2. By using these values, I observed that link is established and I can send messages over SRIO. When I check the ERR_STAT registers for the ports, some ports are seemed to be not PortOK (ERR_STAT=0x30305 or 0x30301). Is it possible that some of the ports does not work? Which registers gives the information about link status?

If port_ok is not asserted, you don't have a link established.  How are you verifying this?  You can not send any data without port_ok.  Are you in 4 ports 1x mode or 1 port 4x mode, or other?  If you are in a multiple port mode, then yes it is possible that some ports are port_ok, and others are not.

Alpaslan Lorasda���� said:

Q3. Can I select the port to which I send the messages? 

Yes, but when you say messages, which FTYPE are you referring, i.e. type 5, type 11, etc?  For messaging (type 11 or type 9), it is not as straight-forward as directIO packets that use the LSU.  For messaging, you must setup the RIO_TX_QUEUE_SCH_INFOx registers to determine outbound port and priority.  Everytime you open a subsequent instance of the driver, the next TX queue for SRIO is associated with that instance of the driver.

Regards,

Travis

Q1 and Q3 are OK. For Q2, 2 C6678 are connected thru SRIO in my custom board. SRIO is configured as 4 1x ports with 3.125Gbps. Communication seems to be succesful, but when I look at the ERR_STAT register, it changes between 0x02, 0x202, 0x20202 meaning PortOK, Input error countered, output error encountered. In the loopback mode, this value is always.0x2.

So does this correspond a erronous situation? Can we neglect these reports?

Thank you for your concern..

Alpaslan

Hi Alpaslan,

The input/output error encountered bits are generally not anything to worry about, since the HW has automatically recovered from some sort of transmission error.  The input/output error stopped states definitely need to be resolved before sending any packets.  Regardless of seeing the encountered bits or error stopped bits, I suggest you follow the procedure (software error recovery) discussed here to clear any error conditions and error flags BEFORE any packets are sent.  Note that you do not need to do the ackID alignment if you are resetting both link partners.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/170264/752157.aspx#752157

Regards,

Travis

Regards,

Travis

Hi tscheck, 

As a final emphasis, related with Q3,  I make some trials about using SRIO Port 0, 1,2,3. There is a "outPortID" field in bindInfo.dio structure. It is explained as "the ouput port number for the packet transmitted" in srio_drv.h. In the example, there are 3 sockets opened. I changed their outPortID number with their corresponding index values, 0,1,2. When I configured all of the ports in SrioDevice_init(), they can communicate over 3 of the sockets. But when I configure port 0 and port 1, it fails in port2. So it seems to be enough to make outPortID field to the port number which I want to use. I did not chance CSL_SRIO_SetTxQueueSchedInfo() function (as you suggest) that is used for configuring port number and priority for the transmit queue. So what is wrong in this scenario? Is it enough to use the port by setting outPortID?

Thank you,

Alpaslan

Hi Alpaslan,

The outPortID field in the socket structure is only for directIO packet types that use the LSU for transmission.  For messaging, here is the way it works. 

- CSL_SRIO_SetTxQueueSchedInfo() sets the outbound port and priority for each TX queue( #672-687). Done at initialization before any attempts to send packets.

- Each time you open a SRIO Driver Instance through the Srio_start API; the driver instance is allocated a unique SRIO Transmit queue.  You can actually specify the transmit queue when you open it.  So if you want to use all 16 Tx queues, you need to open 16 driver instances.  This can be done during SoC initialization at the beginning of the program.  Sharing of driver instances among cores is NOT allowed.  There is no issue with multiple cores opening the same driver instances and using the same TX queue. 

- When you open a socket to send a message, you specify which driver instance to bind the socket too.  You can bind multiple sockets (up to 64) to any driver instance, including combinations of both type 11 and 9.  So essentially, you always choose the TX queue you want to use when sending a message via a socket.  Sockets can be opened as needed.

Regards,

Travis