This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SRIO Single Lane operation on EVM6455

Hi,

I have an EVM6455 which I've used to run the various SRIO examples.

Our hardware will only have a single SRIO lane so I thought I would try and configure the EVM DSPs to only use a single lane.

To enable 4 ports each of 1 lane I tried to set 1X_MODE=1 and SP_MODE=01 but I cannot do SRIO_REGS->SP_IP_MODE = 0x4400003F. Specifically I can't set SP_IP_MODE bit 30, I write 0x4xxxxxx but always read back 0x0xxxxxxx.

There's obviously something I don't understand.

Any help comments greatly appreciated!

Thanks,

Matt

  • I noticed that the EVM6455_SRIO_MSGQ (see http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/11544/45009.aspx#45009) example was configuring for single lane operation so I copied its srio_init() into my application. This srio_init() successfully sets SP_IP_MODE to 0x4400002A.

    Obviously my initialisation function is not identical to srio_init() but they are similar and my version is based on other examples (I didn't write it from scratch on my own!).

    I wondered if it was something to do with BOOT_COMPLETE but I tried setting WRITE_ENABLE early in my initialisation function and then WRITE_DISABLE near the end (similar to what happens in srio_init()) but this didn't help.

    Can anyone give me any clues about what else is important when trying to set 1X_MODE=1 and SP_MODE=01?

    Thanks,

    Matt

  • I think I've got it working now and it is to do with BOOT_COMPLETE.

    Now I don't really understand what I'm supposed to do with BOOT_COMPLETE!

    Some examples set BOOT_COMPLETE just after enabling all the blocks. EVM6455_SRIO_MSGQ disables boot complete in the middle of srio_init() and then enables it again a bit later.

    It's seems to me that the best place to enable BOOT_COMLETE would be at the end of srio_init() and just before the loop that waits for the port to become initialised.

    Further I don't understand the description of read-only registers in the manual. In particular I've been looking at SPn_CTL where PORT_WIDTH and INITIALIZED_PORT_WIDTH are described as read-only.

  • I now understand that the SRIO Physical Layer can sort out how many lanes to use and I don't have to specify it i.e. if the FPGA only implements a single lane then the C6455 will only setup one lane.

    Much of my initial confusion stems from CSL_srioHwSetup and CSL_srioHwSetupRaw (in the CSL SRIO functional layer) which both set PER_SET_CNTL (and therefore BOOT_COMPLETE) before anything else. I can now see that all the other examples don't do this (although they are not very consistent about the order). As far as I'm concerned this is another nail in the coffin of the CSL SRIO functional layer!

  • Matt,

     

    What version of CSL are you using? 

    You are correct that Boot_complete should be written last.  Essentially, Boot_complete tells the peripheral to start the initialization process with the link partner.  So, before setting this bit, the other important registers that control the mode of the peripheral must be written, i.e. Serdes registers, SP_IP_MODE, SP(n)_CTL, etc.  There is sequencing and a wait time for the SerDes PLL to lock, before writing some registers.  This should be handled by srio_init from the CSL.  Some register bits are R/W before setting Boot_complete, then read only afterwards.

    I'm not sure I understand your comments about "SRIO physical layer can sort out how many lanes to use....".  You must program the mode of operation, either single or multi-port mode, however, if you configure it for single port mode it will try to establish communication as a 4X port first, then if it can't it defaults back to a 1X port using either lane 0 or lane 2.  Is this what you were describing?  If you are using it in this way, it is safer to use lane 0 on the DSP since this lane must always be enabled since the internal SRIO peripheral clock is generated by lane 0 SerDes.

    Hope that helps.

    Regards,

    Travis

  • tscheck said:
    What version of CSL are you using? 

    C6455 CSL V03.00.10.02, CSL_srioHwSetup.

    tscheck said:
    This should be handled by srio_init from the CSL.

    C6455 CSL V03.00.10.02 doesn't contain srio_init. CSL_srioInit and CSL_srioOpen don't do very much.

    CSL_srioHwSetup does all the work based on CSL_SrioHwSetup but at no point does it wait for anything to initialise.

    tscheck said:
    Is this what you were describing?

    I think so but you describe it better.

    tscheck said:
    it is safer to use lane 0

    I think we've only got lane 0 connected so that's okay.

    Thanks,

    Matt

  • Matt,

    Hopefully you are up and running by now, but I wanted to let you know that I just posted a known working srio_init.c sequence on another post.  It contains the PLL lock wait, boot_complete handling, as well as the check for port_ok, and software error recovery step.  Check it out. 

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/33378/119907.aspx#119907

     

    Hope that helps,

    Travis