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: 
Highlighted
Visitor kgelec
Visitor
5,908 Views
Registered: ‎06-01-2009

Spartan 3A +PCI 3.3V

Jump to solution

Hello,

 

I am trying to obtain communication via PCI Bus like in the XAPP1038 (spartan3 on Avnet board + ml410; both using plb46_pci core). I am using the ML510 and spartan 3AN on my custom board. Most of constraints for the Spartan3AN I took from the reference design in xapp1038 - however they differ in pin mapping. Signals from the ML510 PCI 3.3V slot are directly connected to the Spartan 3AN pins.

 

The problem is when some transactions occur on the PCI bus the Spartan3AN rapidly become very hot.

I suspected signal confilict on the bus, however:

 

- I run pci_hello reference design on ml510 which sequentially checks config regs in: core itself, SouthBridge, TI 3.3V->5VBridge and all PCI slots, including PCI 3.3V Slot 5 where the board with spartan3AN is placed. 

- During this test the southbridge and the TI 3.3/5V bridge respond properly (data readout from their config regs look familiar), but the Spartan rapidly become very hot, and it seems to not respond at all.

 

- I checked connections among signals on the slot and fpga - are ok. For example when AD bus is declared as an input and it is used for ILA debugging (and other IO signals on PCI bus are disabled), everything is working well: the fpga does not become hot and I can observe PCI bus transactions.

 

Thus, I am not sure if signal conflict is the real problem source.

 

Any suggestions how to solve this problem would be very appreciated. BTW: plbv46_pci ip core is in early access for Spartan3A architecture, is this can be a reason of such behaviour??

 

Best,

Kamil

 

 

Message Edited by kgelec on 03-04-2010 05:20 AM
Message Edited by kgelec on 03-04-2010 05:22 AM
Message Edited by kgelec on 03-04-2010 05:33 AM
Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Visitor kgelec
Visitor
7,398 Views
Registered: ‎06-01-2009

Re: Spartan 3A +PCI 3.3V

Jump to solution

Hello again,

 

Problem has been succesfully solved. The source of the problem was #GNT signal in PCI core, which was physically unconnected. During design I decided that the board will work only as a PCI slave and left these lines unconnected from edge connector, however these nodes were declared in the ucf file and furthermore connected to the ports in edk (I still don't know how). Unfortunatelly unconnected #GNT and #REQ lines were assumed by synthesizer as logical "0"...thus PCI core behaved as master and during other master reqests on the bus FPGA became hot. Solution is to declare #GNT signal in the core as net_vcc and #REQ left unconnected.

 

I hope this trivial case will help other developers...

 

Best,

Kamil

 

 

0 Kudos
6 Replies
Scholar austin
Scholar
5,894 Views
Registered: ‎02-27-2008

Re: Spartan 3A +PCI 3.3V

Jump to solution

Kamil,

 

Did DONE go high?

 

Can you load a test pattern and show that the device is operational?

 

What clock rate is the PCI bus?

 

Have you run the power estimator to see what the power is when the design is running?  Perhaps it is normal?

 

"Hot"is not a very descriptive term:  how many degrees C is the case temperture?  Has it ever exceeded the absolute maximum ratings?  If so, the device is no longer under warranty, and may be destroyed.  One can assume that if the case is at 125C the junction may have reached 150C, for example.

 

Does the Spartan 3A device remain hot, if the PCI bus is not being used?

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor kgelec
Visitor
5,887 Views
Registered: ‎06-01-2009

Re: Spartan 3A +PCI 3.3V

Jump to solution
"Did DONE go high?"

 

Accordingly to led state and jtag information, Yes. Each time FPGA is powered up Microblaze contained in the project sends some startup information, so normally works.
"Can you load a test pattern and show that the device is operational?"
 According to above it seems to be operational. Additionally, after I change AD port from I/O to Input only I can observe PCI Bus transactions (pci core disabled and bus connected to ILA) so bank seems to be also operational.
"What clock rate is the PCI bus?"
33MHz
"Have you run the power estimator to see what the power is when the design is running?  Perhaps it is normal? "
No I did not. However temerature doesn't lookto normal - see below..
""Hot"is not a very descriptive term:  how many degrees C is the case temperture?  Has it ever exceeded the absolute maximum ratings?  If so, the device is no longer under warranty, and may be destroyed.  One can assume that if the case is at 125C the junction may have reached 150C, for example."
Yes, sorry. It is very rapid temperature increase to above 100C, measured on the case. Usually after I notice it I manually put FPGA into HiZ on all pins state (by loading empty bitstream). After that I can make same experiment with bus transaction debug as I described above. 

Does the Spartan 3A device remain hot, if the PCI bus is not being used?

 
No, It does not. Works normally. 
 
0 Kudos
Scholar austin
Scholar
5,880 Views
Registered: ‎02-27-2008

Re: Spartan 3A +PCI 3.3V

Jump to solution

Kamil,


Well, you are a lot further along, good.

 

First, how much power should it take?  I expect this to be reasonable (less than a watt or so).  The junction temperature indicated by the estimator will nopt be 100C or greater.

 

Second, What happens when the PCI bus is not connected to the other device (just load the PCI core in the 3A, clocks running)?

 

If everything should be OK, but it isn't, then contention is left (there isn't any other cause).  One has to then start debugging the PCI interface at the interface level, between the two devices.  Use of a scope to look at the tristate enable of device 1, and at the same time, on another channel, the tristate of device:2  are the drivers both enabled at the same time?  Why? (what other control signals tell you what the bus is doing/should be doing?)...

 

Oh, and I am presuming there is nothing else on this PCI bus.  If there is a master somewhere, then you need to look at its tristate enable (when it is, and isn't driving the bus) for a total of three channls on the scope.  I would also suggest you simplify this case back to only two PCI devices, and make that work first!

 

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor kgelec
Visitor
5,869 Views
Registered: ‎06-01-2009

Re: Spartan 3A +PCI 3.3V

Jump to solution

Austin,

 

First of all, thank You for Your fast response.

According to Your last suggestion there is only one master (pci core in V5 on ML510), and three slaves: SouthBridge, TI3.3/5V Bridge, and my custom board. Because I cannot get rid of other slaves I will also check if pci arbiter in V5 works fine. 

Now I need some time to perform all tests You mentioned.

 

Best regards, Kamil

0 Kudos
Scholar austin
Scholar
5,867 Views
Registered: ‎02-27-2008

Re: Spartan 3A +PCI 3.3V

Jump to solution

Kamil,

 

Good luck.  Let us know how it goes, and I will try to answer any questions you may have along the way (or find someone who can),

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor kgelec
Visitor
7,399 Views
Registered: ‎06-01-2009

Re: Spartan 3A +PCI 3.3V

Jump to solution

Hello again,

 

Problem has been succesfully solved. The source of the problem was #GNT signal in PCI core, which was physically unconnected. During design I decided that the board will work only as a PCI slave and left these lines unconnected from edge connector, however these nodes were declared in the ucf file and furthermore connected to the ports in edk (I still don't know how). Unfortunatelly unconnected #GNT and #REQ lines were assumed by synthesizer as logical "0"...thus PCI core behaved as master and during other master reqests on the bus FPGA became hot. Solution is to declare #GNT signal in the core as net_vcc and #REQ left unconnected.

 

I hope this trivial case will help other developers...

 

Best,

Kamil

 

 

0 Kudos