UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jsli
Visitor
580 Views
Registered: ‎08-14-2019

MicroZed Board IO issue

We developed some design on MicroZed board recently, and connected it to another Xilinx FPGA platform (S2C, proFPGA). The first design was a SPI interface with total 6 wires(SCK, SCS, 4 wire SIO data bus). These 6 wires(Dupont wire) were connected to the IO of S2C platform. The GND of each board were connected. The IO voltage of each board were set to 1.8V. Then we wanted to use oscilloscope to probe these 6 wires for debugging. At the moment the probe contact to the IO pins. The S2C platform shutdown immediately. Unfortunately, the S2C platform was fatal damaged and unable to repair. But MicroZed still works. We finally couldn’t found the root cause and concluded it as human body electrostatic discharge.

The second design was a LVDS interface with one differential clock pair and one differential data pair. This time MicroZed was connected to proFPGA platform. The GND were also connected and the IO voltage was set to 2.5V. The communication worked well in the first several experiments. We didn’t probe the wires this time( due to last painful lesson…). After one experiment, we powered down both platform and powered on again. We found that proFPGA was unable to finish initialization process. We did some tests and found that proFPGA was damaged again! Due to the first design, every time we wanted to touch these boards, we touch a metal wire connected to ground(not connect to each board’s gnd) to eliminate human body electrostatic. However, the similar scenario happened again.

After that, we made some experiments and found that the IO of MicroZed board discharge very slowly. It seems that IO of MicroZed has no good discharge path. We doubt that if any residual electric charge on the wire(or electrostatic discharge) will rush into other FPGA IO while power off and damage permanently.

 Could you please help to analysis these issue or give some suggestion? Thanks!

0 Kudos
9 Replies
Highlighted
Scholar u4223374
Scholar
504 Views
Registered: ‎04-26-2015

Re: MicriZed Board IO issue

In the first case - were the board grounds connected to the oscilloscope ground? Was the oscilloscope's ground lead really connected to a ground? I've had this problem in the past (although with no damage done) because I had incorrectly assumed that the oscilloscope had a floating ground (as multimeters do), so it wouldn't matter if connected its ground to the easily-accessible positive lead and put the probe on the circuit's ground wire (just like it doesn't matter if you swap red and black on the multimeter). As it turns out, most oscilloscopes do not have a floating ground, and connecting oscilloscope ground (ie mains ground) to the test circuit's 5V rail does cause it to shut down instantly. I can easily imagine that it'd cause permanent damage in a less robust circuit.

 

When you say the I/O voltage of each board was set to 1.8V (later 2.5V) - how are you setting that? I just ask because I've seen a lot of people here just set the IOSTANDARD to (for example) LVCMOS18 and assume that this will produce a 1.8V output (it won't, unless VCCO is set to 1.8V).

Visitor jsli
Visitor
476 Views
Registered: ‎08-14-2019

Re: MicroZed Board IO issue

Hi, u4223374 , thanks for reply!

were the board grounds connected to the oscilloscope ground? Was the oscilloscope's ground lead really connected to a ground?

There is an auxiliary ground wire with every probe, and we did connected it to board's ground. The oscilloscope and the borad's power cable were all connected to the same extension cord. I'm not sure if this is really connected to a ground(earth ground). At least, we made our experiments like this in the past and the results looked fine. We had other experiments that two S2C platform connected together with many Dupont wires and probed those wires even boards were powered on. The platforms worked great and nothing happend. The weirdest thing in the second case was that we powered on proFPGA and MicroZed boards after connected all the wires. After that, we only used iLA to check waveform. Nothing ever approached or contacted those platforms. But the proFPGA still damaged with unknown reasons. so we doubt if there is any special design of MicroZed's IO circuit or any special consideration when we need to connect two different platform?

When you say the I/O voltage of each board was set to 1.8V (later 2.5V) - how are you setting that?

