This project is read-only.

Integration of FTR/MPR pin indexes and states with PMRs, PGRs, and PLRs


I can see the eventual STDF v5 changing the structure of PLRs/PGRs/PMRs and their connections to FTRs/MPRs. First of all, having 2 PLR fields for the "left" and "right" characters of a potential 2-character state value is ugly. I'd rather the PLR spec define 3 counts/lengths -- a group count, a program state length, and a return state length -- then have 2 fields for program and return states, and those would be of some new kxCfn4 type, where k is defined by a field, f is defined by a field, and n4 is the variable length byte, like it is for C*n, but limited to 0-15 instead of 0-255. So if you had 5 pin groups, and the platform used 2-character pin state values for both program and return, the later program state list field would need to be something like a 5xC2n4, which we'd make an array of an array of string.

But right now in PLR, we've got 4 arrays of string, where each string really should be interpretted as an array of single characters, with a maximum length of 16. The appropriate use case of these values is taking an FTR's ProgramStates and/or ReturnStates, which are nibbles, and using those to index into the PLR's ProgramStates and/or ReturnStates strings (both having a right and optional left). Of course, you must first figure out which string in the array to look at (and also which PLR, assuming there are more than one). To find that index, you have to take the FTR's corresponding ProgramIndexes and/or ReturnIndexes, which identify a particular PinIndex, which has a PMR of its own (hopefully). That PinIndex can also be searched for in a particular pin group (as defined in PinIndexes field of the PGR). Once the PGR that contains that PMR is found, that PGR's Index (and we need to rename this "GroupIndex") can be searched for in the various PLRs' GroupIndexes. And once the index of the GroupIndex is found, we know what index to use for finding the correct string in the PLR's 4 (Program/Return)States(Right/Left) fields.

Wouldn't life be grand if we had some sort of mechanism built-in to LinqToStdf that could take care of all the indexing insanity for us? And also, upon write, wouldn't it be nice if we tried to write an FTR that included an index that didn't exist in the set of PMRs/PGRs/PLRs, the writer would throw? I'm thinking this would take the form of some sort of PinMapHelper object, which interacted with an STDF file's set of PMRs/PGRs/PLRs and could also be used to validate / help with the references in FTR and MPR.


marklio wrote Apr 15, 2012 at 3:57 AM

Instead of treating shared-length arrays as shared length arrays, should we be thinking of them as a single array of a more complicated structure? as far as your indexing helper, that seems like a job for an indexing strategy or at the very least a record filter.