Pipe Operation Questions

You need to go back and read all my previous posts.

On the 3001 there is only 16K words of buffer available… on top of that, the FPGA FIFO cannot be attached to the Cypress FIFO. For instance if you ask for more than a 4K read, there is no flow control to the FPGA FIFO, so that the FPGA FIFO can say it does not have anything available. Your routines just return the 4K+ requested reads, and will fill the end of the transmission with whatever is sitting on the FPGA FIFO Ouput, with no indication that the data was not available. In fact as I recall it would do this even for short reads, if there is no data. This is where you guys left the hardware, opting for making the 3010 instead of fixing this nagging problem.

What I have had to do is to add my own flow control around the FIFO’s, using wire in and wire outs, and FPGA data counters, so that I do not request more data than is actually there. Additionally since you guys choose to use the lowest priority data transfer mode, these counts take “forever” to transfer back and forth to the PC. (It would be thoughtfull to provide high priority “control” packets for transfers of this type).

So between the use of lowest priority bulk packets for the data which can be interrupted by anything, including USB mouse, USB Keyboard, USB disk, USB etc (there are a lot of them these days) (also note that the ISOCHRONOUS packet mode would be suitable for data that can be a little lossy, and I would sure like the option) and the incomplete FIFO implementation…

I cannot achieve reliable sustained transfers of over 128KB in length and 1.6MB/s. And try telling a customer they can’t use USB2 cause it will mess up the data transfer…

And that’s just the begining of the story. I’ve been working it for sometime, and the ONLY solution you have ever offered me, is BUY MORE MEMORY. Which would work, except that when you designed the 3010, you #&%#! CHANGED THE CONNECTORS, so I would have to redesign all my boards AND pay you another $200 per board. The other alternative, an add-on memory board, requires an entire J2 or J3 row of connectors, which also will not work for me, since my board designers did not pay attention to my directions to leave that avenue open…

So I’m stuck, and to top it all off, there is that nasty little issue of the Device Driver going away without notification! Welcome to the BSOD! When’s that one going to be fixed?

You know, I wish you guys would just quit dancing around like a bunch of kids, and fix these very real problems, that you know all about, before you do anything else. And don’t bother to reply to this with some hogwash, we’ve been there before. Just make a commitment to fix the problems… and actually get it done. It will do you well in the long term. I want to see the real 22 MB/sec that Cypress can produce…

Bill

— Begin quote from sonoranbill;1066

So I’m stuck, and to top it all off, there is that nasty little issue of the Device Driver going away without notification! Welcome to the BSOD! When’s that one going to be fixed?

— End quote

Can you explain this? We are not aware of a situation that causes the driver to disappear without notification. Our Windows API is built on top of the Cypress driver, so there is probably little we could do about it, but we could at least inform Cypress of the issue.

You need to go read the thread:

“Device Power Off Causes Device Driver Lockup”

I wish you guys would take care of this for us, so we don’t have to… especially since most of us don’t have the DDK…

So how about the other issues?

Bill

Bill-

I looked up the thread you mentioned and re-read it. I don’t see any reproducible behavior indicated there that would suggest a bug on our end. Your last post in that thread suggested that you were going to try the WM_DEVICECHANGED handling and get back to us. Have you done so?

What other issues? If you have genuine bugs to report, please do so. But please try to draw a distinction between a bug report and feature request so that we can properly address them.

No I have not, due to time constraints, but then before that, you said you would look into adding that feature into your code. Have you done that?

In my book these are all bug reports.

I realize you have a buissiness to run, and want to put the best face on things. Well, so do I. I have customers, and I hate listening to their complaints about throughput and BSOD, which your product is the cause of. And truthfully, I am really tired of you people hiding behind calling my bug reports, feature requests. That is just bullshit semantics.

So please fix your software, and quit telling people it can go faster than 1.5MB/sec until it can, and start telling them it can generate BSOD until you fix the problem.

Bill

Bill-

First, let me be very clear that we will not permit inappropriate language on our public forum. It is not polite to other members or Opal Kelly employees. It is simply unprofessional.

Please be clear on what is causing the BSOD to your customers. We have not experienced this in our software. If it is because you are not properly handling the WM_DEVICECHANGED event, then you must do so.

Software can be very complicated, in particular if you are using software that works at lower levels. It is important that you use the driver software properly.

Unfortunately, as an API provider, we do not have control over your software. If your software is not correctly handling events that it needs to be handling, we would advise that you address the issue by writing the appropriate handling code or hiring someone with the skills necessary to do so for you.

OK here is another advertising line for you…

You must have DDK before using our product!

You guys are not worth the time…

I gave you advice for free, try to help you out, try to help myself out.

You know what, I call problems like your product has, “Features”, which in your case is an inside joke about the code creators ability.

Anyway this conversation is worthless. After 9 months complaining to no avail I should know you guys never fix anything.

No more design in’s for you guys…

Bill

Bill-

We’re sorry to see you go. I’d like to mention, however, that the Windows DDK is available for free here:

http://www.microsoft.com/whdc/devtools/ddk/default.mspx

Obviously not sorry enough, else you would fix things, instead of letting them hang… I think 9 months and 40 something boards is long enough…

Bill

I’ll still be around, have to, but don’t expect anything new from me either…

Bill

Hello,

I’m not the expert by any means, and this should be out on the Forum, so I will copy it there.

It seems to me that there can only be two causes for “apparent” bit inversion. One: that you are using two different clocks at an interface so that a read is occuring while a write is happening. Two: that you are experienceing buffer overflows or underflows so tha you are getting duplicated or missing data…

I have found in my own use that the problem is almost always over/under flows, and that even with a 16k output FIFO it is impossible to maintain a sustained transfer rate greater than several Mb/s because of using Bulk Transfers. This is really exacerbated if there are USB1.1 devices or HID’s on the hub which can send out slow/high-priority packets which will trash your transfer rate.

Bulk may be allright if you have a really large FIFO like on the 3010, but I used the 3001. Really need to use the Isochronous Transfer method, and build in an error notifier, so corrupted data can be repeated if required… I understand something like this might be coming out soon…

Hope this helps…

Bill

[QUOTE=chameleon]Hi,
I am terribly stuck at one of the problems. I need help and I can see that you have a very good understanding of the pipes stuff.
Well the problem is
I am using pipe in and a 2047 FIFO as input and pipe out and another 2047 FIFO as output. I am using the wr_count and the read_count outputs of the FIFOs to determine how much should be written and how much to be read. It seems that 600K words go through without problem but after that one or two bits seems to be inverted. I am not sure if the software or the hardware is causing the problem. My own design works at 57MHz.[/QUOTE]