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.

PCIe on C6678 EVM

The "pre-release" and "production" versions of the C6678 EVM board mentionPCIe connectivity in an AMC slot.  However, there are no PCIe P2P connectivity records in the FRU data for the card.  TI has said this is because the PCIe testing with the card has not been completed.

How is the PCIe testing effort going ?  Has the testing been concluded now and is it working ?

  • The PCIe functionality of the C6678 EVM was tested using the AMC to PCIe AdapterCard and a PC environment.  At this point we haven't recreated those tests in an AMC environment but the functional testing is considered complete.

  • Now I am a bit confused.  When talking with Peter (and Tom), they led us to believe the the initial EVM board (pre-production) did not come with PCIe connectivity records in FRU data because the testing was not complete.  I assumed this was AMC testing.  Are you saying now that the card works in an AMC to PCIe adapter, it has never been tried in a uTCA chassis (for PCIe connectivity) and there is no plan to do such testing ?

    Dan

  • The initial boards didn't support using the backplane PCIe reference clock which was required for both AMC and PC environments.  Once we had boards that could accept the backplane clock the priority was testing using the AMC to PCIe adapter to prove both the functionality of the EVM and the operation in a PC.  Operation in the PC environment was the configuration that most of our customers were asking for.  Once both of these were achieved the testing in the AMC chassis was set to a lower priority and moved father back on the schedule.  There are a number of other tasks that need to be completed before we get back to that and the testing has not been scheduled at this time.

  • I see.  What are some of the other tasks that are ahead of it ? Any idea just how much "further back" it will get pushed ?

    thanks,

      Dan

  • Dan,

    What "PCIe connectivity records in FRU data" do you need?  I thought this was part of the MSP430 MMC code repair that you were doing to get it to work in your chassis.

    Tom

     

  • Hi Tom,

    When the original "pre-production" EVM was advertised to work in a uTCA chassis (and it was), we assumed that meant (among other things) that PCIe in a uTCA chassis had been tested.  But the original MMC code never had any PCIe connectivity records so we know this didn't happen.  When we talked to you in June, you said the PCIe testing was still "in progress".  We assumed this meant PCIe testing in a uTCA chassis was under testing, and when completed, you would give some example PCIe connectivity records for the EVM card in whatever chassis you had tested it in.  Then everyone would modify the records for their own chassis.  Or since you were making the EVM card work with the Advantech MCH, we assumed you would be testing PCIe as part of that work and include PCIe example connectivity records when testing was completed.

    Per Bill's post yesterday, it appears that PCIe testing as been done in a PC (with a PCIe<=>AMC adapter) and currently PCIe in a uTCA chassis is so far down on the list it's not currently scheduled.  Can you confirm this ?

    And yes, I did create PCI connectivity records for the EVM board in our particular chassis and am currently testing with them.  I was hoping that TI giving out example PCIe connectivity records would be the result of test completion of PCIe in a uTCA chassis and we would know that everything works.

    Dan

  • Hi Dan,

    Allow me to clarify a few things, as we want to be perfectly clear on setting expectations. The focus of all our EVMs is to aid in DSP Development tasks.

    The C6678 EVM is indeed AMC.0 compatible in a uTCA chassis but, as we have said, is not 100% compliant (no HotSwap, front panel, mech interlock, etc.).

    This decision was made to keep our costs as low as possible for our customers (where else can you get a uTCA card for $350?!)  and to focus on the needs of the DSP development community rather than try to meet AMC System Production requirements.

    This is also a new card with new software which is still evolving. The MCSDK 2.1 release was just posted last week which has considerable improvements over the software that was shipped with the EVM and we encourage all users to upgrade. But still we have some things to do before we can call it 'done'.

    The PCIe on the EVM has been fully verified to 5Gbaud data rates. The initial focus has been on the needs of the PC-desktop developer needs, since that is a primary user interface (Using the AMC-to-PC Adapter card). Again, this has successfully validated PCIe so we are confident in the performance and functionality of PCIe interface on the EVM. However, PCIe in a PC-desktop is not quite the same as PCIe in uTCA; there are system integration differences which involve more than just the EVM.

    Most of our uTCA/AMC customers are successfully using the GigE framework and are asking for SRIO GEN-2 interoperability as well as Hyperlink between cards so they can scale up to high performance multiple DSP configurations. This is where we are currently focused.

    PCIe in the AMC chassis (AMC.3 spec) is mostly a system integration issue involving the MCH and host card. We will get to this eventually, but likely not as quickly as you may need a solution.We do believe that the PCIe should be perfectly functional in a uTCA system. This is mostly software integration work at the system level, which, quite frankly, many of our customers are better able to accomplish than TI.

    If you need to work on PCIe system integration immediately then would like to help you where we can.

    Regards,

    Peter.

     

  • Peter,

    thanks for the detailed reply, I appreciate it.

    >Allow me to clarify a few things, as we want to be perfectly clear on setting expectations. The focus of all our EVMs is to aid in DSP Development tasks.

    Agreed, I think the expectations are the focal point.

    >The C6678 EVM is indeed AMC.0 compatible in a uTCA chassis but, as we have said, is not 100% compliant (no HotSwap, front panel, mech interlock, etc.).

    This is the sentence that I (and I'm sure others) have a problem with.  AMC.0 "compatible" leaves a lot of "wiggle room" for what the card does and doesn't do.  If the card actually came with a list of items that it did (and didn't do), it would have made things a lot clearer, especially to those of us particularly interested in AMC and uTCA.  I'm fine with the limitations listed above (hot swap, front panel etc...).  However, the primary reason for using it in a uTCA chassis is to make use of PCIe and the GbE on the uTCA backplane, and that it does not do.  At least it hasn't been tested/verified/advertised.  I've heard the point to point SRIO also works between the EVM card and another card.  If I was expecting to use the card in a uTCA chassis with SRIO switch fabric and found out that it hadn't been tested in that configuration, I wouldn't be happy.  On the other hand, if that was documented, then at least I would know what I was in store for as far as system integration issues, schedules, etc...

    >This decision was made to keep our costs as low as possible for our customers (where else can you get a uTCA card for $350?!)  and to focus on the needs of the DSP >development community rather than try to meet AMC System Production requirements.

    Again, I have no problem with the overall goals of the project in mind.  But if that was the focus, then I think the AMC/uTCA limitations should have been listed/explained/justified/detailed so that people aren't buying it thinking they are getting something they are not.

    >This is also a new card with new software which is still evolving. The MCSDK 2.1 release was just posted last week which has considerable improvements over the >software that was shipped with the EVM and we encourage all users to upgrade. But still we have some things to do before we can call it 'done'.

    Can yo point me to this link ?  I went to the web site and couldn't find it.  I think I found a 2.0.0.1 (or 2.0.1), is that the same thing ?

    >The PCIe on the EVM has been fully verified to 5Gbaud data rates. The initial focus has been on the needs of the PC-desktop developer needs, since that is a primary user >interface (Using the AMC-to-PC Adapter card). Again, this has successfully validated PCIe so we are confident in the performance and functionality of PCIe interface on the >EVM. However, PCIe in a PC-desktop is not quite the same as PCIe in uTCA; there are system integration differences which involve more than just the EVM.

    Absolutely, and I'm not doubting the functionality of the PCIe interface.  But then at least describe what the test scenario is.  When you say tested in a uTCA chassis with an MCH and host card, I would think most people would assume the PCIe interface was tested.  But that part is left out of the documentation.

    >Most of our uTCA/AMC customers are successfully using the GigE framework and are asking for SRIO GEN-2 interoperability as well as Hyperlink between cards so they >can scale up to high performance multiple DSP configurations. This is where we are currently focused.

    I see, and understand that.  Are they using it in an AMC chassis with SRIO Gen-2 fabric with an MCH or just point to point ?  I don't think the EVM card comes with any test applications burned in that exercise the GigE framework on the backplane do they ?  it might be nice to allocate another dip switch or jumper that says to do networking over the front panel RJ-45 or the backplane, just to exercise both interfaces.

    Is there an application burned into the EVM that can exercise the GigE on the uTCA backplane ?

    >PCIe in the AMC chassis (AMC.3 spec) is mostly a system integration issue involving the MCH and host card. We will get to this eventually, but likely not as quickly as you >may need a solution.We do believe that the PCIe should be perfectly functional in a uTCA system. This is mostly software integration work at the system level, which, quite >frankly, many of our customers are better able to accomplish than TI.

    This may be true, but it gives customers a higher level of confidence in trying it themselves if they knew it had already been verified in at least one uTCA configuration, that is all I am saying.

    >If you need to work on PCIe system integration immediately then would like to help you where we can.

    We are working on it and will let you know if we need any help.

     thanks,

       Dan

  • Dan,

    SRIO GEN1 and Gigabit Ethernet are fully tested on the C6678 EVM in a MicroTCA environment.  This was completed with an ELMA chassis with the SCOPES compatible backplane and an MCH from NAT.  We can provide the name of a system integrator that can deliver these integrated systems.

    Tom

     

  • Thanks Tom.  If memory serves, the SRIO Gen1 testing was only point to point between the JumGen host card and the EVM card.  I.e. it didn't even go through the NAT MCH.  Can you tell me which exact NAT MCH was used, i.e was the backplane fabric SRIO or XAUI ?  I'm sure the GbE went through the MCH but I don't recall anything else going through the MCH.  I'm not very familiar with SCOPES but the port map document I found at:

    http://scope-alliance.org/sites/default/files/documents/SCOPE-MicroTCA-Profile-v1.0.pdf doesn't even show PCIe going through an MCH, is that correct ?

    Do you know if any of the burned in images that come with the EVM support GbE through the backplane ?  The hua example seems to only use the front panel.

    Dan

  • Dan,

    Putting PCIe on ports 4 through 7 and SRIO on ports 8 through 11 is one of the recommendations of this working group.  There are multiple SCOPES documents that point to this and the one you referenced does show this in a figure.  We have not found any MCH boards available that perform both PCIe and SRIO switching.  The backplane we are using routes SRIO from ports 8-11 back to the MCH.  PCIe on port 4 of each slot routes to a host which would be contained in AMC slot 1.  This is where we had the JumpGen card.  The GIGE and SRIO testing in the MTCA chassis has been through the switches on the MCH.

    The sample binaries loaded in the EVM are focused on table-top operation.  These Out of Box demos need to function for all customers and most will not be using them n a chassis.  The sample code provided can be modified to use the backplane ports.  The new versions of the MCSDK contain additional support for the SERDES interfaces.  The MCSDK software is available through the link: http://focus.ti.com/docs/toolsw/folders/print/bioslinuxmcsdk.html.  The release notes show the new features supported in the latest release.

    Tom

     

  • Dan,

    I understand that you would like to focus on uTCA, but you are a little ahead of us!

    Most of our customers use our EVMs on the desktop so that has been the primary focus for this initial release.

    That is why we have not published any information about the AMC functionality beyond 'uTCA form factor'.

    And there is the reality that not all uTCA chassis are equal; cards don't always inter-operate, as you have found!

    We can say that in the SCOPES chassis from Elma and using the N.A.T. cards the following havebeen verified on the backplane using MCSDK release 2.1:

                         MMC registration and power up

                         GigE through MCH switch to host card and external networks.

                          SRIO GEN-1 through MCH switch between two EVMs

                          TDM backplane clocking

                          4x TSIP data path between EVM and N.A.T. TDM card.

     

    Next our our list SRIO GEN-2 and then PCIe across the backplane to a host card. Please stay tuned!

    Regards,

    Peter.