Hardware implementation of the Xilinx configuration CRC generator

Hi, I need a hardware implementation of the Xilinx CRC generator for the configuration process. I want to manipulate the configuration date before I download them to the SelectMap interface, but as the CRC checksum changes by manipulating the configuration bistream, I have to calculete the new CRC checksum in hardware and include this into the new configuration stream. In the App 151 and 138 they talk about a parallel implementation, because timing (clock cycles) is critical for me.

Any suggestions how to implement the CRC checker or better, is there an existing hardware implentation that I can use? Heiko

Reply to
Heiko
Loading thread data ...

The following website will create Verilog or VHDL for any CRC polynomial from 1 to 33 bits, and can parallelize the implementation from 1 (basically serial) to 511 bits.

formatting link

It has a few preset CRC generator polynomials, you need the second one in the list : "CRC-16 / USB".

Select it, click "set to", select the level of parallelism for the data bus, for example, 32, click apply, and then generate.

There are lots of ways to screw up CRC: load from the wrong end, shift in the wrong direction, forget to initialize the CRC register, reverse the results bits, forget to invert the result at the end, and many more. Not all CRC standards require all these steps, but some do. The best procedure is to implement a 1 bit at a time version, the N bit at a time version, and the C code in XAPP151.

Run some test data through all of them, then fix things until they all give the same answer. Note that the parallel versions can not be made to work with data streams that are not an integer multiple of bits of the width you choose for the parallel version.

If you must do this, then a possible solution is to process as much as possible in the parallel section, then transfer the result to the CRC register of a 1 bit at a time CRC generator, and then finish of the remaining bits there.

Have fun,

Philip

Philip Freidin Fliptronics

Reply to
Philip Freidin

This is not true in general. There's a number of ways of getting wide parallel CRC calculators to work with frames of any length.

I call these the "ragged start word" and "ragged end word" problems if the packet does not start or end on a word boundary.

Some methods described here:

formatting link

Regards, Allan.

Reply to
Allan Herriman

Indeed. Although more like clues, rather than methods :-)

While my previous article suggested using a 1 bit serial solution to finish of the "ragged end" as you name it, for a packet that is byte oriented, you could process it 32 bits at a time, and then finish off the last 1, 2, or 3 bytes with an 8 bit generator, or if cycle count was really critical, have a generator for 8, 16, and 24 bits that is only used for one cycle at the end of the packet.

Thanks for the interesting addition algorithm behavior info,

Philip

Philip Freidin Fliptronics

Reply to
Philip Freidin

Hi Philip, hi Allan, many thanks for your answers, I am sure this will help me. Regards Heiko

Reply to
Heiko

I had to do this for USB CRC-5 on a processor with an instruction to do an 8-bit-at-a-time CRC with a polynomial of up to 32 bits (Ubicom IP3023). Preloading the CRC register with a suitable value caused the CRC to be the all-ones initialization value *after* the extra zero bits at the high end of the data were computed into the CRC. I wrote a simple C program to do a brute-force search for the correct values, but a more clever approach might be possible by running the CRC backward.

Reply to
Eric Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.