We set the I/O voltage by selecting jumpers on those boards. We checked those I/O voltage by oscilloscope or multimeter before any new expirement. In the first case, the IOSTANDARD were set to LVCMOS18 and the second case were set to LVDS_25. we pretty sure that voltage setting were correct. Is there any other detail we might miss or lack of consideration?

Thanks!

0 Kudos
Scholar u4223374
Scholar
457 Views
Registered: ‎04-26-2015

Re: MicroZed Board IO issue

Well, that sounds like you've done everything right. Having it all on the same extension lead ensures that you definitely won't be using two different non-floating grounds; worst-case would be that one or both boards has a floating ground (if its using an isolated power supply), and they'll both be grounded by the oscilloscope.

 

The MicroZed doesn't really have "I/O design". The I/O pins are just connected straight to the Zynq pins, with nothing but copper tracks in between and no protection. This is normal for FPGA development boards, because any sort of protection would most likely cause problems for at least a few of the FPGA's many I/O standards.

 

All I can think of is to put a 1K resistor on each line between the boards (often a wise idea for buses that have push-pull drivers at both ends, just in case both decide to output data at the same time) - but that's not practical for LVDS and it doesn't explain why the original problem occurred.

0 Kudos
Scholar drjohnsmith
Scholar
418 Views
Registered: ‎07-09-2009

Re: MicroZed Board IO issue

A interesting one, would love to be there, as remote is difficult to debug.

Thoughts, and thats all they are.

The microzed, when powered down, the FPGA et all will still be drawing power, so will discharge the power quickly.

You are changing the IO voltage , you are doing different builds of the code for each ?

I had a fun one a few years ago, cables between boards, 50 MHz signal, 3v3 driver, the signal at the receiver end was getting up to 12 volts plus, average life of the receiver board was a few hours, and during that time it deteriorate ,

could it be the proFPGA board ? during configuration the IO are different to during run time, that can cause problems,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Visitor jsli
Visitor
323 Views
Registered: ‎08-14-2019

Re: MicroZed Board IO issue

The MicroZed doesn't really have "I/O design". The I/O pins are just connected straight to the Zynq pins, with nothing but copper tracks in between and no protection. This is normal for FPGA development boards, because any sort of protection would most likely cause problems for at least a few of the FPGA's many I/O standards.

Yes, I agree. What I mean "I/O design" are not pin connector or tracks on the PCB board. But the I/O circuitry (protection circuit or something else...) inside the FPGA. In fact, I believed those circuit are well-designed and verified. And to connect two FPGA boards are pretty common application. But we're just concerning the entire circuit structure or behavior is not as easy as what we think after connecting two different boards.

We made an experiment which put both SPI TX and RX in the same FPGA. For example, if running in dual mode, the data bus IO0 will act as output during TX is sending instrucion,address,data to RX. Then it will change output to input for receiving data from RX. There are some dummy clocks before RX to send data in order to let I/O change their state. When experiment on S2C platform, if the last transfer bit of TX is a "1", we will see damping on IO0 during I/O changing its state in a short period( 3~5 SPI clock). It means that IO0 is discharging very quickly to a voltage level of logic "0". But when experiment on MicroZed, the discharging rate is very very slow. Even after thousands of dummy clocks(we can program length of dummy clocks), we cannot see the voltage level approach logic"0". That's why we doubt the MicroZed board has no good discharge path, so that residual charge on the wire ran into other platform.

All I can think of is to put a 1K resistor on each line between the boards (often a wise idea for buses that have push-pull drivers at both ends, just in case both decide to output data at the same time) - but that's not practical for LVDS and it doesn't explain why the original problem occurred.

We indeed put some resistors between the boards afterwards in the first design. But as you said, it's not practical for the second case. Anyway, You provided lots of practical suggestions. We do appreciate that!

0 Kudos
Visitor jsli
Visitor
306 Views
Registered: ‎08-14-2019

Re: MicroZed Board IO issue

A interesting one, would love to be there, as remote is difficult to debug.

Thoughts, and thats all they are.

The microzed, when powered down, the FPGA et all will still be drawing power, so will discharge the power quickly.

