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
Just put the " use UNISIM.VComponents.all; " in the library declaration part it will do the trick.. Moti.Article: 80276
"Yaju N" <yaj_n@hotmail.com> wrote in message news:<1109807829.504700.170280@f14g2000cwb.googlegroups.com>... > For now, I have a 50Mhz oscillator on board, > so the application would run at a maximum of 50Mhz. Actually there are DCMs in a Spartan-3 that allow you to run your design on much higher frequencies, even if there is only a 50 MHz oscillator present. Kolja SulimmaArticle: 80277
Hello ALL, This is my second message :( I did not get answer for the first one, so I am sending it again. My be it got lost somewhere in news-server, or this is not the right NG to post this message. Any way, people here are talking about FPGA and SDRAM adn this is my current problem. I am having hard time designing the schematic to interface conventional SDRAM chip to Virtex-4 FPGA. As a SDRAM we have selected Micron 256Mbit part with 32 bit wide data bus. Both packages a BGA, Virtex-4 is FF-672 type, SDRAM is FBGA-90. Our chips is planned to be located about 5-10mm (0.2-0.4 inches) from each other and the longest trace is suppose to be about 2.0-2.5 inches. We are also planning to have data bus traces to be as short as possible. First approximation gives about 1.3-1.5 inches data bus traces. The trace impedance is planned to be about 53-55Ohms. The interface is planned to run at 125MHz. The memory we are going to use has conventional 3.3V interface. We are planning to use DCI for all outputs in our design, i.e. control signals, address bus, clock and clock enable signals. Doing simulation we found that DCI does pretty good job for all these lines - there is no overshot/undershot problems at all on all these lines. The only problem is the data bus. Than signal originates from Virtex-4 FPGA everything goes fine, because DCI still active for this direction, everything becomes bad when signal originates from SDRAM. There is significant overshot and undershot around every edge of the signal. Its value goes as high as 4.2V for overshot and to -900mV for undershot. This extreme condition lasts for 200-300 picoseconds according to our simulation. For simulation we are using Virtex-4 and SDRAM Ibis models from manufacturers. The relatively simple solution is to terminate each line in data bus, but it requires relatively lots of space on the PCB and can not be done reliably :( As soon as Micron driver gets terminated properly the line becomes less than suitable for Virtex-4 driver, something in between is not very good for both of them. The funniest thing that I saw several existing and reliably working designs, using average trace length about 2.5 inches with similar components working with close frequencies and DOES NOT using any series termination on data lines with default FPGA drivers. So, what part are we missing? Should we believe in simulation or it is not as accurate as expected? With best regards, Vladimir S. MirgorodskyArticle: 80278
where can I get the docs that specify the usage of Xilinx Driver API? I found all the docs Xilinx provides are talking on how to use the GUI or specify its hardware products,but little comments on how to create a software application with microblaze. Or if you own any tips of writting software application,do you mind sharing it?I'm urgently consulting it. thank youArticle: 80279
Newman, Perhaps I'm unclear about something... when I say 'JTAG' below--what I was referring to is the sysACE controller ASIC JTAG interface to the FPGA and it's auto-load of given file to FPGA at boot. Not impact or a GUI JTAG load. I'm trying to get the case elevated in Xilinx support somehow. I'm puzzled as to how a problem like this is now impacting more/all ML310 users. We sort of suspected that the CF is somehow getting trashed--but if that is the case, why I can retry a boot and it might boot the very next pwr cycle. That does not compute--nor does the fact that low-level, non vxWorks boot code can access the compact flash EVERY time. Purely conjecture, but I think perhaps the Xilinx FAT Fs libraries are leaving the CF in some quasi-bad state after I close the file and then crank up vxWorks--and it just flat out does not like the state the boot-level lib calls left it in.... If you come across anything.. let me know. Thanks, Paul "newman" <newman5382_nospam@yahoo.com> wrote in message news:IOpVd.139443$JF2.104363@tornado.tampabay.rr.com... ><snip> >> So to summarize: >> >> 1) Why the behavior of vxWorks boot seems to vary depending on >> whether the bin executable was loaded via the PPC using Xilinx FAT Fs >> library versus the vxWorks executable being loaded by sysACE controller >> (as an appended image to the ACE file)? What is sysACE doing to >> CF/himself after loading that the boot code/sysACE load of the boot code >> is not? >> >> 2) Why vxWorks hangs on std file i/o operations (intermittently) >> >> 3) Why even with errors occurring in the sysACE controller >> registers, does the system permanently hang-or put another way, >> "shouldn't the drivers recover gracefully when errors occur on the sysACE >> controller/core?" >> >> At first I thought the issue had to be a problem with the Xilinx FAT >> calls or the loader itself--but after verifying checksums of actual file >> vs the RAM copy of vxWorks binary file, I would hope to have ruled this >> possibility out-- and now that sysACE loads are also hanging, albeit much >> less frequently, I'm thinking a HW or driver issue? >> >> Are there are any other signals I should be looking at? Anyone have any >> idea of other things to try? Or have the name/email of someone at Xilinx >> that could shed light on this issue? I've tried everything I can think >> of. Unfortunately it seems the FAEs are extremely overburdened and >> finding someone knowledagble of EDK and vxWorks is not easy to begin >> with..... (Is someone from Xilinx corporate listening????) >> >> > > Paul, > I saw something somewhere on the net, looked but could not find it again, > saying that they were having lots of trouble writing to the CF. They > thought the sysace interrupt was firing all the time, and they could not > turn it off and or handle it correctly. I had some problems getting my > little program going. I ended up having the EDK generate the sysAce file > and dragging the file into the compact flash rather than doing it via > impact. I also had another problem where sector 0 on the CF got trashed, > and I had to redo stuff with fdisk via a linux system to get it "write" > again. excuse the pun. In a former life, I did some VxWorks stuff and > filed a problem report. They pretty much called me every few days to > status whether I had made any progress solving the problem. ;,) It sounds > like you are at a higher level of sophistication than I am. I was > thinking that heh, SysAce ain't so bad, but it sounds like more fun is > waiting for me. > > regards > -Newman >Article: 80280
Moti wrote: > Just put the > " use UNISIM.VComponents.all; " > in the library declaration part > it will do the trick.. > > Moti. -- synthesis translate_off library UNISIM; use UNISIM.VComponents.all; -- synthesis translate_on gives you one warning less during synthesis...Article: 80281
Validimir, I don't believe you'll do any damage to the Virtex with the size and duration of overshoot you have in your simulation. I am not yet using Virtex 4, but in all instances where I used SDR SDRAMs I have not used DCI in the FPGA or installed series resistors. Note that the data bus is not a clock, so you have a lot of settling time at 125 MHz to deal with overshoot and ringing. Also be aware that using DCI on a wide data bus can add significant power consumption. The very short duration of the overshoot leads me to believe there is very little power dissipated in the clamp diodes, and the relatively high voltage during that time is most likely indicating turn-on characteristics of the diode rather than showing large currents. If your simulation shows the data within the normal logic high or low ranges by the time your FPGA samples it (clock edge minus setup time) you should not have a problem with this design. Regards, Gabor v_mirgorodsky@yahoo.com wrote: > Hello ALL, > > This is my second message :( I did not get answer for the first one, so > I am sending it again. My be it got lost somewhere in news-server, or > this is not the right NG to post this message. Any way, people here are > talking about FPGA and SDRAM adn this is my current problem. > > I am having hard time designing the schematic to interface conventional > SDRAM chip to Virtex-4 FPGA. As a SDRAM we have selected Micron 256Mbit > part with 32 bit wide data bus. Both packages a BGA, Virtex-4 is FF-672 > type, SDRAM is FBGA-90. Our chips is planned to be located about 5-10mm > (0.2-0.4 inches) from each other and the longest trace is suppose to be > about 2.0-2.5 inches. We are also planning to have data bus traces to > be as short as possible. First approximation gives about 1.3-1.5 inches > data bus traces. The trace impedance is planned to be about 53-55Ohms. > The interface is planned to run at 125MHz. > > The memory we are going to use has conventional 3.3V interface. We are > planning to use DCI for all outputs in our design, i.e. control > signals, address bus, clock and clock enable signals. Doing simulation > we found that DCI does pretty good job for all these lines - there is > no overshot/undershot problems at all on all these lines. The only > problem is the data bus. Than signal originates from Virtex-4 FPGA > everything goes fine, because DCI still active for this direction, > everything becomes bad when signal originates from SDRAM. There is > significant overshot and undershot around every edge of the signal. Its > value goes as high as 4.2V for overshot and to -900mV for undershot. > This extreme condition lasts for 200-300 picoseconds according to our > simulation. For simulation we are using Virtex-4 and SDRAM Ibis models > from manufacturers. > > The relatively simple solution is to terminate each line in data bus, > but it requires relatively lots of space on the PCB and can not be done > reliably :( As soon as Micron driver gets terminated properly the line > becomes less than suitable for Virtex-4 driver, something in between is > not very good for both of them. > > The funniest thing that I saw several existing and reliably working > designs, using average trace length about 2.5 inches with similar > components working with close frequencies and DOES NOT using any series > termination on data lines with default FPGA drivers. So, what part are > we missing? Should we believe in simulation or it is not as accurate as > expected? > > With best regards, > Vladimir S. MirgorodskyArticle: 80282
Phil Hays <Spampostmaster@comcast.net> wrote: >On Thu, 03 Mar 2005 03:42:41 +0000, nospam <nospam@nospam.invalid> >wrote: > >>Phil Hays <Spampostmaster@comcast.net> wrote: >> >>> >>>Sticker with "Windows only", and both a Windows CD and a Linux CD in >>>the case. >> >>No ISE 6.3i eval with it then? Did you get ISE 6.3i with the starter kit? >There was a 6.3i with the starter kit and another 6.3i eval with the >EDK. Those of us who got ISE 6.2i with the kit will be ok then :)Article: 80283
We are in Europe and definately do a Spartan-3 board. Broaddown2 is available now. Also soon a small cheap S3 hobby/student board. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Jens Baumann" <annonce05_nospam@web.de> wrote in message news:42260dc0$0$29271$14726298@news.sunsite.dk... > Hi, > I'd like to buy the Spartan3 board from Digilent > https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD > > However, it seems not to be available in Europe, as previous discussions in > this group show. > > Another oprion would be Memec > http://www.memec.com/uploaded/Spartan3LC_4.pdf > although I'd prefer Digilent for several reasons (on board ram, recommended > by Xilinx). > > Is there any possibility to order the digilent board, clones of this board, > or at least a board with equivalent specifications in Europe? > > Thanks > JensArticle: 80284
On 22 Feb 2005 00:44:48 -0800, "SD" <sourabh.dhir@gmail.com> wrote: >Hi all, I have a signal algorithm implementation design on FPGA. I >simulated the design in Modelsim and now I want to export the output >values and compare with those of the Matlab. Can somebody suggest me >how to do that? > >I read the input values of my testbench from the same input file which >I use for Matlab input. Get the testbench to write an output file. It's easy both in VHDL and in Verilog. And you get to choose the output format yourself, so you could easily make it look like CSV or Matlab or whatever. And you get to choose when the data are sampled. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 80285
"Bo" <bo@cephus.com> wrote in message news:84833$42270c02$18d6ec55$18295@KNOLOGY.NET... > Newman, > > Perhaps I'm unclear about something... when I say 'JTAG' below--what I was > referring to is the sysACE controller ASIC JTAG interface to the FPGA and > it's auto-load of given file to FPGA at boot. Not impact or a GUI JTAG > load. OK, I was referring to generating the ACE file via Impact or generating it via the EDK tool menu selection. I've had luck generating the file with the EDK method, but have not gone back to verify the Impact method works for me. > > I'm trying to get the case elevated in Xilinx support somehow. I'm puzzled > as to how a problem like this is now impacting more/all ML310 users. My system is a Memec UltraController with a mezzanine memory card and an add-on SysAce card. > We sort of suspected that the CF is somehow getting trashed--but if that > is the case, why I can retry a boot and it might boot the very next pwr > cycle. That is tough to figure out. My problem was repeatable from a hard SysAce reset start up. I think it had a different failure scenario from a soft (XMD) rst. My guess was that the BRAMs were not reloaded on a soft reset. > That does not compute--nor does the fact that low-level, non vxWorks boot > code can access the compact flash EVERY time. Purely conjecture, but I > think perhaps the Xilinx FAT Fs libraries are leaving the CF in some > quasi-bad state after I close the file and then crank up vxWorks--and it > just flat out does not like the state the boot-level lib calls left it > in.... I did a lot of work adding debug code to the local libraries, and spewing results out the serial port. I had to recompile the local libraries manually cause EDK by default, over writes the local files with fresh copies when recompiled from the pull-down menu. Perhaps the status of the Compact Flash could be output out the serial port before entering and after exiting the problem code area. A major problem I had with VxWorks stuff was that I had to beg VxWorks to supply a section of source code of the area in which I suspected a problem so I could add debug code into it to isolate the cause. Sometimes the cause was a bug in their source code. My information is several years old. - Good luck, Newman > > If you come across anything.. let me know. > > Thanks, > > Paul > > "newman" <newman5382_nospam@yahoo.com> wrote in message > news:IOpVd.139443$JF2.104363@tornado.tampabay.rr.com... >><snip> >>> So to summarize: >>> >>> 1) Why the behavior of vxWorks boot seems to vary depending on >>> whether the bin executable was loaded via the PPC using Xilinx FAT Fs >>> library versus the vxWorks executable being loaded by sysACE controller >>> (as an appended image to the ACE file)? What is sysACE doing to >>> CF/himself after loading that the boot code/sysACE load of the boot code >>> is not? >>> >>> 2) Why vxWorks hangs on std file i/o operations (intermittently) >>> >>> 3) Why even with errors occurring in the sysACE controller >>> registers, does the system permanently hang-or put another way, >>> "shouldn't the drivers recover gracefully when errors occur on the >>> sysACE controller/core?" >>> >>> At first I thought the issue had to be a problem with the Xilinx FAT >>> calls or the loader itself--but after verifying checksums of actual file >>> vs the RAM copy of vxWorks binary file, I would hope to have ruled this >>> possibility out-- and now that sysACE loads are also hanging, albeit >>> much less frequently, I'm thinking a HW or driver issue? >>> >>> Are there are any other signals I should be looking at? Anyone have any >>> idea of other things to try? Or have the name/email of someone at Xilinx >>> that could shed light on this issue? I've tried everything I can think >>> of. Unfortunately it seems the FAEs are extremely overburdened and >>> finding someone knowledagble of EDK and vxWorks is not easy to begin >>> with..... (Is someone from Xilinx corporate listening????) >>> >>> >> >> Paul, >> I saw something somewhere on the net, looked but could not find it >> again, saying that they were having lots of trouble writing to the CF. >> They thought the sysace interrupt was firing all the time, and they could >> not turn it off and or handle it correctly. I had some problems getting >> my little program going. I ended up having the EDK generate the sysAce >> file and dragging the file into the compact flash rather than doing it >> via impact. I also had another problem where sector 0 on the CF got >> trashed, and I had to redo stuff with fdisk via a linux system to get it >> "write" again. excuse the pun. In a former life, I did some VxWorks >> stuff and filed a problem report. They pretty much called me every few >> days to status whether I had made any progress solving the problem. ;,) >> It sounds like you are at a higher level of sophistication than I am. I >> was thinking that heh, SysAce ain't so bad, but it sounds like more fun >> is waiting for me. >> >> regards >> -Newman >> > >Article: 80286
john.deepu@gmail.com wrote:
>Hi all,
> I am currently implementing a module which has large number of
>registers(the datapath is heavily pipelined and lotsa registers). To
>reduce the area of the design , I have replaced many of the internal
>registers ,with FFs without a RESET pin.
>So now all the internal register dont get cleared (reset) while
>applying an external reset. they just keep on shifting unknown value,
>until the actual data fills in the pipeline. this is perfectly
>acceptable for me except for the initial X's I see in waveform, till
>the actual data reaches to the point.
>
>I save around 10-15% area by this way. (in a total size of ~90K).
>My module is part of a ~1.5Mgates asic.
>
>I want to ask you people , whether this method of reducing area will
>cause any problems(in the design flow) considering the total system.
>
>please giveme ur valuable suggestions.
>
>thanks a lot
>Deepu John
>
>
>
generally, it won't cause a problem except for with ASIC folks who don't
accept anything less than 100% reset. You can make the reset totally
invisible by a) making sure you break all internal loops by forcing a
reset on one element in the loop and holding that reset for enough
clocks to make the known data propagate all the way around the loop, and
b) putting reset on all the output registers that is applied immediately
and then held until good data propagates to the output register. The
output register reset can easily be accomplished by using a sync RS-FF
that is set by the reset input signal and then cleared by either a
delayed version of the input reset signal or using a counter that is
preset by the input reset signal and whose terminal count clears that
FF. Same is true for the loop resets.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 80287I would use a 32-bit accumulator (or a dds) clocked at 24MHz with a constant input of 1.8432*2^32/24. The msb of the output is your clock. Anyone please correct me if I'm wrong. dsp novice.Article: 80288
V4 SI: The package is thrilling, but the Cin is bleak
Peter wrote:
>
> Still no comments on the newsgroup.
>
I didn't catch the webcast, but looked at that BGA paper
last night. It appears to be limited in scope to discussing
package related output switching effects, which is not the
whole story for high speed I/O.
Looking at the output waveforms shown in figure 20, my first
reaction was that it clearly showed that Xilinx hasn't done
much to improve their I/O cell capacitance [1] since V2.
And, from DS302, V4 Cin = 10 pF, identical to the V2 spec.
Meanwhile, the marketeering data rate has gone from
"840 Mbps" for V2 to "1 Gbps" for V4.
Perhaps Dr. Johnson could proffer his honest opinion of
a "1 Gbps" LVDS receiver with a Cin of 10 pF [2].
While the reduced output slew rate due to capacitive loading
may be of marginal "benefit" for low speed I/O standards, the
disadvantages of high I/O capacitance far outweigh the advantages,
especially for parts whose I/O is marketed as 1 Gbps capable.
Since you have that spiffy board at hand, I'd love to see
plots of the following:
A) X vs. A ICCO for the "Hammer Test" at several toggle rates
B1) X vs. A waveforms for a high speed single ended standard (xSTL)
B2) X vs. A ICCO for a high speed single ended standard (xSTL)
C1) X vs. A waveforms for 1 Gbps differential LVDS
C2) X vs. A ICCO for 1 Gbps differential LVDS
D) X vs. A differential TDR input waveforms into a DT termination
at 100, 200, 500 ps input edge rates
What I'd expect to see from those plots, if the Altera I/O
capacitance is really half that of the Xilinx part:
A) dynamic ICCO would increase faster with frequency for the
Xilinx output driver
B) the output waveforms would look worse at higher speeds for
the Xilinx driver
C) Differential output switching would mitigate the SSO package
effects somewhat as compared to single ended switching at
the same rate
D) input reflections would be worse for the Xilinx part
The last time I pointed out the impacts of high I/O capacitance
in this forum [3], a certain overzealous Xilinx engineer flamed
the thread into oblivion. Hopefully this thread will suffer a
gentler fate, with rational technical discussion prevailing.
Brian
a longtime (mostly) Xilinx user who wants to see better parts
[1] While I like the flexibility of the Xilinx general-purpose
nearly-all-IOBs-have-LVDS capability, if Cin could be improved
by having having some I/O banks without DCI or certain of the
I/O standards, I'd still buy the parts.
[2] I'd be happy to quote a Cdiff instead, if someone could tell
me where it is documented.
Ideally, the differential input model would include both
the single ended shunt Cin values as well as a differential
across-the-pair Cdiff, so I could model both the differential
and common mode reflections.
If Cdiff is negligible, and the input waveform is purely
differential, then Cdiff = 1/2 Cin, as Austin has argued before.
[3] http://groups-beta.google.com/groups?q=lvds_25_dci+cdiff
or http://www.fpga-faq.org/archives/61300.html#61312
Article: 80289
I'm using an Altera APEX20KE with 200k gates on a bought FPGA board.
The Clocks 1 and 2 of the FPGA are used by the board, the Clocks 3 and 4 are
free.
I testet the i2c-core from opencores.org working with the onboard clock on
Clock-Pin 2 and it works fine.
If I connect (just connect not use in the FPGA, I'm still using the onboard
clock from Clock-Pin 2) an own clock to the two free Clock-Pins, the
i2c-core doesn't work anymore !!! :-(
If I use my own clock on Clock-Pin 3 or 4 as clock-input for the i2c-core,
it doesn't work too.
I can't understand this behaviour !?!?!?
If I put in the Altera Megafunction altclklock at the input of Clock2 and
Clock4 Quartus II 4.2 SP1 can't fit. The Error Messages of the Fitter are:
Error: Project requires too many 2 ClockLock PLLs, but the selected
device can contain only 0 ClockLock PLLs
Error: Project requires 2 signals of type clock output, but the target
device can contain only 1 signals
Error: Can't fit design in device
Error: Quartus II Fitter was unsuccessful. 3 errors, 0 warnings
but the APEX20KE: EP20K200EFC672-3 has 2 PLLs according to the data
sheet!!!!
Is this an Error in Quartus or mine???
Please Help
Manfred Balik
Article: 80290
Jason Zheng wrote:
> Does anyone know of a good software for drawing timing diagram under
> linux/X11?
http://www.timingdesigner.com/
has a linux version for drawing timing diagrams.
I prefer to write an hdl model and let
modelsim do the drawing.
-- Mike Treseler
Article: 80291> -- synthesis translate_off > library UNISIM; > use UNISIM.VComponents.all; > -- synthesis translate_on > > gives you one warning less during synthesis... I forgot to mention the "library UNISIM" You got me there ;-))Article: 80292
Jaxato, Your Athlon is not a very IO intensive chip, the only other chip it has to talk with is the northbridge and the bus that it uses to do this does not run overly fast (several hundred MHz, nowhere near fast serial IO speeds that are achievable using modern FPGA io's). Newer Athlon's use the hyper transport interface, which is more comparable in speed, but even in that interface there is a total of 16 differential IO's that are involved; it is vastly easier to ensure good signal integrity in such a small IO interface (even if all of the bits were simultaneously switching) then to do so for all of the IO banks of an FPGA. I guess that, in short, no "black magic" is neccessary for the current crop of cpu package designs. Ljubisa Bajic jaxato@gmail.com wrote in message news:<1109799264.708758.308200@z14g2000cwz.googlegroups.com>... > So, is there real black magic behing the socket of my athlon 1.8GHZ > processor???Article: 80293
Thanx... The video module design is a black burst generator...which has two modes of operation.....When no external input is connected it has to run as a master free running black burst generator....whereas when an extrenal input is conected the black burst generated has to lock to the incoming video signal I am using an sync stripper and an external PLL which is locking the hsync generated from the sync stripper....ouput clk from the PLL along wth the Hsync is given to the FPGA....where I wanna lock the subcarrier.....which works fine....I mean it locks but with some jitter...which I guess is not acceptable... Hope the details are fine...if u need more....let me knowArticle: 80294
>You could gain immunity to transient faults by changing the design and/or by >choosing a proper component (e.g Actel has Hi-Rel fpgas with build-in TMR). Just a Caution : These FPGAs are not reprogrammableArticle: 80295
Newbie Question, how to read back a configuration? I am using a Xess-50 board with Sparatan2 on it. Please refer to any good tutorial on readback, if possible. Thanks, VSRArticle: 80296
Hi Manfred, I'm not familiar with Apex too much but I know on Stratix certain PLL can ONLY be instatiated with certain dedicated clock pins, ie. the PLL # has to match the clock pin, otherwise a no-fit occurs. I suspect this is your problem. Check the Apex docs, or swap the clock pins that feed your PLLs. HTH, PeteArticle: 80297
HI, I am using PCAD 2002 and use XC9572 64 pin VQFP package in my PCB design. I haven't been able to locate the pattern in PCAD 2002 library. I have also looked through Altium's website for the pattern, but no luck. Could anyone suggest where I can obtain it? Thank you. PapuArticle: 80298
Hi Manfred, > but the APEX20KE: EP20K200EFC672-3 has 2 PLLs according to the data > sheet!!!! > Is this an Error in Quartus or mine??? The EP20K200Exxx-1X and -2X have proper PLLs, the others don't. All the bigger 20KEs have PLLs, but in the non-X version these haven't been tested and might therefore be defective. If this is a recently-produced device and doesn't push the edge of performance of the -3, you might want to classify it as a -2X and see how well you fare in practice, but don't try this if you're going to actually produce something with a -3 posing as a -2X. Best regards, BenArticle: 80299
Hi, there was a thread with the same topic here: http://groups.google.de/groups?hl=de&lr=&selm=885a4a4a.0412030423.4f6b7e7c%40posting.google.com In addition to this I would like to know if it is possible and advisable to make an FPGA hot by intentionally creating contention within the FPGA. I know that this it not possible with HDL but with JBits this should be possible. Thank you.
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