cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
7,983 Views
Registered: ‎04-22-2010

Spartan-3E VGA to PS/2 cross-talk

Jump to solution

I'm working on project that uses VGA and PS/2. I have both VGA and PS/2 controllers. When apart, each of them works fine. But once I include VGA controller into working PS/2 project, the PS/2 component starts functioning improperly.When I disable VGA signals generation, the PS/2 component works fine again.Any idea on what may be a problem? Is it interference between VGA and PS/2 connectors (which are close to each other on the board), or is it possibly a cross-talk inside the FPGA?

VGA has 5 relatively high-frequency outputs - R,G,B and scanning.
PS/2 has 2 low-speed inputs - clock and serial data in.

Message Edited by alexium on 04-22-2010 01:38 PM
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Professor
Professor
6,816 Views
Registered: ‎08-14-2007

alexium wrote:

I've set slew to SLOW. That didn't seem to change anything. Then I decreased drive strength from 8 to 4, and now everything looks good. Unfortunately, I don't have the tools neccessary to check the real signal shape, so I can only suggest that this is possibly not the problem of the design itself.

Message Edited by alexium on 04-23-2010 07:24 AM

Are you using the mouse clock signal directly as a clock?  If this is the case and it has a slow

rise and fall time, that would make it very sensitive to ground bounce since it would normally

spend a significant time inside the threshold region.   Most designers treat slow clocks as standard

inputs to be sampled on another clock and possibly filtered.  When I design for slow interfaces

like I2C I generally place the same filter on the clock and data signals to be sure the filter delay

doesn't change the relative sample timing.  The filter should have enough stages to get

rid of glitches on the order of the worst case signal rise time.

 

HTH,

Gabor

-- Gabor

View solution in original post

14 Replies
Highlighted
Historian
Historian
7,974 Views
Registered: ‎02-25-2008

alexium wrote:

I'm working on project that uses VGA and PS/2.  have both VGA and PS/2 controllers. When apart, each of them works fine. But once I include VGA controller into working PS/2 project, the PS/2 component starts functioning improperly.When I disable VGA signals generation, the PS/2 component works fine again.
Any idea on what may be a problem? Is it interference between VGA and PS/2 connectors (which are close to each other on the board), or is it possibly a cross-talk inside the FPGA?

Message Edited by alexium on 04-22-2010 08:35 AM

This is likely a design problem, not a crosstalk problem. Did you simulate the design?

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Participant
Participant
7,971 Views
Registered: ‎04-22-2010

I've simulated it partially. I'm not really sure how to verify the VGA controller and PS/2 transmitter without the real hardware. PS/2 receiver and other modules work like charm in simulation.
Any ideas on how to fix this or the exact origin of the problem would be greatly appreciated.

Message Edited by alexium on 04-22-2010 09:55 AM
0 Kudos
Highlighted
Adventurer
Adventurer
7,958 Views
Registered: ‎08-13-2007

Things I would check :

 

1) Timing constraints are used and are met.

2) how are the PS/2 inputs used ? what happens if one rises slowly ?

3) how are you getting data across the clock domains ?

 

How does the PS/2 controller function improperly ? how is its clock generated ?

0 Kudos
Highlighted
Professor
Professor
7,957 Views
Registered: ‎08-14-2007

Several things happen when you add a lot of code to the design, even if it doesn't directly

affect the logic that stopped working.

 

1)  Any time you rebuild the project timing will change.  This can cause lurking hidden

timing problems to show up.  For example if you have an asynchronous signal that

gets sampled on the same clock by more than one flip-flop, changing the relative

path delays to those flip-flops will change the behavior when the asynchronous

signal doesn't meet setup time at all of the flops.

 

2) Adding a lot of logic will tend to increase the average route length in the design,

including route lengths within the original portion of the design that didn't change.

If you don't have adequate timing constraints this can lead to more timing-related

failures.

 

3) (the "cross-talk" issue) adding a lot of outputs to a design that switch simultaneously

can cause ground-bounce, leading to problems sampling seemingly unrelated

inputs.  This sort of problem is described in several white papers on "SSO"

(simultaneous switching outputs).  It can be mitigated by using slower slew rate,

lower drive strength, or staggering output switching.

 

HTH,

Gabor

-- Gabor
0 Kudos
Highlighted
Participant
Participant
7,948 Views
Registered: ‎04-22-2010
Thanks for the replies. Looks like I should add timing constraints (never used those before).

to dp11: the clock for serial PS/2 interface is always generated by the device, i.e. mouse. Unfortunately I don't understand what's the problem with receiver - it just misses some data packets, about 50% of packets are not received. I suspect interference on the serial data line, the clock line is probably OK. I need more tests to be sure, though.

