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
In Peter's defense, The software is not his, nor is it his area of expertise. No, I'm not defending the software. In my opinion, they still haven't gotten back the utility and robustness of the old XACT6 software. Pity, seeing that it has been been nearly 2 years since M1 was released. The Virtex side is still not really ready for prime time. I've personally found and reported 2 show-stopper bugs in the last week and a half. Steve Dewey wrote: > Isn't it interesting that Peter Alkfe, who regularly gives advice and > explains the reasoning behind certain xylinx decisions always goes very > quiet when there is a discussion that highlights the shortcomings of the > software xylinx sells ? > > In article <01bf395a$df27ca70$207079c0@drt1>, Austin Franklin > <austin@darkroom098.com> writes > >> I would guess by the tone of your message that you are pretty frustrated > >> over this. > > > >Frustrated? HA! That's an understatement! > > > >And they ask me the most STUPID question they can possibly every ask "Why > >do you want to use that tool anyway?...NO ONE uses it". DAMN does that > >piss me off. I need to use THAT tool because with it, I can fill in the > >blanks that THEIR documentation leaves out...like what is the best IOB to > >use for the RESET input, where the hell IS the upper right and left corner > >of the die, with relation to the package...and just WHAT did the tools do > >to my logic? > > > >These, and many other questions can be answered with this tool...but their > >attitude is, "hey, the OTHER tools work just fine, so you don't really need > >that tool, Oh, and by the way, NO ONE uses it anyway"...GRRRRRRRR. > > > > -- > Steve Dewey > remove 123 to email. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19126
If you are like me - you really don't have a lot of time trying to figure out which books to buy. Cost is not that important. You only want to get the best literature without wasting valuable time. So - you want to learn VHDL from a book? It's easy. Go to Amazon.com and search for the VHDL title word, and you will end up with 100+ hits or so. Get ready to spend a lot of time trying to figure out which one to get. The good thing at Amazon.com is that they allow their customers to leave a short review of the book, which can be very useful info for those who come after. Then - you can search for the individual titles on the Internet, and soon you will have reduced the number of really interesting titles to 10 or so. You are in luck today. I just did this job for you. I've spent a lot of time searching for the best VHDL books. I have not read all of them myself, but all of these books have been receiving great reviews from users. To make it really easy for you, I have also for each book provided: - A direct link to the book's "homepage" at it's publisher's website. - 4 scripts which will start a search for the lowest price on most online book stores. - A direct link to the Customer Reviews at Amazon.com. If you have any suggestions for new additions, please send me an email. If you would like to review a book, I suggest you do that at the Amazon.com website - that would be very convenient for all of us! My report can be found at http://freecore.com Rune Baeverrud, November 1999Article: 19127
When I talked about Pentium MMX, I meant the use of MMX instruction set to speed up multimedia operations. After all, that's what MMX technology is all about. It uses SIMD (Single Instruction Mutiple Data) - or pipelining- technique to process data in parallel. 8 MACs can be performed in one cycle. As Steven kindly showed, A 500MHz PIII MMX may outperform FPGAs for 3x3 convolutions and I guess for many other small algorithms. I know that when the parallelism granularity gets bigger, there is nothing better than a dedicated hardware solution, but still for many applications, a GPP may do the job if well programmed. Though, MMX is programmed in assembly, it offers the SW flexibility. Concerning the power consumption, that's a fair point for FPGAs against GPP, but for ordinary PC users, who cares !! Most PC users do not care about it. After all, they will not use their PCs as image processors 24 hours a day. It is the speed they are asking for, in addition to the ease of use. It is nice to use FPGAs when you have the necessary support and $$$, but for most people, they stuck in front of a buggy silicon compiler or a rigid piece of hardware. I agree entirely with Steven about the communication overheads issue. Often, the performance is slow down by the lack of fast and flexible onboard memory, and you cannot do much about it, unless you design your own board ($$$). Frankly, most people would prefer using their general purpose Pentium processors, with a nice GUI debugger (if it can do the job of course) rather than buying an expensive FPGA board and spending weeks if not months struggling with the tools to make ends meet. I presume it depends on the problem you have in hand, I think that people should first consider flexible SW solutions before going any further, and not exlude them from the beginning even for computationaly intensive algorithms such as DSP.Article: 19128
Ray Andraka wrote: > Basically what I was trying to say. Given enough local memory and the bandwidth (pins) to access it, an FPGA can do > the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996 > paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate > using a tiled array of 4 chips similar to the Atmel AT6005s. But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom better than a good progammed CPU solution. I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation of a 2D 3x3 convoluiton with my PII600 " > > Arrigo Benedetti wrote: > > > Steven Derrien <sderrien@irisa.fr> writes: > > > > > > Not necessarily: the image stream can "flow-through" the FPGA and be processed > > on the fly. Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it requires for flushin the input and output imega in and out of the fpga. StevenArticle: 19129
Hi all I juste implemented a design in a Xilinx Virtex. The clock constraint is 20ns period, 10ns high. On one path, the total delay is (copied from the .log file): Total (4.935ns logic, 5.885ns route) 10.820ns (to clk_BUFGPed) The tool then tells me the minimum clock period is 21,640 ns (exactly twice the delay) Why does it want the delay to be less than half the clock period ? I thought it needed to be less than the entire period. Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 19130
> Why does it want the delay to be less than half the clock period ? Hi Nicolas, I think you use in you design the rising and the falling edge of you clock signal. That's why the transition delay between the part that clocked with rising edge and the part that clocked with the falling edge of your clock signal must be less than half of your clock delay. Hope it is the answer on your question. with best regards Bonio * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 19131
I have to transmit data using an optical link (100 MBd). How can I serialize / encode and deserialize / decode the data using an FPGA only (no analog solution, no CPU) ? Are there any pure digital solutions ? The way RS232 transmission works is not practicable (would need at least 400 MHz sampling clock) Where can I find descriptions of encoding technics. -- Manfred Kraus mkraus@cesys.com -- Manfred KrausArticle: 19132
Hi Bonio Hey! I just checked and you were right! I'm really confused... I NEVER use falling edges. Must be a stupid misstype. Thanks a lot :o) Bonio Lopez wrote: > > > Why does it want the delay to be less than half the clock period ? > > Hi Nicolas, > I think you use in you design the rising and the falling edge of you > clock signal. > Hope it is the answer on your question. > with best regards > Bonio Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 19133
Let's put it this way: I can design the FPGA 2D 3x3 to run as fast as you can give me the data. I am not bounded by resources the way a microprocessor is, instead I am bound by I/O bandwidth (The processor is too), except that in a system context, I can make my I/O arbitrarily wider to make up for I/O bandwidth limitations. With a constraint of an identical system interface as the Pentium III, I can make the FPGA process a 3x3 at least as fast as the Pentium, and probably faster since I have more of an opportunity for parallelism and my control overhead is not handled by the same logic as my data path. Most likely, you are doing more than just a 3x3 convolution in your processing. I can include that extra processing in the FPGA and not suffer a throughput hit (I may incur a latency hit, but not throughput). A microprocessor throughput will suffer as you add more tasks. Steven Derrien wrote: > Ray Andraka wrote: > > > Basically what I was trying to say. Given enough local memory and the bandwidth (pins) to access it, an FPGA can do > > the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996 > > paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate > > using a tiled array of 4 chips similar to the Atmel AT6005s. > > But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary > positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom > better than a good progammed CPU solution. > > I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation > of a 2D 3x3 convoluiton with my PII600 " > > > > > Arrigo Benedetti wrote: > > > > > Steven Derrien <sderrien@irisa.fr> writes: > > > > > > > > > Not necessarily: the image stream can "flow-through" the FPGA and be processed > > > on the fly. > > Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it > requires for flushin the input and output imega in and out of the fpga. > > Steven -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19134
I'll bet that you've got flip-flops clocked on both edges of the clock. It's an easy mistake to make. Nicolas Matringe wrote: > Hi all > I juste implemented a design in a Xilinx Virtex. > The clock constraint is 20ns period, 10ns high. > On one path, the total delay is (copied from the .log file): > Total (4.935ns logic, 5.885ns route) 10.820ns (to clk_BUFGPed) > > The tool then tells me the minimum clock period is 21,640 ns (exactly > twice the delay) > > Why does it want the delay to be less than half the clock period ? I > thought it needed to be less than the entire period. > > Nicolas MATRINGE DotCom S.A. > Conception electronique 16 rue du Moulin des Bruyeres > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE > Fax 00 33 1 46 67 51 01 FRANCE -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19135
What is the bit rate again? I read that as 100 Megabaud, but without knowing the length of the transmitted symbol that doesn't tell me the bit rate. With careful design you can run a small circuit in the FPGA at 400 MHz, but in this case the design would be difficult at best. The design difficulty is in the receiver, not in the transmitter. The transmitter reduces to nothing more than an encoder (a polynomial 'scrambler' perhaps?) and a shift register clocked at the bit rate. The easiest way would be to use a commercial ser/deser chip like the AMCC 8401/8501 to recover the data timing and deserialize it, then you can use my descrambler/framer or scrambler core (see my website) to decode and frame the data. The trick is finding a ser/deser chipset designed for your data rate. RS232 UARTs generally oversample with a 16x clock, then look at the bit edge positioning to find the most likely bit center, which it then uses to sample the clock. The 16x is required to allow for drift of the receive clock relative to the transmit clock while still maintaining an acceptable margin at the last bit. If your receive and transmit clocks can be spec'd to a tighter tolerance, you can reduce the oversampling ratio and perhaps make the design easier. Another option is to manchester encode the data. At the receiver, the edges have to be used to synchronize a clock, which can then be used to recover the data. You might find a clever way to use an on-board PLL or DLL to generate a data clock from manchester encoding. I haven't looked at that possibility too closely yet. Manfred Kraus wrote: > I have to transmit data using an optical link (100 MBd). > How can I serialize / encode and deserialize / decode > the data using an FPGA only (no analog solution, no CPU) ? > Are there any pure digital solutions ? > The way RS232 transmission works is not practicable (would need at least > 400 MHz sampling clock) > > Where can I find descriptions of encoding technics. > > -- > Manfred Kraus > mkraus@cesys.com > > -- > Manfred Kraus -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19136
I'm experiencing the same difficulty with the EPC2LC20 for programming of a 10K200E part. I also get the 'Unrecognized device or socked empty' message with MaxPlusII, ver. 9.30. I would also be very interested to find out the solution for amking this work. Edwin Grigorian "Volker Kalms" <ea0038@uni-wuppertal.de> wrote in message news:383CBB4B.5D4D@uni-wuppertal.de... > Hi all, > > Since a quarter of a year I discover the beatiful world of > AHDL and VHDL. Until now everithing worked fine. But now I would > be very grateful for a little help. > > Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured > by Ing. Buero Lindmeier) in my hands. This evaluation board contains > an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the > ALTERA MAX+plusII (v 9.1) software......no problem to this point. > > Two weeks ago I purchased an configuration EPROM (EPC2LC20), which > could optional plugged into my evaluation board.I set up the MAX plus > JTAG chain due to the requirements (as far as I would say), performed > an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus > detected the additional device in the JTAG Chain. > But when I try to Program the .pof file to the EPROM I get the message: > Unrecognized device or socked empty. > > > What am I doing wrong????? From my point of view I changed nearly every > parameter in the MAX plus setup. > > I hope there is somebody out there, who could give me a hint how to get > this EPROM configured. > > > MANY THANKS IN ADVANCE!!! > > Best regards, > > VolkerArticle: 19137
Ray Andraka wrote: > Let's put it this way: I can design the FPGA 2D 3x3 to run as fast as you can give me the data. I am not bounded by > resources the way a microprocessor is, instead I am bound by I/O bandwidth (The processor is too), except that in a system > context, I can make my I/O arbitrarily wider to make up for I/O bandwidth limitations. I completely agree. However you sometime want to use your FPGA as coprocessor board for accelerating some computations, these boards are usually in the form of a PCI based system with some local memory. In this case (and this is the kind of system i was considering, which might explain our misunderstanding) your I/O bandwidth at the system level is set by the PCI bus.(or whetever kind of bus you use) > With a constraint of an identical system interface as the Pentium III, I can make the FPGA > > process a 3x3 at least as fast as the Pentium, and probably faster since I have more of an >opportunity for parallelism and my control overhead is not handled by the same logic as my > data path. For such an app, I'd tend to think that even the PIII exhibits enough instruction level paralleslism and high enaough clock speed compared to the memory so that its performance is limited by memory accesses (assuming no cache miss) rather than its computationnal power. Then perfromances for both implementation should be more or less the same. >Most likely, you are doing more than just a 3x3 convolution in your > processing. I can include that extra processing in the FPGA and not suffer a throughput hit (I may incur a latency hit, > but not throughput). A microprocessor throughput will suffer as you add more tasks. Right. So we need a good computation to communication ratio to get some good speed improvement from an FPGA implementation. > > > Steven Derrien wrote: > > > Ray Andraka wrote: > > > > > Basically what I was trying to say. Given enough local memory and the bandwidth (pins) to access it, an FPGA can do > > > the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996 > > > paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate > > > using a tiled array of 4 chips similar to the Atmel AT6005s. > > > > But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary > > positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom > > better than a good progammed CPU solution. > > > > I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation > > of a 2D 3x3 convoluiton with my PII600 " > > > > > > > > Arrigo Benedetti wrote: > > > > > > > Steven Derrien <sderrien@irisa.fr> writes: > > > > > > > > > > > > Not necessarily: the image stream can "flow-through" the FPGA and be processed > > > > on the fly. > > > > Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it > > requires for flushin the input and output imega in and out of the fpga. > > > > Steven > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randrakaArticle: 19138
George <g_roberts75@hotmail.com> wrote in message news:821p1o$adu$1@news.qub.ac.uk... > As Steven kindly showed, A 500MHz PIII MMX may outperform FPGAs for 3x3 > convolutions and I guess for many other small algorithms. Yes, and if one small algorithm is all you need to run (or at least all you need to run the bulk of your data through), a GPP may be sufficient. > I know that when > the parallelism granularity gets bigger, there is nothing better than a > dedicated hardware solution, but still for many applications, a GPP may do > the job if well programmed. Ever played a 3D game on your PC? Look at the significant frame rate and quality differences between a Pentium III-500 doing software rendering and something like an nVidia GeForce 256 DDR chip using using its entire pipeline (including the transform and lighting stages) for rendering. I think there's about an order of magnitude there. The constraints of memory bandwidth that you mention are good ones. A GeForce 256 DDR has six times the memory bandwidth of a Pentium III-500 (150MHz clock, 128 bits wide, double data rate vs. 100MHz clock, 64 bits wide). Of course, with caching the Pentium III does a lot better than this, but for very large data sets such as those found in image processing, you do eventually have to look at the raw interface speed to memory. > It is nice to use FPGAs when you have the necessary > support and $$$, but for most people, they stuck in front of a buggy silicon > compiler or a rigid piece of hardware. Who's "most people?" The closest "most people" get to using very sophisticated hardware data processing probably is when they play their 3D games on their PC. The subset of people who are hard-core PhotoShop users probably have the money to pay for FPGA processing boards. On the other hand, in order to build "most people" their inexpensive set-top decoder boxes for their satellite dish receivers, somebody has to sit around and design a hardware MPEG decoder (usually in an ASIC, but that's due to the really high volumes possible for set-top boxes). Although you can do hardware MPEG decoding in real time at VGA resolutions on a Pentium III, the price difference would be astronomical. You won't see Dish Network or DirectTV handing out Pentium III-based set-top decoders in return for a one year subscription anytime soon. In fact, have you tried out the software-only DVD players for PCs? It's a good way to suck up a very large percentage of a Pentium III's CPU time on a system that costs one heck of a lot more than a $199 standalone DVD player, but hey, if you weren't using your PC for anything else anyway, why not? > Frankly, most people would prefer using their general purpose Pentium > processors, with a nice GUI debugger (if it can do the job of course) rather > than buying an expensive FPGA board and spending weeks if not months > struggling with the tools to make ends meet. Although there's a lot of overlap, FPGAs, ASICs, DSPs, and GPPs each have their own area that they accel in. Overkilling a design is not quite as bad as choosing an underpowered solution, but each is arguably not good design technique. > I presume it depends on the problem you have in hand, I think that people > should first consider flexible SW solutions before going any further, and > not exlude them from the beginning even for computationaly intensive > algorithms such as DSP. It's interesting to look at modem developments for PCs. "Real" modems usually have two processors on them: a DSP to handle the signal processing and a general purpose processor to handle the AT command interface and housekeeping. WinModems ditch the general purpose processor but keep the DSP; Host Signal Processing modems (HSPs) ditch the DSP as well (they're really just a DAC and ADC coupled to a CODEC and your telephone line). HSPs are kind of an interesting development... they suck a significant portion of your CPU time, they often have problems on heavily loaded systems (because the HSP process gets starved for CPU time, hence the output FIFO on the DAC underflows, and if the other modem doesn't hang up before the HSP process gets serviced again, at best the modems have to re-train, pausing your connection for 5-15 seconds), but they are dirt cheap (at Fry's you sometimes even see them for free -- with the mail-in rebate!). In my opinion, it's not a very good compromise, yet I imagine that millions have been sold this year. In the same way that these difference modems target different market demographics, so do FPGAs vs. ASICs vs. GPPs. ---Joel KolstadArticle: 19139
"Manfred Kraus" <mkrausnews@cesys.com> writes: > I have to transmit data using an optical link (100 MBd). > How can I serialize / encode and deserialize / decode > the data using an FPGA only (no analog solution, no CPU) ? > Are there any pure digital solutions ? > The way RS232 transmission works is not practicable (would need at least > 400 MHz sampling clock) > > Where can I find descriptions of encoding technics. May I suggest using 100 Mbit ethernet on fibre. PHYs are available that do the tricky clock recovery stuff. You can either use them as 4 bit@25 MHz with start/stop (of frame) or as a 5 bit@25 MHz. In the latter case you must do the enconding yourself so as to include proper amount of edges for clock recovery. Have a look at some datasheets, www.tsc.tdk.com, www.level1.com, www.altima.com etc. Hope this helps a bit. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 19140
--------------5CBE6767130FB295445D2FE7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <a href="http://www.cliosoft.com"><img SRC="cid:part1.3845B449.1647E6BD@cliosoft.com" height=75 width=303></a> <br> <p><b><font color="#FF0000">Free Data Management Software with Remote-Site support</font></b> <p><b><a href="http://www.cliosoft.com">http://www.cliosoft.com</a></b> <p><b>* Revision control of directories and files for true configuration management</b> <br><b>* Import RCS database into SOS</b> <br><b>* Graphical and easy to use</b> <br><b>* Increase project visibility</b> <br><b>* Manage data from remote sites</b> <br><b>* Tagging, Branching, Visual Diff, Snapshot.....</b> <p><b>To learn more about SOS <a href="http://www.cliosoft.com">click here</a></b></html> --------------5CBE6767130FB295445D2FE7 Content-Type: image/gif Content-ID: <part1.3845B449.1647E6BD@cliosoft.com> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="C:\WINDOWS\TEMP\nsmail5B.gif" R0lGODlhLwFLANQAAAAAAP8AAP///wAAAEBAQIAAQICAgKCgoMDAwBAQECAgIDAwMFBQUGBg YHBwcHh4eIiIiJCQkJiYmKioqLCwsLi4uMjIyNDQ0NjY2AAAAAAAAAAAAAAAAAAAAAAAAAAA ACH/C05FVFNDQVBFMi4wAwEAAAAh/sFodHRwOi8vd3d3LnJ0bHNvZnQuY29tL2FuaW1hZ2lj CgpDcmVhdGVkIHdpdGggQW5pbWFnaWMgR0lGIFYgMS4wNmIKYnkgUmlnaHQgdG8gTGVmdCBT b2Z0d2FyZSBJbmMuCgpUbyBzdXBwcmVzcyB0aGlzIG1lc3NhZ2UgaW4gdGhlIHJlZ2lzdGVy ZWQgdmVyc2lvbgp1bmNoZWNrICJPcHRpb25zIHwgQW5pbWFnaWMgY29tbWVudCBmcmFtZSIK ACH5BAksAQMALAAAAAAvAUsAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweCgom83Cc3nM1gXe8Hig3VKrf/Z1HU1ny/+Ac30oemQC I3wrdk6Fgy2BkH+OJY0ii5ZnJHcmlYWbmIecoZiiiJkAl5+oo5MokCuvk5Wrp3mgp5qslJer hKyznrV3trStKYCmeYXIjrPFptC9pLu+o3zAm3raus+JwdPGJZK3yp/jdMSN6ofrpSedofCL 2+C54O3S4SNy5OXlIvzQpfplS5kobvlI8UoojV6/e+kQTuLnr+KigGycrcu2MBc8asQYOtzG MRkuZ44w/xpM8Q+jGI0E30mUGcwaPW+6RsazCdGXPgBx9s3BtWdT0DEw7XXbibCmSZw00Uhl 57Ahz2c/AcLRunWmootbXzYlyFFVtHqqUJb9FPHpN2NBD7lMpvQgmqNgUNolqzYmC71RE9ES 7BHfxK5Az9E9u1du2C+Adaz8isdrVnFdHc8VHDkTXi+Rc3RUEfqykLh3FXO2PDjxG9M0SsOe gjr1udVFNQua/UI2byiZTzHDyrDamse/kx8eSpSZb7uulUsfFHzW8Mlfj7+ezl1MdYTI/OWO 3r18l9ozw4vP7np3bsIynrMcHaSv+Rrfjyk+mF1z73+xsfYXgIZwA999LlQHy/9+b5GmnXvs mSSZWfPxRQRRRO1AH2NeKMhSe8gZVg15LmCzy2pVsUVhPSyaJY9eGKJYk4w20ciYjQ/V5UN+ 84G4XUKd2fafTG4xNRUo04Sk440ZviiRTkCexEtZSQ60UkRpCUiDhxX6KEgnA/pX4lhnQZki UyymWdxSGRIXzU1joVnckVW+Oc9OduI5mHwJvtbmiV6qyR5ylLmDz0f5nEmkO6Vgp+aMgira KE+HrgGnUt84mgOXPQbKp5BjLjpZpSU9SqZbHO55amtRClPmMHcOVOeVV625A6fGeRrfg0Ma 2lGDKqa65oxQFXagYcRKiiVJUs46Za18woBrrsPBAOr/HqKeCiWjSXELbU616gjsVW9lauCT elqK7qun+XlgVJ7Kdu2A/FmV7r3NuplmsYnCKiyM31apZy+yYmWmnPai2sO0Durm7rsekUgv Nf0YqVOp9lFcsbGqruotxjVmUtCzzgYr0p83MPzIOCjTRaiDhXEsoUJ+hbYRuC3nqDGjqkaq JLM1U/XUkkeo3KVzQYr5Xs5jbmjcisL6xPPORDes5KJfGG0JoPFaNm9/EO8a9tPR+lB2hWdz YTSKQlHk1deFVpE2glWsjRMrkgAGN918N6G1MLrk3bDEfRe+BHpop7cfoJ8Z7jgSWnd8R7WM //j45UbwmLgtlN9COOagBxF5/8V4z4Xky6GnvvDDZS+z2d4xUOj0rlLjoHepokF9GXqs4cYV Xp6hHnubs9tab8QTd9pYVTZoOhviEdaDtG4T1iWvljGWdrZTPHAvHfSkcYKZ2+1p6BfB4Br7 toxRI2oqxe6Tg3WdjSksv87GA8H7puQ33vz56trZ1exEMya16HxVO6D6zqU89K3lGlbyHeS+ oyUVjMN//7Oe0HIEQW3hqUFWUVi3sFawOc2kHeWiFPdoVEE3UBAHeBFeDZC1QYOI6FWSop8N LQYw0t3QeCgklwrhxxem7SgsxftQWDB4A+8FkEM/7FcOQwhFHmYMLQN8VxAJWEBMMdBvvHuO Z0BUmfTF0EmB/wJguJgXv5gJsIh9MRE0UjjH9JnwCW4b4AIdBoQO1hCBUZrfuLy4pNuJKIq5 MiAEkeRAM37RCQGxSEV+B6EeBPCJN3vi+2qXsFadUYNrxBIJSdWxjZVyX7ojwm0kmYjFWVJo mMSZJod1QjjOck+01OCJCCQuW4ZkIVkKDB5XSaDOVeZIzBslJ6kmsg020ICCGpogZckqqi3H lSSIRRH8aC0B9TB5w0tiOFO5yaxE4pyWMwI3kzC3MI0tQEYs5+7QiU0lvBMpLZxBO8tzTtWZ zxD+DKhAB0rQghr0oAhNqEIXytCGOvShEI2oRCea0BAAACH5BAlkAAEALAAAAAAvAUsAAAX/ ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikMiVoOp/QqHRKrVqv2Kx2W116vzmu eEwum8/RXWK0FrUB7zh7rpK76XA8zJ6/+/uAbzJohIWGh1tgioswiI6PkGg5a5R5lZeWmZV/ JJiemqAun6OgmJwvkamqq1M+pK8zsKY1sqU6rLi5kLFztb6htpcJlMPBeHK/v6csus3OZzjE w9PU1dbVmX/S19zYmynb3eLU2YPP5+hYMaPTCgnu8O/y8fTkr+3z+fXu08bCw/v0CeRX7JOL dAgTQrFhTYHDhxAjSnTIDc61iRghyvOmqVrGjxo5xjhToKTJkmNO/6o8aWblypYux7xABoDe wwUKcOJ0uDOnz571ttnk+bOozqLxSA01ipTpw3wGV5BxSZVLVUMvYVI1mUiGx5s5F4gdG1bn WLJAKX69ebat27Yhu0E0CxetW59PsaGyylKKSjF9EQVOOVhAVnWiLM37uYBA48eOHYuNDPnx 0YBEJ1emzLny5Y34Mm/2PJryZ36AmG0p7BclX9eCuU6V3Zq2Fa/twhLYzbs378a+fZ/NOJk3 AwLHjwdP3nv4U3hsg0sHLn23c3J7s7CuDdg2Vu9atj/5e2UFTejFmTNYj9y4e/XtJTONjHw9 gwb27ddfj18/A8t4vcPYbuqxBx+B7TEXWf+As6gQHnhUwPaghN9RqB2EUYi30EwA8QQcf/c1 0J+BCeZnonJv9cafiCziN6KLLYrInmRisUUdiCyeWOKJM5LVT3ZXaJhhAd1ZSIiQERo5BZIC tCCMh7vB6EADU7qY3373ZdlffJvVJ+KUYFIpo5Rihrnlf/KlRwCZVWppoH1WnlkjPOU4iAWT UBD5mp6xKVkFnk0wmViHk/HnwKEOPIBojifGKKN+y4V46AOUUnqoo4hWquilW3LmJZWZLtqi iY52Oid2qgWJYYRF8nkIoOOtOqSsTdahGJRrgmrArrtSKmacWv46ZoIlTknprhAYAIGlYYLp ALLK7srpjCV++Sz/rwb42iawX47Z4wIbpcaEqn6+Suts5dbm6p20ikIogVQ+oGwEENS77Kaj YjqqfyHGqywEEQRcb7aIZooswAIT/Cip/gLs8L2cjhljlTJap1YxLbCbbiGwrnZunh/Hmq55 typAIAOH1itBBCtLUK+23rL5q5vW7hqwBBIcgPPLmyKKLMs440yvtm4a+4DKLLP8sgHTxlnm o9btVJC4Jmi8LiQdT3i1FVkj6a6HhiqL8wFkC71sxKWaGbOuAOd8wARl00uwwW27TfYBcuNr rbxt363zysnqXWqM7En9Y6p/hkyS4h5vDLLjIm/9BMlruFOoiGJLMMEEFGy+89nCUtzs/9qH 7orz5p1TELe0k/J9Ouecr860s/IGTDbqnrscAessij4ziuCiJsi4XDNeRtYXQu5E1+1SLmBj 9z3LMucVUGA93C7PTXGL20987fTUV6864MwmOu/b1ouPfd7Hnn9A+tZ3/vfugnM/qsUEDU98 4sprJfni/TOM8bxmK0ItYD0pi8DmKlABBDBQfi5b1uyeNjrumQ98DHRg9SaAM9Yl6mgQyFn6 GshAz9ErWTZj2fsokMEHwg1vu5vg6NqknJyES38nsBorkKfDxv1vSc2rQzuAI6KjaS6DCEji BnUmt2z1bFHda1jOJoBEDcJtaD2rneZYmEQlVmB99uob9bqoxP/Ora9XT/xd1C6GwxyS64cV giO65Pg4OkbuNgV83gFR9gCWWS+JFghkEq3HxAjKK1EFC128APY2BloAAY9EACElwLtjQYBs LHykJkvIQd0BbYEVCKQoB/nFvy0NkWDKEpooIryM9TAVPHzjnuwowI2xIDfQw1wEGglJC1xA kA5UXdxQWCko9u5ZIXxfA0X5yOrhDWKTMsD0KNDLUS5RaGMboy8v8MtIcpKJxBQc8NTSiFdG IpbFC2AtaSmoPIKNj34M5TZ/eYFBmpFsAkMhKst0wS0mkZvddGb2LpWyS1KxlwC1Z9nGhj5A ztOXkHQhPk/Iu06xsk77458696QdH7b/akKIESJAiNgAIx7UlxgA6C81eL35hbNgH2TkSVX6 SNUNrWBanClAmym/v02Ri9tM6U4j2VKzzW1LpzqcVJJHyzneiaMflWV53BkWBDoghJyDJDdT KtRAkvCLL0xY+SwpQnly1avj413pDNrArV4AA14Fa87mCspAuvWs9bRiWOlHpRmxcmqIkyq7 oMo1wvoQjoC6pUV4ghwqSVOZdsWAZLtqzaI2UVM282dQuVnTZz4xp8t8q2RX6kyf3g6oW53s aLsZTAjSb0ooIieQrCbHAZ4rgLEkj7q04DzLkVRZjTSraLnKWW/KNYK9SiEvU5tSCwhUrchc 7nC56cDcAQ2T/9REwC+5OlrKevGKEVCUiNbYysDSdms8RJI60XmY5THuazmpT6JkGtrhTpam etXZwH5W1siOtrM3Ndj0zHpfnk70uisEJHPvu1Mreha28kHVUme5FcJs5Spa26h7LywGytVE QPBK1DSXGVTVrjau1qUXvU6XXeb+8rkyjO5BXVzP4zpsZdh16F1VW9wSPvNQ60kq1dw4x9xe mMPnbS+FNaxYA4b4aLtMMELfat/m8hR7LftpKO27UpueTcBHhCSPm4m9/f5LhZzLrigBamLS XpFp+JEPalypkDqjw8MGXBHfohy+f7K5u9SVpDCFdlo/FxjGBJVxW4cbV3wS82C2Q/8fEu06 Xbg6twL6fcB4CUDOb6DAzqB+BnzTE709Z5OLUyYua5doWur5l7OSfDCYZ3piSXKQfe1D2KlZ WF9V83Rl4j2O4Q4S6mLjwsPoOWCuoqkyt43wnxbw9aU9pzOdjfGuaNUZdIE7YypbWqA8Q2Su Q+g21LU42lTO6+Z2VzGxAHbIIjC2vFXRZD2ebG97RnOa69tgQS/U2dScJ3WdicVZBxy/pbys ohZeqXkhWJs0dW5aIWw4jNlp3qvQrajdCeI94od28gKh7VBHYnqiuJMIRm2Px5csmNYruHaF qK0B50SYMjxb9bqZpBEq887Ri+LBe/enMX5O40Xilrj8kKT/QNW6n1kbqMwM5vpupuVqktmz WZSmP6tZRv1CE6Y4lde/WExiQT6X4rI1L9E51lRW9NYn9+4dBc2na1ACUqEwvLHmqBhKSCqU khO0JCYb6PdgOlpaaZzhBzNr94gmHM7CDl4gMqoLJcOy7bF6BNLf9Sm5W5BSOZ9iCyWazzOL nvBSf6b2csr3Ll4zhuWDqffWiubRdw7YaM+f2nfoGg0XycK7oCqpu6W2brUPgyxsacCSK3YM MpCTHWQaw1W2wucrH/YLT2Txj8l4KiY/rZpuwG4u6ukTHPn86E+/+tfP/va7/8ibf0eh+iWs tClqXj/d3BlXj3/0xQ+MY3U+afZ//0yERmCXSINDe/l3RkCXdhOWC0Z3JBsVgVnwdqRWQTTD T5lzOxOlVroiTXy2OR04O4undbcjgjDkgc7SLDQjKcjEUADoAIXTaXQGgRrGPJYHRDkIDebR IfG1Iiu4L/RHd1RHc+IlMcymQndjhFkEQgzlUkdFfGAnhFKSb0FzU3HmGBdDbDa4XihhW5hX S6kADiVTHDKzLcFSRM33METzIihTUk6YNCfELKDCNyEkhzxTfxT0NNwSIsfHhlVCXlPTRiPg DB0DG4xDgRRYgT3IeUMohPlxTGLHK0dILXFnPv8yMLFHN2HUK9uThkwHiXCyN9iiMHGWVBb3 gF1oR4iIW/8T6HuMSIaEYjKfYiaqlIG0s0+mQh9AuHghhy/N4otONDNnkiUY6IZAWIe6GGRS owAYNXTNgCcSkog3CIshJYv21nmiGIly94nAMxbGcUxTiCnjCDUqsiKOwiPoyIcj4iNKtXsZ Ryu2QY1huIi8xXG4giOqRCyRmIYGAiBHwYtLZ4tOQ5Ak4in9aCXwkRwZKCeclhTwRmTRKI+t 2FSKaI3XKFK4giX+4RsMySNRMydzQWr6qI7AAikpYhw6ohzvoY7kRRDmYIjpMo9tF4H2eI+y uFgJYBYIciDUwY/Ekib6EB3KtpBA6ZNpMiAfApT04RhGOU4QyQcXd3kgQy7u9Rr/6CJAY+gk uKQbP/kbntKUliGS+bMYZ1EdaNkcZCERZ/mV1hGW1DGWFUeIqvgIffExsuGFYbhOe4mTBaST R6EZppEichkgrQQQ8hCYpbGYl/FX6FEWo/EWpHEagxiRVaMKMcFUr3g8N5mR2OiDNnIXihmY cSEObCmZkikRHiEgovEWRlEjjal7dDmVa9cdtVkrk3cHmLAUpEkUvmmYUBEMi/GbpBmbULGa 0JEZeLGcPdGMwTkLfDA8tzkbt7kHFkENyQkSEQEa/fAN4TCc2nmc4wCe2vkc1vCMXDidDzKd /iCcmDEQAtGd7Ymd8BkQHOEJ9ZmfSVGZyQAI6ukx6jko/9c5ngR6n8JZoAg6oAi6oOUwmxL5 n4nzn/N5oKBBEBaKD9IwoRlKn4jpDfxZChhaoSEqPB/an/EGocUDoRtaECz6nQtKoNcZoy9a oDI6owzanS1ao4KAourSl+mgoR1ho+eZDC16o/4gpEMKpFHBo0xKBUj6pFAapVI6pTB6ok16 pU4wolraoSLKpRfqpVvapWL6pWMapmR6pmaapmD6BljapgKApmtapnEKp3Jap3R6p2pqp3mK poXopleqn4D6noIaqIQ6qIZaqIh6qPvQp37KpOX5qJAaqZI6qZRaqZbqjIyQqYzAFMXJqZ7a qaD6qaIaqqQ6qqZaqqh6qpq6qg+s2qqu+qqwGquyOquaGgIAIfkECcgAAQAsAAAAAC8BSwAA Bf8gII5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKQyJWg6n9CodEqtWq/YrHZbXXq/ Oa54TC6bz1Gweg1Du9/w+JZNr5/k+Lwebe/b94CBglN+hWuDiIl6hoxeio+QZ42TSJGWl1mU mkSYnZ5Qm6FAZwWlpqVjp6qnZqurra5jorM8ZK63XLhwr7C3pnO0wTdiqlPFub94rGXHTrxY wtE0yKhWyVvLctnE11HNVtLhbVrbVN1Z5W/p6Ofe62lBTiNNo/Qi8j34APZC5O3mBbhV0/bv yjsoB5/4kDIPVEMBMRjec1hD4j6KFyHi8DfQYEBqHwl25MgxJJVahCb/gnNxUiXGFy0zdtmI JaEUk+xGqitYxeYTnztmyoy5gqjQFkKh0fSo05pAnDubWuPpjqrGpfBMHEWxdehLJim1Eq3I FGoen6msVjXb02qYsFwtxoVLoqtYuXfwTis7CO1TkIDtRqQ7VyHYsQ8J11V81/AwvoL8Bi45 mTFMxIX5NWZ8JfNXz2+nShXJlpRahKd/urUhePNV11lLKJWNOa9j1pADScaW2lnvJjYfW97s Wa9LzK2JYwU4Os5uyryb31y9NzltzYkFZ1psnftrsqJLO/8NvXxO8d8Hr2RxO3vt7e6N204/ oyZ5W/ftS19bWT5L+Ielp0VxcA1YlD645bbH/3PngYSeavslaGBc8613XWfxWSiWDg3qlp+C Her3oITAXDbbhRaSwYmID5q2H3DRtYjai8C9SKIY/53oXYpmxBOiHmjJ6BuNM7aI1o2yqFAi iuu58UOM/vRnjJQshgdgfU4SyNmEXqmIUkkPkucTkTWSCeFokgnHR4UaZljgG1+CaRaDAthk Zp0f4pnObsv1CNt7XHbpZWgx+iLkmYZ+w+Kha+myZHVZ7tjmcRrGwSEzsaSVqKPhcergh4Su 6aZ8jwo6KJKfpKrIpXCOGpukdlmqpqq0JhJUq5RqF6irpcpQ66+2xumnqaTuCmuS4AGr7CIL SZIroFeyiSOqyypDJ/8cuAU47bPFnojdsdGqV+1ZecqR7IFcgPsqr/q09+ek44xrba3nsrek scRS5K603aELyTORMapaHvXmyKOO7PKzr7a1mfhIMnfiJ7CezGKJoL2VIswtRp8x7J8Lm4Ys 8sgkl2zyySiXkix9SnYVbr4IduzxwvEmUi6mE9/cL2g1rwszyzr63PJwBiPy4XOeMqdopL4K rSV9Gv/MJMtP9+nhnb+IGbHOO0vbM80Yvntxl1+PbbHNvw2UdsQU77Gy2QT6261iRB/LqiJ+ qW1mflx3LTbGMqtbNb/f/nnrw6d1tPbEbbsNqX8N/z013PnOTPXZeFvVzeKaCvJ2WPAObVG9 cvCF/jja0l3DeeeBFDx63ZZnCHh8bj4ZieaKM8o32+mSpRzZoV7l9IYo0l6Ph6gx5Rs1EuMJ iI8P9SP85XtFvyIgyyReDdZsL22uOODLTa73xpA/Fc6M9xr++j/LC5D71LMvDfz4wS///RvT Xz79+N+vP2/665/8/seO/wmQfQT0CAEPuL4ETqdvj2Bg+BxIwchJMBQVzGDgLrgJDXowfhyc xAc1GML5jbCCJUyhClfIwha68IUwjKEMkRACADs= --------------5CBE6767130FB295445D2FE7--Article: 19141
Greetings Please visit Verilog FAQ http://www.angelfire.com/in/verilogfaq/index.html In part 1 under "Editors which support Verilog" topic 6 editors are listed and most of them are free. Hope this helps Rajesh (Verilog Center : http://www.angelfire.com/in/rajesh52/verilog.html ) In article <81ltfs$l59$1@sun27.hrz.tu-darmstadt.de>, "Ahmad A." <aa939788@oak.cats.ohiou.edu> wrote: > Hi.. > Can any one tell me where can I find Free, Student edition, or Shareware HDL > editor? > > Thank you in advanced. > Ahmad. > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19142
Greetings This is semimonthly announcement of Verilog FAQ. Verilog FAQ is located at http://www.angelfire.com/in/verilogfaq/ Alternate Verilog FAQ is an attempt to gather the answers to most Frequently Asked Questions about Verilog HDL in one place. It also contains list of publications, services, and products. Alternate Verilog FAQ is divided into three logical parts. Part 1 : Introduction and misc. questions Part 2 : Technical Topics Part 3 : Tools and Services What's New section outlines the changes in different versions and announcements. Links connects you to related informative links in internet. Your suggestions to make this FAQ more informative are welcome. Rajesh Bawankule (Also Visit Verilog Center : http://www.angelfire.com/in/rajesh52/verilog.html ) Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19143
Problem resolved by calling Altera Tech Support (they were great!). In my case, I have 3 devices on the JTAG chain: 1 10k200E and 2 EPC2's. When making up the JTAG chain list, you should have all three devices defined but only reference the two .POF files and leave out the SOF file for the FPGA. On the file list, it should just say <none> for the 10k200E device. Device order is important so make sure that the FPGA is the last device listed in the JTAG chain. Select "Detect JTAG Chain info". After that, you can start programming the EPC2s by hitting the PROGRAM button. It programs the two EPC2s one after the other. I can now cycle power to the board and the FPGA is almost instantaneously configured. Hope this helps others, Edwin Grigorian "Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov> wrote in message news:823k5o$6jo@netline.jpl.nasa.gov... > I'm experiencing the same difficulty with the EPC2LC20 for programming of a > 10K200E part. I also get the 'Unrecognized device or socked empty' message > with MaxPlusII, ver. 9.30. I would also be very interested to find out the > solution for amking this work. > > Edwin Grigorian > > "Volker Kalms" <ea0038@uni-wuppertal.de> wrote in message > news:383CBB4B.5D4D@uni-wuppertal.de... > > Hi all, > > > > Since a quarter of a year I discover the beatiful world of > > AHDL and VHDL. Until now everithing worked fine. But now I would > > be very grateful for a little help. > > > > Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured > > by Ing. Buero Lindmeier) in my hands. This evaluation board contains > > an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the > > ALTERA MAX+plusII (v 9.1) software......no problem to this point. > > > > Two weeks ago I purchased an configuration EPROM (EPC2LC20), which > > could optional plugged into my evaluation board.I set up the MAX plus > > JTAG chain due to the requirements (as far as I would say), performed > > an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus > > detected the additional device in the JTAG Chain. > > But when I try to Program the .pof file to the EPROM I get the message: > > Unrecognized device or socked empty. > > > > > > What am I doing wrong????? From my point of view I changed nearly every > > parameter in the MAX plus setup. > > > > I hope there is somebody out there, who could give me a hint how to get > > this EPROM configured. > > > > > > MANY THANKS IN ADVANCE!!! > > > > Best regards, > > > > Volker > >Article: 19144
So, Xilinx does require a backup fifo (just not a fast one :>)). Assuming that I am bus mastering a write....Isn't the problem with the fifo being out of sync at the end of a transaction eliminated by the fact that the transaction can only be terminated by a stop (unless I end it), which will take the data just saved in the hidden register? It's hard for me to see how (if I am writing) I can be out of sync after the transaction completes. Bruce Eric Crabill wrote in message <3842D3BF.B9407981@xilinx.com>... >Hi Bruce, > >The Xilinx PCI64 and PCI32 cores do not require FIFOs that back up >during a bus transfer. Depending on the type of transfer, we may require >the user to back up the FIFO when the bus transaction terminates. > >The situation you describe is never an issue when the core is the target of >a write or the initiator of a read. In cases where the core is the target >of a read, or the initiator of a write, it can occur if the other bus agent >inserts wait states in the middle of a burst. > >Our implementation contains the necessary "shadow" registers as a buffer >for the cases where it can be an issue. In situations where the core needs >to use this buffered data, it does so automatically and transparent to the user. > >In cases where it can be in issue, the "shadow" registers may still hold valid >data at the end of a transfer, depending on how the transfer terminated. >We ask the user to back up their FIFO at this time. There are two main >reasons for this: > >1. It forces a FIFO state consistent with what took place on the bus. >2. It allows the next transfer on the user side to be unrelated to the first. > >The largest issue is item two. Many designs have more than one target >address space (multiple base address registers) and have more than one >"channel" as an initiator. To assume otherwise would seriously limit the >flexibility of our implementation. > >Hope that clarifies, >Eric Crabill > >Bruce Nepple wrote: > >> One thing you might look at when you consider PCI cores is whether you need >> a "backup fifo" or is it implemented in the core. When you get a late >> TRDY-false does the core save the data in a hidden register or do you have >> to backup your fifo pointer to send it (there is no way you will be able to >> stop the fifo from advancing since the signal comes so late). My impression >> is that Xilinx requires a backup fifo. >Article: 19145
Manfred Kraus wrote:
>
> I have to transmit data using an optical link (100 MBd).
> How can I serialize / encode and deserialize / decode
> the data using an FPGA only (no analog solution, no CPU) ?
> Are there any pure digital solutions ?
> The way RS232 transmission works is not practicable (would need at least
> 400 MHz sampling clock)
I doubt that this is something you really want to try to do in an
FPGA. Can I suggest that you look at:
http://www.cypress.com/cypress/prodgate/datacom/cy7c9689.html
for a single-chip addition to your system that you could easily interface
to an FPGA to do the serialise/encode and deserialise/decode functions.
Mark
Article: 19146In article <823gqf$bgk$1@thetenth.astat.de>, "Manfred Kraus" <mkrausnews@cesys.com> wrote: > I have to transmit data using an optical link (100 MBd). > How can I serialize / encode and deserialize / decode > the data using an FPGA only (no analog solution, no CPU) ? > Are there any pure digital solutions ? > The way RS232 transmission works is not practicable (would need at least > 400 MHz sampling clock) > > Where can I find descriptions of encoding technics. > > -- > Manfred Kraus > mkraus@cesys.com > > -- > Manfred Kraus > > Cypress has 2 serializer/deserializer devices like the CY7B923 and CY/B933 which operates at 25 MByte/sec and interface with FibreChannel transmitters/receivers. Really easy to use. Best regards -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19147
Hello, Is there a possibility to use a command line option for FPGA express for checking, synthesis and optimalisation? I presume that Xilinx foundation also calls FPGA express with a command line option. Thanks in advance MarkArticle: 19148
>You might find a clever way to use an on-board PLL or DLL to >generate a data clock from manchester encoding. That sounds great. I'll check out whether I can make improper use of the XILINX DLL. Thanks a lot Manfred KrausArticle: 19149
Steven Derrien wrote: > Right; but total execution time will always be bounded by the time it takes to transfer the > orginal image into the FPGA plus the time to transfer the resulting image out of the FPGA. > > What I wanted to say is that in many cases the maximum speed-up that you can expect from an > FPGA solution is strongly limited by communication time. What a curious discussion! Steven Derrien seems to want to limit the universe of problems-that-are-worth-solving to be the same as the universe of problems-that-are-memory-bandwidth-limited, because that way he can show that the P3 MMX is faster (or more cost-effective, or less hassle, or something) than an FPGA. But if I use an FPGA I can do all kinds of things about memory and processing bandwidth that are physically impossible with a CPU regardless of cache: * have multiple, physically separate memories being accessed simultaneously * have very, very wide datapaths to modest amounts of local memory (hundreds of bits wide, if appropriate) * perform bit position manipulations and even some simple arithmetic as part of the process of transferring to/from memory * put arbitrary different ALUs in parallel, not just the SIMD stuff that the CPU manufacturer happened to think was sexy at the time If I have multiple *separate* memories, then I can still get real-time processing with an FPGA even if the image data rate is so high that it fully occupies the bandwidth of one of my memories! Why do you think FPGAs are pushing the pin-count envelope so hard? CPUs are getting faster and more ingenious all the time, but for any given application I would say you can *always* get higher performance from dedicated hardware if you are prepared to pay/work for it. Despite this assertion, it may well be possible to do in software some operation that has traditionally been hardware-only, because the GPP is now so fast that the software approach is *fast enough*. But your "fast enough" may be slug-like in the eyes of the guy around the corner, and he'll need a dedicated hardware solution. Another major issue when using clever GPPs to do compute-intensive pipelined tasks is the question of context switching. You may be happy for Windoze to take half a second to respond to a mouse click, but some real-time applications are less forgiving and need some events to interrupt the CPU for prompt service. This tends to require the CPU state to be saved and then restored later, a disaster for any GPP with intensely pipelined internal processing hardware. Using a dedicated processor for the compute pipelines frees-up the GPP for the stuff it does best- complex control and branching - without those things screwing the performance of the computation through repeated flushes of pipelines and cache because of task switching. Jonathan Bromley
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