Question about OC PCI Cores

S

Sink0

Guest
Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores
and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc).


Any one here have any experience with one or both boards? Are they
different on performance? Are they reliable? I was looking on OpenCores
forum and a user was having a problem using PCI_Target on Windows. He had
success to use it on Linux (i will be using on Linux too). He was able to
use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is
too slow. PCI_Bridge looks so much complete, whay it would be slower? I was
unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is
Verilog, and i dont have much experience with VHDL (actualy very little).
So what would you guys sugest me? Any comment about both Cores?

Thank you!!

---------------------------------------
Posted through http://www.FPGARelated.com
 
I don't know for sure, but judging from the names, they do different
things. A bridge connects two PCI busses. A target should have PCI
on one side and a different bus on the other to connect to some device
or a function internal to the FPGA.

Which of these do you need?

One of the advantages of open cores is that you can root around in the
guts. Do you understand how they work? What software do you expect
to use with them? The speed issue may be in the software.

Rick
I will be using it on a Spartan-III FPGA. Well not exactly, PCI_Bridge is
bridge between PCI BUS and Wishbone Bus. But it does have a PCI Master an
PCI Slave module. The PCI Target is a bridge too but as i understood jus
have a PCI Slave (and a WB Master on the other hand of the bridge). Th
program and drivers are going to be made by me. I will be running o
Linux.

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sep 9, 11:56 am, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores
and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc).

Any one here have any experience with one or both boards? Are they
different on performance? Are they reliable? I was looking on OpenCores
forum and a user was having a problem using PCI_Target on Windows. He had
success to use it on Linux (i will be using on Linux too). He was able to
use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is
too slow. PCI_Bridge looks so much complete, whay it would be slower? I was
unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is
Verilog, and i dont have much experience with VHDL (actualy very little).
So what would you guys sugest me? Any comment about both Cores?

Thank you!!        

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
I don't know for sure, but judging from the names, they do different
things. A bridge connects two PCI busses. A target should have PCI
on one side and a different bus on the other to connect to some device
or a function internal to the FPGA.

Which of these do you need?

One of the advantages of open cores is that you can root around in the
guts. Do you understand how they work? What software do you expect
to use with them? The speed issue may be in the software.

Rick
 
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores
and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc).


Any one here have any experience with one or both boards? Are they
different on performance? Are they reliable? I was looking on OpenCores
forum and a user was having a problem using PCI_Target on Windows. He had
success to use it on Linux (i will be using on Linux too). He was able to
use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is
too slow. PCI_Bridge looks so much complete, whay it would be slower? I was
unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is
Verilog, and i dont have much experience with VHDL (actualy very little).
So what would you guys sugest me? Any comment about both Cores?
AFAIK the timing constraints may be the biggest issue besides whether
the core works correct. You should be okay if you make sure the input
and output flipflops are inside the IOBs. You can force the latter
with timing constraints and check it using the floorplanner on the
routed design.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Sep 9, 2:26 pm, n...@puntnl.niks (Nico Coesel) wrote:
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores
and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc).

Any one here have any experience with one or both boards? Are they
different on performance? Are they reliable? I was looking on OpenCores
forum and a user was having a problem using PCI_Target on Windows. He had
success to use it on Linux (i will be using on Linux too). He was able to
use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is
too slow. PCI_Bridge looks so much complete, whay it would be slower? I was
unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is
Verilog, and i dont have much experience with VHDL (actualy very little)..
So what would you guys sugest me? Any comment about both Cores?

AFAIK the timing constraints may be the biggest issue besides whether
the core works correct. You should be okay if you make sure the input
and output flipflops are inside the IOBs. You can force the latter
with timing constraints and check it using the floorplanner on the
routed design.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
I read a post by someone, likely in this group, about the core they
wrote which was able to clock at 66 MHz while the Xilinx core could
only clock at a little over 33 MHz and needed some careful integration
to do that. Anyone remember that post? I think he may have been
discussing his core with Xilinx, I assume because they wanted to
license it.

Rick
 
AFAIK the timing constraints may be the biggest issue besides whether
the core works correct. You should be okay if you make sure the input
and output flipflops are inside the IOBs. You can force the latter
with timing constraints and check it using the floorplanner on the
routed design.

The problem with the PCI interface is that you can't run all the IOs
synchronously. From memory FRAME, TRDY, IRDY and STOP have to be
treated combinatorially at the top level.


Nial.
 
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
wrote:

