|
Message
From: Rudolf Usselmann <rudi@a...>
Date: 29 Aug 2003 11:46:48 +0700
Subject: Re: [usb] how to correctly operate the usb 1.1 core
On Fri, 2003-08-29 at 07:53, amt98007@s... wrote:
> Hi!
>
.....
> 1. wait until usb_busy = 1 and ep_sel = "our OUT endpoint"
> 2. wait until usb_busy = 0 or ep_sel != "our OUT endpoint"
> 3. if crc16_err = 1 clear fifo and return to step 1
> 4. read fifo contents.
>
> We are also not sure of how to time the fifo:s re and dout signals
> correctly (it's a little embarrassing to ask about such a trivial thing.
> sorry to bother you with this!). This is how we tried to read two bytes
> in a row from the fifo:
> @clk: ep_re <= 1
> @next_clk: ep_re <= 1, data1 <= ep_dout
> @next_clk: ep_re <= 0, data2 <= ep_dout
> When we tried this we ended up with the same data in data1 and
> data2. What would be the correct way to do this? (We have tried to
> simulate the fifo in Modelsim but for some reason the dout signal was
> always XX (undefiend) during simulation so it didnt help us)
Look at the test bench, should be obvious from there.
> Another thing we have been thinking about concerns IN transactions
> (bulk & int). It is about how to handle the situations when a packet
> sent by the device doesnt get an ack from the host.
> As we can understand it, the function using the endpoint is responsible
> to resend the packet when a timeout occure, right? (the core wont
> automatically handle this?)
> The function can detect when a timeout occured using the int_to_set
> and ep_sel signals, right?
> This also means that the function must hold a copy of the packet in a
> second buffer until it has been ack:ed by the host, right?
> If the above is true, how will the function know when an ack has been
> received? (so it can proceed with the next packet)
No the core doesn't handle that, just as CRC errors you
described above. This was intended to be a "dumb" device
that does not need a CPU and is small. We where using it
for multiple channel low end audio, so dropped packets or
skipped packets didn't matter so much.
In case of errors you would have to back up the FIFO and
resend the packet. Or ignore the packet altogether if it
had a CRC error. Perhaps a double buffering scheme for that ?
The IP core does actually indicate some errors:
crc16_err Payload CRC Error (RX frame)
dropped_frame WE dropped a RX frame - no space in FIFO
misaligned_frame Frame was not FIFO size aligned
Inside the Core you will also find:
nse_err No Such Endpoint Error (Function Address
matched but endpoint does not exists)
crc5_err Token CRC error
int_seqerr_set Data Sequencing Error (dropped frame)
int_to_set Time Out. Both, waiting for an ACK (during IN),
or waiting for a packet (during OUT).
All you need is to add some hardware that can "fix" those
errors when they occur.
> Sorry for the long post, but we would greatly appriciate if someone
> could help clear these things out for us. Thanks!
Cheers,
rudi
--------------------------------------------------------
www.asics.ws --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores
|
 |
Browse
