Crc core: add purely combinatorial CRC engine

[t-wallet]

Currently, the CRC engine assumes that data is fed into it over multiple cycles. This is true for calculating the CRC over an Ethernet frame, but it is not the case for some other use cases. Apart from adding resource overhead to such use cases, the delay of 1 cycle makes it a pain to use. That's why there is a need to add a purely combinatorial function that has no residue. Note that we will probably need to add new types for its parameters, as the matrix sizes do not match.

An example:

• Quick "hashing" of values, such as to index an ARP table.

[rowanG077]

You could add a version of the crcEngine that has no latency. One thing though is that AES MixColumns is not a CRC afaik. CRCs aren't cryptographic hashes. The are aimed at error detecting.

[t-wallet]

You could add a version of the crcEngine that has no latency. One thing though is that AES MixColumns is not a CRC afaik. CRCs aren't cryptographic hashes. The are aimed at error detecting.

Is it not just polynomial multiplication in a finite field? There must be a reason why crc8_aes exists :)

Edit: it looks like the polynomial of crc8_aes is different from the actual polynomial MixColumns uses. So it's probably just a confusing name. But the point related to quick hashing still stands.

[rowanG077]

What would be trivial to add is a type level bool. registered :: Bool including a KnownBool registered constraint and use that to choose which one you want use. This should only be a few line change and will do hat you want.

Regarding crc8_aes. I simply copied all CRC params from: https://reveng.sourceforge.io/crc-catalogue/all.htm. If I look at the doc there it refers to some audio thing and not AES encryption.

[DigitalBrains1]

If I look at the doc there it refers to some audio thing and not AES encryption.

Yup: https://en.wikipedia.org/wiki/AES3
It doesn't check the audio data but rather the channel status word.

AES is pretty similar to S/PDIF but for professional broadcasting. S/PDIF does not include a CRC in its channel word; just the parity in each sample that covers both audio and metadata (this parity is also in AES but they added a CRC for the metadata).

[DigitalBrains1]

What would be trivial to add is a type level bool.

Does it have to be type-level? I think in general we're okay with constant term-level arguments to configure things like this. I don't want to call out our SPI slave as an example, with its current deficiencies... but it does have pretty much exactly this.

I'd rather only move to the type level if it actually achieves something compared to term level; not just "well this needs to be a constant"; we have plenty of terms that need to be constant in a synthesisable design.

[rowanG077]

I personally prefer having circuit configuration constants be type level. But it's not super important for me.