Hardware implementation of the Xilinx configuration CRC gene

[Heiko]

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

 

[Philip Freidin]

On 8 Jun 2004 00:50:31 -0700, heiko@thecoldies.de (Heiko) wrote:

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

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.

http://www.easics.be/webtools/crctool

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

 

[Allan Herriman]

On Tue, 08 Jun 2004 08:55:29 GMT, Philip Freidin
<philip@fliptronics.com> wrote:

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.

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:
http://groups.google.com/groups?threadm=434d10fb.0302160949.75d1736f%40posting.google.com

Regards,
Allan.

 

[Philip Freidin]

On Tue, 08 Jun 2004 19:37:21 +1000, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

On Tue, 08 Jun 2004 08:55:29 GMT, Philip Freidin
philip@fliptronics.com> wrote:

Note that the parallel versions [of CRCs] 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.

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:
http://groups.google.com/groups?threadm=434d10fb.0302160949.75d1736f%40posting.google.com

Regards,
Allan.

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

 

[Heiko]

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

 

[Eric Smith]

Philip Freidin wrote:

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.

Allan Herriman wrote:

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.

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.