B*x type fields are being misinterpreted

[JackNelson]

Tasks/Steps/Elements

The bits are being read in reverse

>>> [pow(2, 7-i) for i in range(8)]
[128, 64, 32, 16, 8, 4, 2, 1]

Should be assigned in ascending order rather than descending

>>> [pow(2, i) for i in range(8)]
[1, 2, 4, 8, 16, 32, 64, 128]

https://github.com/Semi-ATE/STDF/blob/main/Semi_ATE/STDF/STDR.py#L1673-L1677

Versions checklist

• Spyder version: >= 5
• JupyterLab = 3.4.2
• Python version: 3.8.13
• Qt version: all
• PyQt version: 5.15.1
• Operating System name/version:
  • server : Ubuntu 20.04 Linux
  • client : Linux

[seimit]

Hi Jack,
Thank you for your contribution!
I would suggest you to keep the current implementation and to add your PR as an option in the STDF library.
Because I'm not the original author of the STDF library, I assume that initial implementation of the fixed
length bit-encoded data, follow the description of the variable length bit-encoded field (Bxn) - the first
data bit is located in the least significant bit of the char array, according the "Data Type Codes and Representation"
table in page 8 in the STDF v.4 spec file.
Example:
Let's data is stored in char array named vla (stands for variable length array) with 3 elements:

vla[0] 00000010 - value 2 for data length in bytes
vla[1] 0000000x - first data bit value x (First data item in least significant bit of the second byte of the
array)
vla[1] 000000x0 - second data bit
vla[1] x0000000 - eight data bit
vla[2] 0000000x - nine data bit
vla[2] 000000x0 - ten data bit
vla[2] x0000000 - sixteen data bit

Which translates in "The bits are being read in reverse" as you mention. The first read bit in the sequence
is the last bit stored in the first byte.

So my proposal is to add an option in the STDR class to support ascending order of bits for fixed length
bit-encoded data in order to support STDF files which are generated in such format. And to keep the
original implementation as the default one. In this case we will be still compatible with the old releases.

Let me know if you have arguments to implement the ascending order as default one.

Kind Regards,
Seimit

[iynehz]

I see a similar issue. Actually it's not simply about the order be it ascending or descending. The problem is that B*x type field is treated inconsistently across this library. This is a definitely a bug.

• In STDR class when it parses the raw "B*x" type data, it converts a byte into a list of this order: [b7,b6,b5,b4,b3,b2,b1,b0].
  

  STDF/Semi_ATE/STDF/STDR.py

  Lines 1674 to 1679 in 5bbcbe7

  	for Byte in range(len(temp)):
  	for Bit in range(8):
  	## to be consistent with pack
  	mask = pow(2, 7-Bit)
  	if (temp[Byte] & mask) == mask :
  	result[(Byte * 8) + Bit] = '1'

• In other places like here, it assumes TEST_FLG's value list is in this order [b0,b1,b2,b3,b4,b5,b6,b7]
  

  STDF/Semi_ATE/STDF/PTR.py

  Lines 125 to 141 in 5bbcbe7

  	# TEST_FLG
  	# bit 6:
  	# 0 = Pass/fail flag (bit 7) is valid
  	# 1 = Test completed with no pass/fail indication
  	v = self.get_fields(6)[3]
  	if v != None:
  	if v[6] == '1':
  	buff += ' '
  	elif v[6] == '0':
  	test_status = 'Unknown'
  	# TEST_FLG
  	# bit 7:
  	# 0 = Test passed (ignore value, go to PARM_FLG bit 5)
  	# 1 = Test failed
  	if v[7] == '1':
  	buff += 'F'