to gszakacs: thanks for info on SSO. Probably not the problem of my project, but the knowledge is useful.
Message Edited by alexium on 04-22-2010 12:46 PM
Message Edited by alexium on 04-22-2010 12:47 PM
0 Kudos
Highlighted
Adventurer
Adventurer
7,910 Views
Registered: ‎08-13-2007
I understand the clock is generated by the mouse, but what happens if it rises slowly or glitches on the transition ? Do you have any thing to prevent this causing problems ? how are you getting data from the mouse clock domain across into the next clock domain ? 
0 Kudos
Highlighted
Participant
Participant
7,901 Views
Registered: ‎04-22-2010
As for transition speed - I don't know. Obviously, glitches will prevent the receiver from working properly. I just hope there is Schmidt trigger somewhere on the line (maybe, I should try to implement a simple digital filter?). As for clock domains - I use registers which are written by mouse receiver and then read by top-level architecture according to the "data_received" signal the receiver produces. Also these registers are mapped to inputs of the VGA controller. 

I'd like to emphasize the fact that I have now design with both VGA and PS/2. The design is implemented, the FPGA is configured and the board is powered on. When I disable VGA signals generation using switch on the board, the PS/2 works fine. If I then turn VGA generator on - PS/2 receiver starts working improperly again. That's why I considered this to be a cross-talk.
I'm going to do some experiments today. Maybe I'll find something...
Message Edited by alexium on 04-23-2010 04:40 AM
0 Kudos
Highlighted
Professor
Professor
7,892 Views
Registered: ‎08-14-2007

If you have one design that works properly when VGA is off but not when VGA is on,

you could have a power supply issue.  Make sure you don't get sagging on your core

voltage and any Vcco power that might be shared by the PS2 portion of the design.

If you suspect SSO problems rather than power supply, try setting the VGA outputs

to slow slew rate and possibly even lower drive strength to see if it has any effect.

 

regards,

Gabor

-- Gabor
0 Kudos
Highlighted
Participant
Participant
7,883 Views
Registered: ‎04-22-2010

I've set slew to SLOW. That didn't seem to change anything. Then I decreased drive strength from 8 to 4, and now everything looks good. Unfortunately, I don't have the tools neccessary to check the real signal shape, so I can only suggest that this is possibly not the problem of the design itself.

Message Edited by alexium on 04-23-2010 07:24 AM
0 Kudos
Highlighted
Historian
Historian
4,634 Views
Registered: ‎02-25-2008

alexium wrote:

I've simulated it partially. I'm not really sure how to verify the VGA controller and PS/2 transmitter without the real hardware. PS/2 receiver and other modules work like charm in simulation.
Any ideas on how to fix this or the exact origin of the problem would be greatly appreciated.

Message Edited by alexium on 04-22-2010 09:55 AM

You can model what the PS/2 transmitter and the VGA controller talk to.

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Professor
Professor
6,817 Views
Registered: ‎08-14-2007

alexium wrote:

I've set slew to SLOW. That didn't seem to change anything. Then I decreased drive strength from 8 to 4, and now everything looks good. Unfortunately, I don't have the tools neccessary to check the real signal shape, so I can only suggest that this is possibly not the problem of the design itself.

Message Edited by alexium on 04-23-2010 07:24 AM

Are you using the mouse clock signal directly as a clock?  If this is the case and it has a slow

rise and fall time, that would make it very sensitive to ground bounce since it would normally

spend a significant time inside the threshold region.   Most designers treat slow clocks as standard

inputs to be sampled on another clock and possibly filtered.  When I design for slow interfaces

like I2C I generally place the same filter on the clock and data signals to be sure the filter delay

doesn't change the relative sample timing.  The filter should have enough stages to get

rid of glitches on the order of the worst case signal rise time.

 

HTH,

Gabor

-- Gabor

View solution in original post

Highlighted
Participant
Participant
4,622 Views
Registered: ‎04-22-2010

Thanks for the advice. I'll now try to do what you described. What magnitude of transition time would you expect from a signal of 10kHz?..

0 Kudos
Highlighted
Professor
Professor
4,619 Views
Registered: ‎08-14-2007

What you need to know is the transition time.  It may not depend on the frequency at all.  If

the signal is open-drain with a 1K Ohm pullup resistor, and 100 pf on the whole net the

quick calculation of R x C gives a rise time on the order of 100 ns.  This might be a

reasonable rise time at only 0.1% of the cycle time at 10 KHz.  An actively driven signal

would have a rise time in the region of a handful of nanoseconds.  What clock frequency

do you have for sampling?  At 50 MHz you could add a 5-stage glitch filter without

significantly changing the input timing and that would clean up the clock signal.  My

filter is usually a 5 stage shift register followed by a flop that only gets set if all 5 stages

are 1 and cleared when all 5 stages are 0.

 

HTH,

Gabor

-- Gabor
Highlighted
Participant
Participant
4,586 Views
Registered: ‎04-22-2010
That's it! Filtering PS/2 lines solved the problem.
The funny thing is I've already tried the same filter on PS/2 inputs long before I added VGA, and the filter seemed to disrupt normal PS/2 controller functioning. But now everything's great.
Thanks for help and advices.
0 Kudos