Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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
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
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
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.comArticle: 148929
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.comArticle: 148930
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? KJArticle: 148931
>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.comArticle: 148932
Can anyone have a sample vhdl code for Huffman text Encoder and Decoder pls? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148933
Does anyone have a sample vhdl code for Huffman text Encoder and Decoder pls? For static or dynamic Huffman ? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148934
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. RickArticle: 148935
"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
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
> 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
>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.comArticle: 148939
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
>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.comArticle: 148941
> 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
>> 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.comArticle: 148943
> 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
"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
>"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.comArticle: 148946
"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
>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.comArticle: 148948
"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
>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:
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