Minutes of Weekly Meeting, 2008-03-10

Meeting was called to order at 8:21am Eastern DST

1. Roll Call (Participants):

Brad Van Treuren
Peter Horwood
Ian McIntosh
Carl Nielsen
Carl Walker
Heiko Ehrenberg
Adam Ley (joined at 8:26am EDT)

Participants via proxy
[All messages from participants providing Proxy feedback are denoted by (P) after their name]
Yingwu Li
Timothy Pender

2. Review and approve 3/3/2008 minutes

minutes were approved (moved by Ian, second by Heiko)

3. Review old action items:

  • 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)
  • Register on new SJTAG web site (http://www.sjtag.org) (All)
  • All need to check and add any missing Doc's to the site (All)
  • Respond to Brad and Ian with suggestions for static web site structure (Brad suggests we model the site after an existing IEEE web site to ease migration of tooling later) (All)
  • Look at proposed scope and purpose from ITC 2006 presentation (attached slides) and propose scope and purpose for ATCA activity group (All)
  • Look at use cases and capture alternatives used to perform similar functions to better capture value add for SJTAG (All)
  • Volunteers needed for Use Case Forum ownership (All)
  • Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
  • Continue Structural Test use case discussion on SJTAG Forum page (All)
  • We will need to begin writing a white paper for the System JTAG use cases to provide to the ATCA working group (All)
  • Most likely, champions will own their subject section and draft the section with help from others. This paper will be based on the paper Gunnar Carlsson started in 2005.
  • All: review how to use the forum
  • Locate ATCA glossary of board and system states (Adam, Brad)
  • Ian and Brad work on setting up a Glossary Page on the SJTAG site. (Done - http://www.sjtag.org/glossary.html)
  • Continue POST use case discussion on SJTAG Forum page (All)
  • Brad submit an abstract regarding SJTAG Use Cases for ITC. (Done)
  • Adam review ATCA standard document for FRU's states
  • Brad to review Service Availability Forum

4. Discussion Topics

  1. SJTAG Value Proposition - Programming and Updates
    • [Brad] Today I want to change the order of discussion to:
      • How updates are performed in a system (all types)
      • What strategies are used to perform updates and programming
      • What tooling is required to support these strategies
      • What are the architectures used to perform updates and programming
    • [Brad] But first I think we need to identify what things need to be updated in a system
    • [Brad] To start with, FPGAs and CPLDs need to be programmed within a system
    • [Ian] I think there are to categories for change in a system in which FPGAs and CPLDs fall into one of these categories. These categories are:
      • Predictable areas to change (Managers often erroneously call this software)
        • Application level programming
          [Timothy(P)] Is this the Application and boot code in memory?
        • Mission data
          [Timothy(P)] Isn't this FLASH too?
      • Non-predictable areas to change (Managers often erroneously label this firmware)
        • PLDs
          [Timothy(P)] + FPGA configuration proms
        • FLASH
          [Timothy(P)] FPGA configuration via uP/Flash (is this what is meant by Flash here)?
    • [Ian] predictable (application software; in our case typically programmed via mission bus) vs. non-predictable / upgrade / lower level activities (e.g. PLD, more likely to use JTAG) This gets us back to the notion of repair vs. update in how you support each action
    • [Heiko] - serial and parallel FLASH, including embedded memory of DSP's, microprocessors, etc.
    • [Timothy(P)] Often serial FLASH are I2C based
    • [Brad] - configuration parameters (e.g. temperature ranges, thresholds, etc.)
    • [Ian] - any programmable operational parameters, incl. programmable resistors, for example.
    • [Adam] - any kind of non-volatile storage
    • [Ian] Most are set and forget but you may need to adjust operational parameters you may not have expected
    • [Brad] I think it would be good for me to take as an action item to create a list of items needing to be upgraded on the forum for this topic that others may add to as they identify more
    • [Brad] How about FLASH memory. It is important because of the time that it takes.
    • [Ian] - FLASH is an important issue to many people because it is such a time consuming task using JTAG; alternatives include FPGA or CPLD access for parallel programming or do programming through emulation interface
    • [Brad] - program only boot loader, then use microprocessor to program the rest with parallel access
    • [Brad] Others rely only on preprogrammed FLASH prior to assembly of the board
    • [Ian] - some people create a special JTAG implementation in FPGA's to include only the FLASH pins (and any other pins needed) in a BScan register in order to shorten the scan chain and hence to reduce the programming time
    • [Peter] Our JTS15 service is an example of this
    • [Brad] - what goes into the FLASH (and how it is organized) may help determine the tools needed
    • [Ian] We should be able to define what sectors are to be programmed. Should have a trick of knowing what pages may be skipped if the device is erased first and so already contains all ff's for these sectors
    • [Adam] - most of the discussion seems to refer to NOR FLASH; NAND FLASH poses some other challenges; There are special features available with NAND FLASH. NAND may be used in a system as sort of a non-volatile RAM
    • [Brad] - Data to be loaded: system data, system software, FPGA Images, maybe configuration information (system parameters, network parameters), "boot code" for processors, diagnostic results for system self test
    • [Carl W.] - log files of some sort
    • [Adam] - POST source code will likely reside in a FLASH. This includes microprocessor code and bit streams
    • [Brad] - any other types of data? [pause] if not, why don't we move into the topic of tooling requirements then ...
    • [Brad] - obviously, we need an Erase of the FLASH, whole device vs. sector/block erase
    • [Carl N. (P)] in considering the Erase options, a blank check verification could also be included.
    • [Adam] - some devices even don't have a Chip Erase, but only a sector by sector erase
    • [Ian] It is desirable for the tool to emulate a full device erase operation using multiple sector erase operations at the GUI
    • [Adam] - Block locking/unlocking needs to be considered as well
    • [Brad] - there needs to be some sort of verification of what has been programmed; also there may be a need to read the contents back out;
    • [Adam] - readback is a precursor to verification: if you can't read it back, you can't verify it;
    • [Brad] - what does the tooling need to provide to support readback
    • [Heiko] It would be nice to protect the data so that not everyone can read it
    • [Ian] That would have to be a function of the device and not the tooling
    • [Peter] It is impossible to protect parallel FLASH
    • [Adam] At the primary interface of the FLASH there has to be some way to read the data back so it is obscured
    • [Ian] Sure you can encrypt the data and it is up to the designers to design a way to decrypt the data on the board
    • [Adam] We were talking about readback as a precursor to the verification process
    • [Brad] Readback needs to provide a fine granularity to the data required
    • [Ian] We should be able to read back at least what we write (e.g., board id, Serial numbers).
    • [Ian] We might need to have some sort of interrogation of the FLASH or an iteration on the data
    • [Ian] - address range needs to be specifiable, maybe even specific addresses or a handful of bytes
    • [Brad] - when you want to read back log files, those may not have a predetermined size
    • [Ian] Usually you read back a whole sector
    • [Adam] In these cases you do not just want to read back the raw data but it will need post processing to present to user
    • [Ian] Yes: Is this going too far?
    • [Adam] Can be done
    • [Ian] may not be possible to generate something acceptable for general use
    • [Brad] May be possible to do this, but concerns over reading a whole sector as
    • [Ian] - you could read a specific number of blocks; or there may be file size information / pointer that allows you to first read the memory range to be read back;
    • [Ian] It will probably require a two step process
      • Read format to obtain header information to obtain the data size
      • Read the amount of data
    • [Ian] Needing to define a range to read that is not based on the device characteristics is important.
    • [Heiko] Where do you store the results of your read operation?
    • [Brad] Is it to a screen, a file, a callback, other?
    • [Heiko] - another question is whether the data read back needs to be stored in a file and some other application needs to use that data
    • [Brad] - call-back to another software that uses the read data is another alternative to support this; it may also be beneficial to display read data on the screen
    • [Brad] - what kind of things are needed for tooling for remote embedded/interactive programming? some special requirements may apply
    • [Peter] Are you going to come up with an embedded system that may cost too much money? Raw physical component count? We seem to be trying to define the look and feel
    • [Peter(P)] Maybe that we should consider a mandatory feature set plus optional features similar to IEEE1149.1. This would enable PCB designers to support SJTAG in a manner that works for their cards.
    • [Peter] - would an embedded system really have the performance and capability to do the kind of programming tasks discussed above?
    • [Brad] - a subset should certainly be applicable (e.g. taking an SVF or STAPL file and running it to configure/program on the fly)
    • [Heiko] - in an embedded environment, you'll still need to be able to erase at a sector level, program parts of the FLASH, maybe even do some readback
    • ... Ian had to leave the call ...
    • [Source Unknown] Basic functions are we need to apply these at a vector level and may not have to provide a raw read back
    • [Heiko(P)] It may not be enough to look at the plain data coming back from the chain, you may need to sort out which part of the scan vector is the actual data coming from the FLASH (requiring some cell mapping, something the embedded tools may or may not be able to do)
    • [Brad] We need to leverage the test interface already available in the embedded boundary scan implementations
    • [Brad] - could be executed as a routine similar to a test, previously developed on an external tool
    • [Heiko] - if the data is predetermined, you should be able to do that
    • [Brad] We could also capture the response data vectors and post process them to obtain raw data if we have to
    • [Brad] - so an external tool should be able to generate programming sequences for embedded execution, e.g. in SVF of STAPL format?
    • [Heiko] - SVF would not be good, for example file size reasons
    • [Adam] - SVF is problematic, does not provide any flow control; even STAPL may not be a good option because of file size
    • [Brad] - this takes us to a discussion about strategy ...
    • [Adam] - one key consideration is where is the programming data coming from, especially in an embedded programming application
    • [Adam] Strategy of where the data originates and how it is transferred to the embedded facility is still up in the air. Also, how the data gets into the system as part of our strategy?
    • [Brad] we'll need to continue this discussion next week ...
    • [Yingwu(P)] About FLASH programming, I think if we have download the "boot code" for processors to the FLASH using the SJTAG bus, the application software can download to the FLASH using mission bus. And the boot code is small.
    • [Yingwu(P)] Maybe it is a problem how to store the data and control information. We have not too much choices only to use STAPL files now. So that we need an external tool to generate the STAPL format files for embedded execution. If we only get the test feedback and not to diagnose in the embedded system, in addition we need an external tool to diagnose using the test feedback. Except the two tools, I think we don't need the other tools up to the present.
    • [Ian(P)] I have no particular comment to make on the draft notes. What I might have been inclined to add looks like where we're going next week anyway!
    • [Timothy(P)] Block of notes from feedback follows: I have included some notes below. Topics may be a bit scattered, one topic just led into another, so I rambled.
    • Data formats
      Possibly STAPL bytecode version if it exist , I remember Jam player used .jam files and jam byte code used .jbc files ;compressed format. Don't know if the current byte code player is stapl compliant.
    • Using an external controller, I used a proprietary scheme to select the scan path, then I executed the stapl actions. I used a piece meal sequence file to incorperate a sequence of events, small individual steps were needed to create a level of diagnostics.

      pseudo code in sequence file
      select path1
      update dev1
      select path2
      update dev2
      select path 1 and 2
      test interconnect1 (checks cable 1)
      test interconnect2 (checks cable 2)
      test interconnect n ( checks bd1 to bd2 connection)
    • Programming file generation
      For example if you have two plds, when you create the STAPL file you need to tell the file generator the number of devices in the chain. Should a programming file be created for each individual device or all devices?
      I would usually create several combinations. u1_only.jbc u2_only.jbc (one device chain) and both u1_u2.jbc (two device chain). If you only created the both_u1_u2.jbc programming file you could not program just one device.
      Likewise for the several piece meal test files we would use our expensive Jtag test development software to create tests and export them to stapl.
    • Gateway communication
      The selected jtag chain needs to match that of the programming files so gateways need the knowledge of which path to select. Is this something accopmlished with extra traces beyond the tap pins or can data be shifted in via tap pins in stable states other than shift states (like TI shadow protocol).
      I don't like Jtag partitioning devices that are "In" the chain because it creates too many issues with DSP and PLD vendor tools. I prefer a transparent gateway that select the path based on user input. Do you want to standardize scan path selection into a programming file, like a scan path selection register, individual gateways would need to interpret it to make the path selection. Program file generators would have to create an scan path selection action that could be read by a gateway. Or should a separate sequence file be needed.
    • Security
      In some cases providing all native programming files with the product makes it vulnerable to IP thieves or malicious hackers.
      Does any application data include customer proprietary data that needs to be safeguarded?
    • Strategy
      Updates should make the product better not worse, save last known good version before overwriting.
      For Flash updates, do as much as you can functionally, but allow a backdoor via JTAG to program boot code.
    • Safety
      Any remote operations must be safe, remote diagnostics aren't going to be moving mechanical parts etc. Our model was more of a pull rather than a push. Allow the user to pull stuff from the web and run it. The customer is supervising so field service doesn't need to be on site.

5. Schedule next meeting

Wednesday, March 19, 2008, 8:15am EDT

6. Any other business

ATCA is meeting on 3/14/08 in CA; primary topic is JTAG at system level and forming a sub committee for that

7. Review new action items

Brad to create a list of types of things programmed in a system for the Forum discussion

8. Adjourned at 9:39am EDT

(moved by Heiko, second by Adam)

My thanks to Heiko and Peter for assistance in writing these minutes.
There was a lot of feedback activity as well. I hope this means a larger interest than the silence experienced in the previous meetings!

Respectfully submitted,