1. Home
  2. Field-Programmable Gate Arrays
  3. Correction for hwicap_v1_00_a code

Correction for hwicap_v1_00_a code

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.

Reply to
Neil Steiner
Loading thread data ...

You mean like this one:

formatting link

?

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

formatting link

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

Reply to
John Williams

Hi John,

formatting link

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 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

Reply to
Neil Steiner

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.