Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 148925

Article: 148925
Subject: Re: Question about OC PCI Cores
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 10 Sep 2010 20:01:12 GMT
Links: << >>  << T >>  << A >>
"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=.)
--------------------------------------------------------------

Article: 148926
Subject: Re: Question about OC PCI Cores
From: Gabor <gabor@alacron.com>
Date: Fri, 10 Sep 2010 13:49:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 4:01=A0pm, 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=3D.)
> --------------------------------------------------------------

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.

Article: 148927
Subject: Re: Question about OC PCI Cores
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 11 Sep 2010 11:56:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
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 ----------

Article: 148928
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sat, 11 Sep 2010 12:18:48 -0500
Links: << >>  << T >>  << A >>
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.

Thank you!	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148929
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sat, 11 Sep 2010 12:57:36 -0500
Links: << >>  << T >>  << A >>
Hmm really nice information. Thank you guys. But at both cores spec they
say they can run at burst mode and both are PCI complient so they are
suposed to be able to run at 33Mhz. Assuming that why they would be
different on speed. I am using a Enterpoint Raggedstone 1 Board (Spartan
III).

Thank you!	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148930
Subject: Re: Question about OC PCI Cores
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 11 Sep 2010 17:02:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 148931
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 12 Sep 2010 00:01:56 -0500
Links: << >>  << T >>  << A >>
>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 through http://www.FPGARelated.com

Article: 148932
Subject: Re: Text compression Huffman Encoder and Decoder
From: "kude" <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 12 Sep 2010 02:43:46 -0500
Links: << >>  << T >>  << A >>
Can anyone have a sample vhdl code for Huffman text Encoder and Decoder
pls?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148933
Subject: Re: Text compression Huffman Encoder and Decoder
From: "kude" <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 12 Sep 2010 02:47:50 -0500
Links: << >>  << T >>  << A >>
Does anyone have a sample vhdl code for Huffman text Encoder and Decoder
pls? For static or dynamic Huffman ? 	   
					
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148934
Subject: Re: Question about OC PCI Cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 12 Sep 2010 22:01:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 11, 1:18=A0pm, "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

Article: 148935
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 13 Sep 2010 10:16:16 +0100
Links: << >>  << T >>  << A >>
"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. 



Article: 148936
Subject: Re: Question about OC PCI Cores
From: Paul <pault.eg@googlemail.com>
Date: Mon, 13 Sep 2010 09:17:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 12, 1:01=A0am, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
wrote:
> >On Sep 11, 1:18=3DA0pm, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.co=
m>
> >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 mayb=
e
> there are other issues as instabilities and reliability that can affect t=
he
> communication. Thats why i asked opinions.
>
> Thank you =A0 =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> 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.


Article: 148937
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 13 Sep 2010 17:30:18 +0100
Links: << >>  << T >>  << A >>
> 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. 



Article: 148938
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 13 Sep 2010 13:02:07 -0500
Links: << >>  << T >>  << A >>

>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

Article: 148939
Subject: Re: Question about OC PCI Cores
From: Paul <pault.eg@googlemail.com>
Date: Mon, 13 Sep 2010 12:36:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
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't understa=
nt
> some points of documentations. I am planing on use it with a 32 bits WB.
> But i could not understand the =A0bytes lane table at implementation 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.

Article: 148940
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 13 Sep 2010 16:07:51 -0500
Links: << >>  << T >>  << A >>
>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't
understa=
>nt
>> some points of documentations. I am planing on use it with a 32 bits
WB.
>> But i could not understand the =A0bytes lane table at implementation
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 got
something i made folloiwng LDD third editions but i got some doubts. I am
not going to use yours, just see how you did it if possible. My e-mail is
sink00 at gmail dot com.  Thank you for all your information. Thats helped
a lot!!	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148941
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Tue, 14 Sep 2010 09:58:39 +0100
Links: << >>  << T >>  << A >>
> Hmm 4MB/s is very slow for PCI.


As above (/below) it's reasonable target performance, no x86 system
allows you to burst to a target card (seems ridiculous but is the case).

