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
On Dec 21, 11:44=A0pm, austin <aus...@xilinx.com> wrote: > Ales, > > http://xgoogle.xilinx.com/search?output=3Dxml_no_dtd&ie=3DUTF-8&oe=3DUTF-= 8&... > > (a bit too long) try: > > http://tinyurl.com/yeewsxp > > All of the H.264 IP cores offered for sale. > > Austin I think the OP was not going to buy anything.. but maybe i am wrong AnttiArticle: 144651
On Dec 21, 11:53=A0pm, Antti <antti.luk...@googlemail.com> wrote: > On Dec 21, 11:44=A0pm, austin <aus...@xilinx.com> wrote: > > > Ales, > > >http://xgoogle.xilinx.com/search?output=3Dxml_no_dtd&ie=3DUTF-8&oe=3DUTF= -8&... > > > (a bit too long) try: > > >http://tinyurl.com/yeewsxp > > > All of the H.264 IP cores offered for sale. > > > Austin > > I think the OP was not going to buy anything.. but maybe i am wrong > > Antti maybe i was wrong, but the SALES info is usually easy to find, so i was wondering why there is a need to make such inquiry AnttiArticle: 144652
Antti <antti.lukats@googlemail.com> wrote: ... > 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? Did you try Opencore FIFO? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 144653
Antti wrote: > On Dec 21, 10:21 pm, Peter Alfke <al...@sbcglobal.net> wrote: >> On Dec 21, 11:58 am, Antti <antti.luk...@googlemail.com> wrote: >> >> >> >> >> >>> On Dec 21, 9:50 pm, Peter Alfke <al...@sbcglobal.net> wrote: >>>> On Dec 21, 9:30 am, Antti <antti.luk...@googlemail.com> wrote: >>>>> On Dec 21, 7:20 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >>>>>> On Dec 21, 3:01 am, Antti <antti.luk...@googlemail.com> wrote: >>>>>>> On Dec 21, 12:56 pm, 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 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. >>>>> 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 >> 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 Looking at UG175 The document says that you should hold WR and RD in the inactive state whilst resetting the device. The number of reset clock cycles needed for each condition is documented. UG175 is here:- www.xilinx.com/support/documentation/ip.../fifo_generator_ug175.pdf > - 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 This implies the fault is not the fifo but what is driving it. Can you route the signals to a port and monitor the port with a scope? Does this occur on the bench and in the simulator? I am still learning design so if I'm teaching you to suck eggs you have my apologies. Andy > > 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: 144654
Antti <antti.lukats@googlemail.com> wrote:
>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!
>>
>
>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?
IIRC there is some constraint that ignores the clock but only
specifies the delays in the paths. Thats what you want with unrelated
clocks. I just can't find it in the ISE7.1 docs and I don't have a
newer version installed at this moment.
IMHO for some reason a counter gets messed up. This probably means
there is more then one signal crossing the clock domain boundary or
the signal crossing the boundary isn't synchronised with the domain
before using it.
--
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: 144655On Dec 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote: > 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> wr= ote: > > > > > > > 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, on= ly FULL EMPTY > > > > > > > > > flags present. > > > > > > > > > > signals at input correct, as expected (checked with ChipS= cope) > > > > > > > > > signals at output: > > > > > > > > > - double value > > > > > > > > > - missing 1, 2 or 3 values > > > > > > > > > - FIFO will read out random number of OLD entries, this c= ould 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 woul= dn't work > > > > > > > > because of your specific implementation? It seems to have d= ifferent > > > > > > > > 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 work= arounds > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M= Hz write, > > > > > > > one is PLB clock 62.5MHz read > > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h= m 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 sour= ce? > > > > > > > 2) It seems like you have a PLB core that is reading from the F= IFO, > > > > > > 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 corege= n > > > > > FIFO's fail with about same symptoms, but in all > > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o= ut > > > > > > 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: possibl= e > > > > 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 th= e > > > > 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. > > Antti Antti, my very simple question: Do the two clocks (125 and 62 MHz) run continuously? They should, or more precisely: THEY MUST, and all speed control is to be done by WE and RE. I am sure that's covered in the User Guide. PeterArticle: 144656
Antti, If he is looking for something for free, then that is fine. I do not have free IP for H.264. I wish him good luck. AustinArticle: 144657
On Dec 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote: > 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> wr= ote: > > > > > > > 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, on= ly FULL EMPTY > > > > > > > > > flags present. > > > > > > > > > > signals at input correct, as expected (checked with ChipS= cope) > > > > > > > > > signals at output: > > > > > > > > > - double value > > > > > > > > > - missing 1, 2 or 3 values > > > > > > > > > - FIFO will read out random number of OLD entries, this c= ould 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 woul= dn't work > > > > > > > > because of your specific implementation? It seems to have d= ifferent > > > > > > > > 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 work= arounds > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M= Hz write, > > > > > > > one is PLB clock 62.5MHz read > > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h= m 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 sour= ce? > > > > > > > 2) It seems like you have a PLB core that is reading from the F= IFO, > > > > > > 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 corege= n > > > > > FIFO's fail with about same symptoms, but in all > > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o= ut > > > > > > 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: possibl= e > > > > 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 th= e > > > > 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. > > Antti- Hide quoted text - > > - Show quoted text - Since you can't get further on the MGT clocking circuit topology, what about the 62.5 MHz read clock? How is this generated? It sounds like it could be glitching. In one of your other posts, you had mention that ChipScope had shown that the write data was correct and that the read data wasn't. Did you have two separate ILA cores with the 125 MHz and 62.5 MHz clocks when you did this testing? Ed McGettigan -- Xilinx IncArticle: 144658
On Dec 21, 4:43=A0pm, Antti <antti.luk...@googlemail.com> wrote: > 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> = wrote: > > >> > > >> Well once you have written and tested your own fifo then you = would=3D > > > have > > >> > > i=3D3D > > >> > > >t > > >> > > >> for any other project. It seems like you have wasted a lot of= time > > >> > > alread=3D3D > > >> > > >y > > >> > > >> trying to fix the Xilinx version so I dont see that you have = anyth=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 ab= solut=3D > > >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 wi= th yo=3D > > >ur > > >> > > >own, if there are other options. > > > >> > > >If 2 completly different FIFO implementations both have same er= ror? > > >> > > >you think 3rd one would instantly work? Could be, yes. > > > >> > > >Antti > > > >> > > In my opinion people tend to use coregen far too often. Looking = throu=3D > > >gh > > >> > > some of Xilinx code it is awfull. I went down the route of writi= ng 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 fast= er th=3D > > >an the > > >> > > Xilinx version. I also know to as good a degree as I can test th= at it=3D > > > will > > >> > > work 100%. > > >> > > I dont really think you can say that their fifos have been valid= ated =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 her= e is > > >> > the deal: > > > >> > =3DA0 component mgt_fifo > > >> > =3DA0 =3DA0 port ( > > >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 down= to 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 err= or > > >> > 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 p= ay. > > > >> > 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 on= e > > >> 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 = 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 tim= e > > >> 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 mak= e > > >> 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 use= d 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 a= ll > > >> 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 bi= gger 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? > > Antti Sometimes the simpler things can get in the way of complex issues. Are you certain your read enable and write enables are showing up relative to the correct data? It seems some people expect the read enable to indicate the valid data is being removed from the FIFO while others believe the read enable should produce valid data on the following clock. Double check where the documentation says the valid data should be relative to the enable pulse especially for the read, but check the write as well. ___ How deep do you want your FIFO? Is latency an issue? Do you want rd_en to indicate you're taking valid data or that the next clock is valid? You want wr_en to be present in the same clock cycle as the din, right? Long time no post (partly because I miss having a real newsreader), - John_HArticle: 144659
On Dec 22, 1:12=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Dec 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > 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> = wrote: > > > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wro= te: > > > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wro= te: > > > > > > > > > > Antti wrote: > > > > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, = only FULL EMPTY > > > > > > > > > > flags present. > > > > > > > > > > > signals at input correct, as expected (checked with Chi= pScope) > > > > > > > > > > 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 wo= uldn't work > > > > > > > > > because of your specific implementation? It seems to have= different > > > > > > > > > work-arounds depending on whether the read clock is faste= r or slower > > > > > > > > > than the write clock. Do your clocks change frequency? > > > > > > > > > > Are you sure your clocks don't have any glitches? The res= et also? > > > > > > > > > Power's OK? Is your office made of Cobalt 60? > > > > > > > > > > HTH., Syms. > > > > > > > > > 1) I entered the clock figures in FIFO16 implementationm, b= ut the > > > > > > > > error also happens with BRAM based FIFO that do not need wo= rkarounds > > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 12= 5MHz 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 move= s as the > > > > > > > CDR moves. =A0Why are you using this instead of the REFCLK so= urce? > > > > > > > > 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 t= he guy > > > > > > says it is OK all the way it is connected. > > > > > > > yes, It is very unlikely to belive that all THREE types of core= gen > > > > > > 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 syncronis= e the > > > > > > fifo? > > > > > > > Antti > > > > > > PS I just received a attempt to collect the reward, by using no= n > > > > > > 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: possi= ble > > > > > ambiguity of Full and EMPTY) > > > > > Since you use two clocks that are roughly 2:1 in frequency, I hop= e > > > > > 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. > > > Antti- Hide quoted text - > > > - Show quoted text - > > Since you can't get further on the MGT clocking circuit topology, what > about the 62.5 MHz read clock? =A0How is this generated? =A0It sounds lik= e > it could be glitching. > > In one of your other posts, you had mention that ChipScope had shown > that the write data was correct and that the read data wasn't. =A0Did > you have two separate ILA cores with the 125 MHz and 62.5 MHz clocks > when you did this testing? > > Ed McGettigan > -- > Xilinx Inc Peter, Ed, et others * yes both clock are running all the time * 125MHz is coming from MGT (recovered clock) there is no gating * the 62.5mhz clock is PLB clock directly there is no gating * the 62.5mhz read is generated as edge detect that generates 1 clk wide pulse on PLB reads * I used separate ILA cores in different clock domains * Routing out the 125MHz for external scope would not show the internal signal same as it is seen by the FIFO module, besides the IOB characteristics would filter out something and introduce an delay so the measurement would not be likely to show anything. OTOH the chipscope inside the FPGA also doesnt tell much about the clock, except that the data if clocked with the selected clock is latched properly at the same conditions where FIFO does go crazy. * The design occupies about 80% of all available resources of Virtex-4 FX40, in order to see the error, I have to start 2 units with GbE to the first one and fiber link between the two, and send specific commands to the master unit where the packets are processed by PPC running custom firmware, that then triggers the condition in the slave where then the problem can be seen. If anyone says this kind of system can be simulated with meaningful results I am all ears to know the setup for this. It doesnt make sense to simulate Xilinx FIFO's they are almost certain not to exhibit the observed fault behavior. the possibilities i still see are: 1) one of the clocks has something really "bad" in it, do not even know what it could be: 1.2Ghz ringing? short bursts of some very high frequency that do not trigger CS but do trigger FIFO ? 2) Xilinx tools are missing the timing that badly that all 4 type of fifos inhibit similar error, but parallel connected CS core doesnt? 3) Problem with power supply? 4) Unspecified technical problem? 5) Me needing in sign off from this project to preserve my sanity? It could be 5, it can be that the problem is there but I constantly connect CS to some other clock and the FIFO's are one some other clock that has problem. Well I have asked help, and a fellow engineer has looked over the clock routing and what he has said is that it is all OK the way it is right now. Maybe he needs a break as well. AnttiArticle: 144660
Hi, Where can I get the information on resource usage (and current consumption) of the FFT cores for Altera devices (specifically 32k to 512k fixed point for Stratix family). I tried a web search but no decent results. NagarajArticle: 144661
On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote: > On Dec 21, 4:43=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > 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> wrot= e: > > > > >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk= > wrote: > > > >> > > >> Well once you have written and tested your own fifo then yo= u would=3D > > > > have > > > >> > > i=3D3D > > > >> > > >t > > > >> > > >> for any other project. It seems like you have wasted a lot = of time > > > >> > > alread=3D3D > > > >> > > >y > > > >> > > >> trying to fix the Xilinx version so I dont see that you hav= e anyth=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 = absolut=3D > > > >e > > > >> > > >premium > > > >> > > >And if the system working (except occasional errors about 2 o= f fiber > > > >> > > >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 = error? > > > >> > > >you think 3rd one would instantly work? Could be, yes. > > > > >> > > >Antti > > > > >> > > In my opinion people tend to use coregen far too often. Lookin= g throu=3D > > > >gh > > > >> > > some of Xilinx code it is awfull. I went down the route of wri= ting my=3D > > > > own > > > >> > > fifos not because I had a problem with Xilinx fifos but becaus= e I bel=3D > > > >ieve a > > > >> > > fifo written by myself is a lot more flexible and simulates fa= ster 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 val= idated =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 h= ere is > > > >> > the deal: > > > > >> > =3DA0 component mgt_fifo > > > >> > =3DA0 =3DA0 port ( > > > >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 do= wnto 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 e= rror > > > >> > 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 g= et > > > >> 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\hd= l > > > >> \vhdl. > > > > >> There are multiple implementations, including an async BRAM based = one > > > >> that has the same ports as you list above, except that it uses exi= st > > > >> 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. =3DA0Thi= s 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 t= ime > > > >> of the error. > > > > >> If you have not used it before, FPGA editor has the ability to fin= d a > > > >> ChipScope ILA core, and change what is connected to it. That can m= ake > > > >> it much quicker to follow the trail of clues since you avoid havin= g 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 u= sed a > > > >> 125 MHz clock from the MGT, but it was not the recovered clock, bu= t > > > >> 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 t= he > > > >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 t= o > > > 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 = bigger 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? > > > Antti > > Sometimes the simpler things can get in the way of complex issues. > > Are you certain your read enable and write enables are showing up > relative to the correct data? > It seems some people expect the read enable to indicate the valid data > is being removed from the FIFO while others believe the read enable > should produce valid data on the following clock. > > Double check where the documentation says the valid data should be > relative to the enable pulse especially for the read, but check the > write as well. > ___ > > How deep do you want your FIFO? > Is latency an issue? > Do you want rd_en to indicate you're taking valid data or that the > next clock is valid? > You want wr_en to be present in the same clock cycle as the din, > right? > > Long time no post (partly because I miss having a real newsreader), > - John_H Hi John, 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO wr_en is active when the incoming char is not IDLE. 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow anyway :( 3 rd_en almost do not care, well currently it is wrong, 1 clock too late so PPC doesnt pull the last value from fifo (it is pulled when new data comes in), but this minor issue does really not explain the error where the fifo reads out out half of the old values AnttiArticle: 144662
On Dec 21, 3:12=A0pm, Antti <antti.luk...@googlemail.com> wrote: > 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> wr= ote: > > > > > > > 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, on= ly FULL EMPTY > > > > > > > > > flags present. > > > > > > > > > > signals at input correct, as expected (checked with ChipS= cope) > > > > > > > > > signals at output: > > > > > > > > > - double value > > > > > > > > > - missing 1, 2 or 3 values > > > > > > > > > - FIFO will read out random number of OLD entries, this c= ould 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 woul= dn't work > > > > > > > > because of your specific implementation? It seems to have d= ifferent > > > > > > > > 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 work= arounds > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M= Hz write, > > > > > > > one is PLB clock 62.5MHz read > > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h= m 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 sour= ce? > > > > > > > 2) It seems like you have a PLB core that is reading from the F= IFO, > > > > > > 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 corege= n > > > > > FIFO's fail with about same symptoms, but in all > > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o= ut > > > > > > 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: possibl= e > > > > 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 th= e > > > > 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. > > Antti Hello Antti, With four different FIFOs all failing, it is not likely that they are the source of the problem, just where the symptoms are showing up, as if you did not already know that. If you still want suggestions, here are a few. First, I always consider having an error condition I can trigger on to be worth its weight in gold and you apparently have one in the FIFO. Put in ChipScope with multiple ILAs observing one of the FIFOs that you have source code for. Use what ever you are currently triggering on to trigger the other ILAs. Put one on the write clock domain, and one on the read clock domain. Have them look at all of the IOs, as well as the counters and other logic in the FIFO. I doubt that you will find a problem with the FIFO, but something will look wrong and give you a clue to follow. Also use separate ILAs to watch the read and write clocks. I am always suspicious of IO clocks, I have seen too many problems with them. If one of those clocks is having a problem, and you are using that clock as the clock for the ILA, you will not see the clock problem with that ILA. Since you are using the recovered clock instead of the reference clock (which you can do, and is how we do it), I would pay extra attention to it. Over sample the read and write clocks by either using one faster clock, or multiple ILAs running on multiple phases of a faster clock. On a Virtex-4FX, we have multiple MGTs/EMACs running GigE. We use the 125 MHz reference clock instead of the recovered clock so we only have one 125 MHz clock to deal with. We feed it through a PMCD to generate the 62.5 MHz clock so that they are not asynchronous. That give us a bit less to have to deal with. Do you have access to a digital storage oscilloscope? If so, run the ILA trigger out of the FPGA and use that to trigger the scope. Use it to look at the clocks and power supplies, and anything else that the other test turned up. Use the timing analyzer to look for unconstrained paths. Look for any cross clock domain buses that have more than a cycle of skew on them. I have not seen that cause problems yet, but I use from to constraints to minimize skew to prevent a gray coded bus from having more than a cycle of skew crossing domains and causing problems. I don't think it is a high probability, but your symptoms remind me of the time we wrote our own FIFO that had different read and write widths and incremented the Gray code counter by two. That would cause two bits to change at a time, and eventually that would cause it to fail. Good luck, and remember that it it was easy, it would not be called hardware. John McCaskill www.FasterTechnology.comArticle: 144663
Hi, thanks for the response. That much I know from scouring around the internet. In fact, I have the Xilinx Platform Cable USB II. Perhaps I should be more clear: I guess I'm looking for a clear step-by-step procedure (for lack of a better term) for downloading and running a project on the ML402. -Sean. > 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. =A0It 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: 144664
On Dec 22, 7:02=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Dec 21, 3:12=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > 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> = wrote: > > > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wro= te: > > > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wro= te: > > > > > > > > > > Antti wrote: > > > > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, = only FULL EMPTY > > > > > > > > > > flags present. > > > > > > > > > > > signals at input correct, as expected (checked with Chi= pScope) > > > > > > > > > > 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 wo= uldn't work > > > > > > > > > because of your specific implementation? It seems to have= different > > > > > > > > > work-arounds depending on whether the read clock is faste= r or slower > > > > > > > > > than the write clock. Do your clocks change frequency? > > > > > > > > > > Are you sure your clocks don't have any glitches? The res= et also? > > > > > > > > > Power's OK? Is your office made of Cobalt 60? > > > > > > > > > > HTH., Syms. > > > > > > > > > 1) I entered the clock figures in FIFO16 implementationm, b= ut the > > > > > > > > error also happens with BRAM based FIFO that do not need wo= rkarounds > > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 12= 5MHz 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 move= s as the > > > > > > > CDR moves. =A0Why are you using this instead of the REFCLK so= urce? > > > > > > > > 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 t= he guy > > > > > > says it is OK all the way it is connected. > > > > > > > yes, It is very unlikely to belive that all THREE types of core= gen > > > > > > 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 syncronis= e the > > > > > > fifo? > > > > > > > Antti > > > > > > PS I just received a attempt to collect the reward, by using no= n > > > > > > 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: possi= ble > > > > > ambiguity of Full and EMPTY) > > > > > Since you use two clocks that are roughly 2:1 in frequency, I hop= e > > > > > 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. > > > Antti > > Hello Antti, > > With four different FIFOs all failing, it is not likely that they are > the source of the problem, just where the symptoms are showing up, as > if you did not already know that. > > If you still want suggestions, here are a few. > > First, I always consider having an error condition I can trigger on to > be worth its weight in gold and you apparently have one in the FIFO. > Put in ChipScope with multiple ILAs observing one of the FIFOs that > you have source code for. =A0Use what ever you are currently triggering > on to trigger the other ILAs. =A0Put one on the write clock domain, and > one on the read clock domain. =A0Have them look at all of the IOs, as > well as the counters and other logic in the FIFO. =A0I doubt that you > will find a problem with the FIFO, but something will look wrong and > give you a clue to follow. > > Also use separate ILAs to watch the read and write clocks. =A0I am > always suspicious of IO clocks, I have seen too many problems with > them. If one of those clocks is having a problem, and you are using > that clock as the clock for the ILA, you will not see the clock > problem with that ILA. Since you are using the recovered clock instead > of the reference clock (which you can do, and is how we do it), I > would pay extra attention to it. =A0Over sample the read and write > clocks by either using one faster clock, or multiple ILAs running on > multiple phases of a faster clock. =A0On a Virtex-4FX, we have multiple > MGTs/EMACs running GigE. =A0We use the 125 MHz reference clock instead > of the recovered clock so we only have one 125 MHz clock to deal > with. =A0We feed it through a PMCD to generate the 62.5 MHz clock so > that they are not asynchronous. =A0 That give us a bit less to have to > deal with. > > Do you have access to a digital storage oscilloscope? =A0If so, =A0run th= e > ILA trigger out of the FPGA and use that to trigger the scope. Use it > to look at the clocks and power supplies, and anything else that the > other test turned up. > > Use the timing analyzer to look for unconstrained paths. Look for any > cross clock domain buses that have more than a cycle of skew on them. > I have not seen that cause problems yet, but I use from to constraints > to minimize skew to prevent a gray coded bus from having more than a > cycle of skew crossing domains and causing problems. =A0I don't think it > is a high probability, but your symptoms remind me of the time we > wrote our own FIFO that had different read and write widths and > incremented the Gray code counter by two. That would cause two bits to > change at a time, and eventually that would cause it to fail. > > Good luck, and remember that it it was easy, it would not be called > hardware. > > John McCaskillwww.FasterTechnology.com Thank you John, AnttiArticle: 144665
austin wrote: > If he is looking for something for free, then that is fine. I do not > have free IP for H.264. > > I wish him good luck. A "Guru" with a gmail account could implement the 670 pages standard ( http://www.itu.int/rec/T-REC-H.264-200903-I/en ) in zero time. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 144666
Griffin <captain.griffin@gmail.com> writes: >Hi, thanks for the response. >That much I know from scouring around the internet. In fact, I have >the Xilinx Platform Cable USB II. Perhaps I should be more clear: I >guess I'm looking for a clear step-by-step procedure (for lack of a >better term) for downloading and running a project on the ML402. >-Sean. http://www.fpga4fun.com/ISEQuickStart.html gives a quick overview of the basic steps of loading code in to an FPGA using ISE (as I think the ML402 is Xilinx, there is a version for Quartis on the site as well if I'm wrong). Its for an older version of ISE so the screen shots aren't quite correct but it gives the flow you need to compile and load a project which is I think what you are asking for. It got me to the point of being able to successfully compile, load and execute one of their example progams (writing my own is likely quite another matter though :-)) into their Dragon board using a later version of ISE. At the end of it there is a reference to Xilinx tutorials for the various versions of ISE (I haven't gotten that far yet though :-)) Peter Van EppArticle: 144667
Antti <antti.lukats@googlemail.com> wrote: (big snip) > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO > wr_en is active when the incoming char is not IDLE. > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow > anyway :( > 3 rd_en almost do not care, well currently it is wrong, 1 clock too > late so PPC doesnt pull the last value from fifo (it is pulled when > new data comes in), but this minor issue does really not explain the > error where the fifo reads out out half of the old values If the fifo is empty half the time, then half the time you will be reading the wrong value. -- glenArticle: 144668
To follow on, here are some of my thoughts:
- I would try to limit the scope of this issue by using a chain of three async identical FIFOs (with the control signals properly forwarded: the point is to make the whole thing transparent, although with increased cycle latency)
[MGT] ---> [FIFO #1] ---> [FIFO #2] ---> [FIFO #3] ---> [PLB]
MGT, FIFO #1 (both ports), inbound port of FIFO #2 @ 125 MHz
Outbound port of FIFO #2, FIFO #3 (both ports), and PLB @ 62.5 MHz
The FIFO #1 and #3 are useless but they may experience the issue you are facing, bringing up interesting facts such as knowing which port is going south.
Also I guess that you already went through the obvious items:
- I would check and re-check __myself__ the clocking scheme inside and outside the FPGA
- Same thing with power-supply
- Check that all I/O pads are LOC'ed (I once had an unconstrained pad due to a typo inside the UCF file, nasty things followed)
- Check that the FIFO reset is performed correctly (all clock stable, FIFO state is idle) and meets the required duration
- A good sleep, cold shower and breakfast are very effective when dealing with though issues !!
--
Matthieu Michon <prenom.nom@gmail.com>
Article: 144669>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. > >Ales > thank you Ales, I use MPMC memory in my design. but, can you tell me if I can put two cores processors on the same PLB bus or not? and if it is possible, what is the best method to working for : using two PLB buses for each core processor or a single PLB bus for both?? thank you very much for your great help INES --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144670
On Dec 22, 10:09=A0am, "ines_fr" <benhlima_i...@yahoo.fr> wrote: > >On Dec 21, 12:36=3DA0pm, "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 =3DA0 =3DA0 =3DA0 > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> This message was sent using the comp.arch.fpga web interface > onhttp://www=3D > >.FPGARelated.com > > >I do not think that you can put more than two if you use MPMC memory > >controller. > > >Ales > > thank you Ales, > I use MPMC memory =A0in my design. but, =A0can you tell me if I can put t= wo > cores processors =A0 on the same PLB bus =A0or not? and if it is possible= , what > is the best method to working for : using two PLB buses for each core > processor =A0or a single PLB bus for both?? > > thank you very much for your great help > > INES =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com- Hide quoted text - > > - Show quoted text - Hi, MPMC has 8 ports and each port can be a dual-XCL (handling two XCL interfaces) so in theory you can have 8 MicroBlaze connected to MPMC and external memory. But you woulnd't be able to have any other master accessing the external memory. G=F6ranArticle: 144671
Guru <ales.gorkic@gmail.com> wrote:
>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?
I've been down that route. FPGA is the wrong choice for such a
project! A SoC with an H.264 accellerator or DSP is the cheapest,
easiest and least power hungry solution. For example: a Freescale
IMX27 costs less than the FPGA.
--
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: 144672I tried to import the IP cores to a new project (through a global/local repository or peripheral import), but the only core that is detected correctly is the "GammaCore" which is kinda useless without the others. I used EDK10 and 11 (both full patched) and also downloaded the ug456.zip from the xilinx hp to get the latest release of the cores. Besides that, the size of the other cores seem to be quite small compared to the working GammaCore. I tried to import both versions of the IPs, the one on the provided cd and the one from the xilinx hp. Has anyone successfully imported and used the IP cores? -- regards, MaikArticle: 144673
On Tue, 22 Dec 2009 09:36:39 +0100, Matthieu Michon <prenom.nom@gmail.com> wrote: >To follow on, here are some of my thoughts: > > >- I would try to limit the scope of this issue by using a chain of three async identical FIFOs (with the control signals properly forwarded: the point is to make the whole thing transparent, although with increased cycle latency) > [MGT] ---> [FIFO #1] ---> [FIFO #2] ---> [FIFO #3] ---> [PLB] > MGT, FIFO #1 (both ports), inbound port of FIFO #2 @ 125 MHz > Outbound port of FIFO #2, FIFO #3 (both ports), and PLB @ 62.5 MHz >The FIFO #1 and #3 are useless but they may experience the issue you are facing, bringing up interesting facts such as knowing which port is going south. > > >Also I guess that you already went through the obvious items: > >- I would check and re-check __myself__ the clocking scheme inside and outside the FPGA This triggered one thought. when checking the clocking arrangements, have you done so in the technology view? (or the post-synthesis netlist, which I find MUCH easier to search?) Somewhere between ISE7.1 and ISE10.1, XST changed the way it inferred clock buffers, so that a correct design in 7.1 became incorrect in 10.1... So if the non-Antti part was verified it a previous existence, and imported to this design, something may have changed even though the source is identical. In my case it manifested as a named clock which inferred an IBUFG into (a) logic and (b) a DCM to generate related clocks - correctly in 7.1. ISE10.1 inferred the IBUFG for the named clock - to the logic only; taking the DCM feed from the IBUF part (ahead of the BUFG) - thus the "related" clocks were skewed ahead of the logic clock by a few ns. This took a while to find, since it was in stable "proven" code, and shook me up a bit. It was definitely not what I asked for, but not quite a synthesis bug... And one case where explicitly instantiating Xilinx-specific black boxes proved to be necessary. I have no idea if this is related to your problem, but the weight of evidence does suggest some common problem causing all the FIFOs to fail. Alternatively: think about a simple clock domain crosser in registers, (depth = 1) either ahead of or after a synchronous FIFO. (After is easier, because it is controlled by the slow PLB). Even if it doesn't work, it gives you a probe point between the FIFO and the clock crosser, which will hopefully exonerate one of them... - BrianArticle: 144674
On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote: > > > Sometimes the simpler things can get in the way of complex issues. > > > Are you certain your read enable and write enables are showing up > > relative to the correct data? > > It seems some people expect the read enable to indicate the valid data > > is being removed from the FIFO while others believe the read enable > > should produce valid data on the following clock. > > > Double check where the documentation says the valid data should be > > relative to the enable pulse especially for the read, but check the > > write as well. > > ___ > > > How deep do you want your FIFO? > > Is latency an issue? > > Do you want rd_en to indicate you're taking valid data or that the > > next clock is valid? > > You want wr_en to be present in the same clock cycle as the din, > > right? > > > Long time no post (partly because I miss having a real newsreader), > > - John_H > > Hi John, > > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO > wr_en is active when the incoming char is not IDLE. > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow > anyway :( > 3 rd_en almost do not care, well currently it is wrong, 1 clock too > late so PPC doesnt pull the last value from fifo (it is pulled when > new data comes in), but this minor issue does really not explain the > error where the fifo reads out out half of the old values > > Antti If the rd_en is one cycle off, the data during that cycle is undefined. If the rd_en is active for two cycles, the data extracted will be precisely one cycle off for the rd_en pulses after the first. The specific FIFO implementation may provide what looks like valid data - or not - during the first of those consecutive rd_en pulses. I would *love* to know how much data is "good" versus "bad" with the rd_en realigned. - John_H
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