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
glen herrmannsfeldt wrote: > The thought process is different between serial C and "everything > happens all the time" HDL's. A VHDL program is more like wire > and gates, and very little like a C program. ... unless the hardware description is completed in a single process using no signals. Some examples: http://home.comcast.net/~mike_treseler/ -- Mike TreselerArticle: 126501
On Nov 21, 4:22 am, Ved <vedpsi...@gmail.com> wrote: > Hi all, > How can we measure setup and hold time of a flip-flop on FPGA in lab ? Ved, 1. Why do you want to do this? What do you gain? 2. The difference between set-up and hold time is a very small fraction of a picosecond, for any given device and operating condition. 3. Whatever you measure includes unknown clock delays and data delays, so you really are not measuring the set-up time. 4. My advice: Measure performance and available speed margins by implementing a shift register and increasing the clock rate until it fails. Then you still do not know whether it failed because of clock- to-Q, routing, or set-up time, but why would you care? Peter Alfke, Xilinx ApplicationsArticle: 126502
On 2007-11-22, Philipp <Patrick.Bateman23@gmx.at> wrote: > > My intention was to use Chipscope in combination with JTAG to > download the bitstream to the FPGA Standard warning: If that card directly connects the PCI bus to the Virtex II, you will need to get the FPGA configured before the BIOS probes the card. That's going to be a challenge if you do it manually. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 126503
On 2007-11-24, naresh <naresh.hk@gmail.com> wrote: > Is it possible to port an OS that uses this dual-core system. I think the biggest obstacle is lack of hardware cache coherency. There's a big Xilinx appnote on 2 PPC setups, though: http://www.xilinx.com/support/documentation/white_papers/wp262.pdf -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 126504
Jan Decaluwe <jan@jandecaluwe.com> wrote: >Wolfgang Grafen wrote: > > > I doubt that Python is the ideal language based for >> hardware description. I believe it is possible to design a very concise dynamic >> language for hardware design. But this will significantly more than one person >> to bring it up. My impression is MyHDL is not very suitable for large projects now. > >doubt, believe, impression ... instead of spreading FUD, why not just >tell us about our complaints and the features you are missing. (Not in this >newsgroup of course.) Aside the obstacles I mentioned in my earlier post, I'm also concerned about the ability of MyHDL to write clever code. I would like to know how you can implement a 16 to 4 priority encoder in MyHDL.... -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 126505
>...Not in this newsgroup of course... Yes, maybe you could create a new group in which to boldly go.Article: 126506
I'm using a Cyclone II with 1.2V core. The 1.2V regulator has an open drain "power good" signal and a cap to delay that after startup. It looks like I could hook this to either nSTATUS or nCONFIG to delay FPGA configuration. The only difference I can see is that nSTATUS is meant for daisy chaining FPGAs and does not appear to be tested after configuration unless nCONFIG is first pulled low. Looking at the Configuration Cycle State Machine (p1-5, figure 1-2 in the configuration handbook) it looks like the chip itself has a 'power supply not stable' test, and it may not be necessary to hook up PWRGD at all. What's the best practice here? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 126507
On 24 nov, 05:24, "HT-Lab" <han...@ht-lab.com> wrote: > "HT-Lab" <han...@ht-lab.com> wrote in message > > news:8HS1j.43310$9Y3.1560@newsfe1-win.ntli.net... > > > "fl" <rxjw...@gmail.com> wrote in message > >news:ccb086d1-775c-44cf-8666-bc357a309d93@b15g2000hsa.googlegroups.com... > > .. snip > > > > >> Thanks in advance. > > > Send me an email and I will create a standalone Modelsim version for you. > > Use this procedure: > > 1) Navigate to the work_mti directory in a DOSbox/cygwin/Msys shell etc > 2) Issue the following command > > vlib Cordic > vmap work Cordic > vcom -work Cordic -just p ..\hdl\*.vhd > vcom -work Cordic -just b ..\hdl\*.vhd > vcom -work Cordic -just e ..\hdl\*.vhd > vcom -work Cordic -just a ..\hdl\*.vhd > vsim -c -do tb.scr > > And you should get something like: > > # Angle=60101B Sin=3FD815 Expected=3FD816 Cos=0476E0 Expected=0476E3 PASS > # Angle=612E10 Sin=3FE98D Expected=3FE98B Cos=035976 Expected=035978 PASS > # Angle=624C04 Sin=3FF603 Expected=3FF604 Cos=023BCB Expected=023BCB PASS > # Angle=6369F8 Sin=3FFD7E Expected=3FFD81 Cos=011DF3 Expected=011DF0 PASS > # ** Failure: *** End of Test *** > > Next remove all the std_logic_arith/std_logic_unsigned package references > and replace them with the recommended numeric_std package :-) > > Regards, > Hans.www.ht-lab.com Thank you for your reply. I don't know the reason of: > Next remove all the std_logic_arith/std_logic_unsigned package references > and replace them with the recommended numeric_std package :-) > Could you tell me that? Thanks again.Article: 126508
Nico Coesel wrote: > Aside the obstacles I mentioned in my earlier post, I'm also concerned > about the ability of MyHDL to write clever code. I would like to know > how you can implement a 16 to 4 priority encoder in MyHDL.... Just like you would in VHDL or Verilog: loop over the input bits and break out early as soon as a '1' is found. No cleverness needed, just an HDL with support for procedural statements. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.comArticle: 126509
On Sun, 25 Nov 2007 17:58:24 -0600, Ben Jackson <ben@ben.com> wrote: >I'm using a Cyclone II with 1.2V core. The 1.2V regulator has an open >drain "power good" signal and a cap to delay that after startup. > >It looks like I could hook this to either nSTATUS or nCONFIG to delay >FPGA configuration. The only difference I can see is that nSTATUS is >meant for daisy chaining FPGAs and does not appear to be tested after >configuration unless nCONFIG is first pulled low. > >Looking at the Configuration Cycle State Machine (p1-5, figure 1-2 in >the configuration handbook) it looks like the chip itself has a >'power supply not stable' test, and it may not be necessary to hook up >PWRGD at all. > >What's the best practice here? Connect PWRGD to nConfig. Do not let nConfig go high until all supplies are within tolerance. (IOW, pull nConfig low if any supply is out of tolerance.) >From the StratixIIGX data sheet: "(4) VCCPD must ramp-up from 0 V to 3.3 V within 100 us to 100 ms. If VCCPD is not ramped up within this specified time, the Stratix II GX device will not configure successfully. If the system does not allow for a VCCPD ramp-up time of 100 ms or less, hold nCONFIG low until all power supplies are reliable." Since in general you will not be able to control brownouts (i.e. you cannot guarantee any particular risetime), you really do need a precision supply monitor. Regards, AllanArticle: 126510
Jan Decaluwe schrieb: > Wolfgang Grafen wrote: > >> MyHDL is a one man show. > > MyHDL is set up as a typical open-source project. It is as open as possible > and encourages people to contribute. People do contribute when it's useful > to them, and they do so for MyHDL. Of course, there is a benevolent > dictator > (yours truly) to set the pace and to arbitrate. > > So the statement above is disrespectful to all those who contributed in > some > form to MyHDL. I immediately add that I'll take the blame: I haven't > acknowledged these contributions explicitly enough in the past. I'll try > to fix that, and I apologize to all those concerned Whether it is disrespectful or not depends on the view point. For one person or probably a hand full person it is a great effort. I didn't mean it in a negative way. > > > I doubt that Python is the ideal language based for >> hardware description. I believe it is possible to design a very >> concise dynamic >> language for hardware design. But this will significantly more than >> one person >> to bring it up. My impression is MyHDL is not very suitable for large >> projects now. > > doubt, believe, impression ... instead of spreading FUD, why not just > tell us about our complaints and the features you are missing. (Not in this > newsgroup of course.) > First of all, I miss sufficient documentation and really useful examples. A large project I think of has some millions gate coded in hundreds of blocks designed by five or more hardware designers with several clock domains and will finally work. It should be able to efficiently simulate, write back synthesis timing information and so on. I like Python for a long time. Python was not designed for hardware design. The ideal language has the most comprehensive syntax and good support e.g. for parallel processes. It can be done in Python, but with less comprehensive syntax and less simulation performance compared to an optimised language. Of course, this is only my opinion. I promise I will look over MyHDL again (did it last half a year ago). Best regards WolfgangArticle: 126511
On Mon, 26 Nov 2007 23:33:44 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >On Sun, 25 Nov 2007 17:58:24 -0600, Ben Jackson <ben@ben.com> wrote: > >>I'm using a Cyclone II with 1.2V core. The 1.2V regulator has an open >>drain "power good" signal and a cap to delay that after startup. >> >>It looks like I could hook this to either nSTATUS or nCONFIG to delay >>FPGA configuration. The only difference I can see is that nSTATUS is >>meant for daisy chaining FPGAs and does not appear to be tested after >>configuration unless nCONFIG is first pulled low. >> >>Looking at the Configuration Cycle State Machine (p1-5, figure 1-2 in >>the configuration handbook) it looks like the chip itself has a >>'power supply not stable' test, and it may not be necessary to hook up >>PWRGD at all. >> >>What's the best practice here? > > >Connect PWRGD to nConfig. Do not let nConfig go high until all >supplies are within tolerance. (IOW, pull nConfig low if any supply >is out of tolerance.) > > >From the StratixIIGX data sheet: > >"(4) VCCPD must ramp-up from 0 V to 3.3 V within 100 us to 100 ms. If >VCCPD is not ramped up within this specified >time, the Stratix II GX device will not configure successfully. If the >system does not allow for a VCCPD ramp-up time >of 100 ms or less, hold nCONFIG low until all power supplies are >reliable." > > >Since in general you will not be able to control brownouts (i.e. you >cannot guarantee any particular risetime), you really do need a >precision supply monitor. Somehow I managed to edit out the part where I explained that brownout detectors made on linear chips (e.g. your regulator) are probably much more accurate than the ones made on digital chips (e.g. your FPGA). They also won't suffer from risetime limitations, etc. Regards, AllanArticle: 126512
On Mon, 26 Nov 2007 23:57:04 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >On Mon, 26 Nov 2007 23:33:44 +1100, Allan Herriman ><allanherriman@hotmail.com> wrote: > >>On Sun, 25 Nov 2007 17:58:24 -0600, Ben Jackson <ben@ben.com> wrote: >> >>>I'm using a Cyclone II with 1.2V core. The 1.2V regulator has an open >>>drain "power good" signal and a cap to delay that after startup. >>> >>>It looks like I could hook this to either nSTATUS or nCONFIG to delay >>>FPGA configuration. The only difference I can see is that nSTATUS is >>>meant for daisy chaining FPGAs and does not appear to be tested after >>>configuration unless nCONFIG is first pulled low. >>> >>>Looking at the Configuration Cycle State Machine (p1-5, figure 1-2 in >>>the configuration handbook) it looks like the chip itself has a >>>'power supply not stable' test, and it may not be necessary to hook up >>>PWRGD at all. >>> >>>What's the best practice here? >> >> >>Connect PWRGD to nConfig. Do not let nConfig go high until all >>supplies are within tolerance. (IOW, pull nConfig low if any supply >>is out of tolerance.) >> >> >>From the StratixIIGX data sheet: >> >>"(4) VCCPD must ramp-up from 0 V to 3.3 V within 100 us to 100 ms. If >>VCCPD is not ramped up within this specified >>time, the Stratix II GX device will not configure successfully. If the >>system does not allow for a VCCPD ramp-up time >>of 100 ms or less, hold nCONFIG low until all power supplies are >>reliable." >> >> >>Since in general you will not be able to control brownouts (i.e. you >>cannot guarantee any particular risetime), you really do need a >>precision supply monitor. > > >Somehow I managed to edit out the part where I explained that brownout >detectors made on linear chips (e.g. your regulator) are probably much >more accurate than the ones made on digital chips (e.g. your FPGA). >They also won't suffer from risetime limitations, etc. Another note from the StratixIIGX data sheet: "(3) Maximum VCC rise time is 100 ms, and VCC must rise monotonically from ground to VCC." To me, this implies that you need a precision (i.e. external) monitor on all rails. The last time I designed a board with an FPGA (last month), I used the PWRGD outputs on several different regulators in conjunction with an LTC2900 so that every rail on the board was monitored. The resultant (active low) signal was ANDed into the nCONFIG signal. The LTC2900 is expensive (~$3.63 Digikey), but flexible. There are hundreds of similar parts to choose from. Regards, AllanArticle: 126513
First of all, thanks a lot for your reply! > What is the value of r8? Here you load the contents of address (r8 + > 0x7a810001) into register r8. > To load addr's contents you should better write you should write: > lwi r8, r0, addr > So you don't need to set r8 to 0 first. > Unfortunately you cannot load a word from an unaligned location anyway. So > addr must be divisible by 4. I followed your advice and loaded the contents of memory 0x7a810010 which is an address divisible by 4. The contents of that address is "bbbbbbbb" given through a testbench file. As a result and based on your instructions, i use the code: asm(" lwi r8, r0, 0x7a810010"); > > asm(" sw r8,r8(r8) "); > > I don't seem to get the contents of 0x7a810001 address (which is > > 'bbbbbbbb' - given by vhdl testbench) into the simulation outcome. > > Is there sth wrong with the use of instructions? Should i use an OR/ > > ORI as well? Any problems with 16 or 32 bit values? > As I mentioned above lwi needs a word-aligned address. If you really have to > load a word beginning at 0x7a810001 you coud read the words at 0x7a810000 > and 0x7a810004 and do some shift magic than. The following step was to use the 'store' instruction in order to see the contents of the address "0x7a810010" at register 8. asm(" sw r8,r8(r8) "); The problem is that i can see the address value on the opb_abus of the mb_opb simulation waveform, but i cannot see any data on the opb_dbus (see only undefined value or series of 'x'). Any idea what could be wrong with the use of instructions? Should i use an OR/ORI? Any problems with 16 or 32 bit values? Really appreciate your help guys!Article: 126514
On Nov 26, 1:58 am, Ben Jackson <b...@ben.com> wrote: > I'm using a Cyclone II with 1.2V core. The 1.2V regulator has an open > drain "power good" signal and a cap to delay that after startup. > > It looks like I could hook this to either nSTATUS or nCONFIG to delay > FPGA configuration. The only difference I can see is that nSTATUS is > meant for daisy chaining FPGAs and does not appear to be tested after > configuration unless nCONFIG is first pulled low. > > Looking at the Configuration Cycle State Machine (p1-5, figure 1-2 in > the configuration handbook) it looks like the chip itself has a > 'power supply not stable' test, and it may not be necessary to hook up > PWRGD at all. > > What's the best practice here? I think it is best to use a voltage supervisor circuit that accurately monitors Vcc and provides a clean and long reset signal. It's also useful for brown-out conditions and orderly reset when the power fails. EliArticle: 126515
> I just have one question > Whenever DCM is UNLOCKED, LOCKED signal is low, is that sure? Not 'sure', as already mentioned, the status register has flags which you also need to check: The most useful is "CLKIN" stopped bit DO(1). There are also other status bits you may wish to look at ("CLKFB" stopped) to decide if you should reset the DCM, or not. http://www.xilinx.com/support/documentation/user_guides/ug070.pdf (page 64) Since the DCM is a synchronous state machine, if the clock input stops, the LOCKED signal will not transition, but the 'stopped' flag will. AustinArticle: 126516
Hi everybody! Is Itanium supported by ISE software? Best RegardsArticle: 126517
On Nov 25, 9:25 am, "Nevo" <n...@nevo.com> wrote: > Argh. I just discovered that my ByteBlaster MV clone can't program an EPCS > configuration PROM, but the ByteBlaster II can. > > Google led me to a web forum that suggests an MV can be converted to a II, > but I haven't been able to find any details. > > Does anyone know if it's possible to convert a ByteBlaster MV into a > ByteBlaster II, and if so what the details are? > > Thanks, > > -Nevo A brand new USB-Blaster from the people that make it for Altera is US$ 80 delivered. I would thing the conversion process would be: 1) Sell old one on eBay. 2) Buy new one. G.Article: 126518
nbg2006@gmail.com wrote: > I just want to find out if I have to provide a constraint on enable so > that the synthesis tool understands that the enable1 doesnt become > high every clock cycle and that the state machine wont miss any > enable='1' input coming in and the desing would funtion properly ? or > is it that synthesis and post sysnthesis tools dont care about this at > all? Synthesis is pretty clever with this and I wouldn't expect that any constraint other than Fmax is needed. If I can't make Fmax, I much prefer pipelining or ready/ack strobes to oddball timing constraints. -- Mike TreselerArticle: 126519
"rickman" <gnuarm@gmail.com> wrote in message news:d1662618-8529-41c6-a716-d83b5fc791ac@w28g2000hsf.googlegroups.com... > On Nov 20, 6:22 pm, <steve.l...@xilinx.com> wrote: >> A substantial amount of work is required for each appication when we >> move away from Wind/U. We have decided not to do that for FPGA >> Editor. Instead, we are creating a new application that is a combination >> of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be >> available in 11.1 (March 2009). >> >> Steve > > I read that correctly as a year and a half from now, right? Yes. We plan to keep FPGA Editor around for a while so if there are issues, let us know. Hopefully the issue that started this thread is solved by the answer record provided. > That seems like a loooooong way off. I remember once being told that > supporting partial reconfiguration on the Spartan devices was a few > months off and that Xilinx was committed to it. I don't remember a commitement on Spartan support. We have it working internally, but it's a very difficult flow and not something we are prepared to support. The big difference between Spartan and Virtex is that Spartan glitches when reconfigured. That means you need to isolate partial regions including IO, and static routes cannot cross parial regions. We are commited to Partial Reconfig for Virtex. > I don't think that has > ever materialized. How serious is Xilinx about this new tool, PACE? PACE is the old tool. The new tool will replace PACE, Floorplanner, FPI, FPE and FPGA Editor. We are committed. However, in 11.1, the new tool will not replace all FPGA Editor functions (like detailed manual routing) so FPGA Editor will be around for things that a small percentage of customers use until 12.1. Steve From m.nguyen@arcor.de Mon Nov 26 11:22:18 2007 Path: newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!news.karotte.org!news2.arglkargh.de!news.mixmin.net!newsfeed-fusi2.netcologne.de!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Message-Id: <474b1bfd$0$13117$9b4e6d93@newsspool2.arcor-online.net> From: Minh Nguyen <m.nguyen@arcor.de> Subject: Re: can't read/load memory contents Newsgroups: comp.arch.fpga Date: Mon, 26 Nov 2007 20:22:18 +0100 References: <a237d8ac-8862-4f20-8996-274dd3149101@d61g2000hsa.googlegroups.com> <474823d0$0$27140$9b4e6d93@newsspool1.arcor-online.net> <2682078d-2248-45ed-b91d-f2d83ebb33ce@s6g2000prc.googlegroups.com> User-Agent: KNode/0.10.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 60 Organization: Arcor NNTP-Posting-Date: 26 Nov 2007 20:18:22 CET NNTP-Posting-Host: 0ea71923.newsspool2.arcor-online.net X-Trace: DXC=NYoV[0d\jC[5TOT9_N5i<VA9EHlD;3YcR4Fo<]lROoRQ4nDHegD_]RUfE3m\@`M^\Vj??9;AV]e>QnE8XogL7[_Zj8d:IN]D^<U X-Complaints-To: usenet-abuse@arcor.de Xref: prodigy.net comp.arch.fpga:138589 On Mon 26 Nov 2007 15:39 dartanian wrote: > First of all, thanks a lot for your reply! > > >> What is the value of r8? Here you load the contents of address (r8 + >> 0x7a810001) into register r8. >> To load addr's contents you should better write you should write: >> lwi r8, r0, addr >> So you don't need to set r8 to 0 first. >> Unfortunately you cannot load a word from an unaligned location anyway. >> So addr must be divisible by 4. > > > I followed your advice and loaded the contents of memory 0x7a810010 > which is an address divisible by 4. The contents of that address is > "bbbbbbbb" given through a testbench file. As a result and based on > your instructions, i use the code: > > asm(" lwi r8, r0, 0x7a810010"); > > > >> > asm(" sw r8,r8(r8) "); >> > I don't seem to get the contents of 0x7a810001 address (which is >> > 'bbbbbbbb' - given by vhdl testbench) into the simulation outcome. >> > Is there sth wrong with the use of instructions? Should i use an OR/ >> > ORI as well? Any problems with 16 or 32 bit values? > >> As I mentioned above lwi needs a word-aligned address. If you really have >> to load a word beginning at 0x7a810001 you coud read the words at >> 0x7a810000 and 0x7a810004 and do some shift magic than. > > > > The following step was to use the 'store' instruction in order to see > the contents of the address "0x7a810010" at register 8. > > asm(" sw r8,r8(r8) "); Ah yes. This should be sw r8, rA, rB where the address (rA + rB) must be word-aligned again--and 0xbbbbbbbb * 2 isn't. You could also use an IMM, so you don't need to fill rA and rB: swi r8, r0, addr Good luck. > The problem is that i can see the address value on the opb_abus of > the > mb_opb simulation waveform, but i cannot see any data on the opb_dbus > (see only undefined value or series of 'x'). > Any idea what could be wrong with the use of instructions? Should i > use an OR/ORI? Any problems with 16 or 32 bit values? > > > Really appreciate your help guys! HTHArticle: 126520
"Yannick" <yannick.deal@gmail.com> wrote in message news:04025b14-3c87-4269-a234-f2837cff8cd7@w28g2000hsf.googlegroups.com... > Hi, > > How many long Xilkernel take to startup with microblaze (System > Clock : 50 MHz). > On my design, the Microblaze need more than 30 second to create the > first thread after xil_kernel_main(). Sounds like you have a large context switch interval configured. Check the value for the parameter systmr_internal (specified in milliseconds) in the kernel configuration. Also check if an incorrect value has been provided to systmr_freq. Assuming these two values are correct, the first context switch should take around about the time you have specified for systmr_interval. Note the kernel initialization time is dependent on the numbers you have configured for the various kernel features like number of threads/semaphores -- but unless you threw in a huge number there, this overhead should be negligible.Article: 126521
"taco" <tralalal@joepie.nl> wrote in message news:fi6j21$6dg$1@usenet.uva.nl... > wojjed@gmail.com wrote: > > the 44.1 khz is a serial output rate of the ADC? and the total output rate > without headers, dataprocessing or whatever is 44.1*20*16= 14 Mbps? > Should > be possible with such a device if you choose a correct clock frequency. > Taco I am sure the OP is talking about audio ADCs, so 44.1 kHz is not serial rate but rather parallel. However, your calculation of the total bandwidth required is still correct... Obviously this speed is not an issue with any of the modern FPGAs. /MikhailArticle: 126522
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:p86dnXdxkoQO2tTanZ2dnUVZ_v3inZ2d@comcast.com... > Ved wrote: > >> How can we measure setup and hold time of a flip-flop on FPGA in lab ? > > Configure a device with one FF connected to I/O pins. The clock likely > connects to a dedicated clock input pin. Put in signals with varying > delay and see what the output looks like. > > As someone else mentioned, a stripline with a movable tap could > probably do it. > > -- glen > All of these ideas are measuring setup and hold of the FPGA (not the FF). MikeArticle: 126523
The issue will be the number of parallel inputs to the FPGA. 16 x 20 bits would require 320 data inputs, unless you can do some external multiplexing or data ORing.. Once inside the FPGA, the bandwidth should be no problem. Peter Alfke, Xilinx Applications On Nov 26, 12:40 pm, "MM" <mb...@yahoo.com> wrote: > "taco" <trala...@joepie.nl> wrote in message > > news:fi6j21$6dg$1@usenet.uva.nl... > > > woj...@gmail.com wrote: > > > the 44.1 khz is a serial output rate of the ADC? and the total output rate > > without headers, dataprocessing or whatever is 44.1*20*16= 14 Mbps? > > Should > > be possible with such a device if you choose a correct clock frequency. > > Taco > > I am sure the OP is talking about audio ADCs, so 44.1 kHz is not serial rate > but rather parallel. However, your calculation of the total bandwidth > required is still correct... Obviously this speed is not an issue with any > of the modern FPGAs. > > /MikhailArticle: 126524
On Nov 26, 11:23 am, "GaLaKtIkUs(tm)" <taileb.me...@gmail.com> wrote: > Hi everybody! > Is Itanium supported by ISE software? > > Best Regards No. Dan
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