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
Antti wrote: > > 1) I entered the clock figures in FIFO16 implementationm, but the > error also happens with BRAM based FIFO that do not need workarounds > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write, > one is PLB clock 62.5MHz read > 3) Power OK? Well the problem happens at 2 different sites, hm yes it > could be still be power problem > > 4) My office is not of Cobalt 60, ... and its cold here too > > Antti > Whoops, looks like this link didn't make it with my post, sorry. http://www.xilinx.com/support/answers/22462.htm But you've read that already of course. Does temperature make any difference to its operation? Syms.Article: 144626
Antti I have an async fifo that I can give you but it is in Verilog as I dont use VHDL. Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.com From prenom.nom@gmail.com Mon Dec 21 04:48:08 2009 Path: unlimited.newshosting.com!s03-b20.iad!npeersf02.iad.highwinds-media.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp20-1.free.fr!not-for-mail Date: Mon, 21 Dec 2009 13:48:08 +0100 From: Matthieu Michon <prenom.nom@gmail.com> Newsgroups: comp.arch.fpga Subject: Re: Please help, Xilinx FIFO problem! Message-Id: <20091221134808.d9e880fe.prenom.nom@gmail.com> References: <635ecee2-85b2-4d28-ac9a-a29d76b2ff05@k19g2000yqc.googlegroups.com> <yY6dncX6fIpb1bLWnZ2dnUVZ_qudnZ2d@giganews.com> <7aa7e326-6fc7-45db-88b8-cd85cd0be2c6@m38g2000yqd.googlegroups.com> <682dnWft4P1S07LWnZ2dnUVZ_r2dnZ2d@giganews.com> <15e59a60-0b21-4579-abdd-e78d11fbb707@k17g2000yqh.googlegroups.com> <f5ednXDidICzwbLWnZ2dnUVZ_u-dnZ2d@giganews.com> <9bfecb62-8e74-4a9a-869d-6d27094b837c@s31g2000yqs.googlegroups.com> X-Newsreader: Sylpheed 2.7.1 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 4 Organization: Guest of ProXad - France NNTP-Posting-Date: 21 Dec 2009 13:48:30 MET NNTP-Posting-Host: 213.215.9.6 X-Trace: 1261399710 news-2.free.fr 24600 213.215.9.6:52092 X-Complaints-To: abuse@proxad.net Xref: unlimited.newshosting.com comp.arch.fpga:96235 X-Received-Date: Mon, 21 Dec 2009 05:49:31 MST (s03-b20.iad) Hi Antti You may want to check the sources of the async FIFOs included in the FSL IP core (inside the EDK HW IP folder).Article: 144627
Also I dont want any money. It's not like I am giving you a USB 3.0 core :) Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144628
Hi, Ghostboy wrote: > Thanks > But what if I need to buffer a frame with a resolution of 1024*768 and it > will constantly be updated? You seem to mistake latency, access time and bandwidth. Video streams are fairly stable, so latency issues can easily be "masked", "shadowed", pipelined... given some FIFOs here and there for example. now, the speed is another issue but it can easily be overcome, just do the math and read the datasheets. 1024*768*3 (assuming 888 RGB) = 2.3MB If you need double buffering (if you can't exploit some smart-ass pointer techniques) then the requirement is 5M bytes. With a kit that has 8MB of RAM, you're fairly safe. now, the bandwidth : let's say you need to read and write the whole buffer for every frame, 30 times per second : 2.3MB*2*30 = 141MB/s that's more than what a PCI bus can handle but given a 32-bit wide bus, it is reduced to 35MHz speed. Account for refresh cycles, bus turnaround cycles, blanking times, inefficient packing of the RGB components (0RGB aligned to 32-bit boundaries) and other stuff, so you need around 60MHz. Most decent and recent kits should do this out of the box. Even this old board http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150398039709 (i'm not the seller) has 6MB of fast asynchronous SRAM nicely organised in 24-bit words, no byte is wasted with 32-bit alignment. it can store a bit more than 2 frames of 768Kpx. Access time is 33ns, so let's say it can work at pixel speeed (27 or 30MHz) with 96 bits each time : that's 360M Bytes per second. With no refresh cycle, no burst, no address multiplex and no DRAM bank to manage... OK I cheat : this board is obviously designed for video applications. And I have not checked the schematics. But if only I could make Altera's tool work on my computer... :-( Have fun, yg -- http://ygdes.com / http://yasep.orgArticle: 144629
Hi, Ghostboy wrote: > Thanks > But what if I need to buffer a frame with a resolution of 1024*768 and it > will constantly be updated? You seem to mistake latency, access time and bandwidth. Video streams are fairly stable, so latency issues can easily be "masked", "shadowed", pipelined... given some FIFOs here and there for example. now, the speed is another issue but it can easily be overcome, just do the math and read the datasheets. 1024*768*3 (assuming 888 RGB) = 2.3MB If you need double buffering (if you can't exploit some smart-ass pointer techniques) then the requirement is 5M bytes. With a kit that has 8MB of RAM, you're fairly safe. now, the bandwidth : let's say you need to read and write the whole buffer for every frame, 30 times per second : 2.3MB*2*30 = 141MB/s that's more than what a PCI bus can handle but given a 32-bit wide bus, it is reduced to 35MHz speed. Account for refresh cycles, bus turnaround cycles, blanking times, inefficient packing of the RGB components (0RGB aligned to 32-bit boundaries) and other stuff, so you need around 60MHz. Most decent and recent kits should do this out of the box. Even this old board http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150398039709 (i'm not the seller) has 6MB of fast asynchronous SRAM nicely organised in 24-bit words, no byte is wasted with 32-bit alignment. it can store a bit more than 2 frames of 768Kpx. Access time is 33ns, so let's say it can work at pixel speeed (27 or 30MHz) with 96 bits each time : that's 360M Bytes per second. With no refresh cycle, no burst, no address multiplex and no DRAM bank to manage... OK I cheat : this board is obviously designed for video applications. And I have not checked the schematics. But if only I could make Altera's tool work on my computer... :-( Have fun, yg -- http://ygdes.com / http://yasep.orgArticle: 144630
On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > >> Well once you have written and tested your own fifo then you would h= ave > > i=3D > > >t > > >> for any other project. It seems like you have wasted a lot of time > > alread=3D > > >y > > >> trying to fix the Xilinx version so I dont see that you have anythin= g > > to > > >> loose by creating your own. > > > >> Jon =3DA0 =3DA0 =3DA0 =3DA0 > > > >If you REALLY need todo something else, when your time is at absolute > > >premium > > >And if the system working (except occasional errors about 2 of fiber > > >packets are corrupt) > > >Then you do not go replacing Xilinx validated FIFO solutions with your > > >own, if there are other options. > > > >If 2 completly different FIFO implementations both have same error? > > >you think 3rd one would instantly work? Could be, yes. > > > >Antti > > > In my opinion people tend to use coregen far too often. Looking through > > some of Xilinx code it is awfull. I went down the route of writing my o= wn > > fifos not because I had a problem with Xilinx fifos but because I belie= ve a > > fifo written by myself is a lot more flexible and simulates faster than= the > > Xilinx version. I also know to as good a degree as I can test that it w= ill > > work 100%. > > I dont really think you can say that their fifos have been validated 10= 0% > > if they have to release patches for them. > > > Jon =A0 =A0 =A0 =A0 > > Dear Jon, > > I do not feel to be in health right now to write this fifo, so here is > the deal: > > =A0 component mgt_fifo > =A0 =A0 port ( > =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0); > =A0 =A0 =A0 rd_clk : in =A0std_logic; > =A0 =A0 =A0 rd_en =A0: in =A0std_logic; > =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic; > =A0 =A0 =A0 wr_clk : in =A0std_logic; > =A0 =A0 =A0 wr_en =A0: in =A0std_logic; > =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0); > =A0 =A0 =A0 empty =A0: out std_logic; > =A0 =A0 =A0 full =A0 : out std_logic); > =A0 end component; > > if you can write fifo that i can "drop in" and the Xilinx FIFO error > is gone, > then i will stand up, go to postal office and send you 1000 EUR by > western union. > If 1000 EUR is not enough, name your price, i will consider it. > there is no price on the health of our family > > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay. > > Antti Hello Antti, If you want to try a different implementation of a FIFO, you can get the one that the FSL bus uses out of the EDK pcores directory at C: \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl \vhdl. There are multiple implementations, including an async BRAM based one that has the same ports as you list above, except that it uses exist instead of empty on the read port. That said, I don't expect a third implementation to work instantly when the previous two implementations had the same error. This FIFO has the full source to it, so it is straight forward to see how it works, and add ChipScope to observe what is happening around the time of the error. If you have not used it before, FPGA editor has the ability to find a ChipScope ILA core, and change what is connected to it. That can make it much quicker to follow the trail of clues since you avoid having to go through a full place and route every time you want to look at something different. Is your 62.5 MHz clock a divided version of the 125 MHz clock? You mention that the 125 MHz is the recovered clock from the MGT, but there are other options. When we did our GigE interface, we used a 125 MHz clock from the MGT, but it was not the recovered clock, but the local MGT PLL. This let us use the same 125 MHz clock for all four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is phase aligned with the 125 MHz clock. Regards, John McCaskill www.FasterTechnology.comArticle: 144631
sorry for the double post, due to a NNTP server hickup. -- http://ygdes.com / http://yasep.orgArticle: 144632
On Dec 21, 3:21=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > > > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > > >> Well once you have written and tested your own fifo then you would= have > > > i=3D > > > >t > > > >> for any other project. It seems like you have wasted a lot of time > > > alread=3D > > > >y > > > >> trying to fix the Xilinx version so I dont see that you have anyth= ing > > > to > > > >> loose by creating your own. > > > > >> Jon =3DA0 =3DA0 =3DA0 =3DA0 > > > > >If you REALLY need todo something else, when your time is at absolut= e > > > >premium > > > >And if the system working (except occasional errors about 2 of fiber > > > >packets are corrupt) > > > >Then you do not go replacing Xilinx validated FIFO solutions with yo= ur > > > >own, if there are other options. > > > > >If 2 completly different FIFO implementations both have same error? > > > >you think 3rd one would instantly work? Could be, yes. > > > > >Antti > > > > In my opinion people tend to use coregen far too often. Looking throu= gh > > > some of Xilinx code it is awfull. I went down the route of writing my= own > > > fifos not because I had a problem with Xilinx fifos but because I bel= ieve a > > > fifo written by myself is a lot more flexible and simulates faster th= an the > > > Xilinx version. I also know to as good a degree as I can test that it= will > > > work 100%. > > > I dont really think you can say that their fifos have been validated = 100% > > > if they have to release patches for them. > > > > Jon =A0 =A0 =A0 =A0 > > > Dear Jon, > > > I do not feel to be in health right now to write this fifo, so here is > > the deal: > > > =A0 component mgt_fifo > > =A0 =A0 port ( > > =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0); > > =A0 =A0 =A0 rd_clk : in =A0std_logic; > > =A0 =A0 =A0 rd_en =A0: in =A0std_logic; > > =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic; > > =A0 =A0 =A0 wr_clk : in =A0std_logic; > > =A0 =A0 =A0 wr_en =A0: in =A0std_logic; > > =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0); > > =A0 =A0 =A0 empty =A0: out std_logic; > > =A0 =A0 =A0 full =A0 : out std_logic); > > =A0 end component; > > > if you can write fifo that i can "drop in" and the Xilinx FIFO error > > is gone, > > then i will stand up, go to postal office and send you 1000 EUR by > > western union. > > If 1000 EUR is not enough, name your price, i will consider it. > > there is no price on the health of our family > > > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay. > > > Antti > > Hello Antti, > > If you want to try a different implementation of a FIFO, you can get > the one that the FSL bus uses out of the EDK pcores directory at C: > \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl > \vhdl. > > There are multiple implementations, including an async BRAM based one > that has the same ports as you list above, except that it uses exist > instead of empty on the read port. > > That said, I don't expect a third implementation to work instantly > when the previous two implementations had the same error. =A0This FIFO > has the full source to it, so it is straight forward to see how it > works, and add ChipScope to observe what is happening around the time > of the error. > > If you have not used it before, FPGA editor has the ability to find a > ChipScope ILA core, and change what is connected to it. That can make > it much quicker to follow the trail of clues since you avoid having to > go through a full place and route every time you want to look at > something different. > > Is your 62.5 MHz clock a divided version of the 125 MHz clock? You > mention that the 125 MHz is the recovered clock from the MGT, but > there are other options. =A0When we did our GigE interface, we used a > 125 MHz clock from the MGT, but it was not the recovered clock, but > the local MGT PLL. =A0This let us use the same 125 MHz clock for all > four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is > phase aligned with the 125 MHz clock. > > Regards, > > John McCaskillwww.FasterTechnology.com Hi I have tried all 3 variants possible with coregen, all 3 have similar errors and no, the clocks are not divided version, the 125MHz comes from master over fiber the master could be 100 hops away, the 62.5mhz is derived from local oscillator so the frequencier are very close but not synchron Antti who has to give up, at least for a while :( good advice still welcome, if there is any hope or idea how to fix the issue and yes it could be power supply issue at the end of the day alsoArticle: 144633
whygee wrote: > Access time is 33ns, arghl ! it's not 33ns but 10ns ! > so let's say it can work at pixel speeed > (27 or 30MHz) with 96 bits each time : that's 360M Bytes per second. no, more than that : we can expect about 60MHz, more than 700MB/s which should be more than enough :-) yg -- http://ygdes.com / http://yasep.orgArticle: 144634
Well, this depends on what processors are we saying... If we are taking about some IP Cores there are informations about how large is design, if it is your own design it depends if it is complex desgin or not and what Spartan ( there are few types... ) >Hello, > >In a multiprocessor architecture, how many processors can support >spartan 3 starter kit?? >Please, if anyone knows this trick answer me!! > >thanks in advance >INES > >--------------------------------------- >This message was sent using the comp.arch.fpga web interface on >http://www.FPGARelated.com > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144635
On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > > > Antti wrote: > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPT= Y > > > flags present. > > > > signals at input correct, as expected (checked with ChipScope) > > > signals at output: > > > - double value > > > - missing 1, 2 or 3 values > > > - FIFO will read out random number of OLD entries, this could be 4 > > > values, or 50% of the FIFO old values > > > I know you will have read this. > > > Can you think of any reason why the Xilinx work-around wouldn't work > > because of your specific implementation? It seems to have different > > work-arounds depending on whether the read clock is faster or slower > > than the write clock. Do your clocks change frequency? > > > Are you sure your clocks don't have any glitches? The reset also? > > Power's OK? Is your office made of Cobalt 60? > > > HTH., Syms. > > 1) I entered the clock figures in FIFO16 implementationm, but the > error also happens with BRAM based FIFO that do not need workarounds > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write, > one is PLB clock 62.5MHz read > 3) Power OK? Well the problem happens at 2 different sites, hm yes it > could be still be power problem > > 4) My office is not of Cobalt 60, ... and its cold here too > > Antti- Hide quoted text - > > - Show quoted text - Are you sure that this is a FIFO issue and not something else? Some things to think about. 1) The recovered clock from the MGT is a bit noisy as it moves as the CDR moves. Why are you using this instead of the REFCLK source? 2) It seems like you have a PLB core that is reading from the FIFO, could the problem be in this? Ed McGettigan -- Xilinx Inc.Article: 144636
On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > Antti wrote: > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EM= PTY > > > > flags present. > > > > > signals at input correct, as expected (checked with ChipScope) > > > > signals at output: > > > > - double value > > > > - missing 1, 2 or 3 values > > > > - FIFO will read out random number of OLD entries, this could be 4 > > > > values, or 50% of the FIFO old values > > > > I know you will have read this. > > > > Can you think of any reason why the Xilinx work-around wouldn't work > > > because of your specific implementation? It seems to have different > > > work-arounds depending on whether the read clock is faster or slower > > > than the write clock. Do your clocks change frequency? > > > > Are you sure your clocks don't have any glitches? The reset also? > > > Power's OK? Is your office made of Cobalt 60? > > > > HTH., Syms. > > > 1) I entered the clock figures in FIFO16 implementationm, but the > > error also happens with BRAM based FIFO that do not need workarounds > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write, > > one is PLB clock 62.5MHz read > > 3) Power OK? Well the problem happens at 2 different sites, hm yes it > > could be still be power problem > > > 4) My office is not of Cobalt 60, ... and its cold here too > > > Antti- Hide quoted text - > > > - Show quoted text - > > Are you sure that this is a FIFO issue and not something else? =A0Some > things to think about. > > 1) The recovered clock from the MGT is a bit noisy as it moves as the > CDR moves. =A0Why are you using this instead of the REFCLK source? > > 2) It seems like you have a PLB core that is reading from the FIFO, > could the problem be in this? > > Ed McGettigan > -- > Xilinx Inc. Well the MGT datapath and clock system is not done by me, and the guy says it is OK all the way it is connected. yes, It is very unlikely to belive that all THREE types of coregen FIFO's fail with about same symptoms, but in all 3 cased Chipscope sees correct data into fifo, and trash coming out the system can span up to 100 boards, all synced to master unit, the local refclk is not fully sync to the clock of the master unit, so I see no way to use this clock to syncronise the fifo? Antti PS I just received a attempt to collect the reward, by using non xilinx FIFO implementation, i let you all know the test resultsArticle: 144637
On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > Antti wrote: > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL = EMPTY > > > > > flags present. > > > > > > signals at input correct, as expected (checked with ChipScope) > > > > > signals at output: > > > > > - double value > > > > > - missing 1, 2 or 3 values > > > > > - FIFO will read out random number of OLD entries, this could be = 4 > > > > > values, or 50% of the FIFO old values > > > > > I know you will have read this. > > > > > Can you think of any reason why the Xilinx work-around wouldn't wor= k > > > > because of your specific implementation? It seems to have different > > > > work-arounds depending on whether the read clock is faster or slowe= r > > > > than the write clock. Do your clocks change frequency? > > > > > Are you sure your clocks don't have any glitches? The reset also? > > > > Power's OK? Is your office made of Cobalt 60? > > > > > HTH., Syms. > > > > 1) I entered the clock figures in FIFO16 implementationm, but the > > > error also happens with BRAM based FIFO that do not need workarounds > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write= , > > > one is PLB clock 62.5MHz read > > > 3) Power OK? Well the problem happens at 2 different sites, hm yes it > > > could be still be power problem > > > > 4) My office is not of Cobalt 60, ... and its cold here too > > > > Antti- Hide quoted text - > > > > - Show quoted text - > > > Are you sure that this is a FIFO issue and not something else? =A0Some > > things to think about. > > > 1) The recovered clock from the MGT is a bit noisy as it moves as the > > CDR moves. =A0Why are you using this instead of the REFCLK source? > > > 2) It seems like you have a PLB core that is reading from the FIFO, > > could the problem be in this? > > > Ed McGettigan > > -- > > Xilinx Inc. > > Well the MGT datapath and clock system is not done by me, and the guy > says it is OK all the way it is connected. > > yes, It is very unlikely to belive that all THREE types of coregen > FIFO's fail with about same symptoms, but in all > 3 cased Chipscope sees correct data into fifo, and trash coming out > > the system can span up to 100 boards, all synced to master unit, the > local refclk is not fully sync to the clock of > the master unit, so I see no way to use this clock to syncronise the > fifo? > > Antti > PS I just received a attempt to collect the reward, by using non > xilinx FIFO implementation, i let you all know > the test results Antti If I remember right (I am no longer at Xilinx) the FIFO is NOT designed for unequal data width of write and read. (Reason: possible ambiguity of Full and EMPTY) Since you use two clocks that are roughly 2:1 in frequency, I hope that you do not try to have double width on one of the ports. The FIFO must have the same width on both ports. You must design the width conversion outside the FIFO. That little circuit will be synchronous and thus quite simple. Peter AlfkeArticle: 144638
On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > > Antti wrote: > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FUL= L EMPTY > > > > > > flags present. > > > > > > > signals at input correct, as expected (checked with ChipScope) > > > > > > signals at output: > > > > > > - double value > > > > > > - missing 1, 2 or 3 values > > > > > > - FIFO will read out random number of OLD entries, this could b= e 4 > > > > > > values, or 50% of the FIFO old values > > > > > > I know you will have read this. > > > > > > Can you think of any reason why the Xilinx work-around wouldn't w= ork > > > > > because of your specific implementation? It seems to have differe= nt > > > > > work-arounds depending on whether the read clock is faster or slo= wer > > > > > than the write clock. Do your clocks change frequency? > > > > > > Are you sure your clocks don't have any glitches? The reset also? > > > > > Power's OK? Is your office made of Cobalt 60? > > > > > > HTH., Syms. > > > > > 1) I entered the clock figures in FIFO16 implementationm, but the > > > > error also happens with BRAM based FIFO that do not need workaround= s > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz wri= te, > > > > one is PLB clock 62.5MHz read > > > > 3) Power OK? Well the problem happens at 2 different sites, hm yes = it > > > > could be still be power problem > > > > > 4) My office is not of Cobalt 60, ... and its cold here too > > > > > Antti- Hide quoted text - > > > > > - Show quoted text - > > > > Are you sure that this is a FIFO issue and not something else? =A0Som= e > > > things to think about. > > > > 1) The recovered clock from the MGT is a bit noisy as it moves as the > > > CDR moves. =A0Why are you using this instead of the REFCLK source? > > > > 2) It seems like you have a PLB core that is reading from the FIFO, > > > could the problem be in this? > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Well the MGT datapath and clock system is not done by me, and the guy > > says it is OK all the way it is connected. > > > yes, It is very unlikely to belive that all THREE types of coregen > > FIFO's fail with about same symptoms, but in all > > 3 cased Chipscope sees correct data into fifo, and trash coming out > > > the system can span up to 100 boards, all synced to master unit, the > > local refclk is not fully sync to the clock of > > the master unit, so I see no way to use this clock to syncronise the > > fifo? > > > Antti > > PS I just received a attempt to collect the reward, by using non > > xilinx FIFO implementation, i let you all know > > the test results > > Antti > If I remember right (I am no longer at Xilinx) the FIFO is NOT > designed for unequal data width of write and read. (Reason: possible > ambiguity of Full and EMPTY) > Since you use two clocks that are roughly 2:1 in frequency, I hope > that you do not try to have double width on one of the ports. > The FIFO must have the same width on both ports. You must design the > width conversion outside the FIFO. That little circuit will be > synchronous and thus quite simple. > Peter Alfke well the FIFO is 9b in 9b out so it should work? at least this is what i hoped... we did not suspect the FIFO as problem at first so spent LOT of time looking for the problem AROUND the FIFOS but.. at least based on what i can see from CS snapshots on fifo inputs and outputs, the only explanation i have is that the FIFO are just goind mad, of course one option is that its me doing, but i have someone who is in better shape looking over the code as well, and he sees no issues there either. I know the FIFOs should work so there must be some explanation, but so far failing to see it. Antti PS thank you Peter for the responseArticle: 144639
On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > > > Antti wrote: > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only F= ULL EMPTY > > > > > > > flags present. > > > > > > > > signals at input correct, as expected (checked with ChipScope= ) > > > > > > > signals at output: > > > > > > > - double value > > > > > > > - missing 1, 2 or 3 values > > > > > > > - FIFO will read out random number of OLD entries, this could= be 4 > > > > > > > values, or 50% of the FIFO old values > > > > > > > I know you will have read this. > > > > > > > Can you think of any reason why the Xilinx work-around wouldn't= work > > > > > > because of your specific implementation? It seems to have diffe= rent > > > > > > work-arounds depending on whether the read clock is faster or s= lower > > > > > > than the write clock. Do your clocks change frequency? > > > > > > > Are you sure your clocks don't have any glitches? The reset als= o? > > > > > > Power's OK? Is your office made of Cobalt 60? > > > > > > > HTH., Syms. > > > > > > 1) I entered the clock figures in FIFO16 implementationm, but the > > > > > error also happens with BRAM based FIFO that do not need workarou= nds > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz w= rite, > > > > > one is PLB clock 62.5MHz read > > > > > 3) Power OK? Well the problem happens at 2 different sites, hm ye= s it > > > > > could be still be power problem > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too > > > > > > Antti- Hide quoted text - > > > > > > - Show quoted text - > > > > > Are you sure that this is a FIFO issue and not something else? =A0S= ome > > > > things to think about. > > > > > 1) The recovered clock from the MGT is a bit noisy as it moves as t= he > > > > CDR moves. =A0Why are you using this instead of the REFCLK source? > > > > > 2) It seems like you have a PLB core that is reading from the FIFO, > > > > could the problem be in this? > > > > > Ed McGettigan > > > > -- > > > > Xilinx Inc. > > > > Well the MGT datapath and clock system is not done by me, and the guy > > > says it is OK all the way it is connected. > > > > yes, It is very unlikely to belive that all THREE types of coregen > > > FIFO's fail with about same symptoms, but in all > > > 3 cased Chipscope sees correct data into fifo, and trash coming out > > > > the system can span up to 100 boards, all synced to master unit, the > > > local refclk is not fully sync to the clock of > > > the master unit, so I see no way to use this clock to syncronise the > > > fifo? > > > > Antti > > > PS I just received a attempt to collect the reward, by using non > > > xilinx FIFO implementation, i let you all know > > > the test results > > > Antti > > If I remember right (I am no longer at Xilinx) the FIFO is NOT > > designed for unequal data width of write and read. (Reason: possible > > ambiguity of Full and EMPTY) > > Since you use two clocks that are roughly 2:1 in frequency, I hope > > that you do not try to have double width on one of the ports. > > The FIFO must have the same width on both ports. You must design the > > width conversion outside the FIFO. That little circuit will be > > synchronous and thus quite simple. > > Peter Alfke > > well the FIFO is 9b in 9b out so it should work? > at least this is what i hoped... > > we did not suspect the FIFO as problem at first > so spent LOT of time looking for the problem AROUND the FIFOS > but.. at least based on what i can see from CS snapshots on fifo > inputs and outputs, the only explanation i have is that the FIFO > are just goind mad, > > of course one option is that its me doing, but i have someone > who is in better shape looking over the code as well, and he > sees no issues there either. I know the FIFOs should work > so there must be some explanation, but so far failing to see it. > > Antti > PS thank you Peter for the response OK, Antti, so you have the same port width, but one clock is about twice as fast as the other. How do you stop the 125 MHz write clock from filling up the FIFO, since you read at only 62 MHz ? I hope you are not gating the clock, but rather run it continuously and use WE to stop the writing. Yes, many of these suggestions are well below your level, but stupid problems need stupid investigations. Cheers PeterArticle: 144640
On Dec 21, 5:40=A0am, "Ghostboy" <Ghost...@dommel.be> wrote: > Thanks > But what if I need to buffer a frame with a resolution of 1024*768 and it > will constantly be updated? > With that little tidbit of information you should be able to compute how much external memory your system will require and nothing more. I'll repeat one more time, video processing does not typically work on more than a relatively small area of the image at a given time. The video data for that relatively small area can generally be held in the internal memory of an FPGA. Your system would move the data from the large, slow external memory into the FPGA's faster internal memory, get processed and then get send it back out (presumably to memory, maybe someplace else). The amount of internal memory you need is defined by the processing algorithm, not the dimensions of the video frames that you're trying to process. KJArticle: 144641
Hello, I'm fairly new to FPGAs and such, and I'm having a really hard time configuring my ML402 board. I'm using EDK / ISE 11.2. I'm using the JTAG connector, and don't have a compact flash reader (yet) to allow my computer to move files onto the ML402's CF card. Is there a way to configure the ML402 board using only the JTAG connector? Thanks in advance! Sean GriffinArticle: 144642
On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrot= e: > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > > > > Antti wrote: > > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only= FULL EMPTY > > > > > > > > flags present. > > > > > > > > > signals at input correct, as expected (checked with ChipSco= pe) > > > > > > > > signals at output: > > > > > > > > - double value > > > > > > > > - missing 1, 2 or 3 values > > > > > > > > - FIFO will read out random number of OLD entries, this cou= ld be 4 > > > > > > > > values, or 50% of the FIFO old values > > > > > > > > I know you will have read this. > > > > > > > > Can you think of any reason why the Xilinx work-around wouldn= 't work > > > > > > > because of your specific implementation? It seems to have dif= ferent > > > > > > > work-arounds depending on whether the read clock is faster or= slower > > > > > > > than the write clock. Do your clocks change frequency? > > > > > > > > Are you sure your clocks don't have any glitches? The reset a= lso? > > > > > > > Power's OK? Is your office made of Cobalt 60? > > > > > > > > HTH., Syms. > > > > > > > 1) I entered the clock figures in FIFO16 implementationm, but t= he > > > > > > error also happens with BRAM based FIFO that do not need workar= ounds > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz= write, > > > > > > one is PLB clock 62.5MHz read > > > > > > 3) Power OK? Well the problem happens at 2 different sites, hm = yes it > > > > > > could be still be power problem > > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too > > > > > > > Antti- Hide quoted text - > > > > > > > - Show quoted text - > > > > > > Are you sure that this is a FIFO issue and not something else? = =A0Some > > > > > things to think about. > > > > > > 1) The recovered clock from the MGT is a bit noisy as it moves as= the > > > > > CDR moves. =A0Why are you using this instead of the REFCLK source= ? > > > > > > 2) It seems like you have a PLB core that is reading from the FIF= O, > > > > > could the problem be in this? > > > > > > Ed McGettigan > > > > > -- > > > > > Xilinx Inc. > > > > > Well the MGT datapath and clock system is not done by me, and the g= uy > > > > says it is OK all the way it is connected. > > > > > yes, It is very unlikely to belive that all THREE types of coregen > > > > FIFO's fail with about same symptoms, but in all > > > > 3 cased Chipscope sees correct data into fifo, and trash coming out > > > > > the system can span up to 100 boards, all synced to master unit, th= e > > > > local refclk is not fully sync to the clock of > > > > the master unit, so I see no way to use this clock to syncronise th= e > > > > fifo? > > > > > Antti > > > > PS I just received a attempt to collect the reward, by using non > > > > xilinx FIFO implementation, i let you all know > > > > the test results > > > > Antti > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT > > > designed for unequal data width of write and read. (Reason: possible > > > ambiguity of Full and EMPTY) > > > Since you use two clocks that are roughly 2:1 in frequency, I hope > > > that you do not try to have double width on one of the ports. > > > The FIFO must have the same width on both ports. You must design the > > > width conversion outside the FIFO. That little circuit will be > > > synchronous and thus quite simple. > > > Peter Alfke > > > well the FIFO is 9b in 9b out so it should work? > > at least this is what i hoped... > > > we did not suspect the FIFO as problem at first > > so spent LOT of time looking for the problem AROUND the FIFOS > > but.. at least based on what i can see from CS snapshots on fifo > > inputs and outputs, the only explanation i have is that the FIFO > > are just goind mad, > > > of course one option is that its me doing, but i have someone > > who is in better shape looking over the code as well, and he > > sees no issues there either. I know the FIFOs should work > > so there must be some explanation, but so far failing to see it. > > > Antti > > PS thank you Peter for the response > > OK, Antti, > so you have the same port width, but one clock is about twice as fast > as the other. > How do you stop the 125 MHz write clock from filling up the FIFO, > since you read at only 62 MHz ? > I hope you are not gating the clock, but rather run it continuously > and use WE to stop the writing. > Yes, many of these suggestions are well below your level, but stupid > problems need stupid investigations. > Cheers > Peter I am level below ground right now the project is just driving me nuts. slowly. To work for months, and end up with Xilinx saying: The man who could have helped you, left Xilinx last friday. Your situation is unsupportable. Well we got out of that situation. To end up in the new ones. The FIFO is never over filled by design. The fiber link is 99% IDLE sending usually only short 10byte packets over the link. For tesing I generate 10 byte pakets with MOUSE so 1 per second so there is no doubt the FIFO is never near full at all. Last results: - ALL 3 types of Xilinx FIFO's same style of errors, about same error rate - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES LESS errors then Xilinx implementation, but still all different types of error did occour: missing values, and FIFO outputtin large junk of OLD values, that is read pointer changing by some random value again, I did not design the MGT clocking and the overall MGT subsystem, the people who did are either unreachable or unable to provide any help beyound saying that the implementation (connection of the FIFO) is done properly. It is also what I have figured out so far, but.. well somewhere must be problem. AnttiArticle: 144643
On Dec 21, 12:36=A0pm, "ines_fr" <benhlima_i...@yahoo.fr> wrote: > Hello, > > In a multiprocessor architecture, how many processors can support > spartan 3 starter kit?? > Please, if anyone knows this trick answer me!! > > thanks in advance > INES =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com I do not think that you can put more than two if you use MPMC memory controller. AlesArticle: 144644
On Dec 21, 7:17=A0pm, Antti <antti.luk...@googlemail.com> wrote: > I hope my plea will not be seen as usual "please help me" request. I > do my (home)work, I try hard but sometimes there come up problems that > seem very hard to solve, with the current problem, well if there is no > solution to that, then I wonder how come it has been ever been > possible to use Xilinx FIFO's with problem at all? So the problem: > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY > flags present. > > signals at input correct, as expected (checked with ChipScope) > signals at output: > - double value > - missing 1, 2 or 3 values > - FIFO will read out random number of OLD entries, this could be 4 > values, or 50% of the FIFO old values > > I can select BRAM or FIFO16 implementation in Coregen, it doesnt > change the problem > > Virtex-4, ISE 10.1SP3 > > Please help me, if anyone has some good suggestion (except use Altera > advice), I am getting really desperate. To the extent that when i > friend called my yesterday, then after my "hello", his first response > was: "Are you dead?". I had to explain that i am not. > > Antti I'm not sure if this is related but i had a similar problem when using the FSL v2.11.a core in EDK 10.1 SP3. In my case it was set up in synchronous mode. The problem was lost data whenever there was a simultaneous read and write at the same time when there was exactly 1 word of data in the FIFO. It was fixed in v2.11.b of the core in EDK 11. Perphaps there is something similar happening in the coregen FIFO. Cheers AdamArticle: 144645
Hi all, I am building a new megapixel camera based on Spartan3A DSP 3400. For one of the applications I would need H.264 core with a performance of minimal 66Mpix/s. I prefer EDK HW core since the camera "brain" is composed there. Does anyone has anything to recommend? Best regards, AlesArticle: 144646
Antti <antti.lukats@googlemail.com> wrote:
>On Dec 21, 3:21=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
>> On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>> > On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>>
>> > > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>> > > >> Well once you have written and tested your own fifo then you would=
> have
>> > > i=3D
>> > > >t
>> > > >> for any other project. It seems like you have wasted a lot of time
>> > > alread=3D
>> > > >y
>> > > >> trying to fix the Xilinx version so I dont see that you have anyth=
>ing
>> > > to
>> > > >> loose by creating your own.
>>
>> > > >> Jon =3DA0 =3DA0 =3DA0 =3DA0
>>
>> > > >If you REALLY need todo something else, when your time is at absolut=
>e
>> > > >premium
>> > > >And if the system working (except occasional errors about 2 of fiber
>> > > >packets are corrupt)
>> > > >Then you do not go replacing Xilinx validated FIFO solutions with yo=
>ur
>> > > >own, if there are other options.
>>
>> > > >If 2 completly different FIFO implementations both have same error?
>> > > >you think 3rd one would instantly work? Could be, yes.
>>
>> > > >Antti
>>
>> > > In my opinion people tend to use coregen far too often. Looking throu=
>gh
>> > > some of Xilinx code it is awfull. I went down the route of writing my=
> own
>> > > fifos not because I had a problem with Xilinx fifos but because I bel=
>ieve a
>> > > fifo written by myself is a lot more flexible and simulates faster th=
>an the
>> > > Xilinx version. I also know to as good a degree as I can test that it=
> will
>> > > work 100%.
>> > > I dont really think you can say that their fifos have been validated =
>100%
>> > > if they have to release patches for them.
>>
>> > > Jon =A0 =A0 =A0 =A0
>>
>> > Dear Jon,
>>
>> > I do not feel to be in health right now to write this fifo, so here is
>> > the deal:
>>
>> > =A0 component mgt_fifo
>> > =A0 =A0 port (
>> > =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0);
>> > =A0 =A0 =A0 rd_clk : in =A0std_logic;
>> > =A0 =A0 =A0 rd_en =A0: in =A0std_logic;
>> > =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic;
>> > =A0 =A0 =A0 wr_clk : in =A0std_logic;
>> > =A0 =A0 =A0 wr_en =A0: in =A0std_logic;
>> > =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0);
>> > =A0 =A0 =A0 empty =A0: out std_logic;
>> > =A0 =A0 =A0 full =A0 : out std_logic);
>> > =A0 end component;
>>
>> > if you can write fifo that i can "drop in" and the Xilinx FIFO error
>> > is gone,
>> > then i will stand up, go to postal office and send you 1000 EUR by
>> > western union.
>> > If 1000 EUR is not enough, name your price, i will consider it.
>> > there is no price on the health of our family
>>
>> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay.
>>
>> > Antti
>>
>> Hello Antti,
>>
>> If you want to try a different implementation of a FIFO, you can get
>> the one that the FSL bus uses out of the EDK pcores directory at C:
>> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
>> \vhdl.
>>
>> There are multiple implementations, including an async BRAM based one
>> that has the same ports as you list above, except that it uses exist
>> instead of empty on the read port.
>>
>> That said, I don't expect a third implementation to work instantly
>> when the previous two implementations had the same error. =A0This FIFO
>> has the full source to it, so it is straight forward to see how it
>> works, and add ChipScope to observe what is happening around the time
>> of the error.
>>
>> If you have not used it before, FPGA editor has the ability to find a
>> ChipScope ILA core, and change what is connected to it. That can make
>> it much quicker to follow the trail of clues since you avoid having to
>> go through a full place and route every time you want to look at
>> something different.
>>
>> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
>> mention that the 125 MHz is the recovered clock from the MGT, but
>> there are other options. =A0When we did our GigE interface, we used a
>> 125 MHz clock from the MGT, but it was not the recovered clock, but
>> the local MGT PLL. =A0This let us use the same 125 MHz clock for all
>> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
>> phase aligned with the 125 MHz clock.
>>
>> Regards,
>>
>> John McCaskillwww.FasterTechnology.com
>
>Hi
>
>I have tried all 3 variants possible with coregen,
>all 3 have similar errors
>
>and no, the clocks are not divided version, the 125MHz comes from
>master over fiber
>the master could be 100 hops away, the 62.5mhz is derived from local
>oscillator
>
>so the frequencier are very close but not synchron
>
>Antti
>who has to give up, at least for a while :(
>good advice still welcome, if there is any hope or idea how to fix the
>issue
>and yes it could be power supply issue at the end of the day also
I always write my own fifo's to keep things simple. I keep a write
pointer, read pointer and number of elements counter in the domain
with the highest clock frequency. I don't cross the clock domain
inside the fifo instead I create an interface which does the clock
domain crossing. I also use an early full signal (say max. elements -X
depending on the expected latency). This allows for fast FIFO's (no
cray code counters) with very little logic.
The control logic looks like this:
if read then read_ptr++;
if write then write_ptr++;
if (read=true and write=false) num_elements--;
if (write=true and read=false) num_elements++;
if (num_elements>=(MAX_ELEMENTS-X)) full=true; else full=false;
if (num_elements==0) empty=true;
The external logic should prohibit itself from reading/writing fifo
when its empty or full.
Besides: could your problem be a timing constraint problem? Did you
specify the amount of time signals may travel from one clock domain to
the other? The Xilinx tools are not doing this automatically!
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 144647Sean, The Xilinx Platform Cable USB II works with the Impact software in ISE to program over JTAG, or over any one of the other modes the FPGA supports. It is what I have on my desk...there may be a newer model. There are third party suppliers of JTAG cables and programming software, as well. AustinArticle: 144648
On Dec 21, 11:29=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > Antti <antti.luk...@googlemail.com> wrote: > >On Dec 21, 3:21=3DA0pm, John McCaskill <jhmccask...@gmail.com> wrote: > >> On Dec 21, 5:42=3DA0am, Antti <antti.luk...@googlemail.com> wrote: > > >> > On Dec 21, 1:29=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wr= ote: > >> > > >> Well once you have written and tested your own fifo then you wo= uld=3D > > have > >> > > i=3D3D > >> > > >t > >> > > >> for any other project. It seems like you have wasted a lot of t= ime > >> > > alread=3D3D > >> > > >y > >> > > >> trying to fix the Xilinx version so I dont see that you have an= yth=3D > >ing > >> > > to > >> > > >> loose by creating your own. > > >> > > >> Jon =3D3DA0 =3D3DA0 =3D3DA0 =3D3DA0 > > >> > > >If you REALLY need todo something else, when your time is at abso= lut=3D > >e > >> > > >premium > >> > > >And if the system working (except occasional errors about 2 of fi= ber > >> > > >packets are corrupt) > >> > > >Then you do not go replacing Xilinx validated FIFO solutions with= yo=3D > >ur > >> > > >own, if there are other options. > > >> > > >If 2 completly different FIFO implementations both have same erro= r? > >> > > >you think 3rd one would instantly work? Could be, yes. > > >> > > >Antti > > >> > > In my opinion people tend to use coregen far too often. Looking th= rou=3D > >gh > >> > > some of Xilinx code it is awfull. I went down the route of writing= my=3D > > own > >> > > fifos not because I had a problem with Xilinx fifos but because I = bel=3D > >ieve a > >> > > fifo written by myself is a lot more flexible and simulates faster= th=3D > >an the > >> > > Xilinx version. I also know to as good a degree as I can test that= it=3D > > will > >> > > work 100%. > >> > > I dont really think you can say that their fifos have been validat= ed =3D > >100% > >> > > if they have to release patches for them. > > >> > > Jon =3DA0 =3DA0 =3DA0 =3DA0 > > >> > Dear Jon, > > >> > I do not feel to be in health right now to write this fifo, so here = is > >> > the deal: > > >> > =3DA0 component mgt_fifo > >> > =3DA0 =3DA0 port ( > >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 downto= 0); > >> > =3DA0 =3DA0 =3DA0 rd_clk : in =3DA0std_logic; > >> > =3DA0 =3DA0 =3DA0 rd_en =3DA0: in =3DA0std_logic; > >> > =3DA0 =3DA0 =3DA0 rst =3DA0 =3DA0: in =3DA0std_logic; > >> > =3DA0 =3DA0 =3DA0 wr_clk : in =3DA0std_logic; > >> > =3DA0 =3DA0 =3DA0 wr_en =3DA0: in =3DA0std_logic; > >> > =3DA0 =3DA0 =3DA0 dout =3DA0 : out std_logic_vector(8 downto 0); > >> > =3DA0 =3DA0 =3DA0 empty =3DA0: out std_logic; > >> > =3DA0 =3DA0 =3DA0 full =3DA0 : out std_logic); > >> > =3DA0 end component; > > >> > if you can write fifo that i can "drop in" and the Xilinx FIFO error > >> > is gone, > >> > then i will stand up, go to postal office and send you 1000 EUR by > >> > western union. > >> > If 1000 EUR is not enough, name your price, i will consider it. > >> > there is no price on the health of our family > > >> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay= . > > >> > Antti > > >> Hello Antti, > > >> If you want to try a different implementation of a FIFO, you can get > >> the one that the FSL bus uses out of the EDK pcores directory at C: > >> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl > >> \vhdl. > > >> There are multiple implementations, including an async BRAM based one > >> that has the same ports as you list above, except that it uses exist > >> instead of empty on the read port. > > >> That said, I don't expect a third implementation to work instantly > >> when the previous two implementations had the same error. =3DA0This FI= FO > >> has the full source to it, so it is straight forward to see how it > >> works, and add ChipScope to observe what is happening around the time > >> of the error. > > >> If you have not used it before, FPGA editor has the ability to find a > >> ChipScope ILA core, and change what is connected to it. That can make > >> it much quicker to follow the trail of clues since you avoid having to > >> go through a full place and route every time you want to look at > >> something different. > > >> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You > >> mention that the 125 MHz is the recovered clock from the MGT, but > >> there are other options. =3DA0When we did our GigE interface, we used = a > >> 125 MHz clock from the MGT, but it was not the recovered clock, but > >> the local MGT PLL. =3DA0This let us use the same 125 MHz clock for all > >> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is > >> phase aligned with the 125 MHz clock. > > >> Regards, > > >> John McCaskillwww.FasterTechnology.com > > >Hi > > >I have tried all 3 variants possible with coregen, > >all 3 have similar errors > > >and no, the clocks are not divided version, the 125MHz comes from > >master over fiber > >the master could be 100 hops away, the 62.5mhz is derived from local > >oscillator > > >so the frequencier are very close but not synchron > > >Antti > >who has to give up, at least for a while :( > >good advice still welcome, if there is any hope or idea how to fix the > >issue > >and yes it could be power supply issue at the end of the day also > > I always write my own fifo's to keep things simple. I keep a write > pointer, read pointer and number of elements counter in the domain > with the highest clock frequency. I don't cross the clock domain > inside the fifo instead I create an interface which does the clock > domain crossing. I also use an early full signal (say max. elements -X > depending on the expected latency). This allows for fast FIFO's (no > cray code counters) with very little logic. > > The control logic looks like this: > > if read then read_ptr++; > if write then write_ptr++; > if (read=3Dtrue and write=3Dfalse) num_elements--; > if (write=3Dtrue and read=3Dfalse) num_elements++; > > if (num_elements>=3D(MAX_ELEMENTS-X)) full=3Dtrue; else full=3Dfalse; > if (num_elements=3D=3D0) empty=3Dtrue; > > The external logic should prohibit itself from reading/writing fifo > when its empty or full. > > Besides: could your problem be a timing constraint problem? Did you > specify the amount of time signals may travel from one clock domain to > the other? The Xilinx tools are not doing this automatically! > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg= er hammer!" > -------------------------------------------------------------- hi I was already thinking of writing "simplified FIFO" that is would work under the conditions it is used, the read is done by PPC software polling so never too often well the clock domains are fully async, so the clock edges of the read- write can have any phase they like so I assumed if the read and write clock are constrained then it is enough? AnttiArticle: 144649
Ales, http://xgoogle.xilinx.com/search?output=3Dxml_no_dtd&ie=3DUTF-8&oe=3DUTF-8&= client=3Diplocator&proxystylesheet=3Diplocator&site=3DIPLocator&filter=3D0&= _ResultsView=3DStandard&num=3D25&q=3Dh.264&as_q=3D&getfields=3D*&newSearch= =3Dhttp://www.xilinx.com/ipcenter/&formAction=3Dhttp://www.xilinx.com/cgi-b= in/search/iplocator.pl&IPCategory=3D&IPSubcategory=3D&sGlobalNavPick=3DPROD= UCTS&sSecondaryNavPick=3DIntellectual%20Property&requiredfields=3DProductTy= pe.-Region&partialfields=3D%28ProductType:Core%29&searchbox=3D (a bit too long) try: http://tinyurl.com/yeewsxp All of the H.264 IP cores offered for sale. Austin
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