FPGA Central

Not sure if anyone else will care to know about this, but I've found
myself mentioning it to a few people, so I'll just put it out here for
archival purposes. (I did pass this along to Xilinx, but I don't think
any fix has propagated to the community yet.)

I was writing a linux kernel driver for the icap, and I found what I
believe to be an error in
hwicap_v1_00_a\src\xhwicap_set_configuration.c. These comments refer to
revision with header stamp:

/* $Header:
/devl/xcs/repo/env/Databases/ip2/processor/software/devel/hwicap/v1_00_a/src/xhwicap_set_configuration.c,v
1.4 2004/11/01 17:48:26 meinelte Exp $ */

When XhwIcap_SetConfiguration() is invoked with less than
XHI_MAX_BUFFER_INTS words, lines 124-125 call XHwIcap_DeviceWrite() with
BufferCount+1 words instead of BufferCount words.

When the code finishes iterating through the for loop in lines 94-118,
BufferCount is equal to I and equal to Size. So if Size was set to 4,
BufferCount will equal 4, and calling XHwIcap_DeviceWrite() for
BufferCount+1 words will actually write 5 words to the ICAP. In my case
that was apparently writing an additional bogus word to the ICAP and
thus causing CRC errors. When I change BufferCount+1 to BufferCount in
line 124, my driver works as expected.

People who always write full frames will probably not have run into
this, but my driver had to write chunks of data as it received them from
the kernel, and thus not split along frame boundaries.

Hi Neil,

Neil Steiner wrote:

> I was writing a linux kernel driver for the icap,

You mean like this one:

http://www.itee.uq.edu.au/~listarch/.../msg00009.html

?

It was written for MicroBlaze / uClinux, but will port trivially to PPC
if you need to. A paper describing the driver and some things we did
with is here

http://eprint.uq.edu.au/archive/00001296/

> People who always write full frames will probably not have run into
> this, but my driver had to write chunks of data as it received them from
> the kernel, and thus not split along frame boundaries.

I think I came across similar issues - with HWICAP you must always write
a full frame at a time which means buffering in the driver in case the
user does something like multiple byte writes (e.g. from "cat") instead
of a nice big block write.

Cheers,

John

Hi John,

>> I was writing a linux kernel driver for the icap,
>
> You mean like this one:
>
> http://www.itee.uq.edu.au/~listarch/.../msg00009.html
>
> ?

Yes, it is similar to yours, and I did download your xilinx_hwicap
before starting to work on mine. (And I certainly appreciate you making
your code available.) I ended up writing mine from scratch though
because I wanted to get gain a better understanding of linux drivers,
but more importantly because I wanted to be able to talk to the device
as /dev/icap from Java code (without JNI) or from a shell. I also
wanted to parse the bitstream header so that I could accept any normally
generated bitstream, and I believe your code assumes that there is no
header.

> I think I came across similar issues - with HWICAP you must always write
> a full frame at a time which means buffering in the driver in case the
> user does something like multiple byte writes (e.g. from "cat") instead
> of a nice big block write.

I did pick up that same impression from someone inside Xilinx, but with
the correction that I mentioned, I've had no problem just writing the
data as it comes in. As you're suggesting, "as it comes in" from
something like cat or cp or a Java write function, is completely
arbitrary, and unlikely even to be word aligned. (Admittedly, I do have
to pack the bytes into words, much like you do.) Perhaps I'm just
lucking out, but my icap driver routinely writes data that is decidedly
not split along frame boundaries, as the driver neither knows nor cares
where those boundaries fall.

Based on what I know of your driver, the correction that I mentioned
should work just as well for you as it did for me, and you might find
that it frees you from having to stick to frame boundaries. We can
compare code offline if need be.

Neil