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
Antti Lukats wrote: > Hi > > I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric > speeds? Over a broad range of applications, a Spartan-3E FPGA is _in general_ the same performance or mildly faster than a Spartan-3 FPGA using the slowest speed grade for both. These tests were done using worst-case speed file numbers, which are more pessimistic than actual silicon. Hopefully, this shouldn't be too surprising as Spartan-3 and Spartan-3E FPGA are built on the same 90 nm process technology using the same manufacturing facility. > I have done some actual measurements and as far of the results the > LUT propagation delay seems to be about 10% bigger than in S3? I would expect some variation comparing actual silicon on two different devices. The data sheet tells you the slowest silicon we're allowed to ship, but the actual device likely is faster, especially at room temperature and nominal voltage. That said, if you compare the Tilo specification for the Spartan-3 and Spartan-3E families in their respective data sheets, you will see about 150 ps of delay difference. Spartan-3: Tilo on a -4 device = 0.61 ns http://www.xilinx.com/bvdocs/publications/ds099.pdf [Page 79] Spartan-3E: Tilo on a -4 device = 0.76 ns http://www.xilinx.com/bvdocs/publications/ds312.pdf [Page 133] I wouldn't focus on a specific parameter per se, as your path delay will include other timing parameters as well. For example, Spartan-3E generally has faster flip-flop clock-to-output delays and faster interconnect. In the wash, Spartan-3E _generally_ is at or about the same performance. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 94801
The Spartan-3E Sample Kit Board is general available at no charge to qualified customers. The boards are avaialable directly from Xilinx sales partners. Information about the board and the accessory pack is available on the Xilinx web site. http://www.xilinx.com/products/boards/s3esamplepack/index.htm Please bear in mind that this is a free introductory board. I affectionately call it the "Blinky Board" because it has somewhat limited capabilities. It makes one heck of an LED blinker. It also demonstrates that a Spartan-3E FPGA can configure from standard commodity parallel NOR Flash. Furthermore, it demonstrates the Spartan-3E FPGA's MutliBoot feature, which allows you to dynamically switch between two different configuration images stored in Flash. However, if you plan on developing anything more complex, I would highly recommend purchasing one of the more advanced development boards. http://www.xilinx.com/s3eboards Direct Links to the Xilinx Sales Partners: Avnet: http://www.em.avnet.com/spc/home/0,1727,RID%253D0%2526CID%253D27914%2526CCD%253DUSA%2526SID%253D4745%2526DID%253DDF2%2526LID%253D0%2526BID%253DDF2%2526CTP%253DSPC,00.html NuHorizons: http://www.nuhorizons.com/Forms/sp3e-100-request.html Silica in Europe isn't currently showing the boards. I'll find out why. Frequent comp.arch.fpga contributor Antti Lukats created a free, friendly, easy-to-use programmer for the Spartan-3E Sample Kit board. You can directly program the FPGA or the Intel StrataFlash PROM via a Parallel Cable III or Digilent JTAG3 cable (I haven't tried it with Parallel Cable IV yet). Antti's software also graphically displays the state of the LEDs on the computer display, monitored over the FPGA's JTAG port. Nice work! http://xilant.com/component/option,com_remository/Itemid,53/func,fileinfo/id,8/ --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 94802
Xilinx CPLDs, Spartan-3 FPGAs, Platform Flash PROMs, development boards, etc. are available directly from the Xilinx online store. The online store may not always have the absolute lowest price for a given device but it's generally similar. http://www.xilinx.com/store These same items, and much more, are available from the various Xilinx Sales Partners. http://www.xilinx.com/company/sales/ww_disti.htm --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 94803
In article <dqjuuq$cuu$1@newsg1.svr.pol.co.uk>, John Adair <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >Xavier > >Raggedstone1 comes free with a programming cable PROG2. > >The mode pins are connected together and go through a 0R resistor to 0V so >not easy to change. > >Boards that are now available for the DIL headers: > >ADC_AD7927 200KHZ - 16 channel ADC based on Analog Devices AD7927 >RS232 >RS485 >PS2 - Mouse and keyboard >LED Array >LED 4 Digit >LED Dot Matrix >USB1.1 - Interface only (core needs to be implemented in FPGA) > >LVDS oscillator module (0.6 inch DIL) - Being tested shortly available >assuming ok. Capable of going to 700MHz although I don't the Spartan-3 will >like it that high. > >There isn't a RAM board yet but there is a slowish 4MBit RAM chip that will >fit the DIL on the LHS. A RAM module is being looked at and coming soon. > >We are waiting for some faceplate/cable assemblies for some of these so >stock is a bit patchy at present. This status should improve within the next >few weeks and after that I expect them to be fully available. > >Coming in the next batch are Ethernet Phy, IDE, Video Codec, 5V tolerant I/O >to name a few. I don't have the full list with me so those are just the ones >I can remember. These should be available in 4-8 week time frame assuming no >design issues. > >PCI Core - The Xilinx core works with our board and Jungo supply drivers for >that core. Not free I'm afraid. I believe at least one of our customers has >got the opencores PCI working as well. I don't know the driver status on >this core. We have not tried it so I can't comment further. We are also at >the testing stage on our own native PCI/OPB Bridge Interface and a driver >for XP is being written for it. Linux to follow. A limited version/license >will be offered free with Raggedstone1 when we are happy with it's >performance. Higher feature level versions will be available too at an extra >cost but low usage licenses won't be too expensive. I'm interested in using your board with a PCI core as well. Is the Jungo driver needed only for programming? (ie. if I program with the cable, I don't need the Jungo driver, right?) I'm primarily interested in communication between the PC's CPU and the FPGA via the PCI bus - the opencores PCI bridge should work for what I want, correct? (Oh, and I'm on Linux, so if you could let me know what issues that might raise I'd appreciate it as well). Thanks. PhilArticle: 94804
In article <1137541975.630883.170430@g14g2000cwa.googlegroups.com>, xavier.tastet@gmail.com <xavier.tastet@gmail.com> wrote: >john, >I've just check the jungo website ans they said : >"In Linux and Windows CE versions - Driver is operational for 60 >minutes after re-starting it." about the free windriver. the full >driver is about 800 $... snif snif :'( >I'll carrefully check the website during the next week :) >thanks, Xavier. > Ouch! What exactly is this jungo driver needed for and are there open source alternatives? (if not, it sounds like a good time to start one ;-) PhilArticle: 94805
In article <dqflq9$sfp$01$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: >"Phil Tomson" <ptkwt@aracnet.com> schrieb im Newsbeitrag >news:dqefe401nol@enews4.newsguy.com... >> In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, >> Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>>Kevin Morris wrote: >>>> >>>> Any takers? >>> >>>Real/Complete programming information would be a very good start to a new >>>hobby phase. But I think that all the FPGA vendors are too scared to give >>>out this information. Come on, xilinx, altera, etc, etc. What could >>>there >>>possibly be so secret in the format for how to program your parts? :) >>> >> >> Indeed. I don't get it either. How much can be reverse engineered from a >> bitstream format? This closedness is a real hindrance to the development >> of >> an open source eco-system around FPGAs. >> >> Any university open FPGA architectures being developed out there? While >> it's >> probably too late in the game for a new FPGA company to enter the race, >> it's >> possible that one of the smaller, hungier players might be able to >> differentiate themselves by opening up their bitstream formats. >> >> Phil > >Phil, Atmel AT40K/AT94K bitstream format is almost open >eg it is available under NDA from Atmel, and open source reverse engineered >documentation is also available - no NDA :) NDA's don't count as open. Is the Atmel part 'capable'? > >As of BIG FPGA companies making their bitstream format public - do not hope! > >because the bitstream holds not only the 'known' bits like routing and LUT, >but >also factory stuff > >bits that compensate against technology changes, those are 'figured out' by >actual measurement by the FPGA companies AFTER wafers are manufactured >that is the FPGA companies makes their chips to have a little 'fine tuning' >to >be done, this fixing is done by bitgen and is totally invisible for the >normal user. > >second there are factory test bits and settings, again something that the >end >user should not mess up > >there are some hidden FPGA primitives that are partially visible for the >end user but not useable by end user, like PMV primitive in V4 and S3 > >there are probably hidden features and primitives that are totally invisble >for the end user as well. > >so there are reasons for keeping the bitstream non public. > >for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files, >those are simple ordered lists of bit names, bitgen uses that > info to convert an NCD to bitstream > >NCD file is almost 1:1 the same as the XDL file would be so actually >pretty much of the bit info is visible for those who want to see > Where can one find more info on NCD and XDL file formats (and what the acronymns stand for)? Are you implying that if one has this NCD file that one can figure out the bitstream format? PhilArticle: 94806
In article <QFTyf.3436$bF.2359@dukeread07>, Ray Andraka <ray@andraka.com> wrote: >Tobias Weingartner wrote: > >> >> I happen to disagree. We are all entitled to our opinions of course. >> If the vendors would have a well defined format to "compile" to, and >> a good library/port for a program to be able to take this format and >> then generate a bitstream, that would be a start. Note, I'd want to >> have the source available to be so that I could port this last bit of >> "technology" to my favourite OS (by choice or necessity). >> >> I can't believe that these things are anything but simple portable ANSI >> C (or some derivative)... >> > >The problem is the bitstream is very tightly tied to the architecture of >the FPGA cell. Having a well defined format tightly constrains the FPGA >architecture to the one the bitstream format is published for. What >that means is that either the format has to change for every fpga >variant out there, now and in the future, or the FPGA has to be frozen >in order to comply with the bitstream format. > >There is far more coupling between the bitstream in an FPGA and its >hardware than there is between an instruction set and a processor >architecture because of the fine granularity of the configuration of the >FPGA. In other words, an instruction set in a microprocessor controls >relatively few connections between some very complex blocks. The FPGA >bit stream controls many many connections between lots of small simple >blocks, so if the bitstream format is predefined by a standard there is >very little lattitude for evolving the FPGA's structure. Sure it might change with each new FPGA (or it might even change more often than that). Still the information is somewhere. Right now I'm sure there are internal docs at Xilinx/Altera which document the formats for their tool developers. What would be so bad if they also put those on the web (with a caveat of course that says, "you're on your own: we don't support you playing with the bitstream directly, but if you want to have at it") > >I'm not sure I see what the big push for having bitstream access is. >I've yet to see a compelling need for it that is not addressed by the >existing tools (there is always XDL if you really want to bit bang). I guess I'll have to look into this XDL to see what it is. Is it a higher level description of the bitsteam format? >The only reason that seems to surface is to allow outside parties to >develop their own place and route tools. Frankly, I don't think the >complexity of modern FPGAs is such that this type of undertaking can >improve on or even compete with the free place and route tools already >offered by the FPGA vendors in the timeframe between device introduction >and obsolescence. You're probably right, but people want to be able to tinker. There's the push for open source tools as well as academic research into P&R algorithms, etc. People have lots of reasons for wanting to try these sorts of things. > Anyway, for those hadry enough to try, as I said, the >XDL tools do give you enough access to every step of the design flow to >allow you to play with any step you feel compelled to play with. I'll have to google for XDL. PhilArticle: 94807
In article <43ccb0e2$0$21031$9b4e6d93@newsread2.arcor-online.net>, Kolja Sulimma <news@sulimma.de> wrote: >Tobias Weingartner schrieb: > >>>so there are reasons for keeping the bitstream non public. > >> I happen to disagree. We are all entitled to our opinions of course. >> If the vendors would have a well defined format to "compile" to, and >> a good library/port for a program to be able to take this format and >> then generate a bitstream, that would be a start. Note, I'd want to >> have the source available to be so that I could port this last bit of >> "technology" to my favourite OS (by choice or necessity). >> >> I can't believe that these things are anything but simple portable ANSI >> C (or some derivative)... > >JBits is a solution to all this. Maybe not a particulary good one, but >you can read, modify, write bitstreams in a platform independant way. >There is no source code available, but java bytecode that you can >essentially call by any language you want on any platform you want. It looks like JBits is a University-developed tool. why wouldn't the source code be available? > >There are even people at xilinx working on a virtual file system to >mount and modify the configuration of a virtex-4 by the embedded PowerPC. > interesting. PhilArticle: 94808
In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab@4ax.com>, Brian Drummond <brian@shapes.demon.co.uk> wrote: >On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >>In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, >>Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>>Kevin Morris wrote: >>>> >>>> Any takers? >>> >>>Real/Complete programming information would be a very good start to a new >>>hobby phase. But I think that all the FPGA vendors are too scared to give >>>out this information. Come on, xilinx, altera, etc, etc. What could there >>>possibly be so secret in the format for how to program your parts? :) >>> >> >>Indeed. I don't get it either. How much can be reverse engineered from a >>bitstream format? This closedness is a real hindrance to the development of >>an open source eco-system around FPGAs. > >Last really open system was the XC6200. But it failed commercially, at >least in part, because it was a finer grained architecture. > >FPGA capacities should now be big enough to support a "virtual FPGA" >layer on top of a real FPGA, using only the "public" parts of the >bitstream (e.g BRAM and SRL16 contents, possibly a subset of the >routing) to give a completely open format. Possibly a virtual XC6200, >but probably a coarser grained architecture (mini-Spartan perhaps). >I wonder what size Spartan-3 you would need for a virtual XC6264? > >This would lose a lot of capacity and performance (you may need several >LUTs dedicated to routing for every one you can use for logic) but the >result is likely to be at least competitive with the sort of technology >a startup or small player has on offer. > >I think it would be big enough to exercise open source development tools >until something better came along... > Interesting idea. Are you saying that a XC6200 model would be developed in HDL and then run through synt, p&r, etc. and that could then be used for downloading the bitstream to? ...but like you say, you would be taking a big performance/area hit. If you were going to do that, then why not just create some sort of higher level Virtual FGPA device (kind of like what a Virtual Machine is to the software world) that would have lots of nice high-level features (high-level macros available, etc.) and also be tunable for the underlying architecture (depending on whether the target was Xilinx, Altera, or Lattice. Just as VMs allow for easier porting, greater genericity, etc. maybe something like a VFPGA could have similar advantages? Also, just like the Java VM doesn't care what underlying architecture it's running on, this sort of thing could potentially make it easier to port designs between FPGA families... I wonder if it could be done such that there is a minimal impact on performance and area? PhilArticle: 94809
morpheus wrote: > It doesn't work even if you create a new project in 8.1 with the design > and constraint files? That'll be the next step.Article: 94810
In article <dqg7ai$a67$01$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: >Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag >news:9p7ns1pch437c81ln9dunkk34bo5p2k3ab@4ax.com... >> On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: >> >>>In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>, >>>Tobias Weingartner <weingart@cs.ualberta.ca> wrote: >>>>Kevin Morris wrote: >>>>> >>>>> Any takers? >>>> >>>>Real/Complete programming information would be a very good start to a new >>>>hobby phase. But I think that all the FPGA vendors are too scared to >>>>give >>>>out this information. Come on, xilinx, altera, etc, etc. What could >>>>there >>>>possibly be so secret in the format for how to program your parts? :) >>>> >>> >>>Indeed. I don't get it either. How much can be reverse engineered from a >>>bitstream format? This closedness is a real hindrance to the development >>>of >>>an open source eco-system around FPGAs. >> >> Last really open system was the XC6200. But it failed commercially, at >> least in part, because it was a finer grained architecture. >> >> FPGA capacities should now be big enough to support a "virtual FPGA" >> layer on top of a real FPGA, using only the "public" parts of the >> bitstream (e.g BRAM and SRL16 contents, possibly a subset of the >> routing) to give a completely open format. Possibly a virtual XC6200, >> but probably a coarser grained architecture (mini-Spartan perhaps). >> I wonder what size Spartan-3 you would need for a virtual XC6264? >> >> This would lose a lot of capacity and performance (you may need several >> LUTs dedicated to routing for every one you can use for logic) but the >> result is likely to be at least competitive with the sort of technology >> a startup or small player has on offer. >> >> I think it would be big enough to exercise open source development tools >> until something better came along... >> >> - Brian >> >> > >it has already been done there was MPGA project that implemented a virtual >"Meta" FPGA >the project is dead vanished/vanishing but its a nice a example of the use >of SRL16 for >virtual FPGA loading > >its however far more interessant to implement dynamic bitstream generator >that patches >some parts of the ready made bitstream to modify the algorithm this needs to >no >resources to be vasted for the download of the new config. But this would require that we know the bitstream format, right? Can you elaborate a bit (no pun intended) on this dynamic bistream generator idea? PhilArticle: 94811
Thank you guys for your suggestions. I'm in the strange position of being a design manager but have not done any logic work myself for about 6 years and never worked with Xilinx tools at all. Some of our hw engineers are consultants with the tendency to "hold out" on information that could possibly lessen my $100/hr dependency on them. I suppose I understand their point of view but am determined to brute force my way through this because I absolutely need to have this capability in house. Even if I have to learn it myself! Thanks, DLRArticle: 94812
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > Xilinx CPLDs, Spartan-3 FPGAs, Platform Flash PROMs, development > boards, etc. are available directly from the Xilinx online store. The > online store may not always have the absolute lowest price for a given > device but it's generally similar. > http://www.xilinx.com/store ..except, if you want the CR2 CPLDs, in either XC2C32A or XC2C64A sizes, then they simply do not exist in the online store. 128 & 256 do show. Is this a not-for-new-designs message ? -jgArticle: 94813
Hey guys. I believe Grant wants to make an EXACT clone of the Mac. I agree
about the "Firmware" issue. As software is has an unlimited, or at least
very long life span. Of course being sewed for an exact clone is possible,
I don't think Apple would care unless you somehow manage to become some
major market player by doing so, which is even more unlikely then being sued
in the first place.
I'm currently cloning an old SCSI controller from Apple, ROM included, if
they do try and send a "nasty-gram" I will promptly remove the ROM from the
card and anyone who purchases the card could just download the ROM from a
number of other sites and burn their own. The fact that Apple isn't going
after these "other" sites is probably a good indication that they just don't
give a crap one way or another about it. Need I mention the expense and bad
publicity if they were to do so, and for what? They couldn't stop me
selling the hardware, just their Firmware.
I say screw em' Grant, and do it anyway. I can only hope they try and sew
me. I'd love to go on CNN and be interviewed. Free advertising!
Henry S. Courbis
www.GSE-Reactive.com
"Eric Smith" <eric@brouhaha.com> wrote in message
news:qhacdzsk6g.fsf@ruckus.brouhaha.com...
> Austin Lesea wrote:
>> Xerox PARC tried to buy a DEC 10, but DEC wouldn't sell them one.
>
> No. Xerox wouldn't let them, since they'd just purchased Scientific
> Data Systems (SDS), which they renamed to XDS. The corporate types
> thought (perhaps correctly) that it would negatively impact XDS sales
> if customers got wind that XDS machines weren't good enough for Xerox'
> own internal use.
>
> Of course, the fact that PARC built their own PDP-10 rather than using
> XDS machines would send the same message to customers.
>
>> So, Xerox got the schematics, put everyone to work, and built one.
>
> Xerox may or may not have had the DEC schematics, but they designed their
> own PDP-10 clone ("MAXC") from the ground up. There was no real
> similarity
> to the DEC hardware; MAXC was simply designed to execute the same
> instruction set.
>
>> Just one.
>
> Two, actually. And the second was a redesign, not a copy of the first.
>
>> Used it for research. Even made their own operating system for
>> it.
>
> They wrote their own operating systems for various small computers they
> developed, but on MAXC they used TENEX, which came from BBN. A few
> years later DEC used TENEX as the basis for TOPS-20, which ran on the
> PDP-10 processor of the DECSYSTEM-20.
>
>> Nothing DEC could do: Xerox PARC did not derive any profit from it,
>> did not use it to do any product (and they had the losses to prove
>> it!).
>
> That wasn't the issue. There weren't any patents on the PDP-10
> instruction
> set. If there were, DEC might have had grounds to sue, even though PARC
> didn't ship it as a product.
>
> Profit is not the same as economic benefit. Even if Xerox posted a loss
> every year that they were using MAXC, it's quite possible that they would
> have had a larger loss without it. MAXC contributed to the development
> of many successful Xerox products.
>
> If company A sells some patented product P, and company B decides that
> buying a P would save them lots of money, but builds their own P to
> save even more, you can bet that company A will sue if they get wind
> of it.
>
> Unless, of course, company B develops P2, which does not use the patent
> claims held by A. In which case they still might get sued, but will
> have a better defense.
>
> I've personally been involved in a case where a company build a clone
> of something, carefully avoiding the patents, but was threatened with
> litigation and negotiated a license rather than spend a bunch of money
> to try to defend it.
>
>> I wonder if today Apple would even care if you went into business
>> offering (old) Mac Clones?
>
> They're not going to care unless you include a copy of the Mac ROM,
> which is the main component of the "secret sauce" of the Macintosh.
>
>> As long as you are not using their IP, their patents (and not
>> impacting their present business), they really have no reason to care.
>
> But of what use is a Mac clone without a ROM? It's arguably of even
> less use than a newborn baby.
Article: 94814Hello, The goal is not to create delay but to handle the fact the 32 bits / 33 Mhz bus is not always available. For the SDRAM controller I already have my solution in mind. I was only wondering if this function ( huge FIFO for FPGA using an external SDRAM ) ,which i'm shure a lot of people would need, would already exist and be available. Stéphane. "Peter Alfke" <peter@xilinx.com> a écrit dans le message de news: 1137514850.769502.197970@f14g2000cwb.googlegroups.com... > Give more details: > depth, width, clock rate for write and for read. Asynchronous clocks? > Peter Alfke, Xilinx >Article: 94815
On Tue, 17 Jan 2006 23:00:54 +0100, "Antti Lukats" <antti@openchip.org> wrote: >"Antonio Pasini" <removethis_pasini.a@tin.it> schrieb im Newsbeitrag >news:43cd66bc$0$1087$4fafbaef@reader1.news.tin.it... <snip> > >Hi > >after verifying the hot keys in 'flaot mode' I was a bit 'breathing' as it >is a workaround, until I tried the > >| > >in float mode - and that doesnt work in float mode either - so we can say it >is confirmed the ISE 8.1 built in editor is useless for non US keyboard >users :( > >well I still use my notepad.exe trick to copy the | into clipboard when I >need it, but I guess others are defenetly not willing to use this kind of >workarounds > >Antti > I am using WebPack 8.1 with an Spanish keyboard, and have not found yet any such problem (other problems, yes, but I have not rechecked against SP1, so I will not disclose them). ZaraArticle: 94816
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im Newsbeitrag news:dqjseg$flv1@cliff.xsj.xilinx.com... > Gentlemen, > > The issue that Antti is complaining about is indeed an issue but not one > related to the ability of iMPACT to program CPLDs (which it can do just > fine, thank you) but due to a bug (yes, a bug) that was revealed when the > JEDEC file used was named "bypass.jed". It so happens that that name (for > no good reason - that's why it's a bug) indicated that iMPACT should treat > that device as if no JEDEC file was assigned and therefore only allowed > the erase, readback and other functions associated with only BSDL files. > We will fix that problem - but for now, avoid using JEDEC files named > "bypass" > > Thanks. Dear Neil, as noted in email to you, I guessed myself that the name 'bypass_lpt.jed' could cause the problem, so I renamed it and tested yesterday (without restart of impact) however the problem persisted. Today I started impact fresh new, in the folder there are no files at all with names like 'bypass...' I assign 'top.jed' to the device and the problem still persists. I am happy to test more but it really looks like on my machine the main menu and right click menu for PLD programming do not work (they are disabled), I can though start PLD programming by double clicking in impact processes window. So its only a minor annouyance. -- Antti Lukats http://www.xilant.comArticle: 94817
"Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> schrieb im Newsbeitrag news:1137548042.068052.289380@g44g2000cwa.googlegroups.com... > > Antti Lukats wrote: >> Hi >> >> I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric >> speeds? > > Over a broad range of applications, a Spartan-3E FPGA is _in general_ > the same performance or mildly faster than a Spartan-3 FPGA using the > slowest speed grade for both. These tests were done using worst-case > speed file numbers, which are more pessimistic than actual silicon. > > Hopefully, this shouldn't be too surprising as Spartan-3 and Spartan-3E > FPGA are built on the same 90 nm process technology using the same > manufacturing facility. > >> I have done some actual measurements and as far of the results the >> LUT propagation delay seems to be about 10% bigger than in S3? > > I would expect some variation comparing actual silicon on two different > devices. The data sheet tells you the slowest silicon we're allowed to > ship, but the actual device likely is faster, especially at room > temperature and nominal voltage. > > That said, if you compare the Tilo specification for the Spartan-3 and > Spartan-3E families in their respective data sheets, you will see about > 150 ps of delay difference. > > Spartan-3: Tilo on a -4 device = 0.61 ns > http://www.xilinx.com/bvdocs/publications/ds099.pdf [Page 79] > > Spartan-3E: Tilo on a -4 device = 0.76 ns > http://www.xilinx.com/bvdocs/publications/ds312.pdf [Page 133] > > I wouldn't focus on a specific parameter per se, as your path delay > will include other timing parameters as well. For example, Spartan-3E > generally has faster flip-flop clock-to-output delays and faster > interconnect. In the wash, Spartan-3E _generally_ is at or about the > same performance. > --------------------------------- > Steven K. Knapp > Applications Manager, Xilinx Inc. > General Products Division > Spartan-3/-3E FPGAs > http://www.xilinx.com/spartan3e > --------------------------------- > The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. > Hi Steve, it was really my fault - I have downloaded DS312.PDF zillion times and this time when I was now looking for timing data I happened to open DS312.PDF dated May 2005 so in that outdated version there was no timing data. my measurements includes delay of 2 LUT, eg 2x Tilo + 2x interconnect within the same switchbox (no routing only switchbox), the result of that measurement indicated the Tilo increase exactly to the amount as as it is stated in the datasheet. Actually a little less, so the interconnect (swithcbox) may really be a little faster. would I have had the latest datasheet open when looking at timing data I would not have been surprised, my mistake, in the feature I will try to use only fresh Xilinx datasheets to avoid using outdated versions. -- Antti Lukats http://www.xilant.comArticle: 94818
Antti Lukats wrote:
> "Antonio Pasini" <removethis_pasini.a@tin.it> schrieb im Newsbeitrag
> news:43cd66bc$0$1087$4fafbaef@reader1.news.tin.it...
>
>>I already saw the message from Antti about '|' char on German keyboard. So
>>I installed WebPack 8.1 with some trepidation...
>>
>>Sadly, *seems* that on XP SP2 with Italian keyboards almost NO control key
>>works.
>>
>>Can some other guy verify this ?
>>
>>I cannot write '@', '#', '[', ']', '{', '}'.. Imagine write verilog
>>code! CTRL-F doesn't work, also...
>>
>>It doesn't work even in "float mode". Tried on three different machines,
>>at work and at home. Machines used different keyboards, and different
>>levels of update of XP.
>>
>>Probably someting very stupid is going on... otherwise, Webpack 8.1 editor
>>(even with SP1) is useless, for an Italian user.
>>
>>If this it's real... really makes me think Xilinx should honestly
>>re-examine its internal development process.
>>
>>I noticed also many other annoying little things:
>>
>>- "Ctrl" keys doesn't work also: forget about Ctrl-F to find some text.
>>- In float mode, "Replace" IS in the Edit menu (but NO quick icon), and
>>Ctrl-H doesn't work
>>- In float mode, "Find" is IS NOT in the Edit menu (but IS present as an
>>icon), and Ctrl-F doesn't work.
>>- Menu windows are sloooooooow... before appearing, a black filled
>>rectangle appears, then text comes. This on all the machines I tried. Fast
>>machines.
>>- TAB sequence is screwed in the "New Source Wizard"... try writing a pin,
>>the press TAB to enter the following one... surprise! need to grab the
>>mouse.
>>
>>All of this in the first ten minutes of playing. Very sad.
>>
>>Sometimes I wonder if Xilinx developers really try to USE what they do, or
>>are they "just" using blind regression testing scripts in search of the
>>last 1% of performance.
>>
>>Performance is important, yes, but first address the "mundane" tasks!
>>
>>Xilinx, usually your support is really second to none. It's one of the
>>reasons I prefer Xilinx over the A guys.
>>
>>Please release an hotfix.... do not ask us Italian guys to wait months for
>>the next service pack...
>>
>>Meanwhile, back to 7.1SP4, waiting for the next 3 service packs for 8.1 to
>>reach an "honest" level... Sigh.
>>
>>
>
>
> Hi
>
> after verifying the hot keys in 'flaot mode' I was a bit 'breathing' as it
> is a workaround, until I tried the
>
> |
>
> in float mode - and that doesnt work in float mode either - so we can say it
> is confirmed the ISE 8.1 built in editor is useless for non US keyboard
> users :(
>
> well I still use my notepad.exe trick to copy the | into clipboard when I
> need it, but I guess others are defenetly not willing to use this kind of
> workarounds
>
> Antti
>
>
>
>
Isn't it still possible to define your own external (favorite) editor in
ISE as it was before? In 7.1 it was done in Edit/Preferences dialog.
That is, when double clicking on a file in the 'Sources in
Project:'-view the code was opened in your predefined editor. I've been
doing this for quite a long time since I never really liked the ISE
editor...
Another workaround could be to install the american keyboard layout
(which I'm using in my external editor since some common characters are
more accessable than on the swedish keyboard). A simple alt+left shift
in windows swaps the layout from your native one to the american one..
As for me I havn't installed ISE 8.1i yet since I'm waiting for EDK...
--
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer
Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems
www.foi.se
Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------
Article: 94819"Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> schrieb im Newsbeitrag news:1137549427.016304.205210@g43g2000cwa.googlegroups.com... > The Spartan-3E Sample Kit Board is general available at no charge to > qualified customers. The boards are avaialable directly from Xilinx > sales partners. Information about the board and the accessory pack is > available on the Xilinx web site. > http://www.xilinx.com/products/boards/s3esamplepack/index.htm > > Please bear in mind that this is a free introductory board. I > affectionately call it the "Blinky Board" because it has somewhat > limited capabilities. It makes one heck of an LED blinker. It also > demonstrates that a Spartan-3E FPGA can configure from standard > commodity parallel NOR Flash. Furthermore, it demonstrates the > Spartan-3E FPGA's MutliBoot feature, which allows you to dynamically > switch between two different configuration images stored in Flash. > However, if you plan on developing anything more complex, I would > highly recommend purchasing one of the more advanced development > boards. > http://www.xilinx.com/s3eboards > > Direct Links to the Xilinx Sales Partners: > > Avnet: > http://www.em.avnet.com/spc/home/0,1727,RID%253D0%2526CID%253D27914%2526CCD%253DUSA%2526SID%253D4745%2526DID%253DDF2%2526LID%253D0%2526BID%253DDF2%2526CTP%253DSPC,00.html > > NuHorizons: > http://www.nuhorizons.com/Forms/sp3e-100-request.html > > Silica in Europe isn't currently showing the boards. I'll find out > why. > > Frequent comp.arch.fpga contributor Antti Lukats created a free, > friendly, easy-to-use programmer for the Spartan-3E Sample Kit board. > You can directly program the FPGA or the Intel StrataFlash PROM via a > Parallel Cable III or Digilent JTAG3 cable (I haven't tried it with > Parallel Cable IV yet). Antti's software also graphically displays the > state of the LEDs on the computer display, monitored over the FPGA's > JTAG port. Nice work! > http://xilant.com/component/option,com_remository/Itemid,53/func,fileinfo/id,8/ > > --------------------------------- > Steven K. Knapp > Applications Manager, Xilinx Inc. > General Products Division > Spartan-3/-3E FPGAs > http://www.xilinx.com/spartan3e > --------------------------------- > The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. > Hi Steve, thanks for nice words - our software defenetly works with Cable IV (only in Cable III mode) current version may have trouble if Cable IV was opened and closed in Cable IV mode with impact, we know the fix, but the drivers with current release may not have the ability to switch the Parallel port away from high speed mode. So the workaround is to open Cable IV in impact force Cable III mode and close impact. all our JTAG software is based on our own hardware abstraction API that was developed for PIC programming on DOS 3.22 machines, so we are able to add support for additional cables without the need to change our application software by releasing new drivers. we are actually also able to support impact CableServer in remote mode so that will bring full support of all Xilinx supported cables instantly. I know how todo it, but its not included yet in our current release. the 'pin monitoring' uses boundary scan in 'sample' mode so it is fully non-intrusuve monitoring, also included is frequency measurement of the on-board clock IC, several other tools are planned to be released. in last (to be uploaded version) support to 'scan' i2c bus is added, I2C may be connected to any pins of the FPGA, the SDA SCL mapping is translated from BSDL file -- Antti Lukats http://www.xilant.comArticle: 94820
"Zara" <yozara@terra.es> schrieb im Newsbeitrag news:39srs1pib0md5de88dnea8uds2gun9ba5i@4ax.com... > On Tue, 17 Jan 2006 23:00:54 +0100, "Antti Lukats" > <antti@openchip.org> wrote: > >>"Antonio Pasini" <removethis_pasini.a@tin.it> schrieb im Newsbeitrag >>news:43cd66bc$0$1087$4fafbaef@reader1.news.tin.it... > <snip> >> >>Hi >> >>after verifying the hot keys in 'flaot mode' I was a bit 'breathing' as it >>is a workaround, until I tried the >> >>| >> >>in float mode - and that doesnt work in float mode either - so we can say >>it >>is confirmed the ISE 8.1 built in editor is useless for non US keyboard >>users :( >> >>well I still use my notepad.exe trick to copy the | into clipboard when I >>need it, but I guess others are defenetly not willing to use this kind of >>workarounds >> >>Antti >> > > I am using WebPack 8.1 with an Spanish keyboard, and have not found > yet any such problem (other problems, yes, but I have not rechecked > against SP1, so I will not disclose them). > > Zara lucky you! the issues with the editor are the same SP1 or not, on my machine the 'alternate ALT' key labelled "Alt Gr" does not work in ISE editor and as this key is used to make | then it makes difficulties -- Antti Lukats http://www.xilant.comArticle: 94821
I have configured an XCV1000 as a data and instruction cache. It is connected to a external hard core. I would like to be able to update the contents of the caches without recompiling the file. I have been using Data2mem, but it appears that the CRC bits for the bitstream are not recalculated. They are always set to: 0xDEFC When data2mem modifies a bit file, it apparently turns off CRC checking by replacing the calculated CRC value with a constant 0xDEFC (which apparently spells DEFault Crc value). 0xDEFC is apparently supposed to tell the FPGA not to bother doing a CRC check on load because we were apparently TOO LAZY to calculate a correct value to check against. I found one (non-xilinx) web site that indicated that Virtex-II etc. will work just fine without a valid CRC value, but not so for Virtex. ngdbuild, or one of those tools near it, explicitly states that "-g CRC:DISABLE" is a valid command line option for Virtex-II but not Virtex, and indeed project navigator complains when I attempt "-g CRC:DISABLE" for our part. It seems clear at the moment that data2mem is not calculating CRC values but is calculating a bypass value instead; and it's less clear, but all signs seem to indicate, that that would work for Virtex-II and later parts but won't work for Virtex. I think there must be a way to get the CRC in the bitfile, hopefully using data2mem, but I haven't found it yet. Has anyone run into this problem and solved it? Here is a diff of the two bit files. Diff between working bitfile addr11.bit, generated by bitgen, and nonworking bitfile tmp.bit, generated by data2mem: 6c6 < Command: data2mem -bm tmp.bmm -bt addr11.bit -d --- Command: data2mem -bm tmp.bmm -bt tmp.bit -d 9c9 < File: addr11.bit [working] --- File: tmp.bit [nonworking] 5480c5480 < Write of CRC (CRC Check) register with 0x0000884F CRC value. < Calculated CRC value = 0x0000DEFC. [???] --- Write of CRC (CRC Check) register with 0x0000DEFC CRC value. Calculated CRC value = 0x0000DEFC. 5499c5499 < Write of CRC (CRC Check) register with 0x00004964 CRC value. < Calculated CRC value = 0x0000DEFC. --- Write of CRC (CRC Check) register with 0x0000DEFC CRC value. Calculated CRC value = 0x0000DEFC. Thanks, JOhnArticle: 94822
ptkwt@aracnet.com (Phil Tomson) writes: > > Where can one find more info on NCD and XDL file formats (and what the > acronymns stand for)? Are you implying that if one has this NCD file that one > can figure out the bitstream format? > > Phil As I understand it, the XDL is a textual representation of NCD. The NCD is the native circuit database, which has pretty much everything required to make a bitstream (logic, placement, routing, startup values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the XDL equivalent, hack it about and then regenerate the NCD from the XDL and from there go to a bitstream... You can also get a list of all the resources in the device using the -report mode of "xdl". Presumably you could create various small designs in XDL, NCD them and then convert to bitstreams and by diffing the bitstream figure out what was going on. In theory you could also automoate this... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 94823
Phil What you need as a driver depends on your software. I'm not a softy so I am not best person to talk about this. If you simply want to use a PC slot to power the card or do what Antti has done with his design that turns a RS1 into a parallel port look-alike you can get away without supplying a driver. We are getting a drivers, XP and Linux, for our own PCI core but probably 4-8 weeks away from releasing the first of these. We have a number of customers using Linux on various boards so if you ask in the Linux community newsgroups someone may offer a driver. We know of a customer successfully using the Opencore PCI. Other than there where some deficencies in the documentation we don't know much more other than that the size is larger than the Xilinx offering. Our own core is looking very good on size and features but more on that when we are ready to launch it. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Phil Tomson" <ptkwt@aracnet.com> wrote in message news:dqkhcl0598@enews2.newsguy.com... > In article <dqjuuq$cuu$1@newsg1.svr.pol.co.uk>, > John Adair <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >>Xavier >> >>Raggedstone1 comes free with a programming cable PROG2. >> >>The mode pins are connected together and go through a 0R resistor to 0V so >>not easy to change. >> >>Boards that are now available for the DIL headers: >> >>ADC_AD7927 200KHZ - 16 channel ADC based on Analog Devices AD7927 >>RS232 >>RS485 >>PS2 - Mouse and keyboard >>LED Array >>LED 4 Digit >>LED Dot Matrix >>USB1.1 - Interface only (core needs to be implemented in FPGA) >> >>LVDS oscillator module (0.6 inch DIL) - Being tested shortly available >>assuming ok. Capable of going to 700MHz although I don't the Spartan-3 >>will >>like it that high. >> >>There isn't a RAM board yet but there is a slowish 4MBit RAM chip that >>will >>fit the DIL on the LHS. A RAM module is being looked at and coming soon. >> >>We are waiting for some faceplate/cable assemblies for some of these so >>stock is a bit patchy at present. This status should improve within the >>next >>few weeks and after that I expect them to be fully available. >> >>Coming in the next batch are Ethernet Phy, IDE, Video Codec, 5V tolerant >>I/O >>to name a few. I don't have the full list with me so those are just the >>ones >>I can remember. These should be available in 4-8 week time frame assuming >>no >>design issues. >> >>PCI Core - The Xilinx core works with our board and Jungo supply drivers >>for >>that core. Not free I'm afraid. I believe at least one of our customers >>has >>got the opencores PCI working as well. I don't know the driver status on >>this core. We have not tried it so I can't comment further. We are also at >>the testing stage on our own native PCI/OPB Bridge Interface and a driver >>for XP is being written for it. Linux to follow. A limited version/license >>will be offered free with Raggedstone1 when we are happy with it's >>performance. Higher feature level versions will be available too at an >>extra >>cost but low usage licenses won't be too expensive. > > I'm interested in using your board with a PCI core as well. > Is the Jungo driver needed only for programming? (ie. if I program with > the > cable, I don't need the Jungo driver, right?) > > I'm primarily interested in communication between the PC's CPU and the > FPGA > via the PCI bus - the opencores PCI bridge should work for what I want, > correct? (Oh, and I'm on Linux, so if you could let me know what issues > that > might raise I'd appreciate it as well). > > Thanks. > > PhilArticle: 94824
Drily Lit Raga <midicad2001@yahoo.com> wrote: > Uwe Bonnes wrote: > > > > Xilinix has a library of old ISE versions to download. Look araound... > Oldest one available is 6.1, and Xilinx website is overloaded or I > don't know what, but I'll keep trying. Follow (Home)->Design Tools->ISE Classics->(Register & ) Download) and find an offer for ISE WebPACK v. 3.3 - v. 7.1 and even older tools -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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