Programming/Updates

Discussion on the justification for SJTAG in each of the identified Use Cases: Alternatives, cost benefits and penalties
Post Reply
User avatar
Guoqing Li
SJTAG Member
Posts: 2
Joined: Tue Dec 18, 2007 10:06 am
Location: Huawei, Shenzhen, China
Contact:

Programming/Updates

Post by Guoqing Li » Sat Jan 05, 2008 3:53 am

Meeting Minutes reference:
http://www.sjtag.org/minutes/minutes080225.html
http://www.sjtag.org/minutes/minutes080303.html
http://www.sjtag.org/minutes/minutes080310.html
http://www.sjtag.org/minutes/minutes080331.html


As a independent system bus, SJTAG can be useed to update firmwares on the blades and kinds of carriers in ATCA system in life cycle. But its application might be limitted in small range. Due to the low speed rate of JTAG, it could not be fit to be used to program logical device and Flash with large volume of data. Some smaller flash, PLD, ROM, EEPROM used as BIOS and other basic configuration units can be high effectively updated by it. Usually FPGA data and large flash could be updated by inband bus of system, such as Ethernet and other CPU bus emulation. They are more efficient than SJTAG at stages of debugging, production and maintenance. Many have konwn that lots of EMSs also adopt pre-burn strategy before going to SMT.
So debugging and maintenance could be two more valuable points of update application by SJTAG.
Last edited by Ian McIntosh on Thu Jun 11, 2009 6:57 am, edited 2 times in total.
Reason: Added links to meeting minutes

User avatar
Ian McIntosh
SJTAG Chair
Posts: 413
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Post by Ian McIntosh » Mon Jan 07, 2008 10:42 am

In my environment, which tends to be low-volume, the use of in-system programming for first time programming of devices (including some large Flash memories) during manufacture is common practice.
Although building boards using pre-programmed devices is often preferred by our sub-contract assemblers, it does not really suit us as we may only build a handful of systems at any given firmware standard (especially true during the first year of production) - the consequent changes to supplier's drawing sets and amendments to purchase orders to incorporate new programmed parts is quite costly. A second factor is that it is common to change the loaded firmware as the boards progress though assembly stages (Module then System) to support different types of functional test. We then load the "Flight Standard" firmware as one of the last production operations.
"Application Software" is usually loadable using a high speed bus, such as Ethernet, but this rarely applies to embedded controllers, PLDs or FPGAs within the system and for these JTAG is the norm.

Edit: Additional comment following meeting of Feb 25th 2008:
As Guoqing noted, large Flash memories (and some large FPGAs) will give rise to JTAG programming times that are unacceptable in many volume manufacturing scenarios, and faster, (parallel) methods will generally be preferred. I think that is inescapable - to some extent, technology has moved on beyond what JTAG can realistically support in this area. Several JTAG "tricks" have been developed to speed up Flash programming over JTAG, but these really just reduce the scale of the problem rather than providing a cure.

Having said that, for in-the-field updates, or for recovering a system that may have suffered gross corruption, JTAG may still be a viable (or even essential) fall-back option.
I also expect that lab development activities will continue to rely on JTAG as a means of programming boards, or at least certain devices.

We should remain aware that not all "systems" will be as large and complex as the systems that Brad and I are familiar with, and in those cases JTAG may well be a viable option for routine programming/updates.

The main thing is that we do not end up precluding the use of JTAG for programming, and that we give adequate consideration to the design issues which may impact the usability of tooling, such that JTAG programming is available and usable when it needs to be.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 413
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Post by Ian McIntosh » Mon Mar 17, 2008 7:07 pm

Tim has raised a few points that are related to this subject, but are probably worth some discussion on their own. The following are links to those threads:

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Post by Bradford Van Treuren » Tue Mar 18, 2008 5:52 pm

During the 3/10/2008 meeting we came up with a set of items that are able to be updated using boundary-scan. I had an action item to enumerate this list on the forum for further discussion. The list identified during the meeting is:
  1. FPGA, CPLD, and PLD family of logic devices
  2. FPGA Configuration PROMs
  3. Parallel FLASH*
  4. Serial FLASH* [Most often I2C based]
  5. Embedded memory* (in DSP, microprocessor, microcontroller, etc.)
  6. Configuration Parameters (temperature/voltage thresholds, etc.)
  7. Programmable operational parameter (programmable resistors, etc.)
  8. Any kind of non-volatile storage
Ian proposed the following categorization for these items:
  1. Predictable areas to change (aka, Software)
    • Application level programming
    • Mission data
  2. Non-predictable areas to change (aka, Firmware)
    • PLDs (FPGAs, CPLDs) and FPGA Configuration PROMs
    • FLASH (including FPGA configuration via uP/Flash)
* Indirectly programmable using JTAG accessible ports/resources on adjoining devices (clusters)
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 413
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Post by Ian McIntosh » Tue Mar 18, 2008 9:00 pm

Ian proposed the following categorization for these items:
  1. Predictable areas to change (aka, Software)
    ...
  2. Non-predictable areas to change (aka, Firmware)
To perhaps clarify what I was meaning by these headings:

The "predictable areas" are those that either by explicit statement or by inference from the requirement for the product may be expected to be updated a number of times during the life of the product. Consequently, it is likely that a provision will be made in one or more of the mission buses to facilitate these updates.

The "non-predictable areas" covers the remainder of the re-programmable entities: There is no requirement for these to be reprogrammable, it's just the way the design has been implemented. Updating via a mission bus is probably unsupported (if not actually impossible), and which may well require the use of a dedicated Test Connector.

Post Reply