Hi Tomas,
I again have a question related to your SSE accelerated Viterbi
decoder, and I hope it's the last issue, which prevents us from
finishing this work. In short, SSE based implementation provides
one-byte different decoding result for SCH transcoding test. So,
the whole GSM 05.03 coding test fails.
I have done some debugging, and would like to share some results.
Have a look at the tests/coding/test_sch(), which first encodes
a L3 packet into ubits and sbits, then some bits are getting
destroyed, then the gsm0503_sch_decode() is being called to get
decoded bytes back, and finally decoded bytes are being compared
with original bytes.
As long as encoder implementation is not covered by SSE code,
it works as before. But SSE accelerated decoder outputs one-byte
different result in case of SCH:
int gsm0503_sch_decode(uint8_t *sb_info, sbit_t *burst)
{
ubit_t conv[35];
int rv;
osmo_conv_decode(&gsm0503_sch, burst, conv);
rv = osmo_crc16gen_check_bits(&gsm0503_sch_crc10,
conv, 25, conv + 25);
if (rv)
return -1;
// ...
}
// Original implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
// Accelerated implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
As you can see, the conv[3] isn't the same in both cases. So,
at the next step the osmo_crc16gen_check_bits() returns -1.
Latest version of this change:
https://gerrit.osmocom.org/#/c/2454/
Do you have any ideas? Despite SCH decoding isn't required on
BTS side, the problem may be more global, than the test shows.
With best regards,
Vadim Yanitskiy.