Programmed device - labelling requirements?

We assign a software ID number and rev letter to each formal software release. A typical number might be 22376B. We stick a label on every programmed part, no matter how it's programmed.

We use mostly Xilinx FPGAs, which are ram based, so we don't label them. A typical product will have an eprom or a flash chip that contains uP code and one or more Xilinx config files, all rolled up into a single release.

John

As a general rule, we solder programmable parts to the board unprogrammed, and program them using JTAG or a parallel interface. We avoid pre-programmed parts like the plague, but we still have some to deal with.

We don't label parts that are blank at board assembly. The file to program a part is maintained with the assembly build configuration. The file is not permitted to change once it's in build configuration. If a change in the file is required, then this is treated like a component change. In this case a new assembly part number is generated and a new complete build configuration documentation (and file) set is produced for the new assembly part number. Therefore, all we need to identify the file(s) in any given assembly is the part number of the assembly. We don't rev assemblies.

When a part has to be programmed ahead of time then we treat this as an assembly itself. We have a build configuration documentation and file set for the programmed PROM. This includes all programming and labeling instructions. All we really need on the label is our part number, but we will provide additional information on the label if there is room. Again, if a file change is required then this would force a new programmed PROM part number, and then this would in turn force a new PCB assembly part number for the PCB where it is used. This protocol ensures that the exact file can be traced from the top level assembly in all cases.

We allow some flexibility during initial prototype debug and verification. While there are only a few assemblies that are under our control we permit changes to the assembly (or PROM) without forcing the generation of new part numbers. Once the design is released to production it is then frozen, and no more changes are permitted.

================================

Greg Neff VP Engineering

Hi John and Geoff

Thanks for your comments, most welcomed. We are medically driven and so have similar proceedure for batch traceability of parts as both you guys, but I'm specifically interested in arguments for and against placing labels on programmed parts. Industry has previously always placed labels on the final programmed part but I need to understand why! Obviously you both use labels too, but I really need documentaional evidence - regulatory standards for labelling would be the ideal.

There is much talk of labelling components in general in the MIL-STD-130 spec but I would hope for a harmonized (euro/US) spec.

Would be do me a favour and briefly review your company procedure manuals to see if the author has referenced any regulatory documents?

Would be MUCH appreciated.

Kind regards Lea

So that, if a customer has a problem, he can look at a board and tell us the programming configuration, and we can see if he's up to date. We have, in theory, manufacturing and RMA (return/repair) records that could tarck his product by serial number, but checking the labels is quicker and a good crosscheck.

We avoid regulatory standards whenever possible. But we don't get audited, as a medical equipment supplier does.

The author was me, and no docs are referenced. Sorry.

John

With UV-erasable EPROM's, an opaque label was more necessity and less luxury. Even if the label was blank :-)

Tim.

I found some more MIL stuff. I checked the requirements for a UV EPLD in MIL-M-38510/507A. It says only this about marking:

"Marking shall be IAW MIL-M-38510. For programmed devices, the altered item part number shall be added to the marking by the programming activity"

Interestingly, there is no mention of covering the window after programming.

I also quickly looked at:

MIL-STD-1285 MIL-PRF-38535 MIL-STD-13281

From the MIL side it looks like labels on semiconductors may be a problem, because the altered item part marking is not permitted to obscure the factory part markings.

For those that are not aware, MIL standards can be downloaded for free from:

The only reference I found to a regulatory standard is UL 969, but I'm not sure at all that this applies. Here is the scope:

================================

Greg Neff VP Engineering

Hi All

Apologies for the delay in responding but had to fly out of town on business so had to let the label issue rest until my return.

Now I'm back and of course I still need to resolve this issue across company and so have taken all your comments on board - they're the same as mine so it's good to know I'm thinking along the correct lines and I'm sure these can be argued as simply common sense!

However, I now need to consider programmed parts that cannot accept labels as I endeavour to make the label process common for parts programmed on and off board alongside parts that can accept a label or not.

Of course, I also need to consider parts, which can be upgraded via the user - now it gets a little more tricky!

Time for some further thinking!

Lea,

I used to work at a company that made medical equipment and used lots of programmable devices. You're right, it gets a lot trickier when you can do in-field upgrading. In that case, it is impossible to make sure that a physical label matches the actual revision of a part.

What my previous company did was have a suffix that was a combined revision of all the programmable devices. So each time one (or more) of the devices changed via an update that suffix was incremented. The combined rev was also stored in the flash so that you could read out the current revision. So the physical labels gave you the state it went out the door at and the electronic labels gave you the current versions of everything.

The downside of this is that it appeared in the ERP system and anytime one programmable device changed there were mountains of paperwork to change the combined revision suffix all the way up the BOM tree.

As devices became more dense, a requirement evolved to indicate that every programmable part had to be able to return its revision to the onboard processor. This made upgrading a lot easier since s/w could be written to only upgrade what was needed and began to make the combined revision a bit redundant. The system hadn't evolved to the point of getting rid of the combined revision and only using electronic labelling but that was the next logical (although widely contested) step.

One bit of advice: Don't let stuff out you know that you will need to rev in order to fix bugs. There's enough paperwork to do there's no sense volunteering.

Cheers.

Hi James

Very wise words and I've interestingly come to similar conclusions after discussing the best way forward with various R&D and Manufacturing colleagues.

My plan is to mandate that prog. devices that are 'user' upgradeable (very common in consumer markets, but now also creeping in the Medical field too) the design includes electronic methods of version recovery for each device. Whether this is by visual (assuming some type of display) or simply by RS232 and a small debug connector (or similar) - field service engineers. can simply connect their laptops.

Of course another thing to consider is that real estate of programmable devices has previously been sufficient area to place labels, BUT often (FPGAs for example) the programmable code is stored within a configuration device and this is too small for a label and naturally has a very low pin count.

Now and in the future we'll have even more ICs that cannot accept labels, and in my opinion this percentage will grow significantly over the next few years so I have considered using a label area on the PCB assy. to represent all devices.

Here's my thoughts.

On the PCB we silk-screen multiple boxes (accounting for the number of prog. devices) and place text within, something similar to that shown below:

U1 UNPROG U4 UNPROG U7 UNPROG U24 UNPROG Axxxxxxxx

So as the operative programs the PCB (whether on board or off board) labels can be affixed over the top covering the 'UNPROG' silk screen. Maybe labels with the following info:

U1 V2.4 U4 V1.0 U7 (V1.1) U24 V2.3 A10001000 R2 - this label is ONLY affixed upon the completion of all programming and is the final top-level number indicating the PCB is now fully programmed and ready for despatch/restocking.

The R2 indicates top-level revision number. The brackets around the version number indicate 'user' upgradeable part' and this was the version at time of programming/shipping.

For us, this system has many advantages: flexibility allowing intermediate storage of the assy. at any stage (after reflow we can return the PCB to stock); it's programmed state will be known at any point of manufacture and flexibility in terms of programming sequence

- the operative can program 100 off U7 parts then return latter to program the U24 parts.

Only downside is real estate for size optimised PCBs with multiple prog. devices!

Thanks for all the comments. Lea