Below is what I reply to u4223374's post.

We made an experiment which put both SPI TX and RX in the same FPGA. For example, if running in dual mode, the data bus IO0 will act as output during TX is sending instrucion,address,data to RX. Then it will change output to input for receiving data from RX. There are some dummy clocks before RX to send data in order to let I/O change their state. When experiment on S2C platform, if the last transfer bit of TX is a "1", we will see damping on IO0 during I/O changing its state in a short period( 3~5 SPI clock). It means that IO0 is discharging very quickly to a voltage level of logic "0". But when experiment on MicroZed, the discharging rate is very very slow. Even after thousands of dummy clocks(we can program length of dummy clocks), we cannot see the voltage level approach logic"0". That's why we doubt the MicroZed board has no good discharge path, so that residual charge on the wire ran into other platform.

Is it the case when powered down both FPGA platforms, all of the current run into other platform instead of MicroZed...

You are changing the IO voltage , you are doing different builds of the code for each ?

Sorry, I'm not understand what you mean here. Could you describe more in detail?

I had a fun one a few years ago, cables between boards, 50 MHz signal, 3v3 driver, the signal at the receiver end was getting up to 12 volts plus, average life of the receiver board was a few hours, and during that time it deteriorate ,

Maybe this is the similar situation we encounterd! Only extremely high voltage or current could damage I/O or even FPGA core circuit. Did you find the root cause finally?

could it be the proFPGA board ? during configuration the IO are different to during run time, that can cause problems,

Maybe we have to probe those leads to find out what's going on during run time. But we're afraid of damaing the platform again...

0 Kudos
Scholar drjohnsmith
Scholar
287 Views
Registered: ‎07-09-2009

Re: MicroZed Board IO issue

the cause of the high voltage was the wiring, inductance / capacitance

It can damage IO, but if your core is dead, then its unlikely to be this,

yep you need to probe both boards,

re the IO voltage, If I remeber, you indicated you changed the IO voltage on the FPGA without changing the FPGA file .

The IO voltage and drive strengths are part of the fpga build,
I don't know if you can just change the IO voltage without a new bit file being loaded.

re the IO, if the FPGA is powered, you have things like built in pull ups and bus hold circuits to consider.

I assume your using the PS SPI, do you know that the driver puts the pin to Z when its finished.
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Visitor jsli
Visitor
254 Views
Registered: ‎08-14-2019

Re: MicroZed Board IO issue

Yes, we might neglect this point. The RLC of the transmission line , the impedance mismatch and the reflection of the signals. Because the operating frequency all over 50MHz in both case. Maybe the reflected energy keep adding to original signal at some operating frequency. Since the energy accumulate over some threshold, the I/O protection circuit breakdown. Is it correct?

re the IO voltage, If I remeber, you indicated you changed the IO voltage on the FPGA without changing the FPGA file .

The IO voltage and drive strengths are part of the fpga build,
I don't know if you can just change the IO voltage without a new bit file being loaded.

No, I changed the I/O voltage and .xdc file simultaneously in each design. This would not be the problem.

re the IO, if the FPGA is powered, you have things like built in pull ups and bus hold circuits to consider.

I assume your using the PS SPI, do you know that the driver puts the pin to Z when its finished.

Yes, the bi-direction signals were all set to tri-state I/O. The I/O would be "0" or "1" when act as output and high Z when act as input.

Maybe we will analyze toward the RLC of the transmission line ( PCB track + Dupont wire + pin connector) issue next. Thanks for your suggestions !

0 Kudos
Scholar drjohnsmith
Scholar
244 Views
Registered: ‎07-09-2009

Re: MicroZed Board IO issue

Have you looked at the spec for the PSI block your using,

    does it include bus hold or the PFGA built in pull ups ?

 

your correct about the explanation of the over volts I described, edge speeds and the cable / board RLC all worked against us.

Check if any over volts protectoin you have is constant or degrades with 'multiple strikes'.

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos