Help me drive a Cypress USB host SL811HS with a FPGA

FPGA and USB host

Hi,


I have to drive a Cypress USB host SL811HS with a FPGA.
My FPGA is a XESS development kit with a Xilinx Spartan3, 1M gates.

As you may know, the Cypress requires an 8 bit data bus and 6 pins for controlling.

I have decided to syntethize all this controlling stuff with a state machine written in VHDL.

The FPGA drives very well the states in the bus but the Cypress doesn't respond well.
The first part of the Cypress is a 256 bytes RAM. I write it asynchronously with a slow clock (1Hz in order to be able to see evolution) but it doesn't respond very well. By reading what I've written it answers my about 2-3 randomly wrong bits in every byte and so on....


Anyone has an idea ? Anyone already developed boards with cypress ?


Thanks

FPGA and USB host

Your questions is so generic that it is almost impossible to answer to without knowing what you are doing, your clock frequency, your timing diagram or any type of information about the interface between the FPGA and the USB chip.

If you look at the datasheet for your Cypress device, on page 24, you have the minimum requirments for the few critical signals. The first one is the Lenght of your WR access, it must be at least 65nS, the second issue is the hold time for your data after CS, you have to keep you A0 signal active for at least 10 nS and Data bus for at least 5. Also, there must be a minimum of 85nS between each CS actions.

If your timing is OK, then you should look into the data you are sending, but look closely to your timing, if you have a good osciloscope, connect it to the signals (o2-4 at a time) and make sure that your access does not violate the timing requirments for the dvicce.

Keep us informed about the progress, I was planning to use the Cypress device in one of my projects as well.

Best regards,
/Farhad

Added after 1 hours 40 minutes:

Just one issue I forgot to ask here, do you know if the chip has a minimum requirments for signals? Not many chips can handle very slow signals like 1s, try to access at a higher rate, something about 1MHz and look at it with a osciloscope, if you have one.

BR,
/Farhad

Re: FPGA and USB host

Hi Farhada and all USB developers,

Many thanks for your interest and quick answer. Now I have some more clear ideas.
In order to build my development platform, I wanted to realize the example which is in the datasheet of the Cypress - i.e. the write and read RAM cycle.

As you can see in the jpeg attached, my timing problems gone. But the actual problem are these bloody glitches. I think now I am specific enough to illustrate my subject.
I also include the .vhd code of my state machine. You will notice that it is perfectly split into 3 processes and it surely targets a perfectly synchronous Moore state machine.
These glitches of course appear even when you haven't connected the Cypress, it is part of the synthesis. On the picture I show one cycle, but if I make it cycle without interruption the glitches re-appear periodically at the same place.

So my precise question is the following : how can I get rid of these glitches since I should have theoretically a synchronous state machine ?
I specify that my synthetizer is the Xilinx XST. I've heard that the Synopys FPGA compiler handles better synthesis algorithms...


Hope that somebody has already seen this boring phenomenon and that my message in a bottle will be read again,

Thanks in advance

tesla101

Re: FPGA and USB host

tesla101 said:

So my precise question is the following : how can I get rid of these glitches since I should have theoretically a synchronous state machine ?

Click to expand...

Your state machine is synchronous, but its outputs not. Moore's outputs are combinational logic from current state, so when you switch to another state, not all outputs will go stable at the same time. Therefore, I would suggest to use Mealey with registered outputs.

As to attached VHDL, I just quickly go through:

1. It is not good idea to call reset signal as OE. Usually, OE states for Output Enable for tri-states outputs.
2. I would remove clock division part from SM process. Use separate process to divide you clock to desired frequency.
3. Output Logic process should be pure combinational for Moore machine. So, remove this "wait until ..."
4. OL process should use current_state as a switch for case statement. Also, do not forget to add it to sensitivity list.

Re: FPGA and USB host

Hi,
Interesting problem. I have one question about your code, why to you have the code "wait until clk = '1'" in one process and the normal "if clk'event and clk='1'" in the other?

The issue with glitches is a commong problem with these type state machines. I agree with ACE-X that you should remove the "wait until" from your process and make it a pure combinatorial process.

If you still wants to make things "clocked", you can combine the OL and NSL process to one process. That way you make your life easier to understand the code as well as easier to handle. But some companies do not allow this kind of coding style.

Hope it helps,

BR,
/Farhad

Re: FPGA and USB host

Good morning to all USB developers, Farhada and Ace-X !

At last I got rid of these glitches by two reasons :

first, I realized the changes in my VHDL code as you gave me pieces of advice and at the end I changed a bit the combinatorial process so that the outputs are registered at last.

second, something I am not sure you will believe, my oscilloscope is a HP 54645D and as every logic analyzer it has a pod, well everything is normal. But ! One wire of my pod is damaged, so damaged that when it gets signal it disturbs all the other bits. I am not kidding, half of the glitches on the picture I previously posted is generated by this bad wire. Incredible.



Now I have a good model of registered state machine, if anyone wants help or the whole model, please contact me.

Yours,


Tesla101

FPGA and USB host

To tesla

I send the PM to you and hope you can reply to me as soon as possible.

Thank you

FPGA and USB host

HI Tesla,
Glad you found your problem, interesting, I never thought about the cable issue! Even thought I spend a week looking for a ghoast glitch that wasn't there myself.

BR,
/Farhad