Minutes of Weekly Meeting, 2007-10-05

Attendees:

Heiko Ehrenberg
Peter Horwood
Patrick Au
Carl Walker
Adam Le
Bradford Van Treuren
Al Holliday

 

Scribes: Adam Le, Heiko Ehrenberg, Bradford Van Treuren

Heiko, Peter, Adam and Brad presented their overview slides from handouts. Carl joined half way through the meeting and Patrick requested to present at next meeting.

Action Items:

  • Can ATCA backplane support a full star routing? (Al and Brad)
  • Where can a JTAG Switch Module (JSM) be placed within the system? (Al and Brad)
  • Do we need JTAG redundancy for ATCA since it was not implemented for MicroTCA? (Al and Brad)
  • Need a better overall understanding of ATCA architecture (Al will present an overview of ATCA presentation at next week’s meeting)
  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)

Issues to be discussed and considered in order to select a suitable architecture:

  • signal integrity
  • performance
  • protocol isolation / multi-vendor interoperability
  • signal voltage levels (microTCA: 3.3V; Patrick: we may need lower voltages, I/O level flexibility)
  • real estate available for JSM implementation and signal routing
  • ...

Propose first look at these issues makes full star / programmable star architecture appear favorable (but 4 pins per board, up to 16 boards) also to be considered: Gunnar Carlson's work regarding using existing resources for JTAG communication/management (Brad gave an overview of Gunnar's work)

