Mark wrote:
> On May 27, 12:37 am, Petter Gustad <newsmailco...@gustad.com> wrote:
>> Andreas Ehliar <ehliar-nos...@isy.liu.se> writes:
>>> It is straight forward in Verilog as well. This is taken from an Ethernet
>>> CRC32 module I wrote a long time ago:
>> <snipped code>
>>
>> But that's not any poly at any length...
>
> Andreas's code snippet shows the point fairly well. It's
> not hard to expand his to have "polynomial" as an input to
> the module as well, and the data length and polynomial length
> as parameters.
>
> It's much easier to read his and understand what's happening -
> for me at least. Without comments, one can puzzle out the
> polynomial, and other CRC parameters fairly easily from the code.
> Try that with the machine generated code.

Automatically generated comments should be just fine.
However, there's no need to put the two approaches against each other
like that.

If synthesis tools were ideal, there would be no need for a
tool such as Easics' CRC Tool. It was developed in the mid 90s
because we found that the for-loop approach caused large synthesis
run-times and inefficient results in cases like:
* wide polynomials
* wide data widths
* CRC embedded in a large FSM

What CRC Tool actually does is a dedicated XOR-based optimization.
The synthesis improvements were quite dramatic.

Whether this is still the case, and for which synthesis tools,
I don't know. I can imagine that some synthesis tools contain
specific XOR-based optimization engines by now, which would
possibly remove the need for CRC Tool.

It all comes down to understanding the capabilities of
your synthesis tool.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com