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 19, 4:21=A0am, John Adair <g...@enterpoint.co.uk> wrote: > Our Craignell2 DIL modulehttp://www.enterpoint.co.uk/component_replacemen= ts/craignell2.html > has been built with FPGA parts from the XC3S200A to XC3S1400A in the > FTG256 package. We did to confirm that we didn't have pinning issues. > We didn't bother with the XC3S50A because it caused to many issues > with pins in the design. I think the XC3S700A and XC3S1400A were > afterthoughts in the family and hence the power pin moves on those > parts. The derivative development board product Drigmorn2 is being > built with XC3S700A but we will probably build it with other chip fits > for OEM customers. > > Whilst these boards were not built to support LVDS we avoided a lot of > pin problems by not using pins that become input only on any of the > variants. This does cut down the usable pins a lot and one of my pet > hates of an otherwise good family. Interestingly Spartan-6 looks a lot > better in this respect and we put a lot LVDS support into Drigmorn3 > the next member of the family. For LVDS output you are restricted to > banks 0 and 2. For inputs use any bank. We have not had any problems > with excessive power either. > > John Adair > Enterpoint Ltd. - Home of Drigmorn2. The Spartan-3A Starter Board. > > On 19 Dec, 05:48, Patrick Maupin <pmau...@gmail.com> wrote: > > > 1) Has anybody designed a board that will work with all members of the > > Spartan3A family in an FT256? =A0Do you use any special pin programming > > on, for example an XC3S400A, to keep it from pulling excessive current > > when it's in the transition region because it's connected to VCCINT > > (because that pin site is a VCCINT pin in an XC3S700A/XC321400A)? > > Also, it seems like the extra startup current (before configuration) > > for all the XC3S700A/XC3S1400A VCCINT/GND pins which are I/O pins in > > an XC3S400 would be in the range of 10 mA or so for the XC3S400. =A0Doe= s > > that sound about right? > > > 2) The Spartan 3A documentation states that LVDS output can only be > > used on banks 0 and 2. =A0It also states that internal 100 ohm LVDS > > receive termination is only available on pins that are output pins, > > but it doesn't explicitly state whether this includes output pins in > > banks 1 and 3, or whether "output" in this context means "pins which > > are capable of LVDS output" =A0(which would only include pins in banks = 0 > > and 2). > > > I suppose for question 2 I can fairly easily fire up ISE and find the > > answer. =A0Maybe I'll do that tomorrow. > > > Thanks, > > Pat Thanks for the quick reply! I think my board will probably support the 50 on up, simply because I'm not going to try to make that many pins available. (But, at the end, I might do like you and give up on it -- that remains to be seen.) Best regards, PatArticle: 144601
I would suggest holding the DCM in reset until the input clock is
stable and running at correct rate. Note also the lock times can be up
nearly 3ms in some circumstances going by the data in datasheet ds099.
John Adair
Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Starter Board.
On 19 Dec, 17:25, ghelbig <ghel...@lycos.com> wrote:
> Details I should have included:
>
> The external clock is a synthesizer that defaults to 50MHz. =A0After
> initialization, it is changed to 100MHz. =A0The DCM is used to reduce
> the skew between the internal clock and the external clock and create
> a half-speed clock for some of the logic.
>
> Some percentage of the time, the chip "just don't run"; my current
> theory is that the clock comes up strange.
>
> I'm not getting anything useful from the status lines. =A0At the time
> the frequency is changed, I get a pulse on status[1]; after that, they
> are always low. =A0I've waited "forever", and the locked signal never
> goes true.
>
> Thanks!
>
> On Dec 19, 2:36 am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > Don't rely on the locked signal for anything. Use the status lines and
> > make your own locked signal.
>
> > The DCM does take a while to fully lock up during which time you will
> > get strange frequencies and strange mark/space ratios. If you are
> > trying to do something like a power saving frequency switch you might
> > be better either to use clock enables to change effective clock rate
> > or alternatively using an external synthesiser that supports these
> > sort of frequency changes a bit more elegantly.
>
> > John Adair
> > Enterpoint Ltd.- Home of Merrick1. The Data Mining Solution.
>
> > On 18 Dec, 23:52, ghelbig <ghel...@lycos.com> wrote:
>
> > > My apologies if this has been addressed - my web searches came up
> > > empty.
>
> > > I am using a DCM in a spartan3 to generate the internal clocks - a 1-=
X
> > > clock and a 1/2-X clock.
>
> > > The output of the DCM goes to a BUFG. =A0The output of the BUFG goes =
to
> > > the feedback pin of the DCM, and to the rest of the logic.
>
> > > After initialization, the input clock changes frequency. =A0Shortly
> > > after that, I send a reset (7 clock wide) to the DCM.
>
> > > The locked signal from the DCM goes away about 22uS after the input
> > > clock changes. =A0I see a short pulse on status[1] indicating that it
> > > didn't like the input clock, and 22uS later Locked goes low.
>
> > > About 20uS after that, I send the reset pulse to the DCM. =A0Locked
> > > never (never) goes high again.
>
> > > The output clock is present, but the logic is behaving like the
> > > warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other
> > > spurious behavior") is very true.
>
> > > Any clues, hints, sympathy?
>
> > > Redards,
> > > Gary.
Article: 144602On Dec 19, 11:25=A0am, ghelbig <ghel...@lycos.com> wrote: > Details I should have included: > > The external clock is a synthesizer that defaults to 50MHz. =A0After > initialization, it is changed to 100MHz. =A0The DCM is used to reduce > the skew between the internal clock and the external clock and create > a half-speed clock for some of the logic. > > Some percentage of the time, the chip "just don't run"; my current > theory is that the clock comes up strange. There are a few possibilities here. A couple off the top of my head: 1) Your synthesizer has excessive jitter at 100 MHz; 2) Your clock termination, board traces, etc. smear the clock out and reduce the amplitude greatly at 100 MHz. This can also look (to the FPGA) like jitter, as you have a slow ramp through the transition region, but this could even look like missing clocks if it is bad enough. My favorite debugging technique in this scenario is to blow off the DLL, and take the clock straight out another I/O pin, and hang a scope off it. This is a little hard to do at 100 MHz, so the next best thing is to take the clock in as a clock (again without the DLL), and have a couple of counters, one running off the posedge, and one running off the negedge. For example, if you bring the outputs of a divide by four on the negedge and a divide by four on the posedge out a couple of pins, now you have two locked 25 MHz signals. Put them on a scope on infinite persistence, and look for anomalies. HTH, Pat 1) Your clock termination frequency doesn't actual swi Have you checked the jitter of the input clock when it is running at 100 MHz.Article: 144603
Hi, The memory on a fpga is limited. But the latency of external memory is still a bottleneck. Especially because the local bus has to share its resources. Anybody who knows a development board/fpga that has a reduced latency of the external memory? --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144604
Ghostboy wrote: > Hi, > > The memory on a fpga is limited. But the latency of external memory is > still a bottleneck. Especially because the local bus has to share its > resources. Anybody who knows a development board/fpga that has a reduced > latency of the external memory? Hi, you don't specify what "reduced latency" is, reduced compared to what ? What is your goal ? Can you speak a bit about your application ? BTW latency is (roughly) proportionnal of - the price of the components - their age - the required capacity all 3 are very closely related. If you only need a few megabytes, some parts (quite expensive) are very fast : there are synchronous SRAMs, some with dual data rate, used in the telecom industry, that go above 200MHz in pipelined mode. Some recent Altera/Xilinx go even faster on expensive reference boards, IIRC. Look at these manufacturers : ISSI, GSI, IDT, Cypress,... Example of an interesting part that I found with a broker : GSI's GS8322Z36B-225 has 1M words of 36 bits, capable of 225MHz (cycle time below 5ns). Some newer parts are even faster (350MHz ?) and have dedicated data buses for read and write. Now, the price may be a problem, not only the part itself but also the PCB technology that the BGA packaging requires... If you need a ready-made solution, it's going to cost you what you'll get (a lot). But there are probably many ways to turn your problem around so it does not kill your budget : for example if your application can be designed to use cache optimisations, strip-mining or space-time locality, then your onchip SRAM could be enough. But I suppose that if large SRAMs exist, it is because not all algorithms can be tweaked this way :-) hope it helps, yg -- http://ygdes.com / http://yasep.orgArticle: 144605
On Dec 15, 11:35=C2=A0am, John Adair <g...@enterpoint.co.uk> wrote: > The V2pro board from Digilent is good value but do take note of the > software issues Austin talks about. > > For what you are describing I'd suggest a board with either SDRAM/DDR > and/or a FPGA that has lots of blockrams. The Spartan-3A DSP does fit > the bill well but there are not many cheap boards with these chips on. > From our products I would suggest Darnaw1, Drigmorn2, Drigmorn3 for > the lower end of what you need. A better fit may be the next board we > launch next month which is Raggedstone2. It has DDR3 and because it > has Spartan-6 XC6SLX45T a reasonable blockram count. This board with > student discount will be at the top of your range but will have a USB > Cable to ship with it. > > John Adair > Enterpoint Ltd. > > On 15 Dec, 03:56, "Ste" <lords...@hotmail.com> wrote: > > > Hello, all! > > > I'm interested in exploring digital design with FPGAs for both learning > > purposes and to help with a senior design project I'll be working on. = =C2=A0To > > start, I spent my entire 1st day of winter break (yay!) looking at > > different starter boards, and I'm pretty much lost. =C2=A0I was wonderi= ng if > > someone could explain the practical differences between the various FPG= A > > boards currently on Digilent's website:http://www.digilentinc.com/Produ= cts/Catalog.cfm?NavPath=3D2,400&Cat=3D10 > > It would be awesome if someone could give me a recommendation on what b= oard > > would be best for me based on the info in this post. I'm typically look= ing > > for something =E2=89=A4$200, but I'm willing to pay $300 for the XUP Vi= rtex-II > > Pro (if necessary), since it seems like a killer deal for students. > > > I guess a lot of this depends on what type of applications you will use= the > > boards for, so I guess I'll explain a bit about my project: > > This past fall semester of school, I took an image processing course an= d > > also my first DSP course. =C2=A0I want to start my senior design projec= t early > > (due May 2011) so I came up with an idea that would emphasize what I > > learned in those two courses. =C2=A0Anyway, my project's goal is to tap= the > > 18-bit RGB lines on a Nintendo DS and produce a 640x480p/i YPbPr/Analog= -RGB > > video output. =C2=A0Though that would probably be something complicated= on its > > own, my main focus would be various selectable screen output modes. =C2= =A0For > > example: > > Mode A) Top Screen only, 256 x 192 centered with black borders all arou= nd > > Mode B) Bottom Screen only, 256 x 192 centered with black borders all > > around > > Mode C) Top Screen only, 256 x 192 resized (bilinear interpolation) to = 640 > > x 480 > > Mode D) Top screen directly above Bottom screen, no gap between screens > > Mode E) Top screen above Bottom screen, 64-line gap filled with > > interpolated data from both screens and/or motion predicted pixels > > > ..and quite a few more modes. > > > I found a thread on here where someone was trying to accomplish somethi= ng > > very similar:http://www.fpgarelated.com/usenet/fpga/show/77345-1.php > > The recommended board for that type of project is the Spartan-3. =C2=A0= But my > > project will probably require more/better "stuff" to be able to impleme= nt > > the various video processing functions, right? =C2=A0Plus, that's an ol= d thread > > and there are a lot of newer boards out there now, so I don't know what= to > > think. =C2=A0I'm totally lost. > > > Oh, and here's some more specific info on what I plan to do: > > I would like to be taking FFTs to help with the video scaling, so I wou= ld > > prefer something capable of that. =C2=A0But, I can avoid the frequency = domain > > altogether if the price difference for that capability is too large. = =C2=A0Also, > > I would probably need to buffer more than one frame of video for the ga= p > > interpolation, and I'm assuming the Spartan-3's 1MB of RAM won't cut it= . > > Though, it seems that people like the RAM on the Spartan-3 because it i= s > > SRAM. > > > To anyone who actually read the mess of words I posted above, I thank y= ou. > > Feel free to respond and help out in any way. =C2=A0I'll take any info = that can > > be given to me and as always, it would be greatly appreciated. > > > -Stephan > > > --------------------------------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > This message was sent using the comp.arch.fpga web interface onhttp://w= ww.FPGARelated.com Agree about the Nexys2. They work great and have a transfer DLL you can use for data as well as FPGA programming, and lots of switches and blinky-lights to simplify debugging and report status, etc. In short, they're great. BUT... They *still* (after promising me they were working on it a couple of years ago) don't have any Linux drivers. There are a couple of open- source solutions floating around, but I don't think anybody has tidied it up and put a bow on it (but I could be wrong -- haven't looked lately). Where I work, we've probably purchased around 30 or 40 Nexys and Nexys 2 boards over the last 3 years, but I probably would have bought twice that many if I could easily use it on my Linux systems with minimal development. PatArticle: 144606
On Dec 20, 2:35=A0am, whygee <y...@yg.yg> wrote: > Ghostboy wrote: > > Hi, > > > The memory on a fpga is limited. But the latency of external memory is > > still a bottleneck. Especially because the local bus has to share its > > resources. Anybody who knows a development board/fpga that has a reduce= d > > latency of the external memory? =A0 =A0 =A0 > > Hi, > > you don't specify what "reduced latency" is, > reduced compared to what ? What is your goal ? > Can you speak a bit about your application ? > > BTW latency is (roughly) proportionnal of > =A0 - the price of the components > =A0 - their age > =A0 - the required capacity > all 3 are very closely related. > > If you only need a few megabytes, > some parts (quite expensive) are very fast : > there are synchronous SRAMs, some with dual data rate, > used in the telecom industry, that go above 200MHz > in pipelined mode. Some recent Altera/Xilinx go > even faster on expensive reference boards, IIRC. > Look at these manufacturers : ISSI, GSI, IDT, Cypress,... > > Example of an interesting part that I found with > a broker : GSI's GS8322Z36B-225 has 1M words of 36 bits, > capable of 225MHz (cycle time below 5ns). Some newer > parts are even faster (350MHz ?) and have dedicated > data buses for read and write. Now, the price may be > a problem, not only the part itself but also the > PCB technology that the BGA packaging requires... > > If you need a ready-made solution, it's going to cost > you what you'll get (a lot). But there are probably > many ways to turn your problem around so it does not > kill your budget : for example if your application > can be designed to use cache optimisations, strip-mining > or space-time locality, then your onchip SRAM could be enough. > But I suppose that if large SRAMs exist, it is because > not all algorithms can be tweaked this way :-) > > hope it helps, > yg > --http://ygdes.com/http://yasep.org latency depends memory TYPE mostly 0 latency (async) memory cost MUCH more then dynamic memory per bit AnttiArticle: 144607
On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote: > Details I should have included: > > The external clock is a synthesizer that defaults to 50MHz. =A0After > initialization, it is changed to 100MHz. =A0The DCM is used to reduce > the skew between the internal clock and the external clock and create > a half-speed clock for some of the logic. > > Some percentage of the time, the chip "just don't run"; my current > theory is that the clock comes up strange. > > I'm not getting anything useful from the status lines. =A0At the time > the frequency is changed, I get a pulse on status[1]; after that, they > are always low. =A0I've waited "forever", and the locked signal never > goes true. > > Thanks! Another suggestion, probably as helpful as "is it plugged in?" - make sure that the logic which generates your DCM reset isn't being clocked by that DCM. I facepalmed this once... EricArticle: 144608
Thank you. I'll tell a little bit more. The development board I have now is the XUPV2 with the Virtex-2 Pro XC2VP30 FPGA. The purpose of the project is to make video processing possible in real-time and with high resolutions. So the internal memory will not suffice. But I heard that the latency of the local bus is too high to make that possible. So I thought anybody could advice me another board or FPGA. Or am I just bad informed about those latencies? --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144609
Antti wrote: > latency depends memory TYPE mostly yes. > 0 latency (async) memory there can not be "0 latency" :-) it's better to measure this in nanoseconds. > cost MUCH more then dynamic memory per bit sure. it's always a trade-off... and the reduced cost of DRAM is offset by the complexity of driving the complex signals :-/ > Antti yg PS: is your server back online ? and your email ? -- http://ygdes.com / http://yasep.orgArticle: 144610
On Dec 20, 8:43=A0am, emeb <ebromba...@gmail.com> wrote: > On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote: > > > > > Details I should have included: > > > The external clock is a synthesizer that defaults to 50MHz. =A0After > > initialization, it is changed to 100MHz. =A0The DCM is used to reduce > > the skew between the internal clock and the external clock and create > > a half-speed clock for some of the logic. > > > Some percentage of the time, the chip "just don't run"; my current > > theory is that the clock comes up strange. > > > I'm not getting anything useful from the status lines. =A0At the time > > the frequency is changed, I get a pulse on status[1]; after that, they > > are always low. =A0I've waited "forever", and the locked signal never > > goes true. > > > Thanks! > > Another suggestion, probably as helpful as "is it plugged in?" - make > sure that the logic which generates your DCM reset isn't being clocked > by that DCM. I facepalmed this once... > > Eric Yeah, that's an excellent idea. Especially in a complicated design, reset loops are easy to achieve... PatArticle: 144611
On Dec 20, 9:48=A0am, "Ghostboy" <Ghost...@dommel.be> wrote: > The purpose of the project is to make > video processing possible in real-time and with high resolutions. So the > internal memory will not suffice. Video processing typically doesn't need access to large memories in order to do the processing. The processing operations are relatively local. For that, I'm sure you'll find that the Virtex has sufficient memory. The larger, slower, external memory is used for the bulk storage. In order to process the data, you move it from the external memory into the internal memory, process it and store it back in the external memory. In that scenario, memory latency is generally not an issue, only clock frequency. > But I heard that the latency of the local > bus is too high to make that possible. So I thought anybody could advice = me > another board or FPGA. Or am I just bad informed about those latencies? = =A0 > You seem to be misinformed about the requirements that you have for your own video processing and how one would implement that function in hardware. Kevin JenningsArticle: 144612
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. AnttiArticle: 144613
> Virtex-4, FIFOs I thought I read there was a bug in those...Article: 144614
On Dec 21, 11:40=A0am, Jon Beniston <j...@beniston.com> wrote: > > Virtex-4, FIFOs > > I thought I read there was a bug in those... Well there is a bug in the V4 FIFO16 hard-fifo, but Coregen says that it DOES APPLY PATCH to fix it. So I assumed that the FIFO's generated by Coregen do actually work, but it seems i was wrong :( AnttiArticle: 144615
Why dont you just write your own fifo? It shouldnt take that long and at least you would know it was 100% ok. Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144616
On Dec 21, 12:07=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Why dont you just write your own fifo? It shouldnt take that long and at > least you would know it was 100% ok. > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 Yeah, that advice I have myself ready :) well, I would most likely not use FIFO but make dual port RAM instead. Thing is that the system works, the firmware works, except that "small Xilinx FIFO problem" .. so if there is at all chance to FIX Xilinx FIFO and to make it WORK then it would made the system work without the need of rewriting HDL or C code AnttiArticle: 144617
Well once you have written and tested your own fifo then you would have it for any other project. It seems like you have wasted a lot of time already trying to fix the Xilinx version so I dont see that you have anything to loose by creating your own. Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144618
Thanks But what if I need to buffer a frame with a resolution of 1024*768 and it will constantly be updated? >On Dec 20, 9:48=A0am, "Ghostboy" <Ghost...@dommel.be> wrote: >> The purpose of the project is to make >> video processing possible in real-time and with high resolutions. So the >> internal memory will not suffice. > >Video processing typically doesn't need access to large memories in >order to do the processing. The processing operations are relatively >local. For that, I'm sure you'll find that the Virtex has sufficient >memory. The larger, slower, external memory is used for the bulk >storage. In order to process the data, you move it from the external >memory into the internal memory, process it and store it back in the >external memory. > >In that scenario, memory latency is generally not an issue, only clock >frequency. > >> But I heard that the latency of the local >> bus is too high to make that possible. So I thought anybody could advice = >me >> another board or FPGA. Or am I just bad informed about those latencies? = >=A0 >> > >You seem to be misinformed about the requirements that you have for >your own video processing and how one would implement that function in >hardware. > >Kevin Jennings > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144619
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.Article: 144620
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 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 AnttiArticle: 144621
On Dec 21, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Well once you have written and tested your own fifo then you would have i= t > for any other project. It seems like you have wasted a lot of time alread= y > trying to fix the Xilinx version so I dont see that you have anything to > loose by creating your own. > > Jon =A0 =A0 =A0 =A0 > 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. AnttiArticle: 144622
>On Dec 21, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: >> Well once you have written and tested your own fifo then you would have i= >t >> for any other project. It seems like you have wasted a lot of time alread= >y >> trying to fix the Xilinx version so I dont see that you have anything to >> loose by creating your own. >> >> Jon =A0 =A0 =A0 =A0 >> >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 own fifos not because I had a problem with Xilinx fifos but because I believe 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 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 --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144623
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.comArticle: 144624
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 hav=
e
> 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 anything
> 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 own
> fifos not because I had a problem with Xilinx fifos but because I believe=
a
> fifo written by myself is a lot more flexible and simulates faster than t=
he
> Xilinx version. I also know to as good a degree as I can test that it wil=
l
> 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:
component mgt_fifo
port (
din : in std_logic_vector(8 downto 0);
rd_clk : in std_logic;
rd_en : in std_logic;
rst : in std_logic;
wr_clk : in std_logic;
wr_en : in std_logic;
dout : out std_logic_vector(8 downto 0);
empty : out std_logic;
full : out std_logic);
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
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