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
Paul, As I said, I wanted to give you the option to respond. Thank you for clarifying when the new material that has been fixed will be available for the 2S60, and publishing an erratum for it. I suppose it would do no good to ask for a replacement with production silicon? As for webinar, is the leakage going to be less for all future production parts? Sounds like the first ES lot was leakier because it was fast corner material. It is possible that it was outside the wafer acceptance critera, so I will grant you that one, too. This ES part was within the latest spreadsheet 'maximum' specifications. 'Typical' is not something you can design to in this case. It would be unusual not to ship material that was a bit too fast, but I grant you that if you have a hot leakage test, you could scrap these in wafer sort, and customers would never see them. Austin Paul Leventis wrote: > Hi Austin, > > As I previously indicated, the EP2S60 *ES* (Engineering Sample) does > exhibit a surge current. This current does not exist in any other > shipping SII device including the EP2S15, EP2S30, EP2S90ES, EP2S130, > and EP2S180. The production EP2S60 devices, shipping later this month, > also do not exhibit a surge. > > The surge current issue was reflected in the Early Power Estimator 2.0. > Since it was fixed, it was removed in EPE 2.1. We just realized that > the errata sheet for the ES device is missing this spec; this will be > rectified shortly. > > >>The leakage follows the spreadsheet, that is there is a lot of >>Iccint(leak) at hot (about one ampere at 70C). In fact, by > > specifying > >>the "turn-on" current required for hot, they are probably able to > > ignore > >>the 3 amperes at cold (eg -- if the start up current is equal to or > > less > >>than the surge, then they can be honest and claim there is no surge). > > > The production start-up current is less than the operating (static) > current across all temperatures. > > Incidentally, our ES devices exhibit higher-than-typical static > currents. I noticed in the screenshot of our chip in your power > seminar that you were measuring an ES device, a fact you decided not to > mention in the talk... > > >>Perhaps someone >>with a production device can confirm this is fixed? > > > Austin, we have measured a bunch of production devices across process > corners, voltages, temperatures, different ramp rates, different power > supply start-up conditions, and on different days of the week for good > measure. There is no contention-based start-up current. > > Please, question our marketing all you want. But our specs are our > specs. Do not accuse us of lying. > > Paul Leventis > Altera Corp. >Article: 80526
Mike Treseler wrote: > Peter Alfke wrote: > >> The basic structure of most FPGAs ( with an abundance of flip-flops) >> favors one-hot encoding. > > > You have to try it both ways on each design to be sure. > I have found that one-hot encoding usually improves > speed by about 3% but not always. It can be slower in some cases. 3%? I wonder how you implemented your 1-hot state machine. My benchmark with multiple synthetic state designs indicate at least 50% speedup over binary. jzArticle: 80527
"Mike Harrison" <mike@whitewing.co.uk> wrote in message news:lr7o21tlf6v77dblgdv4idpcu6jqrch181@4ax.com... > > Xilinx want to sell chips. Getting cheap devkits available helps this, > whether they make them > themselves or fund third parties to do it makes little difference - I > can't see how this is any way > underhand.. If you made a product using Xilinx chips, then you would not object to others competing with you on the same terms. That is, they have similar economic constraints. Fair play. If Xilinx then went and subsidised one of your competitors product line, how would you feel? It would rankle my English sense of fair play. And probably destroy my business. > In practice, third parties can often do a better job as they are typically > smaller companies more in > touch with the needs of lower-end users, and are more geared up to > manufacturing than chip making > companies. Agreed. I just find it annoying that the company that makes FPGA dev boards the way I want them might be put out of business by Xilinx giving an unfair advantage to the makers of a board that is inferior from my POV (it has more bits, but I don't need or want them and they tie up pins I want to use). > Any third party making devkits independently of the manufacturer knows > that there is always a risk > of the manufacturer undercutting them when they decide to do a sales > push/promotion etc. American chip makers complained like hell when the far east sold their DRAM overproduction for economically unfeasible prices. It certainly was unfair, and there are laws to protect people from unfair trading practices. Otherwise any country could build up stockpiles of cheap chips and flood the market to drown their competitors then hike up the cost later. > Any company whose survival depends on selling devkits for > a single chip manufacturer's product is on shaky ground > unless they have a very good relationship with the manufacturer. If so then that's not encouraging anyone to start making anything based on Xilinx chips. I'm against subsidies in general. If Xilinx wants to subsidise manufacturers using their chips, they should do so equally, in proportion to the number used. The fairest way to do that is to reduce the cost of their chips. Then all their consumers have a level playing field.Article: 80528
Peter Alfke wrote: > The basic structure of most FPGAs ( with an abundance of flip-flops) > favors one-hot encoding. The alleged problem of many illegal states > can easily be alleviated since it is so easy to detect all illegal > states, How? Suppose I have a one-hot SM with 32 states. The only good way I've found so far to detect illegal states takes 29 LUTs. Basically I have a first level of six blocks that each take four inputs and produce a two-bit output that encodes whether there were 0, 1, or more than 1 input high. Those take two LUTs each. Then there are three more levels that take two pairs of encoded bits like that, and produce yet another encoded pair. The final level only takes one LUT because it only has to distinguish the "<= 1" and ">1" cases. There's probably some more clever solution that I've overlooked. EricArticle: 80529
> Will asynch design ever be feasible in FPGAs? I suppose it would > require a new tool chain and new ways of thinking, but having never > done it, I have no idea. These guys have done an asynchronous DLX processor in a Xilinx Spartan IIe FPGA: http://www.ics.forth.gr/carv/async/demo/ -- JecelArticle: 80530
Eric Smith wrote: > Peter Alfke wrote: > >>The basic structure of most FPGAs ( with an abundance of flip-flops) >>favors one-hot encoding. The alleged problem of many illegal states >>can easily be alleviated since it is so easy to detect all illegal >>states, > > > How? Suppose I have a one-hot SM with 32 states. The only good way > I've found so far to detect illegal states takes 29 LUTs. Basically I > have a first level of six blocks that each take four inputs and produce > a two-bit output that encodes whether there were 0, 1, or more than 1 > input high. Those take two LUTs each. Then there are three more levels > that take two pairs of encoded bits like that, and produce yet another > encoded pair. The final level only takes one LUT because it only > has to distinguish the "<= 1" and ">1" cases. > > There's probably some more clever solution that I've overlooked. > > Eric Actually there's a solution with 3 levels of logic and 13 4-LUTs. jzArticle: 80531
Jason Zheng wrote: > Eric Smith wrote: > >> Peter Alfke wrote: >> >>> The basic structure of most FPGAs ( with an abundance of flip-flops) >>> favors one-hot encoding. The alleged problem of many illegal states >>> can easily be alleviated since it is so easy to detect all illegal >>> states, >> >> >> >> How? Suppose I have a one-hot SM with 32 states. The only good way >> I've found so far to detect illegal states takes 29 LUTs. Basically I >> have a first level of six blocks that each take four inputs and produce >> a two-bit output that encodes whether there were 0, 1, or more than 1 >> input high. Those take two LUTs each. Then there are three more levels >> that take two pairs of encoded bits like that, and produce yet another >> encoded pair. The final level only takes one LUT because it only >> has to distinguish the "<= 1" and ">1" cases. >> >> There's probably some more clever solution that I've overlooked. >> >> Eric > > Actually there's a solution with 3 levels of logic and 13 4-LUTs. > > jz Nevermind, I thought you meant 16 states. -jzArticle: 80532
Hi Austin, > As for webinar, is the leakage going to be less for all future production > parts? Sounds like the first ES lot was leakier because it was fast > corner material. It is possible that it was outside the wafer acceptance > critera, so I will grant you that one, too. Most ES units while leakier than typical are still within (the now reduced) production specs. Over time we gain better control over the process and hence can provide a better upper bound on worst-case leakage for production units. This was reflected in the last spec upgrade. > 'Typical' is not something you can design to in this case. You don't need to convince me that looking at "typical" numbers for leakage is incorrect for most designs. Altera has published worst-case Stratix II leakage specs since day one. Paul Leventis Altera Corp.Article: 80533
Laurent, I am looking at page 5-2 in IEEE 1149.1 93 section 5.1.2. There is a statement "No matter what the original state of the controller, it will enter Test Logic Reset when TMS is held high for at least five rising edges of TCLK. The controller remains in this state while TMS is high." >From this, you would think it would be safe to tie the TCLK pin high. And I would agree with you had I never worked with JTAG before, but in my limited JTAG coding I have seen devices that will enter this state on one clock. The Motorola 306 for example. I don't know about the internals of the Xilinx parts. Maybe all of their devices require the minimum of 5 edges to enter test mode. Does anyone know that this is for sure the case? Why run the risk pulling it high?Article: 80534
Jason Zheng wrote:
> 3%? I wonder how you implemented your 1-hot state machine.
By changing a synthesis option setting.
The state type is just an enumeration. See:
http://home.comcast.net/~mike_treseler/uart.vhd
-- Mike Treseler
Article: 80535Quick question for those who know... Now that I'm downloading my 7.1i version of BaseX, does that mean I can't use the 6.3 version of the EDK? If that's the case, I'll not be installing 7.1 just yet! I have faith that Usenet will answer this question far in advance of me receiving all of the downloads, even with Comcast's "high speed" internet connection [grin] ATB, SimonArticle: 80536
lecroy7200@chek.com wrote in news:1110249759.373411.51880 @z14g2000cwz.googlegroups.com: > Laurent, > > I am looking at page 5-2 in IEEE 1149.1 93 section 5.1.2. There is a > statement "No matter what the original state of the controller, it will > enter Test Logic Reset when TMS is held high for at least five rising > edges of TCLK. The controller remains in this state while TMS is > high." > >>From this, you would think it would be safe to tie the TCLK pin high. > And I would agree with you had I never worked with JTAG before, but in > my limited JTAG coding I have seen devices that will enter this state > on one clock. The Motorola 306 for example. I don't know about the > internals of the Xilinx parts. Maybe all of their devices require the > minimum of 5 edges to enter test mode. Does anyone know that this is > for sure the case? The JTAG state machine is organized such that it will always return to the Test-Logic-Reset state in at most 5 TCLK cycles if TMS is held high. Depending upon what state it is in, it could arrive at Test-Logic-Reset sooner than that, but it will never take more than five. Why run the risk pulling it high? > > -- ---------------------------------------------------------------- Dave Van den Bout XESS Corp. PO Box 33091 Raleigh NC 27636 Phn: (919) 363-4695 Fax: (801) 749-6501 devb@xess.com http://www.xess.comArticle: 80537
Thanks Marc. I was thinking about getting into the VoIP development & I need a kit that I could start playing with. Then I saw the S3 Kit and was woundering if is something useful for this project. I guess its not! I really appericiate your help. Thanks again! LeoArticle: 80538
Hi Anyone know where I can obtain the Xilinx EDK Service Packs? I don't have a job but need to learn how to use the tools. Thanks, beagleArticle: 80539
google@gornall.net wrote: > It had occurred to me to clock the microblaze at 'only' 66 MHz, and > clock-double the SRAM. That would probably be fine, in fact, but it > seemed a bit of a waste to "lose" 20MHz of CPU frequency. The 87 MHz > comes from their selection options, nothing more - I don't actually > know if it really runs that fast, but they do claim 85 (I think) in > their literature for the S3. Yes, it's the claimed max frequency. But often when I add some IP around it I can't go more than 70 Mhz due to the IP ... > I wasn't actually aware about the supplied DDR IP - The kit only > arrived on Saturday [grin]. If it's there and it works, then that's > probably the way I'll go. I didn't really fancy trying to make the S3 > do fast DDR access - from what I've read you need to play tricks that > are under NDA in order to get it to work. Just add opb_ddr in the design, not a big problem ;) Of course creating a controller yourself that can go up to DDR400, there it's a little more difficult and the appnote describing that are under NDA. But there is no DDR in the started kit and don't count on adding some externally. DDR has a minimum frequency and the connectors on the starter kit will kill your signals integrity. And you also need 2.5V for DDR ... SylvainArticle: 80540
Peter Alfke wrote: > But I am not too excited about honoring them with a Xilinx website, > only to have Altera then come back and claim that they finally "have > REALLY" fixed it. [...] > But the newsgroup is like a club, where we can be more outspoken and > candid... But Austin could post the images on a webpage and link to them in a newsgroup message. I think a good place for such images would be fpga-faq.com but I could also place them on fpga.de Kolja SulimmaArticle: 80541
Er, Peter, > Well, I think there is a difference here. > On the newsgroup we can say: > "Altera Stratix-2 still has the infamous start-up current, even >2A on > a 2S60, and we have measurements to prove it". > > But I am not too excited about honoring them with a Xilinx website, > only to have Altera then come back and claim that they finally "have > REALLY" fixed it. > > Gentlemen should have some constraint in washing each other's dirty > laundry in public, or call each other "liar" in public, even when it > would be justified, as it is in this case. Ok. In the same vein, what are you going to do about that slow interconnect in the V4 series then? Paul never called Austin a liar. He merely exposed a few unmentioned facts in Austin's diatribe. The EP2S60ES silicon is/was a power hog (ha, you should have heard the raspberries when the ES power requirements were first mentioned to the FAEs), and Altera has been exceedingly candid about this to all customers. For the EP2S60, ES silicon is all you'll find at the moment, and it would have been better for your future credibility if Austin had immediately mentioned that your measurements had indeed been done on an EP2S60ES. Altera would have simply responded with "Yep, that's what we said. Didn't you believe us?". Then again, the world would have missed an interesting Usenet thread... Best regards, BenArticle: 80542
You need to set this constraint when XST can't trace all clock signals in your design. You have to identify all your clocks ports at the top level of your design. Compare them with XST Clock information synthesis result. This list reports the automatically identified clock nets, but probably XST has missed one in your design. If so, set the attributes at the very top of your design, targeting the input clock signal that was'nt present in the XST Clock information report. Good luck! /rockyArticle: 80543
Hi! I'm a student in Italy and I'm having some problems with a "xilinx ML310" board.I need to install another O.S. ,on the board, and do so without using the flash memory the board came with.In fact I need to boot from directly from the HDD.In any case damaging the flash is beyond what I can afford to. My problem is that I can't find the boot options to set the HDD to primary boot. Thanx.Article: 80544
I understand that you like the architecture of the 9500. However in PLD terms this device family is mature. Nevertheless this family is widely used as is the Mach4K. If price is the major concern, I suggest to work with the distributor or the supplier. Luc On Mon, 7 Mar 2005 17:48:36 +0100, "M.Randelzhofer" <techseller@gmx.de> wrote: >"Fred" <Fred@nospam.com> schrieb im Newsbeitrag >news:422c4449$0$8754$db0fefd9@news.zen.co.uk... >> I have an old board I'm updating which has 2 of these. I need a similar >> device to revamp the board and give it a new life. >> >> Can anyone suggest an affordable replacement? >> >> Cost is the principle issue. >> >> >> > >Xilinx XC9572XL is the best choice for cost and logic density. >It is in system programmable. >However it needs a 3.3V supply voltage, and has only 34 I/O's availlable in >a 44pin package, so use a VQ64 package: >http://direct.xilinx.com/bvdocs/publications/ds057.pdf > > >MIKE >Article: 80545
Hello Jens, Altium is offering an eval board with a Xilinx® SpartanT-3 FPGA Device (XC3S400-4FG456C) for EUR 99,-. You can order it from the local Altium office located in germany. More info about this board is available at: http://www.altium.com/livedesign/ It comes with a 1 moth eval license of the Altium Nexar Software. But in case you don't want to purchase the Nexar software afterwards you can still use the board as a 'normal' evaluation board together with the Xilinx software. Ciao, Ulrich "Jens Baumann" <annonce05_nospam@web.de> schrieb im Newsbeitrag 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: 80546
We used a labview application to configure a Xilinx device for test purposes. We have modified it to configure an Altera device, but can't get it to work. For the Xilinx we used the .rbt file which is an ASCII version of the .bit file. Does anyone know what the Altera equivalent of the .rbt file is?Article: 80547
Hi,
I'm trying to read in data from a .mif file to initialise some memory
elements in Synplify 7.6.1, but it fails when it encounters the line
FILE initfile : TEXT;
with the error "Expecting type name".
Does Synplify support file read/write (I've Googled and looked at the
Synplify documentation and website to no avail)?
I should say that I've included the std library and the textio package
as well. XST has no problems reading or writing files.
Cheers,
Andrew
Article: 80548Hi Brian, I missed this thread last week, but now I wanna join in! Especially as no-one else seems to agree with you that the big Cin is a big problem. So, some comments.. "Brian Davis" <brimdavis@aol.com> wrote in message news:1110029363.751977.92460@f14g2000cwb.googlegroups.com... > Austin, >> >>> 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. >> >>Why should we do that? >> When I read this, it became clear that Austin doesn't fully understand the problem... > > Because 10 pF and 1 Gbps are a poor match. > and then reading this, that Brian does. >> >>What is it about the Cout that is such a big deal? >> How about the sudden inrushes of current to charge and discharge Cout? How about the slowed rise time of the signal you're trying to drive. Why not take advantage of the spiffy new package and increase signal speeds? >> >>Driving the pcb trace, and the load at the other end swamps >>the intrinsic C of the pin in almost all cases. >> Total bollocks, unless of course you're thinking of driving another Xilinx FPGA? > > Not in my experience, particularly when dealing with > connections from 'real' 1 Gbps logic <-> FPGA Hear, hear! > >> >>To do what we do (which is more than the competitor), we >>need the silicon area. Silicon area = C. >> > > My heretical $0.02: > > DCI = not worth the penalty of excess C > > So ditch DCI, keep the DT terminators, YES! >and invent a controlled > slew driver with low C for the LVCMOS-ish standards. > Or let all the IOs slew fast and add a switchable series termination. A new ST option. Anyway, after watching the show, and thinking about the new packages, I'm convinced things are starting to look better. In the future, Cio will have to decrease, I imagine we'll see more Rocket I/O type dedicated pins. Cheers, Syms. p.s. Did I hear right or did Xilinx recommend in the presentation that you use a 100 thou thick 24 layer board for these parts? Hmmm, I wonder how much PCB consultants get paid... ;-)Article: 80549
Due to popular request, the paper submission deadline has been
extented to
March 18th 2005
http://fpl.cs.tut.fi/
Tero Rissa <fpl-prog-tero.re-move@fpl.cs.tut.fi.invalid> wrote:
> 15th International Conference on
> Field Programmable Logic and Applications
> August 24-26 Tampere Hall, Tampere, Finland
> FIRST CALL FOR PAPERS
> FPL is the first and largest conference covering the
> rapidly growing area of field programmable logic.
> During the past 14 years, many of the advances achieved
> in reconfigurable architectures, applications, design
> methods and tools have been first published in the
> proceedings of the FPL conference series. The 15th FPL
> will be hosted by the Institute of Digital and Computer
> Systems of Tampere University of Technology, Finland.
> CONFERENCE TOPICS
> The Program Committee invites you to participate and
> submit your contribution to FPL 2005. The conference
> topics within the scope of field programmable logic
> include, but are not limited to:
> RECONFIGURABLE ARCHITECTURES
> o Dynamic and run-time reconfiguration
> o Low power architectures
> o Defect and fault tolerance
> o Reconfigurable embedded systems
> o Field-programmable analogue arrays
> o Interconnects and NoCs
> APPLICATIONS
> o Communications/networking/cryptography
> o Bioinformatics
> o Application acceleration
> o Evolvable and bio-inspired applications
> o Rapid prototyping
> DESIGN METHODS AND TOOLS
> o CAD for reconfigurable architectures
> o Optimisation and technology mapping
> o System-level design methods
> o Testing, verification and benchmarking
> o Hardware/software co-design
> o Compilers and languages
> SURVEYS, TRENDS AND EDUCATION
> o Roadmap of reconfigurable computing
> o Teaching reconfigurable systems
> o History and surveys of reconfigurable logic
> o Emerging device technologies
> o Tutorials
> SUBMISSION GUIDELINES
> Authors are invited to submit original and unpublished
> contributions as:
> . 10 page papers to be considered as regular
> papers or posters
> . 2 page extended abstracts for PhD forum
> contributions and tutorial proposals
> All contributions must be submitted electronically in
> PDF format using Springer LNCS Instructions for
> Authors. The conference proceedings will be published
> and distributed at the time of the conference in the
> LNCS series and on CD-ROM. After the conference, the
> proceedings will be published in the SpringerLink
> online collection. For detailed formatting and
> submission information, please visit FPL 2005
> conference website at
> http://fpl.cs.tut.fi/
> IMPORTANT DATES
> Paper Submission Deadline: March 14th 2005
> Notification of Acceptance: May 23rd 2005
> Early Registration Deadline: June 20th 2005
> --
> T.Rissa
--
--
T.Rissa
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