If you want better PCI performance you have to have master functionality
on your plug in card.

Maximum performance depends you your PC architecture and what else is
plugged into your PCI bus. I believe that 60-70 MB/s is considered
a reasonable result for real world systems.


Nial. 



Article: 148942
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 14 Sep 2010 07:11:35 -0500
Links: << >>  << T >>  << A >>
>> Hmm 4MB/s is very slow for PCI.
>
>
>As above (/below) it's reasonable target performance, no x86 system
>allows you to burst to a target card (seems ridiculous but is the case).
>
>If you want better PCI performance you have to have master functionality
>on your plug in card.
>
>Maximum performance depends you your PC architecture and what else is
>plugged into your PCI bus. I believe that 60-70 MB/s is considered
>a reasonable result for real world systems.
>
>
>Nial. 
>

Hmm 60-70 MB/s would be a very reasonable speed. I would be happy with
40-50MB/s. DO you mean. to achive that speed i would have to use the PCI
master of my PCI card to read and write data from/to the x86 or send data
from the x86 to the card with the PC as a master and send data from the PCI
board to the x86 with the PCI board as a master? I am just curious, whats
speed is achivable with a x1 PCI express bus? Any idea?

Thank you	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148943
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Tue, 14 Sep 2010 13:57:09 +0100
Links: << >>  << T >>  << A >>
> Hmm 60-70 MB/s would be a very reasonable speed. I would be happy with
> 40-50MB/s. DO you mean. to achive that speed i would have to use the PCI
> master of my PCI card to read and write data from/to the x86 or send data
> from the x86 to the card with the PC as a master and send data from the PCI
> board to the x86 with the PCI board as a master?

No, all transactions have to me mastered by the plug in card.


Nial. 



Article: 148944
Subject: Re: Question about OC PCI Cores
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 14 Sep 2010 16:37:22 GMT
Links: << >>  << T >>  << A >>
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

>>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't
>understa=
>>nt
>>> some points of documentations. I am planing on use it with a 32 bits
>WB.
>>> But i could not understand the =A0bytes lane table at implementation
>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 got

Actually it is not. Like others pointed out: most x86 can't initiate
burst mode. The PCI card has to initiate burst mode. If the card
cannot do that you'll see the PCI bus has a lot of overhead for single
32bit transfers.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 148945
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 14 Sep 2010 13:05:52 -0500
Links: << >>  << T >>  << A >>
>"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
>
>>>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't
>>understa=
>>>nt
>>>> some points of documentations. I am planing on use it with a 32 bits
>>WB.
>>>> But i could not understand the =A0bytes lane table at implementation
>>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 got
>
>Actually it is not. Like others pointed out: most x86 can't initiate
>burst mode. The PCI card has to initiate burst mode. If the card
>cannot do that you'll see the PCI bus has a lot of overhead for single
>32bit transfers.
>
>-- 
>Failure does not prove something is impossible, failure simply
>indicates you are not using the right tools...
>nico@nctdevpuntnl (punt=.)


Hmm but if initiate burst with my card, will x86 be able to handle it or i
need to make use DMA? And what would be the benefit of using PCI instead of
USB2.0? If i use a chip like PLX PCI 9030 will i be able to achive high
speed at PCI bus? 

Thank you!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148946
Subject: Re: Question about OC PCI Cores
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 14 Sep 2010 19:26:55 GMT
Links: << >>  << T >>  << A >>
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

>>"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
>>
>>>>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't
>>>understa=
>>>>nt
>>>>> some points of documentations. I am planing on use it with a 32 bits
>>>WB.
>>>>> But i could not understand the =A0bytes lane table at implementation
>>>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 got
>>
>>Actually it is not. Like others pointed out: most x86 can't initiate
>>burst mode. The PCI card has to initiate burst mode. If the card
>>cannot do that you'll see the PCI bus has a lot of overhead for single
>>32bit transfers.
>>
>
>Hmm but if initiate burst with my card, will x86 be able to handle it or i
>need to make use DMA? And what would be the benefit of using PCI instead of
>USB2.0? If i use a chip like PLX PCI 9030 will i be able to achive high
>speed at PCI bus? 

