8b/10b decoder sometimes decodes garbage as valid data

[jvnknvlgl]

From #2738 (comment).

The 8b/10b decoder sometimes decodes garbage as valid data. In practice this should not cause any direct issues as properly encoded data will never be improperly decoded, but it is a mistake nonetheless, and needs to be resolved. The linked comment shows some examples:

--- a/clash-cores/src/Clash/Cores/LineCoding8b10b/Decoder.hs
+++ b/clash-cores/src/Clash/Cores/LineCoding8b10b/Decoder.hs
@@ -1495,7 +1495,7 @@ decoderLut =
   , (0, 0, 0, 1, 0b11111100) -- D28.7
   , (1, 1, 0, 1, 0b11100000) -- D00.7
   , (0, 0, 0, 1, 0b11101111) -- D15.7
-  , (0, 0, 0, 1, 0b11100000) -- D00.7
+  , (0, 1, 0, 1, 0b11100000) -- D00.7
   , (1, 0, 0, 0, 0b11100111) -- D07.7
   , (1, 1, 0, 1, 0b11100000) -- D00.7
   , (0, 0, 0, 1, 0b11110000) -- D16.7
@@ -1814,11 +1814,11 @@ decoderLut =
   , (1, 1, 0, 0, 0b01100000) -- D00.3
   , (0, 0, 0, 0, 0b01111100) -- D28.3
   , (1, 1, 0, 0, 0b01100000) -- D00.3
-  , (0, 0, 0, 0, 0b01101111) -- D15.3
-  , (0, 0, 0, 0, 0b01100000) -- D00.3
+  , (0, 1, 0, 0, 0b01101111) -- D15.3
+  , (0, 1, 0, 0, 0b01100000) -- D00.3
   , (0, 0, 0, 1, 0b01100111) -- D07.3
   , (1, 1, 0, 0, 0b01100000) -- D00.3
-  , (0, 0, 0, 0, 0b01110000) -- D16.3
+  , (0, 1, 0, 0, 0b01110000) -- D16.3
   , (0, 0, 0, 0, 0b01111111) -- D31.3
   , (0, 0, 0, 1, 0b01101011) -- D11.3
   , (0, 0, 0, 0, 0b01111000) -- D24.3
@@ -1942,7 +1942,7 @@ decoderLut =
   , (1, 1, 0, 1, 0b11100000) -- D00.7
   , (0, 0, 1, 1, 0b11111100) -- K28.7
   , (1, 1, 0, 1, 0b11100000) -- D00.7
-  , (0, 0, 0, 1, 0b11101111) -- D15.7
+  , (0, 1, 0, 1, 0b11101111) -- D15.7
   , (0, 0, 0, 1, 0b11100000) -- D00.7
   , (1, 0, 0, 0, 0b11100111) -- D07.7
   , (1, 1, 0, 1, 0b11100000) -- D00.7

[leonschoorl]

In your PR you mention the table was adopted from LibSV, does that mean their table is incorrect too?
If so they'd probably like to know.

[jvnknvlgl]

Correct, but I would prefer to do some more investigation first before notifying them.