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
In article <78khl4$oju$1@nnrp1.dejanews.com>, pandey@my-dejanews.com wrote: > Hello, I am studying the architectures of different FPGAs. I want to make a > comparison between Xilinx, QuickLogic and Altera FPGAs. I have some > information about Xilinx but almost no information about Altera and > QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what > are the routing resources and the technology on which it works(like SRAM, > anti-fuse via etc) How do I go about finding literature. Any inputs will be > appreciated. Thanx in advance. Best Regards Pandey > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own > Hi, For a start you could try this web site - it has lots of info and some good links. http://www.optimagic.com/ I am currently working on a comparison between the various technologies - but only just starting. I would be interested in what you come up with - or if any body has a functionality vs price comparison already done for FPGA technologies. Cheers James Moore jamesm@open.co,nz -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14351
Paul Attilla Richards wrote: > I'm interested in generating small-stepped delays with > FPGA/CPLDs for > a phased array transmitter, and initially thinking of > Xilinx 4000E & > 9500 series +M1.5 Foundation, though would happily > consider others. > > I've done a bit of design with all synchronous components > at 30MHz but > now need some small time shifts which are probably too > small to be > done by clocking. I'd welcome any comments or pointers. Interesting problem. Should get many answers. Ray Andraka might have some good ideas. I would suggest to use the fastest parts available. From Xilinx that would be XC4000XLA and Virtex. In a tight design, you can run the clock at 200 MHz = 5 ns period or 2.5 ns half-period. If you have to change your delays in real time, you cannot use the clock polarity configuration option, but for very small incremental delays of a few hundred picoseconds, you might enlist the carry delays. Virtex has four delay-locked loops, each with a timing granularity of ~35 picoseconds. So there are interesting possibilities for you to think about. Peter Alfke, Xilinx ApplicationsArticle: 14352
Hi Bruce, The box your mentionned is checked. The problem is that there are some ports which are connected to IPAD and others not (I have already looked at the XNF file ). The description of the warning message says : "The pad mapping optimization step assumes that if a port in the top design does not have a net attached to it that no pad cells ". These are inputs and connected to input pins of lower components in the hierarchy, that's why they are not attached to any net in the top level. There are no errors or warnings before the optimization phase ( bug?). Khaled.Article: 14353
Pipelinks (http://www.pipelinks.com) is a startup in the process of being acquired by Cisco. This should close by mid-February. Get into Cisco the easy way - get acquired!! Here's the opening: Board/FPGA Designer – Project Lead Skills Required: BSEE plus 5-8 years board level design experience. Experience designing add-drop multiplexers, expecially OC-3, T3, E3, SONET. Must have experience as a project lead or senior designer. Skills Desired: FPGA design in a telecom system - DS1, DS3, T1. Router experience a plus. Please contact: Margie Way, recruiter Pipelinks 490 Race St. San Jose, CA 95126 408-808-4103 408-808-4199 fax 831-427-0838 home office margiew@pipelinks.comArticle: 14354
Peter Alfke wrote: <snip> > > Needless to say, all Xilinx FPGAs have some hysteresis on > all their inputs :-) Does this mean ALL inputs, or just the Clock inputs ? ( or maybe the smiley means none at all ? :-) How many mV of hysteresis ? Does this mean slow edges are legal ? - jgArticle: 14355
--------------C37268972F66108D133BCA3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone in this group done any work related to 4-FSK demodulation using an FPGA? The standard I'm interested is the Home-RF SWAP standard. weeniper@pacbell.net --------------C37268972F66108D133BCA3C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Has anyone in this group done any work related to 4-FSK demodulation using an FPGA? The standard I'm interested is the Home-RF SWAP standard. <P> <A HREF="Mailto:weeniper@pacbell.net">weeniper@pacbell.net</A></HTML> --------------C37268972F66108D133BCA3C--Article: 14356
In article <m31zkismqa.fsf@tade.bendor.com.au>, Zoltan Kocsi <root@127.0.0.1> wrote: >The ANSI C standard states that there is C for environments which >contain an operating system. In that case main returns an int which >the OS should interpret as an exit code. Yup. >However, if you have the so-called free-standing environment, (which is >the case with most embedded systems) the main() function: >- does not have to exist at all, but >- if it exists, it can have any prototype you like, and >- does not have to return at all Not any prototype *you* like. Any prototype the vendor decided to use. And they probably have fairly strict standards. Anyway, if you refer to standard library functions, you're assuming a hosted environment. -s -- Copyright 1999, All rights reserved. Peter Seebach / seebs@plethora.net C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon! Send me money - get cool programs and hardware! No commuting, please. Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam! Article 75 of comp.compilers.lcc:Article: 14357
In article <78bt35$eql$1@nnrp1.dejanews.com>, satish_me@hotmail.com wrote: > Hello I am a customer from India to Xilinx. I purchased the Xilinx Express > foundation series long almost 1 month ago. Till now either for installation > or to tell how to start was not guided by any of the Indian representative. > Hence it shows the poor service of the Xilinx company in INDIA. Hence I > appeal to people of India not to go for purchsing the Xilinx products, which > suffer from lack of service in Indian region. > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own > I am sorry to put the blame on such an well established company. After my request the local rep. has turned to me. Any how I apologise for putting this in the net. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14358
Hello I am in the research field of FPGA. Why the PLL's should be used for FPGA reprogramming.Please intimate to my hotmail account -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14359
Ron Cline wrote: > > In a recent thread, there was a discussion regarding the desire for > hysteresis on clock inputs for programmable logic. Although this > would certainly help those applications where noisy or slow clock edges > are present, there would be repercussions that might make a product with > this feature only useful in special cases. This is already being done, by Vantis, and ICT - they have PLDs with hysteresis on ALL pins. It is a mistake to put hysteresis on just the clock pins - see the input transistion oscillation notes below. > (In other words, to be > frank, the small sales would make the product not worth the investment > from the vendor's (i.e. - my) point of view.) With this in mind, > reactions and comments on the following points are welcome. > > 1. Assume any hysteresis on the clock edges that is sufficient to be > useful (perhaps 0.4 to 0.5 volts) will also cause the clock-to-output > delay to increase by 0.5 nsec. (I think this is a reasonable > estimate.) This depends on your Hysteresis design. We have an IP Schematic, available for license, for an Input cell design that has Hysteresis, and no additional Buffer delay. > Why would you buy this product if you were not interested in > the hysteresis and another PLD was available with a faster Tco? The Tco cost is maybe 6-9 months of process improvement delay, whilst the reliability gains are timeless... With Hyst you KNOW your chip is as digital as it can be, without it and you have a whole lot more to contend with. Use Hyst for applications that do NOT heed fast Tco, but DO need noise immunity, cannot naturally provide 5nS rise/fall signals, or need EMC measures Raw Speed, and Hyst are almost opposite in nature. A growing real world problem is that circuits with 'slow' natured signals, are just waiting to fail, as the headlong rush for SPEED makes faster and faster CPLDs. ICT are one of the few PLD suppliers I have seen, where a SLOWER spec PLD is NOT just a relabeled fast part, but is genuinely quieter, has lower F/Icc, and has better noise immunity. How about a CPLD that IGNORES inputs under 10nS in width ? > Note: Some may suggest making the hysteresis programmable with an EE or > SRAM bit. For the purpose of this discussion, assume that such > programmability would itself add circuit complexity that would increase > the Tco even without hysteresis. (At the very least, we would have to > add a development and time-to-market cost variable into the discussion, > which would muddy the picture a bit too much.) > > 2. Half of the 0.5 nsec delta in Tco is simply due to the translated > threshold point compared to the timing spec. For example, if we have > 0.5 nsec of hysteresis centered around a spec'd 1.5 volt input > threshold, then the input buffer won't switch until the pin signal > reaches 1.75 volts. For a 2.5 nsec clock input rise time (a reasonable > value on IC testers), 10-90% of a 3.3 volt input signal, this implies an > added built-in delay of .25 nsec. In a system with long clock edges > (remember, this is one of the applications this structure is for) the > adder will be even greater. For a 10 nsec clock input (10-90), I > calculate the additional Tco from this effect to be around 1 nsec. So, > the question: With centered hysteresis, the Tco will be fairly > strongly dependent on clock rise time. Comments? Tco is fundamentally dependant on Rise time, whether you have hysteresis or not. Ground bounce of 0.25V can do the same thing to Ip -> Op delays Also, This also only affects external feedback Speeds - internal Clock speeds stay high My PCB design package quotes 150pS / inch of PCB trace, to put your 250pS into perspective. <snip> > 3) Finally, more and more PLDs have output slew-rate control. This also > adds to the Tco, but the choice can be made on a pin-by-pin basis. Does > this feature obviate the need for hysteresis at the input pins? How can Output Slew Rate, obviate the need for Hysteresis ? If you are allowing down the edges to meet EMC, you are _more_ likely to NEED Hyst, surely ? > This subject is often debated in my company, and it occurred to me that > this newsgroup would be a good place to discuss the technical issues > involved. I look forward to your comments with interest. > > Ron Cline > Product Development Mgr > Philips Programmable Logic Products Rather than analyse why it belongs in the 'too hard' box, try some real world designs, and see what hysteresis can do for these. There are quite a few 4000 / HC type GATE designs that no NOT port well to CPLDs, due to the lack of hysteresis. PLD prices have come down steeply, but often other considerations make them miss a design opportunity - Example A: LatestTechCo CPLD is driven from a 40nS rise time FAST optocoupler signal. This PLD has a 1nS In -> First Current Change Spec, and 3nS -> Output. At the time the Icc starts to change, the clock has moved just 10mV past the threshold. ( These first currents, from Ip buffers, are fortunately low) Current disturbances will increase, until outputs arrive at 5nS, at which stage the Clock has moved 300mV past the threshold. This gives a measure of the SELF SYNCRONOUS sensisitvity. A bounce of over 300mV will recross the clock threshold. Now, consider ANY ASYNC signals, elsewhere in the PLD. Now you have an aperture problem, where Double/Miss clocking will be caused. If we take 1nS as a 'visible clock', just 10mV (!) of ASYNC ground bounce is needed. This may fail only rarely, as the effect has a time curve. If your PLD is one of the 'WakeUp' Zero Power models, they have inbuilt hi spike Icc generators, as the internals cycle the power. - Example B : The PCB fails EMC tests, and ferrite beads are used to reduce the clock trace radiation. EMC now passes, but the CPLD at the trace end fails just sometimes. - Example C : Slow inputs from a Rotary Encoder are used to drive 2 PLD pins - these are NOT clock lines, so the designer thought they were ok. Sometimes, depending on the operator, Input transistion oscillation occurs, causing 'ground furr', and a non associated portion of the PLD locks up. - Example D : CPLD is used as a i2c Slave. This needs BIDIRECTIONAL Data/Clock operation. It is not possible to square up a 2 way data line, with an external buffer, and the Open Drain nature of i2c will never get to the sub 20nS some new PLDs need on Rise/Fall times. It needs a BiDir buffer, with Hysteresis. - Example E : Designer has a uC, running at 11MHz, and clocks the PLD from the sine wave OSC signal. There is no budget, or room for a Schmitt buffer ( even a PicoGate ) Product works fine, until new batch of shrink PLDs arrive... - Example F : Designer wants to build a 4046 type VCO, using cross coupled FF. PLD Architecture supports this well, except for the Input slew rate problems at lower OSC freq ... A Schmitt design will have lower Icc. There are many circuits that need an inaccurate local osc, if that could be integrated into the PLD ( a la 4093 ), many new applications will open up. Just as most uC these days have Schmitt Pin buffers, some day most PLDs will too. - jg -- ======= Manufacturers of Serious Design Tools for uC and PLD ===== = CPLD design libraries - uC Slave IO, 82C55, SPI, i2c, SPL, etc = CPLD_Lib@DesignTools.co.nzArticle: 14360
Jamie Lokier wrote: > > [Me speaking from a Handel-C-centric viewpoint] > Handel-C actually started as Handel which was based on Occam. We put a > C "front end" on it to make it more attractive to folks that know C > already. The result is actually a big improvement over the original > Handel, in terms of readability and compact code. > The fine-grained parallelism and communication primitives from Occam are > still present and very usable, so it's a nice combination. Indeed so; and I have done my best to tout the potential benefits of CSP-based hardware description in this NG and elsewhere. I'm sure it's a winner. But, if I may quote from something I recently posted to comp.lang.vhdl: | And don't get me started on how the parallel programming language occam | anticipated so many developments in multi-threading and active objects; | nor on how occam could have been the hardware description language of | choice; but occam died because it met Bromley's Criteria for abject | failure of any engineering development: | 1) it was technically competent | 2) it was at least a decade ahead of its time | 3) it originated in Britain :-) > <Jamie quoting my earlier post> > > - you need > > far more explicit control over parallelism, Handel-C comes close > > but is not sufficiently configurable - but the possibilities are > > obviously there. > > Do you have anything more specific in mind? Mainly, the way in which the present release of Handel-C is something of a Xilinx bigot, and uses all sorts of weird constructs/pragmas that are outside the language proper to control exploitation of device features. Not a criticism of the language itself, of course. If I were being cynical I could suggest that it reflects commercialisation of the language at rather too early a stage.... My most serious concern about the *language* is the irrevocable one-to-one relationship between assignments and clock cycles. I know why this was done, and I know it is often convenient, but there are occasions when a "non-clocking assignment" would make for much clearer expression of certain problems. VHDL deals with this issue by distinguishing between signals and variables. There is also a practical problem about the semantics of channels in a clocked (as opposed to asynchronous) environment. One Handel-C guru (names withheld to protect the guilty :-) ) has told me that he tends to use shared variables in preference to channels to avoid the extra clock cycle overheads. If he had a grave, I suspect Tony Hoare would be turning in it... As a secondary point, I could raise the limitations of Handel-C when addressing asynchronous design (for which Occam offers great potential benefits, as you are aware I'm sure!) and/or multiple clock domains on the same device. And I haven't yet understood how it deals with design/library maintenance issues in the way that VHDL does, although this may be because I haven't got to grips with the details yet. > I find Handel-C's limitations very frustrating, but with experience > I've found ways of doing things that turn out nicely in the end. I defer to your experience. I haven't yet used Handel-C on a "live" project. Certainly I've been very impressed with some of the stuff that your hardware-compilation group has done with it. Nice to see Handel-C protagonists putting their heads above the parapet here (by "here" I mean comp.arch.fpga despite the crossposts!) - is the time ripe for a hardware compilation newsgroup? Jonathan BromleyArticle: 14361
JV "THESYS-Mikropribor" in Kiev, Ukraine specializes in microelectronic
design and
service, namely:
- design of digital ICs for 0.6u/0.8u standard CMOS from idea to
experimental chip;
- design of 0.8u CMOS IC with embedded EEPROM blocks;
- standard digital cell design (Hspice models are needed);
- IC's layout service : design, synthesis, edit, DRC, LVS and layout
support in
accordance with customer task. Our layouts look very beautiful!!!
- any projects on ACTEL's FPGAs.
We look for a design work in ASIC&FPGA sphere.
Long-term cooperation is more preferrable for us. We'd like to be a
constant
partner for any customer.
We use next tools
for WS : CADENCE's tools
Verilog-XL
Leapfrog
Synergy
Virtuoso
Composer
SpectreS
Dracula 4.51
for PC : Actel Designer R1-1998
Tanner Tools 6.50
Hspice
WorkViewOffice 7.31
Engineers from our JV are all microelectronics specialists and
have worked in Kiev's Research Institute of Microelectronics
during 10-15years, have taken part in many projects and have designed
(from schematic to foundry) follow chips :
1) 80ó51 /re-engeneering/
2) Altera's EP600, EP1800 /re-engeneering/
3) Xilinx's X2064, XC1736 /re-engeneering/
4) multi-protocol remote control chip with key programming
5) music chip with 1/3-melodies
6) various versions of 64K EPROM chip
7) 4Kbit I2C serial EEPROM
Besides ASIC we deals with ACTEL FPGA's. In this sphere we fulfilled
above
10 serious projects and a lot of simple from idea to working chip.
The most interest are:
1) phase-digital frequency synthesizer
2) RZ-code transiever
3) controller for high-voltage switch
4) universal controller for CCD
If you have any proposals or ideas, please, mail.
Thank you for your time.
Regards,
--
Romanovsky Sergey phone : 38044 241 7115
Design Manager fax : 38044 241 7031
email : thesys@carrier.kiev.ua
WWW entry : http://www.ln.com.ua/~thesys
Address : JV "THESYS-Mikropribor"
Polytekhnicheskaya Str.33
252056 Kiev,Ukraine
Article: 14362
CALL FOR PAPERS
International Workshop on Parallel Execution on
Reconfigurable Hardware
http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html
Aizu, JAPAN
September 21-24, 1999
in conjunction with ICPP99
28th INTERNATIONAL CONFERENCE ON PARALLEL PROCESSING
US site: http://www.cis.ohio-state.edu/~icpp99/
JP site: http://www.takilab.k.dendai.ac.jp/conf/icpp99/
Workshop proceedings to be published by IEEE Computer Society Press.
THEME
Continuous progress in density, speed and design tools for
reconfigurable hardware devices regularly creates new design
opportunities and directions.
Meanwhile, the increasing diversity of computer workloads are
making the design of a universal and resource-efficient solution
for all computing applications more elusive. Several issues in this
context deserve further investigation.
The main objective of this workshop is to bring together researchers
and practitioners with the aim of stimulating the exchange of ideas and
experiences on the potential and limits of reconfigurable hardware, and
opening new avenues of research.
Topics of interest include but are not limited to:
* Dynamically Customizable Processor Microarchitectures
* Parallel Reconfigurable Architectures
* Performance Evaluation Techniques for Reconfigurable Systems
* General Reconfigurable Computing Models
* Programmable Logic Devices and Systems
* Merging FPGA and Logic/DRAM
* Design Process Flows and Tools
* Hardware/Software Co-design
* Evolvable Hardware
* Performance/Cost Comparative Studies with Standard Designs
* Applications (in search of the "killer" applications)
* Use of Reconfigurable Hardware in Emulation, Prototyping, and
System Validation.
IMPORTANT DATES
* Submission deadline: 1 March 1999
* Notification of acceptance: 8 May 1999
* Camera-ready copies: 15 June 1999
Demos are strongly encouraged. If you plan to make a demo of software
or hardware platform please inform one of the co-chair by the same
deadline.We can provide you with various equipments (WSs, PCs, CAD
Softwares, some FPGA boards, Instruments (digital analyzers,
oscilloscopes, power supplies,etc)).
WORKSHOP Co-CHAIRS
* Fadi Sibai, Intel
* Omar Hammami, University of Aizu
PROGRAM COMMITTEE
* Hideru Amano, Keio University (JP)
* Sameh Asaad, IBM T.J.Watson, (USA)
* Peter Athanas, Virginia Tech., (USA)
* Nader Bagherzadeh,UCI, (USA)
* Pak Chan, UCSC, (USA)
* Abdelaziz Chihoub, SIEMENS (USA)
* Apostolos Dollas, Technical University of Crete, (GR)
* Michel Dubois, USC (USA)
* Carl Ebeling, University of Washington (USA)
* Hossam Elgindy, University of Newcastle, (Au)
* John Granacki, ISI-USC(USA)
* Omar Hammami, University of Aizu (JP)
* Hitoshi Hemmi, NTT (JP)
* Brad Hutchings, BYU (USA)
* Tom Kean, Algotronix, (USA)
* Hassan Kobeissi, AMD (USA)
* Kenichi Kuroda, University of Aizu, (JP)
* Miriam Leeser, Northeastern U., (USA)
* Toshiaki Miyazaki, NTT (JP)
* Masato Motomura, NEC (JP)
* Scott Robinson, Los Alamos National Laboratory, (USA)
* Jonathan Rose, U.Toronto, (CA)
* Stephen Smith, Altera Corp., (USA)
* Yuichiro Shibata, Keio University (JP)
* Fadi Sibai, Intel (USA)
* Steve Trimberger, Xilinx, (USA)
PUBLICITY CHAIRS
* Abdullah Abonamah, University of Akron (USA)
* Imad Mahgoub, Florida Atlantic University , (USA)
TUTORIAL CHAIR
* Abdelaziz Chihoub, SIEMENS, (USA)
LOCAL ARRANGEMENTS
* Omar Hammami, University of Aizu (JP)
* Kenichi Kuroda, University of Aizu (JP)
SUBMISSION DETAILS
Authors are invited to submit research contributions representing
original,previously unpublished work. Submitted papers will be
carefully evaluated based on originality, significance, technical
soundness, and clarity of exposition. All papers will be refereed by
at least two members of the program committee. Accepted papers will
be published by IEEE Computer Society Press as proceedings of the
ICPP'99 workshops. All submitted papers MUST be formatted according
to the author guidelines provided by IEEE Computer Society Press
(two-column format) and MUST NOT be longer than 6 pages.
Electronic Submission
Please submit your paper electronically to our FTP site. Please
prepare your paper as plain ASCII PostScript only, with NO encoding,
condensing, or encapsulation. Please use TrueType 1 fonts wherever
possible. Do not use bitmapped fonts such as Computer Modern if you
can avoid it.
Guidelines for Generating and Submitting Postscript Files.
File Name
Please save your file using your name, i.e. John Smith's file would be
smith.ps. If you are submitting two or more files, please number them:
smith1.ps, smith2.ps, etc.
Transferring to FTP Site
When transferring files to our FTP site, if you have a choice between
ASCII and binary modes, use binary. Although ASCII mode works well
most of the time, binary mode incurs fewer problems.
Our FTP site: ehw1.u-aizu.ac.jp
Logon as: anonymous
Place files in subdirectory: /pub
(available from Dec 1st, 1998)
Submission Notification
When you have transferred your file(s) to our FTP site, please send an
e-mail with subject line ICPP99-PERH to:
perh99tpc@ehw1.u-aizu.ac.jp
with the following information: (1) author's name, (2) postal
address, (3) phone number, (4) fax number, (5) e-mail address,
(6) title of your paper,(7) 5 keywords, (8) abstract, and the
filename(s) you used. (Do NOT send a copy of your postscript file via
email.)
Hard Copy Paper
If, for some reason, you cannot place an electronic copy of your
paper on our FTP site, ONLY THEN you may submit it as four hard
copies to the following address:
Asia-Pacific/Europe/Africa America
Dr.Omar Hammami Dr.Fadi Sibai
University of Aizu Intel Corporation, M/S:SC12-202
Fukushima 965-8580 2200 Mission College Boulevard
JAPAN Santa Clara, CA 95052, USA
Please send also an electronic copy of your abstract, in ASCII format
and including author's name, postal address, phone number, fax number,
e-mail address, title of your paper, keywords,abstract, to both emails:
hammami@u-aizu.ac.jp fsibai@mipos2.intel.com
with in the subject field: ICPP99-PERH.
For any further questions or inquiries please contact one of the
program co-chair :
Dr.Omar Hammami Dr.Fadi Sibai
University of Aizu Intel Corporation, M/S: SC12-202
Fukushima 965-8580 2200 Mission College Boulevard
JAPAN Santa Clara, CA 95052, USA
Voice : +81-242-37-2558 Voice:(408) 765-5581
Fax : +81-242-37-2595 Fax :(408) 765-5263
e-mail: hammami@u-aizu.ac.jp email:fsibai@mipos2.intel.com
updates will be available at:
http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html
Article: 14363My vote is 'forget it'. It's not your problem if someone is driving your chip with a bad clock. My personal experience, with other people's boards, is that if they have a marginal clock somewhere, then they probably have all sorts of other unrelated problems as well, and a fix at a single device probably won't help anyway. And take a look at this from the point of view of an engineering manager at one of your customers: Engineer: weeellll, the board works *most* of the time but, hey, it works all the time if I use a Philips PALxxx..... Should I just specify the Philips PAL? Manager: In your dreams. Fix the problem or you're fired. If you have to spend your development money, then a differential clock input is something I would pay for. The other important area that needs attention is the output driver structure, to make fast devices more usable. BTW, I have a friend with a patent for an adaptive driver which carries out on-the-fly impedance matching, and I'm sure he'd be interested in talking to you - mail me if you're interested. EvanArticle: 14364
On Wed, 27 Jan 1999 05:50:28 GMT, seebs@plethora.net (Peter Seebach) wrote: >In article <m31zkismqa.fsf@tade.bendor.com.au>, >Zoltan Kocsi <root@127.0.0.1> wrote: >>The ANSI C standard states that there is C for environments which >>contain an operating system. In that case main returns an int which >>the OS should interpret as an exit code. > >Yup. Well, I've never seen the ANSI standard, but it shouldn't say this - the OS can do whatever it wants. The standard has no business enforcing an interpretation on the OS. >>However, if you have the so-called free-standing environment, (which is >>the case with most embedded systems) the main() function: > >>- does not have to exist at all, but >>- if it exists, it can have any prototype you like, and >>- does not have to return at all > >Not any prototype *you* like. >Any prototype the vendor decided to use. >And they probably have fairly strict standards. I wrote a kernel some years ago, so that makes either (i) myself, or (ii) the compiler vendor, 'the vendor' in this case. (i) The compiler has no business enforcing a prototype for main, and it didn't. The wrapper put a return value in Rx if there was one, and put zero in Rx if there wasn't one. (ii) That leaves me. I supplied a set of calling params, which were of no interest to the compiler, but were agreed between myself and the application writer. I was also at liberty to do whatever I wanted with Rx on return. In other words, neither of the vendors enforced a prototype. >Anyway, if you refer to standard library functions, you're assuming a hosted >environment. What is 'a hosted environment'? It's not that simple. I supplied some Unix-look-a-like entry points, and the compiler used them to provide 'standard library functions'. The real host was another computer at the end of a comms link, which had no ability to act on a return code. As it happened, I did return main's return value, if there was one, but it wouldn't have made any difference if I hadn't. I also recall using a 'real' OS at some point in the past which ignored the return value (riscos??). Evan Article 76 of comp.compilers.lcc:Article: 14365
On Wed, 27 Jan 1999 02:06:11 +0000, Khaled benkrid <k.benkrid@qub.ac.uk> wrote: >Hi Bruce, > > The box your mentionned is checked. The problem is that there are some ports >which are connected >to IPAD and others not (I have already looked at the XNF file ). The description >of the warning message says : >"The pad mapping optimization step assumes that if a port in the top design does >not have a net attached to it that no pad cells ". These are inputs and >connected to input pins of lower components in the hierarchy, that's why they >are not attached to any net in the top level. There are no errors or warnings >before the optimization phase ( bug?). I'm not sure I understand what you're saying here. Are you saying: (1) The pin you want is a port at the top level of the design, and it's also a port at the next level down, and you're joining the 2 ports together by name without using an intervening signal? or: (2) You have a port at the next level down, and you want it to be a pin, but you haven't connected it either a top-level port or a top-level signal? (1) sounds like an FPGA Express problem; if (2), check Andy's replies again. EvanArticle: 14366
On Fri, 22 Jan 1999 16:52:40 -0500, Rickman <spamgoeshere4@yahoo.com> wrote: >When Synopsys's FPGA Compiler is mentioned, which is this? Is this the >FPGA Express package from Synopsys (ver 2.1.3), supplied via Xilinx in >the Foundation Express package? Or is this a version direct from >Synopsys? Here's my understanding of the Synopsys line-up, in the absense of a more definitive answer. All disclaimers apply. There's a low-end product (FPGA Express), a mid-range product (FPGA Compiler, which I haven't used), and a high-end product (lots of software here, but the front end is Design Analyser, and the compiler is DC). Synopsys appears to want to distance itself from FPGA Express, and you can't buy it directly from Synopsys. It has to come from a distributor. It appears to share the same synthesis core as FPGA Compiler and DC, but I'm not sure about this. However, the analyser itself is certainly different, since it now supports some '93 features, whereas DC doesn't. It has none of the scripting features of DC or FPGA Compiler, and you're stuck with the GUI. Price here in the UK is about 10K (16.5K USD), including all technologies. Xilinx sells a Xilinx-only version, without the constraints manager, for much less. The constraints manager is, in principle, a Very Good Thing to have, since applying constraints to the synthesiser makes much more sense than applying them only to the PAR tool. However, I have heard it said (not from Synopsys) that the constraints are used simply to select between one of three (?) optimisation strategies; if this is true, then the constraints manager is of limited, or no, use. FPGA Compiler is an older product, and comes in two flavours. I believe that it was originally a cut-down version of DC, with a script-only interface. However, there is also now, additionally, something which looks like (or is?) FPGA Express. The two products will be integrated at some point. If the command language is similar to DC's then it should be a very useful product, but I haven't tried it. Pricing in the UK is, I think, about 25K (about 42K USD). It presumably has a schematic viewer. DC is a completely different ballgame, and is an ASIC tool (it can also target FPGAs, but I think this is uncommon). There's a lot of extra software here, and pricing starts at, I guess, about 100K UKP here. As an aside, DC is apparently scheduled to get a Tcl/Tk front end next year, which would also be a nice addition to the cheaper tools (Spectrum/Synplify/Modelsim already have it). I get the impression that Synopsys has a real problem positioning itself in the FPGA market, and coming up with a coherent range of FPGA tools - just compare it with Spectrum, for example. EvanArticle: 14367
ems@riverside-machines.com.NOSPAM writes: > distributor. It appears to share the same synthesis core as FPGA > Compiler and DC, but I'm not sure about this. However, the analyser > itself is certainly different, since it now supports some '93 > features, whereas DC doesn't. It has none of the scripting features of Two errors: The core is not the same as far as I know - the FPGA tools have some FPGA-specific algorithms. DC now also supports some '93 things (since 1998.08) I haven't gotten my hands on the 1999.02 release yet, but I guess it would be natural that it supports an even bigger subset of VHDL'93? GeirArticle: 14368
I have left 2 3042A parts and now I want to make use of them. Unfortunately I havn't got the right P&R tool for 3K devices. (My job at the University has ended, and "Xilinx Student Edition" has only 4K support). So my question is: What options do I have? Are there any old XACT packages for sale (<$100)? I don't have internet access at home, so online services are not applicable. Yours Marc ------------------------------------- -- return address field is invalid -- -- -- -- email: mrp@rz.uni-jena.de -- -------------------------------------Article: 14369
--------------695775E356BAC32D5CCD14D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Your Name wrote: > Has anyone in this group done any work related to 4-FSK demodulation > using an FPGA? The standard I'm interested is the Home-RF SWAP > standard. > > weeniper@pacbell.net Close, but no banana. I am giving a half day seminar on modulation and demodulation next week at DesignCon 99 (1 PM on feb 1) in Santa Clara. While I don't specifically address 4 FSK, the techniques I do address do apply. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka --------------695775E356BAC32D5CCD14D4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> <P>Your Name wrote: <BLOCKQUOTE TYPE=CITE> Has anyone in this group done any work related to 4-FSK demodulation using an FPGA? The standard I'm interested is the Home-RF SWAP standard. <P> <A HREF="Mailto:weeniper@pacbell.net">weeniper@pacbell.net</A></BLOCKQUOTE> Close, but no banana. I am giving a half day seminar on modulation and demodulation next week at DesignCon 99 (1 PM on feb 1) in Santa Clara. While I don't specifically address 4 FSK, the techniques I do address do apply. <P>-- <BR>-Ray Andraka, P.E. <BR>President, the Andraka Consulting Group, Inc. <BR>401/884-7930 Fax 401/884-7950 <BR>email randraka@ids.net <BR><A HREF="http://users.ids.net/~randraka">http://users.ids.net/~randraka</A> <BR> </HTML> --------------695775E356BAC32D5CCD14D4--Article: 14370
On 27 Jan 1999 14:46:23 +0100, Geir Harris Hedemark <geirhe@hridil.ifi.uio.no> wrote: >ems@riverside-machines.com.NOSPAM writes: >> distributor. It appears to share the same synthesis core as FPGA >> Compiler and DC, but I'm not sure about this. However, the analyser >> itself is certainly different, since it now supports some '93 >> features, whereas DC doesn't. It has none of the scripting features of > >Two errors: > >The core is not the same as far as I know - the FPGA tools have some >FPGA-specific algorithms. >DC now also supports some '93 things (since 1998.08) > >I haven't gotten my hands on the 1999.02 release yet, but I guess it >would be natural that it supports an even bigger subset of VHDL'93? Interesting - are you sure about the '93 bits? I put a test case through 1998.08 about a month ago, the last time I used DC, and it failed. IIRC, the test was simply 'entity E...end entity E', which is now supported by FPGA Express, but wouldn't compile on DC - maybe I missed a compilation switch? There was nothing in the help about any 93-related switches. EvanArticle: 14371
ems@riverside-machines.com.NOSPAM wrote in message <36af0a1c.10994993@news.dial.pipex.com>... >On Fri, 22 Jan 1999 16:52:40 -0500, Rickman <spamgoeshere4@yahoo.com> >wrote: > Xilinx sells >a Xilinx-only version, without the constraints manager, for much less. >The constraints manager is, in principle, a Very Good Thing to have, >since applying constraints to the synthesiser makes much more sense >than applying them only to the PAR tool. However, I have heard it said >(not from Synopsys) that the constraints are used simply to select >between one of three (?) optimisation strategies; if this is true, >then the constraints manager is of limited, or no, use. I think you're right; it doesn't seem to be a very aggressive optimizer (optimiser?). I've come across instances where something didn't meet a timing spec and it didn't seem to make any effort at all. I couldn't figure out how to force it to "try harder." One exciting thing FPGA Express does is to embed timing constraints in the xnf. The reason that this is exciting because it creates about sixty (!) different timing constraints, most of which are irrelevant and silly. Of course, when you get bogged down when you're doing PAR because of all the extra constraints. There IS a check-box to turn all of that off, but it seems sort of a waste. Yeah yeah yeah we can go edit xnfs and edifs but we shouldn't HAVE to do that. Also, it *doesn't* create useful contraints like timing ignores (you have to go into the .ucf for that; the Xilinx Constraints Editor actually makes that job easy). -- andy ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.edu "In the beginning, there was darkness. And it was without form, and void. And there was also me!" -- Bomb #20, John Carpenter's "Dark Star"Article: 14372
I think you can buy "The Practical Xilinx Designer Lab Book", it's a good book with the Xilinx Foundation Software in CD-ROM. It's not limited, except by VHDL, but if you are a student, you can upgrade it to v1.4 complete with VHDL support for free. Hernán Sánchez Professor Universidad Pontificia Bolivariana In article <7874b8$c86$4@arachne.labyrinth.net.au>, Hamish Moffatt <hamish@rising.com.au> wrote: > Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote: > > kim tae-chang wrote: > >> Is there any site from where I can down load a free max+plus ll(ALTEAR > >> COMPANY) simulator and runs on Windows 95 environment. > >> This simulator must handle big projects (up to 10k gates) in timing > >> simulation. > > > There is only one _free_ MAX+plus II software. It's available at > > http://www.altera.com > > > For big projects and with timing, the software is $$$. > > So is there ANY way to do free FPGA work yet? Like little projects for home? > > There's a collection of things around, but each have drawbacks. > > ActiveVHDL is very nice, but the demo (a) is simulation-time limited, > and (b) expires after 1 month. It also appears to use a LOT of RAM, > but I don't mind that so much. I gather this is pretty expensive. > > Synopsis have an FPGA Express demo, for VHDL. But the design size > is limited to something quite small, and then there's no way to route > the output netlist anyway. > > Altera have the MAX+PLUS II baseline. It can synthesize and compile AHDL > or schematics. It can't do VHDL, but I can live with AHDL (although the > help doesn't really make a very good tutorial). But you can't simulate it, > and the device range is reasonably limited. > > So what other options are there? I want to be able to enter a design, > either in an HDL or schematics (preferably the former), simulate it, > and route it for a device I can get reasonably easily. (Xilinx is the easiest > to get in Melbourne in my experience.) > > I've used Mentor, XACT 5.2, XACT M1.4 and Synopsis at uni and at work, > and it's frustrating not to be able to get this stuff for home. > > If the manufacturers concentrated on selling chips and gave the software > away, they might just sell a few more chips! I imagine that for a startup > company, the cost of software tools could be quite important. For a home > user it is obviously crucial. > > Hamish > -- > Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au > > Rising Software Australia Pty. Ltd. > Developers of music education software including Auralia & Musition. > 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 > Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 > Internet: http://www.rising.com.au/ > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14373
In article <36af092b.10753191@news.dial.pipex.com>,
<ems@riverside-machines.com.NOSPAM> wrote:
>On Wed, 27 Jan 1999 05:50:28 GMT, seebs@plethora.net (Peter Seebach)
>wrote:
>>>The ANSI C standard states that there is C for environments which
>>>contain an operating system. In that case main returns an int which
>>>the OS should interpret as an exit code.
>>Yup.
>
>Well, I've never seen the ANSI standard, but it shouldn't say this -
>the OS can do whatever it wants. The standard has no business
>enforcing an interpretation on the OS.
The standard doesn't enforce anything on the OS. What the OS does with
the return value, if anything is up to the OS.
The truth it that there is usually an unseen layer between the main()
funtion and the OS. Most operating systems don't look info a file for
a routine called main and call it with an argument count and pointers to
the arguments. Under most systems, the system calls some startup code
either inside or outside the executable which sets up the environment
for the call to main(). After main() exits, control us returned either
to the startup code, or some cleanup code. That is the real interface to
the OS. For example the interface to an OS that expects programs to
return a pointer to an error message could look like....
char *_error_messages[];
char *_startup(char *command_line) {
int argc;
char *argv[MAX_ARGV_PARAMS];
if (!setup_args(command_line,&argc,argv)) {
return _error_messages[main(argc,argv)];
} else {
return _error_messages[BAD_COMMAND_LINE];
}
}
It's usually up to the C implementation to provide this interface code.
If C actually set requirements on what the full interface to the OS looks
like, C implementations would be impossible on many systems.
Eric
--
Eric Korpela | An object at rest can never be
korpela@ssl.berkeley.edu | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
Article: 14374jim granville wrote: > Peter Alfke wrote: > <snip> > > > > Needless to say, all Xilinx FPGAs have some hysteresis > on > > all their inputs :-) > > Does this mean ALL inputs, or just the Clock inputs ? > ( or maybe the smiley means none at all ? :-) Inspite of the smiley I was serious and precise: ALL inputs on ALL Xilinx FPGAs ( the CPLDs are just starting to get the religion ) have a few hundred millivolts of hysteresis, and have had this for the last 15 years. Xilinx is celebrating its 15th birthday this coming weekend :-) > > > How many mV of hysteresis ? The data book - page 13-21 - says "All inputs have limited hysteresis, typically in excess of 200 mV for TTL input thresholds, and in excess of 100 mV for CMOS thresholds" ( The numbers only seem reversed, they are correct ). This description refers to XC3000, but is similar on all other FPGAs. > > > Does this mean slow edges are legal ? There has never been any problem with combinatorial inputs. If they are slow, it just delays the signal and may add some power dissipation. The problem is with clocks.In an environment without any noise and without any ground-bounce, even the incoming clock edges can be as slow as molasses. But show me that kind of environment.... Peter Alfke, Xilinx Applications
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