DMA is something you should forget when talking about PCI. PCI is
about pushing or pulling blocks of data between a master and a slave.
For some reason a PC cannot pull a block of data from a PCI card so
the PCI card needs to be capable of becoming a master and push data
into the PC's memory.

The driver needs to allocate a piece of fixed non-swappable memory and
get the physical address from the OS. The driver sets this address and
the number of bytes to transfer in the PCI card's registers. After
this, the PCI card can write (push) the data into the PC's memory.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 148947
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 14 Sep 2010 16:12:42 -0500
Links: << >>  << T >>  << A >>

>DMA is something you should forget when talking about PCI. PCI is
>about pushing or pulling blocks of data between a master and a slave.
>For some reason a PC cannot pull a block of data from a PCI card so
>the PCI card needs to be capable of becoming a master and push data
>into the PC's memory.
>
>The driver needs to allocate a piece of fixed non-swappable memory and
>get the physical address from the OS. The driver sets this address and
>the number of bytes to transfer in the PCI card's registers. After
>this, the PCI card can write (push) the data into the PC's memory.
>
>-- 
>Failure does not prove something is impossible, failure simply
>indicates you are not using the right tools...
>nico@nctdevpuntnl (punt=.)
>--------------------------------------------------------------
>

That was a very useful piece of information. But explain me something. Let
supose a situation. PC write data to PCI card. After a while PCI card
become master of the bus and send a burst of data to PC. Lets say we are
using Linux OS. TO send and read data to/from the PCI card its
straigtfoward using the functions read and write memory. But considering
the PCI card as a master, how am i going to read that data at the PC side?
With the same read memory function does not seens the most intuitive answer
becouse i supose the read memory function would be associated to a PCI
transaction with a CBE pins pattern. 

Thank you!!!	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148948
Subject: Re: Question about OC PCI Cores
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 14 Sep 2010 21:42:57 GMT
Links: << >>  << T >>  << A >>
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

>
>>DMA is something you should forget when talking about PCI. PCI is
>>about pushing or pulling blocks of data between a master and a slave.
>>For some reason a PC cannot pull a block of data from a PCI card so
>>the PCI card needs to be capable of becoming a master and push data
>>into the PC's memory.
>>
>>The driver needs to allocate a piece of fixed non-swappable memory and
>>get the physical address from the OS. The driver sets this address and
>>the number of bytes to transfer in the PCI card's registers. After
>>this, the PCI card can write (push) the data into the PC's memory.
>>
>>-- 
>>Failure does not prove something is impossible, failure simply
>>indicates you are not using the right tools...
>>nico@nctdevpuntnl (punt=.)
>>--------------------------------------------------------------
>>
>
>That was a very useful piece of information. But explain me something. Let
>supose a situation. PC write data to PCI card. After a while PCI card
>become master of the bus and send a burst of data to PC. Lets say we are
>using Linux OS. TO send and read data to/from the PCI card its
>straigtfoward using the functions read and write memory. But considering
>the PCI card as a master, how am i going to read that data at the PC side?
>With the same read memory function does not seens the most intuitive answer
>becouse i supose the read memory function would be associated to a PCI
>transaction with a CBE pins pattern. 

The PCI card is supposed to generate an interrupt when the transfer is
finished. The driver which handles the interrupts knows that all the
data is written in the buffer and can start processing the data.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 148949
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 14 Sep 2010 17:02:30 -0500
Links: << >>  << T >>  << A >>

>The PCI card is supposed to generate an interrupt when the transfer is
>finished. The driver which handles the interrupts knows that all the
>data is written in the buffer and can start processing the data.
>
>-- 
>Failure does not prove something is impossible, failure simply
>indicates you are not using the right tools...
>nico@nctdevpuntnl (punt=.)
>--------------------------------------------------------------
>

Thank you very much. You are helping a lot!!. I am designing the driver
following the Linux Device Driver book and an driver i found at Open Cores.
Do you have any other good reference for that kind of information? Have you
ever worked with PCI design?

Thank you!!	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search