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
"Sean Durkin" <news_nov06@durkin.de> wrote in message news:456d9828$1@news.fhg.de... > > Nope, Virtex5 does indeed have analogue PLLs, half as many as DCMs. The > FAE told us this was because of the increasing popularity of spread > spectrum clocks (like in PCs), and the only way to handle those is a > PLL, so Xilinx saw a demand there. > Hi Sean, That must be why Xilinx don't support the spread spectrum feature the DCMs have/used to have? Sounds like your FAE is bluffing! http://toolbox.xilinx.com/docsan/xilinx6/de/libs/dcm.pdf Cheers, Syms.Article: 112801
XC3020 is a tiny chip by today's standards. By the fairly inaccurate guide of gate count our starter student product is about x20 in notional gate count. You may be lucky and someone on this group has the data for your board but I guess that most people will have thrown a board of this type away by now. There a number of products from ourselves and our competitors that will do you good service and possible more importantly the current Xilinx tools will support the chips on board. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development Board. http://www.enterpoint.co.uk "sjb" <sjb@mindspring.com> wrote in message news:9Lgbh.4783$tM1.1156@newsread1.news.pas.earthlink.net... > Hi all, > > Would anyone be able to direct me to (or provide me with) any materials > related to this board that I've got. > > http://trifs.dyndns.org/xilinx%20board.jpg > > It's an Xilinx XC3020-50 chip on a board of which I cannot locate anything > describing the layout or functions (dip switches/leds/connections/etc...). > The only markings on the board are: > > Xilinx (1994 (C))(on front side) > 0430456 rev 04 (on front side) > 1280037 Rev 02 (on back side) > > I got this board thinking it would be good to continue my education with > FPGA's, of which I'm just starting (so please go easy on me :>)). I've > tried Xilinx's site and can only get documentation on the chip itself. > Xilinx won't provide me with any support on this whatsoever! Internet > searches turn up nothing. Is this really that old of a board/chip that I > should just scrap this thing and try something else? > > Thanks for any input... > > Scott >Article: 112802
I agree with Martin: Synplify is better than XST in runtime and QOR,
and if you have synplify-pro, the HDL analyst (RTL or gate level
schematic viewing) is much better than what XST has.
I don't have any experience with Quartus synthesis.
Andy
Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details? My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html
Article: 112803I wrote and use is0() and is1() vhdl functions that assert warnings if meta-values are encountered in the argument. They also interpret L and H as 0 and 1. Andy Andreas Ehliar wrote: > On 2006-11-28, John_H <newsgroup@johnhandwork.com> wrote: > > If you synthesize with tristate values, the synthesizer may implement your > > bus_star or the roughly equivalent "1 if idle, 0 if there's bus contention" > > like what the Spartan 2E's internal BUFTs implemented electrically. > > A big problem here is that you might have different behavior in simulation > than in reality unless you take care. > > For example, if you assign z to some signals that are used as control > signals you might have some problems as seen in the following example: > > if(controlsignal) begin > Dosomething; > end > > Dosomething will not happen in simulation because z is not true. However, it > will do something in reality because the signal will in reality be 1 in this > situation due to the pullup you described. (I guess you could add pullups or > pulldowns to the signals in the source code to avoid this in Verilog.) > > But this still shows that you must be careful about this situation. My > advice is to totally avoid tristates internally if you can avoid it. > > /AndreasArticle: 112804
Joseph wrote: > Hi all, > > I wonder if anyone here are in the same situation as me. > I am think of buying a new PC, but wondering if I should > wait for Windows Vista become available first. > Have anyone try running FPGA tools (Xilinx Webpack, > Modelsim XE, Quartus, Cygwin) on Windows Vista beta? > Does it work okay? > Or should I get a "Vista capable" PC now and upgrade later? > (sound too much hassle to me, but it might be better?) > Thanks. > > regards, > > Joe Have to agree with pbdel, Vista is a giant piece of whatever. If W2k or XP or Linux works well already what possible reason could there be to add the extra burden that Vista imposes. From what I hear, Vista takes more things away like your right to rebuild your hardware the way you like, it locks things up with more DRM and more restrictions on changing your base.configuration. It also uses far more resources to do the same job even without the Aero candy. Still we will have to deal with Vista eventually, shame that MS wants to make W2K go away and then XP when they are working just fine. just my 2c John JaksonArticle: 112805
Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details? My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin
Short answer: synplify _is_ better than XST, but its ECP2 technology
mapper is still a little immature.
burns
Article: 112806On Wed, 29 Nov 2006 14:19:56 +0000, Joseph <joseph.yiu@obviously-not-a-valid-domain.com> wrote: >Hi all, > >I wonder if anyone here are in the same situation as me. >I am think of buying a new PC, but wondering if I should >wait for Windows Vista become available first. >Have anyone try running FPGA tools (Xilinx Webpack, >Modelsim XE, Quartus, Cygwin) on Windows Vista beta? >Does it work okay? >Or should I get a "Vista capable" PC now and upgrade later? >(sound too much hassle to me, but it might be better?) You can turn off much of Vista's eye candy which takes quite a bit of cpu cycles. In addition the main saving grace of Vista is that it has a 64 bit version where ISE and other tools (I've tried ISE 8.2 under 64 bit Vista) get a full 4G adress space so if your design doesn't fit to 2G but fits 4G you're still in luck.Article: 112807
=?ISO-8859-1?Q?J=FCrgen_B=F6hm?= <jboehm@gmx.net> wrote: > >hi, > >currently I am working on a small hobby project with the Spartan 3 >Starter Kit board from Xilinx. I use ISE WebPack 8.1i and Verilog as a >language. > > Now some questions have come up during this: > >1) There is a need to implement bus structures, say a 16 bit >bidirectional data bus which should connect several modules on the >highest level of the project. > This is one of the down sides of the Spartan 3. The way to solve this is to have a multiplexer at each device's input. This seems a bit cumbersome, but it actually works quite well and fast. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 112808
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: > Joseph <joseph.yiu@obviously-not-a-valid-domain.com> wrote: > >>I wonder if anyone here are in the same situation as me. >>I am think of buying a new PC, but wondering if I should >>wait for Windows Vista become available first. >>Have anyone try running FPGA tools (Xilinx Webpack, >>Modelsim XE, Quartus, Cygwin) on Windows Vista beta? >>Does it work okay? >>Or should I get a "Vista capable" PC now and upgrade later? >>(sound too much hassle to me, but it might be better?) > > > What is two months waiting time worth to you ..? > If I buy it now I can get everything setup during my Christmas holiday. If I wait two months I could be too busy to sort things out afterward. > What hinders you to use MS-XP after Vista is released..? MS will possibly eventually stop supporting XP. (e.g. no more service pack and security updates) Some existing software will eventually move over to Vista. Also, it is often necessary to learn new stuffs. When you work in IT fields people, e.g. family and friends, expect you to know everything, from changing toner of their printers (brands you've never used before) to fixing virus/spyware infected computer. *sign* :( > > You most likely will pay for hardware that will be consumed by Vista Bells & > Whistles that won't benefit your vhdl/verilog processing. > Processing power is not really my biggest concern. I am using the Xilinx Spartan-3 starter kit anyway (only a 200k FPGA). It is purely for learning, not for real work stuffs. But I want to make sure it can run existing tools that I am using now. Glad to know that someone has actually used ISE 8.2 in 64-bit Vista :) I don't think I will spend that much money to get a home PC with 4G RAM (2GB RAM more likely). JoeArticle: 112809
You do not have to wait for Vista to get 64 bits. WinXP64 is available today and works just fine. One advantage of WinXP64 is that 32 bit Windows Apps have access to 4GB of address space. On the WinXP32 32 bit Windows applications have access to at most 3GB of memory, if the application is linked with a special flag. - Subroto Datta Altera Corp. On Nov 29, 8:20 am, mk <kal*@dspia.*comdelete> wrote: > On Wed, 29 Nov 2006 14:19:56 +0000, Joseph > > <joseph....@obviously-not-a-valid-domain.com> wrote: > >Hi all, > > >I wonder if anyone here are in the same situation as me. > >I am think of buying a new PC, but wondering if I should > >wait for Windows Vista become available first. > >Have anyone try running FPGA tools (Xilinx Webpack, > >Modelsim XE, Quartus, Cygwin) on Windows Vista beta? > >Does it work okay? > >Or should I get a "Vista capable" PC now and upgrade later? > >(sound too much hassle to me, but it might be better?)You can turn off much of Vista's eye candy which takes quite a bit of > cpu cycles. In addition the main saving grace of Vista is that it has > a 64 bit version where ISE and other tools (I've tried ISE 8.2 under > 64 bit Vista) get a full 4G adress space so if your design doesn't fit > to 2G but fits 4G you're still in luck.Article: 112810
Hello everybody. It seems, I wish to build my career as engineer who use FPGA to construct ad hoc designs, in the field of fast computation. I've heard about cryptoanalysts' FPGA experiments.. and I'm interesting, where else I'll able to apply my professional profile, now or in the near future?Article: 112811
tenteric schrieb: > Hello everybody. > > It seems, I wish to build my career as engineer who use FPGA to > construct ad hoc designs, in the field of fast computation. > I've heard about cryptoanalysts' FPGA experiments.. and I'm > interesting, where else I'll able to apply my professional profile, now > or in the near future? You can apply FPGAs to just about any field that you care to mention, there are plenty of companies who are activly seeking engineers with skills in designing with FPGAs.Personaly ive worked on and developed designs for telecoms systems,cryptographic systems,soft processor cores.AS you mention cryptograhic applications I wrote a pipelined AES core a couple of years ago and got my present job of the basis of the knowledge gained during the development of that core.Article: 112812
Symon wrote: > Hi Sean, > That must be why Xilinx don't support the spread spectrum feature the DCMs > have/used to have? Sounds like your FAE is bluffing! > http://toolbox.xilinx.com/docsan/xilinx6/de/libs/dcm.pdf Well, he was talking about spread spectrum clocks as INPUT clocks to the FPGA, not as outputs of a DCM. Supposedly (I've never had the pleasure of dealing with spread spectrum clocks) DCMs can't handle that and won't lock, at least in some cases. But now with PCI-E and SATA and everything going serial and spread-spectrummy this is something people want. But he was still bluffing in a lot of ways when he presented the new architecture. Like availability and prices. :) cu, Sean -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 112813
jez-sm...@hotmail.co.uk wrote: > tenteric schrieb: > > > Hello everybody. > > > > It seems, I wish to build my career as engineer who use FPGA to > > construct ad hoc designs, in the field of fast computation. > > I've heard about cryptoanalysts' FPGA experiments.. and I'm > > interesting, where else I'll able to apply my professional profile, now > > or in the near future? > > You can apply FPGAs to just about any field that you care to mention, > there are plenty of companies who are activly seeking engineers with > skills in designing with FPGAs.Personaly ive worked on and developed > designs for telecoms systems,cryptographic systems,soft processor > cores.AS you mention cryptograhic applications I wrote a pipelined AES > core a couple of years ago and got my present job of the basis of the > knowledge gained during the development of that core. I need to be more precise - my passion is just very fast computation - I'm very interesting in implementing any math algorithm thus it will work as fast as it can.Article: 112814
Subroto Datta wrote: > You do not have to wait for Vista to get 64 bits. WinXP64 is available > today and works just fine. ... and don't forget about Linux. ISE8.2 (I can't comment on Altera's tools) now (I thin SP2 did the trick) runs fine on just about any 64bit-Linux I've tried (OpenSuSE, Ubuntu, Fedora...). Available today AND free ;) cu, Sean -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 112815
I would just go with XP. I will admit that I'm skeptical of anything new from Microsoft and I wait 3-6 months before making the switch, if not longer. > MS will possibly eventually stop supporting XP. > (e.g. no more service pack and security updates) > Some existing software will eventually move over to Vista. > I don't think this should be a concern. I read that Microsoft just stopped (within the past year) supporting Windows 98. So I think you have a few years before they stop supporting XP. -cmwArticle: 112816
davide wrote: > "Daveb" <dave.bryan@gmail.com> wrote in message > news:1164754755.908635.123850@16g2000cwy.googlegroups.com... > > Gabor wrote: > >> Daveb wrote: > >> > Hi, > >> > > >> > I'm using a microcontroller to configure a Spartan-3 device. The device > >> > seems to configure ok (the design works as expected) but INIT_B goes > >> > low & stays low after the last frame has been clocked in. According to > >> > the datasheet this indicates a CRC error. > >> > > >> > Does anyone have any idea why I'd get a CRC error but my design still > >> > works ? > >> > > >> > Thanks > >> > Dave > >> > >> INIT_B is a "dual-purpose" pin. After config it is an I/O. Make sure > >> you > >> haven't inadvertently assigned this pin as an output (this can happen > >> if > >> your .ucf file doesn't specify LOC for all top level module outputs). > >> When > >> in doubt, use FPGA editor to check the pin. > >> > >> HTH, > >> Gabor > > > > Gabor > > > > I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B > > isn't inadvertently being used by the design. I'm really quite baffled > > as to what is going on because the datasheet says that if the CRC is > > incorrect then the startup sequence is aborted. In this situation I'm > > assuming the design isn't used to configure the device. Maybe this is > > an incorrect assumption ? > > > > Dave > > > > Dave, > > During configuration, there are several CRC checks. The first makes sure > that the bitstream device ID matches that of the device being programmed. > The other CRC checks are performed after the final frame of each FRDI read > sequence. After the final CRC is completed, the startup sequence begins and > DONE goes high (assuming default startup). The IO's are released as well as > internal FF's and RAM. > > As you are not using INIT as an IO in your design, the default is to attach > a weak pulldown on the (all unused) IO. Thus, it is now low. Without > knowing what type of file you are using with your u-proc configuration, it > is hard to say what is contained in the last frame of the configuration > file, but everything you are describing appears to be normal. > > You can always specify to leave unused IO as floating or pulled up if you > wanted to test this for a sanity check. > > -David Thanks for the suggestions. I decided to set the INIT_B to an output forced high in my design and hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual purpose I/O pins are weak pull down. Turns out that there's weak and there's weak! the pull down can be less than 2K so my (fairly weak) pull up lost. So no CRC error after all but I should have read the datasheet in more detail before panicking. DaveBArticle: 112817
On 29 Nov 2006 08:56:41 -0800, "Subroto Datta" <sdatta@altera.com> wrote: >You do not have to wait for Vista to get 64 bits. WinXP64 is available >today and works just fine. One advantage of WinXP64 is that 32 bit >Windows Apps have access to 4GB of address space. On the WinXP32 32 bit >Windows applications have access to at most 3GB of memory, if the >application is linked with a special flag. The device driver support for and application compatibility of Vista 64 is much better than XP 64 (I have both installed). As a 64 bit windows, I don't think XP 64 is an option anymore.Article: 112818
Daveb wrote: > I decided to set the INIT_B to an output forced high in my design and > hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual > purpose I/O pins are weak pull down. Turns out that there's weak and > there's weak! the pull down can be less than 2K so my (fairly weak) > pull up lost. So no CRC error after all but I should have read the > datasheet in more detail before panicking. You are not the first engineer to have been caught napping by the Spartan 3 "weak" pullups (downs). Where I work, there is a strong tendancy to not act, or even react, but to *over*react to issues. Someone discovered this on a project a couple of years ago and decided to use 0 ohm jumpers to set the config pins. Then when I was drawing up my schematics, like you, I initially used resistors that were inappropriate. When another engineer corrected me and I investigated, I found what the issue was and decided to only add jumpers to ground since the pullups were plenty strong enough to pull up and could not be turned off. That led to a tirade about how 0 ohm jumpers were required in *all* cases on the Spartan 3s, pullup or pulldown. Of course this is not correct, but that day it was no fun being right. The long and the short of it is that Xilinx does not always get this stuff right and they don't consider this broken enough to fix it. You would think they would note this clearly in the documentation that this part is very different from their other devices.Article: 112819
Nico Coesel wrote: >> >> 1) There is a need to implement bus structures, say a 16 bit >> bidirectional data bus which should connect several modules on the >> highest level of the project. >> > > This is one of the down sides of the Spartan 3. The way to solve this > is to have a multiplexer at each device's input. This seems a bit > cumbersome, but it actually works quite well and fast. > Is it not on the contrary necessary to feed *different outputs* from the different devices into a multiplexer, which then drives a *single* input line for all devices ? Would not otherwise the notorious error message, saying that a single "wire" is driven by several different "out"s appear? At least it was for this reason I conceived this "bus_star" topology (essentially a multiplexer of course) the way I outlined it in my original posting. Greetings Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 112820
Hi, Does anyone have experience with modular design flow or PlanAhead? Could you answer my questions related to it: 1) I know that all IO ports in modular design flow have to be placed on the top level. But does it mean that all FFs/tri-state buffers I want to have in IOBs have to be inferred on the top level as well or these logic can stay locally in modules? 2) Do I understand it correctly that PlanAhead is just graphical interface to modular design and partial reconfiguration functionality (plus some other features)? 3) Do you know if evaluation version of PlanAhead is fully functional? 4) Is this modular design or PlanAhead really useful and not one of toy tools? I would appreciate sharing your experience, Regards WojtekArticle: 112821
Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
>> They use Synplify (and Precision) for synthesis. Not as good as Quartus
>> or XST, but it does the job. Might need some tweaking however when
>> inferring memories.
>>
>
> Can you provide more details? My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin
>
Thanks for the answers, chaps.
I can now be a little more confident of using the devices. I have the
time to do a migration (well, a clean new design as it happens) if I
start now, and most of that extra time should (hopefully) be merely tool
related.
I'll talk to my friendly vendor about pricing etc., tomorrow.
That doesn't mean I won't use the other brands; in this particular case
it may make more sense to use brand L.
Cheers
PeteS
Article: 112822Jürgen Böhm wrote: > Nico Coesel wrote: >>> 1) There is a need to implement bus structures, say a 16 bit >>> bidirectional data bus which should connect several modules on the >>> highest level of the project. >>> >> This is one of the down sides of the Spartan 3. The way to solve this >> is to have a multiplexer at each device's input. This seems a bit >> cumbersome, but it actually works quite well and fast. >> > > Is it not on the contrary necessary to feed *different outputs* from > the different devices into a multiplexer, which then drives a *single* > input line for all devices ? Would not otherwise the notorious error > message, saying that a single "wire" is driven by several different > "out"s appear? > > At least it was for this reason I conceived this "bus_star" topology > (essentially a multiplexer of course) the way I outlined it in my > original posting. > > Greetings > > Jürgen > If you define each module with inout (as if you had tristates internally), then the tools will infer the appropriate multiplexers for you (at least they will in XST). Cheers PeteSArticle: 112823
"rickman" <gnuarm@gmail.com> wrote in message news:1164822883.158338.136150@j72g2000cwa.googlegroups.com... > Daveb wrote: >> I decided to set the INIT_B to an output forced high in my design and >> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual >> purpose I/O pins are weak pull down. Turns out that there's weak and >> there's weak! the pull down can be less than 2K so my (fairly weak) >> pull up lost. So no CRC error after all but I should have read the >> datasheet in more detail before panicking. > > You are not the first engineer to have been caught napping by the > Spartan 3 "weak" pullups (downs). Where I work, there is a strong > tendancy to not act, or even react, but to *over*react to issues. > Someone discovered this on a project a couple of years ago and decided > to use 0 ohm jumpers to set the config pins. Then when I was drawing > up my schematics, like you, I initially used resistors that were > inappropriate. When another engineer corrected me and I investigated, > I found what the issue was and decided to only add jumpers to ground > since the pullups were plenty strong enough to pull up and could not be > turned off. That led to a tirade about how 0 ohm jumpers were required > in *all* cases on the Spartan 3s, pullup or pulldown. Of course this > is not correct, but that day it was no fun being right. > > The long and the short of it is that Xilinx does not always get this > stuff right and they don't consider this broken enough to fix it. You > would think they would note this clearly in the documentation that this > part is very different from their other devices. Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August 19 2005) diction similar to the first instance is found: The Spartan-3 I/O pull-up and pull-down resistors are stronger than the "weak" pull-up/pull-down resistors used in previous Xilinx FPGA families. See Table 6, Module 3 for equivalent resistor strengths. Your design was probably before the data sheet revision but the documentation DOES reflect this change. If you've looked at the S3E data sheet, your comment that "You > would think they would note this clearly in the documentation" is made > MORE clear by adding the great big warning signs and outlined text to > emphasize the issues that are issues. They didn't do a good job with the resistor strength in S3, absolutely. They _have_ taken care of the documentation side of things.Article: 112824
John_H wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1164822883.158338.136150@j72g2000cwa.googlegroups.com... > > Daveb wrote: > >> I decided to set the INIT_B to an output forced high in my design and > >> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual > >> purpose I/O pins are weak pull down. Turns out that there's weak and > >> there's weak! the pull down can be less than 2K so my (fairly weak) > >> pull up lost. So no CRC error after all but I should have read the > >> datasheet in more detail before panicking. > > > > You are not the first engineer to have been caught napping by the > > Spartan 3 "weak" pullups (downs). Where I work, there is a strong > > tendancy to not act, or even react, but to *over*react to issues. > > Someone discovered this on a project a couple of years ago and decided > > to use 0 ohm jumpers to set the config pins. Then when I was drawing > > up my schematics, like you, I initially used resistors that were > > inappropriate. When another engineer corrected me and I investigated, > > I found what the issue was and decided to only add jumpers to ground > > since the pullups were plenty strong enough to pull up and could not be > > turned off. That led to a tirade about how 0 ohm jumpers were required > > in *all* cases on the Spartan 3s, pullup or pulldown. Of course this > > is not correct, but that day it was no fun being right. > > > > The long and the short of it is that Xilinx does not always get this > > stuff right and they don't consider this broken enough to fix it. You > > would think they would note this clearly in the documentation that this > > part is very different from their other devices. > > Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August > 19 2005) diction similar to the first instance is found: > > The Spartan-3 I/O pull-up and pull-down resistors are stronger > than the "weak" pull-up/pull-down resistors used in previous > Xilinx FPGA families. See Table 6, Module 3 for > equivalent resistor strengths. > > Your design was probably before the data sheet revision but the > documentation DOES reflect this change. If you've looked at the S3E data > sheet, your comment that "You > > would think they would note this clearly in the documentation" is made > > MORE clear by adding the great big warning signs and outlined text to > > emphasize the issues that are issues. > > They didn't do a good job with the resistor strength in S3, absolutely. > They _have_ taken care of the documentation side of things. I don't agree with this. I had this discussion with Xilinx (mostly in this group) when I was investigating the behavior of all the pullups on all the pins of the Spartan 3. I found that the required information was scattered over multiple sections of the document and stated in different ways that even appear to contradict each other in some ways. Xilinx did make some adjustments to the data sheet, but I think the issue of using the pullup resistors in Spartan 3 devices is complicated enough that the information should be pulled together in one section where it can be found easily and completely. No one has time to read every sentance in a 200 page document. Instead we rely on the tools available for searching the document and typically don't expect to have to find info in multiple places to tell us the *whole* story. Putting one sentance at the end of one section is not what I would call "taking care" of documentation. Obviously people are still missing this sentance and not realizing that the Spartan 3 pullups are different from the pullups on nearly every FPGA made by any vendor.
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