RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI

[Luben Tuikov <ltuikov@yahoo.com>]

--- "CAVANNA,VICENTE V (A-Roseville,ex1)"
<vince_cavanna@agilent.com> wrote:
> 
> I do not think we should rely on examples to serve as the
> specification.

Absolutely true.

But lets include examples _just_ to back it up, and maybe a
sample implementation (skeleton of), that will be good for
both hardware and software. Of course some optimization
will be sacrificed... (e.g. like processing more than one
bit at a time).

> For
> this reason I recommend that we modify the spec in one of
> 3 ways:
> 
> 1. explicitly show the reference implementation- what I
> call the
> multiply-divide implementation and which I have sent to
> the reflector. It is
> basically the ethernet reference implementation modified
> for the iSCSI poly.

Yep, maybe we should just mention that, plus plenty of
references, the 4 examples with correct values, and a
sample bit-at-a-time skeleton implementation.

> 2. use Paul's description

It says that the message is multiplied by x^32, which
is not correct. See below.

> 3. use Luben's formal description

I wouldn't. In implementor wants to get some speedup, and
optimization and as a formal definition it doesn't offer
them. Maybe the implementor will notice that after 32
clicks the CRC will be all 1's, and that they don't need to
multiply the message by x^32 if they init the CRC register
with all 1's and only xor the message bit and the MSb of
CRC on each click.... but that implies that the implementor
will have to do extra thinking work.

> The point I have been trying to make is that initializing
> the register to 1s
> does not necessarily result in the same process as
> described in the ethernet
> spec. Initializing the register to 1s only results in the
> desired results
> (i.e. agrees with the examples in the iSCSI spec) if you
> are using the
> implementation that I have been calling the
> multiply-divide implementation.
> This is the implementation that ethernet had in mind and
> iSCSI had in mind.

Absolutely true.

> The only reason that the above has worked right for
> implementors is that
> they all use the equivalent of a multiply-divide
> implementation as was
> described in the ethernet spec but that has not been
> described in any manner
> in iSCSI and that I have since recommended that we
> specify.

Abosultely true.
 
> I have to admit that by giving examples the iSCSI spec
> has removed the
> ambiguity since nobody will be able to get results that
> agree with the
> examples _unless_ they use the multiply-divide
> implementation but why not
> make it explicit and eliminate the need for implementors
> to have familiarity
> with ethernet and its implementations. Please note that
> any parallel
> implementations (that process 8 or 16 or 32 input bits at
> once) for ethernet
> are equivalent to the serial implementation that is shown
> as reference in
> the ethernet spec.

Abosultely true.
 
> I can however implement the iSCSi (and ethernet) CRCs
> using what I call a
> divide-only circuit and, if I initialize the circuit to
> 1's, and process the
> examples I will not get the results in the iSCSI spec but
> I will still get
> the magic constant at the receiver! What I will get
> instead are the same
> results as if I had XORed the most significant 32 bits of
> the messages in
> the examples with the magic constant and then processed
> them.

Aboslutely true.
 
-l




=====
--

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com