--- Quote Start ---
This is what I did. I created a file which simulates the FTDI's behaviour (as described in the datasheet) as part of my testbench.
--- Quote End ---
I'm confused by "I created a file". You mean you created a procedure? If I was going to create a bus functional model (BFM) of the FTDI device, I'd create a procedure to generate a byte-stream and receive a byte-stream, then I'd layer read and write byte-sequences on top of those streams. Then my testcase generator would issue read and write commands.
--- Quote Start ---
However, it's hard to create all possible combinations of problems which may cause an error if You don't know what possible combinations may cause an error...
--- Quote End ---
Right, that's where tracing the hardware comes in; it gives you sequences that are representative of reality.
--- Quote Start ---
By the way, it doesn't really matter how the data is transfered over USB. The FTDI has it's own protocoll and will provide any data that comes from it's USB interpreter, so on the FPGA's side, all You need to do is read bytes or write bytes on the application layer.
--- Quote End ---
That's true. But your hardware should handle the case of a partial packet, eg., what happens if you unplug the USB cable and plug it back in again. Lets say the FTDI device was self-powered, so your FPGA remained powered the whole time. Would a partial packet cause your FPGA to get stuck in an FSM state waiting for bytes that'll never show up?
--- Quote Start ---
Maybe I didn't fully get what You wanted to tell me.
--- Quote End ---
Basically I was commenting that your testbench should try to cover a reasonable number of use-cases and byte-streams, so that you can be confident that the design works.
--- Quote Start ---
For debugging, I'm currently transferring an increasing counter (instead of the actual data). If it increases by a value which is not 1 (or doesn't increase at all), I know that something went wrong.
I can trigger on such events with signaltap - I implemented a small interpretation module within the FPGA wich will generate an error signal if the previous value + 1 doesn't match the current value.
--- Quote End ---
Sounds like a good plan. Make sure to send invalid data to check that the FPGA recovers and can then read good data.
Cheers,
Dave
Honored Contributor