Notes:

  • Please review the presentations submitted for individual views. I am capturing information that was stated during the discussion below.
  • Al Holliday joined the meeting as an PIGMG ATCA representative from Alcatel- Lucent to help us answer ATCA specific questions and to guide us through problem issues.
  • Most people felt they did not have enough knowledge about ATCA to make serious comments about what ATCA should be supporting.
  • Heiko voiced that tool vendors would like to have a defined chain selection protocol used so they can build the tooling necessary without needing to support N number of protocols. He is looking for SJTAG to define the protocols in the SJTAG “standard” document.
  • Peter feels only 4 pins are needed to be supported for the TAP interface on ATCA.
  • Peter stated that the 4 primary TAP signals [TDI, TDO, TMS, TCK] should be presented at the backplane connector at the minimum.
  • Adam and Peter both felt TRST could be managed by the local board resources/design
  • Peter emphasized that the interface needs to remain simple and not be based on proprietary designs
  • Brad feels we need to support 3 views for JTAG on each board: Edge access from the backplane, local embedded JTAG controller and External Tester interface.
  • Al reminded all that the key we have to define is the infrastructure to what is needed. We must make the change once!
  • Peter suggested as we move forward with SJTAG that if/when we define an interface that an open interface needs to access other non-1149.1 interfaces.
  • There was a discussion that boards could be addressed with a star architecture and need to be able to still support existing gateway protocols for boards already designed with these devices installed. [e.g., JSM connect with an ASP using the shadow protocol following selection of the slot with the JSM protocol].
  • Adam feels that due to what transpired with MicroTCA regarding system level JTAG that a multi-drop architecture is not going to be accepted for ATCA.
  • To begin answering the questions about whether ATCA could support a full star routing, Al described that the shelf management design already has point to point signals and that the full star support is more a matter of connector size for the JSM than backplane routing.
  • Al also suggested that the JSM feature could reside co-resident with the Shelf Management Controller hardware as an example of a location.
  • Adam raised an issue regarding whether TRST issues should be raised as requirements if it is not going to be managed globally.
  • Brad shared that non-compliant devices may require asynchronous TRST.
  • Brad shared that some non-compliant devices he has worked with require TRST low for the functional mode to operate and TRST high for test mode to operate. Thus, control from the tester interface is required to provide synchronization of transition from functional mode to test mode.
  • Adam raised the issue of what if his module design doesn’t have these non-compliant constraints? Will he have to provide such means?
  • Al raised the question whether JTAG needs to be redundantly supported for ATCA.
  • Al shared that the ATCA Alarm card is not redundant in the standard.
  • Brad stated in MicroTCA, JTAG was deemed not mission-critical. Therefore, no redundancy was needed.
  • Al explained that interoperability between vendor bladed [boards] is going to be key
  • Brad described how a system needs to support a uniform protocol at the backplane so boards may be purchased from multiple vendors and conform to the same testing interface for the system to be able to work. A system that contains both ASP and BRIDGE protocol devices does not seem practical.
  • Carl stated that he is not directly using ATCA but is interested in the SJTAG direction. He feels that multi-drop is simple and eliminates the active components from the backplane. Carl later stated that his view is based on his company’s ownership of all the board designs and they have control over the protocol used. He felt that the discussion of the need for vendor interoperability and protocol isolation biases the decision to a star architecture.
  • Peter suggested that the main differentials between multi-drop and a star architecture are: 1) signal integrity and 2) performance.
  • Peter explained there is variability in signal integrity of a multi-drop design as cards are installed/removed since it is a bussed design. A star design mitigates signal integrity issues.
  • Patrick raised the issue that signal levels needs to be considered as well since many boards are being designed for 2.7 and lower voltages.
  • Brad indicated that ATCA currently uses 3.3VDC for the backplane signals.
  • Al will respond at a later meeting regarding how ATCA will deal with 1.8vdc future boards as indicated by Patrick.
  • Adam noted that multi-drop requires level compatibility across the backplane but star routing provides for flexibility (spin your own interface to the slot).
  • Peter noted that a full star architecture "Future Proofs" the design.
  • Adam was in strong agreement with Peter.
  • Brad raised the question whether we should be supporting a full star or a partial star for consideration.
  • Al pointed out that once a full star is laid out for one case on the backplane it is not that much more difficult to lay down another full star.
  • Adam stated that the cost of a full star versus a partial star (routing area/ complexity) is no big deal. He recommends we view a full star over a partial star [partial star being a design where TDI and TDO are bussed to each slot and either or both TMS and TCK are routed point to point to each slot to reduce traces on the backplane].
  • Al mentioned that there is a separate ATCA committee responsible for the routing of signals on the backplane.
  • Brad gave a high level overview of an ATCA system describing Zone1 on the backplane as the maintenance, power, and operations interface to each board; Zone2 is the fabric interface for signal routing between board slots; Zone3 is for signal routing between front side of midplane to the rear side of the midplane. There is a Board Management Controller (BMC) on each board that is responsible for interfacing with the Shelf Management Controller (ShMC) and is involved in the coordination control from the ShMC to stage its power supply enable when directed by the ShMC.
  • Al described the inventory responsibility of the BMC in the system to present the type/configuration of signals available on the Zone2 (e.g., GigE, PCIe, SRIO) and advertise its availability to the system.
  • Brad described there is already a "network switch" element in the system for Zone2 that is responsible for routing signals between boards in a Star configuration.
  • Regarding the proposal Gunnar Carlsson made at ITC 2005 when ATCA was not going to support JTAG on the backplane, Peter said the use of the IPMI interface over IPMB (I2C type interface) requires two separate test busses and 2 separate protocols that compound the problem.
  • There was a discussion of current JTAG use in ATCA systems by system builders reusing the Metalic Test Bus and Ring Test Bus signals as JTAG signals and a multi-drop architecture. Both ASP and BRIDGE type interfaces have proven to work over these signals. The reason the MTB and RTB are used in existing systems is due to the fact that the requirements are so difficult for these signals, that no one currently uses them as defined. The requirement for using these signals is that the system designer is able to manage the design of each board plugged into the system, thus, standardizing on a common protocol.
  • Brad asked, "Do we need to reach consensus on a protocol to be successful?"
  • There was a discussion regarding the current gateway selection protocols and that all of the current protocols have patents behind them. It is a matter of whether the patents are going to be litigated or not.
  • Adam did not see any technical reason why these multi-drop protocols could not interoperate, but did not know of any system that used both.
  • Heiko mentioned that he has seen systems that use the ASP as the primary with ScanBridge on the secondary side to provide the hierarchical interface but has not seen mixed gateways at the same level. Usually, system builders standardize on one protocol.
  • Brad raised the issue of interoperability with legacy systems that used the MTB and RTB with a multi-drop architecture. The most interoperable/flexible approach at the module level would be to just bring out the four wires. This would require the redefinition of MTB/RTB routing to support the future proposals. Would system implementers that already use these for multi-drop require hybridization?
  • Peter: Just bringing out the wires gives flexibility at the module level.
  • Brad: If a gateway device is on the blade/board, does that prevent access to the blade in the star topology (2 layers of blade selection)?
  • Adam: "JSM" could be configured as a logical multi-drop (one layer of blade selection)
  • Adam asked whether we felt a full star was feasible for ATCA.
  • Al and Brad needed to think about this more and discuss it with their internal ATCA staff.
  • Adam suggested we focus on the clarity of the goals and constraints for these meetings the next time we meet. He suggested we look at:
    • What are the right questions? (If we ask the right questions, the answers will be revealed themselves)
    • What should be our problem statement?
    • We need a consensus on the goals and constraints which will make the tradeoffs black and white
  • Many suggested we spend some time getting a better understanding of ATCA.
  • Al volunteered to provide an overview of ATCA at the next meeting.

Respectfully submitted,
Bradford Van Treuren

(Thanks to Adam and Heiko for additional note taking support)