AFAIK the timing constraints may be the biggest issue besides whether
the core works correct. You should be okay if you make sure the input
and output flipflops are inside the IOBs. You can force the latter
with timing constraints and check it using the floorplanner on the
routed design.


The problem with the PCI interface is that you can't run all the IOs
synchronously. From memory FRAME, TRDY, IRDY and STOP have to be
treated combinatorially at the top level.
Good question. It shouldn't be difficult to get it properly
constrained. IIRC the Xilinx core also has a bunch of location and
timing constraints to match the PCI specs (which aren't FPGA friendly)
exactly. But my experience with PCI from and FPGA is with Spartan 2
devices.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Sep 10, 4:01 pm, n...@puntnl.niks (Nico Coesel) wrote:
"Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk
wrote:

AFAIK the timing constraints may be the biggest issue besides whether
the core works correct. You should be okay if you make sure the input
and output flipflops are inside the IOBs. You can force the latter
with timing constraints and check it using the floorplanner on the
routed design.

The problem with the PCI interface is that you can't run all the IOs
synchronously. From memory FRAME, TRDY, IRDY and STOP have to be
treated combinatorially at the top level.

Good question. It shouldn't be difficult to get it properly
constrained. IIRC the Xilinx core also has a bunch of location and
timing constraints to match the PCI specs (which aren't FPGA friendly)
exactly. But my experience with PCI from and FPGA is with Spartan 2
devices.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Xilinx cores make use of special features of certain pins on the
device with names
like IRDY and TRDY that have some built-in logic to speed up the
combinatorial
PCI requirements. I don't think the synthesis tools support these
functions
directly. However the FPGA's have been getting faster, so you may not
need
the extra stunt hardware to meet PCI timing anymore.
 
Gabor <gabor@alacron.com> wrote:
directly. However the FPGA's have been getting faster, so you may not
need
the extra stunt hardware to meet PCI timing anymore.
Clock to output is longer on Spartan-6 than on Spartan-3

Please correct me if I am wrong...
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
 
Very useful information guys. Thank you, but considering that both core
con work with burst mode and that they are pci complient, so they must b
able to work at 33Mhz, is there any reason for the speed difference? I a
using a Spartan III with Quickswiths for the board. More specificall
Raggedstone I board made by Enterpoint.

Thank you!

---------------------------------------
Posted through http://www.FPGARelated.com
 
Hmm really nice information. Thank you guys. But at both cores spec the
say they can run at burst mode and both are PCI complient so they ar
suposed to be able to run at 33Mhz. Assuming that why they would b
different on speed. I am using a Enterpoint Raggedstone 1 Board (Sparta
III).

Thank you!

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sep 11, 1:18 pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
but considering that both cores
con work with burst mode and that they are pci complient, so they must be
able to work ...
If you really believe this, then why are you asking for confirmation
that they work for others?

KJ
 
On Sep 11, 1:18=A0pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com
wrote:
but considering that both cores
con work with burst mode and that they are pci complient, so they mus
be
able to work ...

If you really believe this, then why are you asking for confirmation
that they work for others?

KJ
Well thats my opinion but i can be wrong. I cant say thats true. And mayb
there are other issues as instabilities and reliability that can affect th
communication. Thats why i asked opinions.

Thank you

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sep 11, 1:18 pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
Very useful information guys. Thank you, but considering that both cores
con work with burst mode and that they are pci complient, so they must be
able to work at 33Mhz, is there any reason for the speed difference? I am
using a Spartan III with Quickswiths for the board. More specificallt
Raggedstone I board made by Enterpoint.
Some PCI installations run at 66 MHz.

Rick
 
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in message
news:EOOdnZUI7IRlJBbRnZ2dnUVZ_rydnZ2d@giganews.com...
Very useful information guys. Thank you, but considering that both cores
con work with burst mode and that they are pci complient, so they must be
able to work at 33Mhz,

Being able to handle burst mode doesn't have any affect on the clock
speed the core will run at, you have to resolve the combinatorial signals
in the same period if you're driving a single cycle or bursting.


Nial.
 
I have used the pci32lite in a Spartan 3. What I found was that:

(1) I couldn't get it to do burst reads, because surprisingly, the PC
doesn't do burst reads. At least that was the conclusion I came to
after googling to find out why my linux driver was breaking up burst
requests into individual transactions. If you want to do burst reads,
you need master functionality in the PCI IP. Also, iirc, pci32lite
documentation indicated that it "supports" burst mode by signaling to
the host system that bursts need to be broken into individually
transactions.
AFAIK no x86 based machines will drive burst accesses to plug in
cards.

As you found out the only way to get burst functionality to or
from a plug in PCI card is if it drives it.


Nial.
 
I have used the pci32lite in a Spartan 3. What I found was that:

(1) I couldn't get it to do burst reads, because surprisingly, the PC
doesn't do burst reads. At least that was the conclusion I came to
after googling to find out why my linux driver was breaking up burst
requests into individual transactions. If you want to do burst reads,
you need master functionality in the PCI IP. Also, iirc, pci32lite
documentation indicated that it "supports" burst mode by signaling to
the host system that bursts need to be broken into individually
transactions.

(2) I couldn't get it to pass timing constraints, it was failing by
about 2ns, but it didn't seem to matter, I tried the card in several
systems and it worked in all of them.
Hmm, you have used it. can you give me some help please? I can't understant
some points of documentations. I am planing on use it with a 32 bits WB.
But i could not understand the bytes lane table at implementation section.
Which was the max speed with PCI32lite you could achive? Which driver you
are using? I will run my card on a linux system too. But was you able to
perform burst writes?

Thank you!!

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sep 12, 1:01 am, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
On Sep 11, 1:18=A0pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com
wrote:
but considering that both cores
con work with burst mode and that they are pci complient, so they must
be
able to work ...

If you really believe this, then why are you asking for confirmation
that they work for others?

KJ

Well thats my opinion but i can be wrong. I cant say thats true. And maybe
there are other issues as instabilities and reliability that can affect the
communication. Thats why i asked opinions.

Thank you          

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
I have used the pci32lite in a Spartan 3. What I found was that:

(1) I couldn't get it to do burst reads, because surprisingly, the PC
doesn't do burst reads. At least that was the conclusion I came to
after googling to find out why my linux driver was breaking up burst
requests into individual transactions. If you want to do burst reads,
you need master functionality in the PCI IP. Also, iirc, pci32lite
documentation indicated that it "supports" burst mode by signaling to
the host system that bursts need to be broken into individually
transactions.

(2) I couldn't get it to pass timing constraints, it was failing by
about 2ns, but it didn't seem to matter, I tried the card in several
systems and it worked in all of them.
 
On Sep 13, 7:02=A0pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com
wrote:
Hmm, you have used it. can you give me some help please? I can'
understa=
nt
some points of documentations. I am planing on use it with a 32 bit
WB.
But i could not understand the =A0bytes lane table at implementatio
sect=
ion.

Unfortunately I don't have the VHDL code in front of me to remind me
of exactly how I connected up the wishbone side, but for me I was
using 32-bit registers, and for that using the core was pretty
straightforward.

Which was the max speed with PCI32lite you could achive?

I was getting a little over a cycle a micro second iirc. So that's a
little over 4MB/s.

Which driver you
are using? I will run my card on a linux system too.

I wrote my own driver from scratch.

But was you able to
perform burst writes?

I didn't need burst writes and so didn't try. But I don't think you
will be able to do that with the pci32lite core - it's pretty basic,
fine for simple reading/writing to registers but not suitable for
higher performance data transfer. For that Master functionality is
needed.

Hmm 4MB/s is very slow for PCI. Can you send me your driver file? I go
something i made folloiwng LDD third editions but i got some doubts. I a
not going to use yours, just see how you did it if possible. My e-mail i
sink00 at gmail dot com. Thank you for all your information. Thats helpe
a lot!!

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Sep 13, 7:02 pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
Hmm, you have used it. can you give me some help please? I can't understant
some points of documentations. I am planing on use it with a 32 bits WB.
But i could not understand the  bytes lane table at implementation section.
Unfortunately I don't have the VHDL code in front of me to remind me
of exactly how I connected up the wishbone side, but for me I was
using 32-bit registers, and for that using the core was pretty
straightforward.

Which was the max speed with PCI32lite you could achive?
I was getting a little over a cycle a micro second iirc. So that's a
little over 4MB/s.

Which driver you
are using? I will run my card on a linux system too.
I wrote my own driver from scratch.

But was you able to
perform burst writes?
I didn't need burst writes and so didn't try. But I don't think you
will be able to do that with the pci32lite core - it's pretty basic,
fine for simple reading/writing to registers but not suitable for
higher performance data transfer. For that Master functionality is
needed.
 

Welcome to EDABoard.com

Sponsor

Back
Top