CRC checker core for framed receive data

01

A wider data bus does not select a wider CRC polynomial

Xilinx’s DS589 for Virtex-5 CRC Wizard v1.3 describes a LocalLink wrapper around the device’s integrated CRC block. It uses the CRC32 polynomial while allowing two 32-bit-input blocks to combine into a 64-bit-input block. The input-width naming describes how data enters the block; it does not change that stated polynomial to a 64-bit CRC. [1]

This is the documented Virtex-5 implementation in the dated specification. For a new core, identify the target device, tool version, polynomial, initialization and input/output transformation settings before comparing implementations.

02

Read the pass/fail indication only with its result-valid signal

UG189’s RX_CRC example passes received data between upstream and downstream LocalLink interfaces and adds CRC_PASS_FAIL_N and CRC_VALID. It states that the pass/fail signal is valid only when CRC_VALID is asserted HIGH. The interface also carries frame-start, frame-end and source/destination-ready signals. [2]

Partial final words need a version check. DS589 lists a variable REM feature. [1] UG189’s receive-interface table describes REM as the final valid-byte offset but also says its release assumes all data bytes are valid. [2] Confirm the behaviour of the delivered RTL with the provider, including non-full final words, before relying on either description.

03

A parallel checkout word is a different interface from a framed error flag

Lattice’s RD1105 reference design instead provides check_ena, a parallel data_crc_input containing message plus CRC, and a CRC-width crc_checkout word. Its documented default example uses an 8-bit message and 16-bit CRC with polynomial 0x8005; the checker timing example applies 0xAA03FC and shows checkout 0x0000. These values belong to that example and its settings. [3]

RD1105 also exposes input/output transpose and complement parameters. Match those settings and the input representation to the reference vectors. Its checkout-word interface does not itself specify the LocalLink framing and result-valid signals of the Xilinx example. [3]

Request the exact RTL or netlist version, interface timing, clock/reset requirements, algorithm settings, final-word rules and reference vectors. Include good and deliberately corrupted frames, interrupted transfers and the result-valid behaviour in the agreed verification scope.

04

Specify the algorithm together with the frame interface

Paste it into your enquiry below or into an email to a maker, then replace every bracket.

Core: [target device; RTL/netlist and tool version]
Algorithm: [polynomial; initialization; transforms]
Data: [bus width; ordering; final-word rules]
Interface: [frame boundaries; ready/valid; result timing]
Verification: [reference vectors; corrupted frames; interrupted transfers]

See manufacturer records Send an enquiry through CNFX