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
staylor@dspsystems.com wrote: > Because they can start the motherboard and chipset design at > the same time as the CPU or soon after. That gives them a lead > that others cannot match. Worse! They might even start earlier or they might have the processor guys change a signal or timing for their needs. That's clearly unfair. Intel chip set designers should get their cpu data sheets from the Intel ftp server like anybody else. > When anti-trust could be enforced is if Intel provided the > information to some outsiders but not others. rotfl. Gerhard -- on the air: DK4XP in the air: D-8551Article: 9901
"CodeLogic" (Digital, Software & Internet Design Services), provides high quality, cost-effective outsourcing alternatives for your electronic and software product development: http://home.intekom.co.za/codelogic - FPGA and programmable logic design (VHDL) - Embedded and DSP firmware (C and Assembler) - Windows Test software and Apps (Delphi 3) - Technical Documentation & Tutorials (HTML, +other) For more details go to: http://home.intekom.co.za/codelogic ----------------------------------------------------------------------------Article: 9902
Does anyone know what the FPGA express package from Synopsys is going for?Article: 9903
In article <352A96B9.6F646E41@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> wrote: >Jacob W Janovetz wrote: > >> Unfortunately, a wide disparity between >> delays of signals of the same bus can cause problems. Especially >> when the delays are on the order of the clock period. > >Fight like hell to avoid that problem, since it is a recipe for >disaster.Intelligent timespecs should get you out of it. >Otherwise get a faster device. > >Peter Alfke, Xilinx Applications > >> > Typical Xilinx response, spend more money and buy a faster device. If the problem is one of short paths due to clock skew a faster device won't help one bit.Article: 9904
Daniel K Elftmann wrote: > In article <352A96B9.6F646E41@xilinx.com>, > Peter Alfke <peter.alfke@xilinx.com> wrote: > > >Jacob W Janovetz wrote: > > > >> Unfortunately, a wide disparity between > >> delays of signals of the same bus can cause problems. Especially > >> when the delays are on the order of the clock period. > > > >Fight like hell to avoid that problem, since it is a recipe for > >disaster.Intelligent timespecs should get you out of it. > >Otherwise get a faster device. > > > >Peter Alfke, Xilinx Applications > > > Typical Xilinx response, spend more money and buy a faster device. > If the problem is one of > short paths due to clock skew a faster device won't help one bit. I tried to be helpful and warn against extreme cases where a delay is longer than a clock period. Any intelligent designer would agree with me. I do not need a vitriolic answer from somebody who obviously did not understand the question. Clock skew is a non-issue in Xilinx XC4000 as long as the design uses fewer than 9 clocks. The global-clock skew is guaranteed to be less than any related data delay, so there are no on-chip hold-time issues ever. Let's keep this newsgroup friendly and constructive. Peter Alfke, Xilinx ApplicationsArticle: 9905
> >I have five asynchronous pulse streams arriving at my logic device. > >Right now they range from 40 Hz to 120 MHz, but that range is pretty > >flexible. I would like to calculate the frequency of each stream. > > > >120 MHz is pushing the limits of the brute-force method (implement > >counters clocked by the pulse stream, periodically compare them to a > >real-time clock). Does anybody know of a more elegant solution? > Thank > >you for any ideas. > > >I have five asynchronous pulse streams arriving at my logic device. > >Right now they range from 40 Hz to 120 MHz, but that range is pretty > >flexible. I would like to calculate the frequency of each stream. > > > >120 MHz is pushing the limits of the brute-force method (implement > >counters clocked by the pulse stream, periodically compare them to a > >real-time clock). Does anybody know of a more elegant solution? > Thank > >you for any ideas. 120 MHz is not pushing the state-of-the-art anymore. I just finished the design of a 6-digit frequency counter ( with direct drive to a 6-digit LCD display, and with a 500-ms time base derived from a 32 kHz oscillator, all in an XC40002XLPC84,) and it works reliably ( and worst-case) at over 400 MHz. It is not a synchronous, global-clock-based design, but a frequency counter should not be designed that way anyhow. You can toggle a flip-flop reliably and over temperature at 400 MHz, and that's all that is required. In your particular case, I suggest some smarts that changes between frequency count and period measurement adaptively. It depends how much time you allot for capturing data, and what accuracy you are after, and how stable your input signals are. Questions, questions... Peter Alfke, Xilinx Applications.Article: 9906
This is a multi-part message in MIME format.
--------------6455D954C250BED35BC3042C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can readers please tolerate this posting for the benefit of specialists
whom may find this of interest.
One of the largest OEM manufactures in the world is in need
many ASIC designers here in the BEST part of Phoenix.
This is a SERIOUS opportunity and I am looking for serious inquiries
only.
The system being developed involves many low orbit satellites.
W2 hourly contract designers needed, pay rates are up to 50$/hour with
full benefits, Health, Life, Dental, Vision, 401K, personal days, sick
days paid, paid 2weeks vacation even though you would be contract.
Would you be interested in knowing more ?
Sincerely,
John D Allen.
---------------------------------------------
John D Allen President.
Leveridge & Friedman INC.
(602) 443 7792.
Fx (602) 607 0223.
Paradise Valley. john@leveridge-friedman.com
Arizona. 85253 www.leveridge-friedman.com
Networks -> Choice -> Quality -> Morality
---------------------------------------------
--------------6455D954C250BED35BC3042C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John D. Allen
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: John D. Allen
n: Allen;John D.
org: Leveridge & Friedman. INC.
adr;dom: ;;;Paradise Valley;Arizona;85253;
email;internet: john@Leveridge-Friedman.com
title: President.
tel;work: (602) 443 7792
tel;fax: (602) 607 0223
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------6455D954C250BED35BC3042C--
Article: 9907Jacob: : >> Unfortunately, a wide disparity between : >> delays of signals of the same bus can cause problems. Especially : >> when the delays are on the order of the clock period. peter a. : >Fight like hell to avoid that problem, since it is a recipe for : >disaster.Intelligent timespecs should get you out of it. : >Otherwise get a faster device. daniel: : Typical Xilinx response, spend more money and buy a faster device. : If the problem is one of short paths due to clock skew a faster : device won't help one bit. rk: jacob, is your problem a result of variation of delays from signals on a bus or clock skew? i believe your post reference data delays, not clock skew as daniel commented. in general, for modern fpgas, clock skew problems [when the correct resources are used] have been eliminated. of course, we sometimes design with old stuff, and it's still something to keep an eye on. but the new clock distributions systems all seem pretty good and manual intervention to get sufficient margis doesn't seem to be that common anymore. unfortunately, this issue has been replaced with managing skew when separate clock systems are used for I/O flip-flops and array flip-flops, but that's another story. just from basic design/timing analysis, if delays between signals from a common timing point exceed the period of the clock, i believe the technical term is "you're screwed" unless you hold the data off at the sink for an additional clock cycle. and, of course, the absolute delays are important too to reliably clock in the data, unless your clocking structure accomodates this. -- -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9908
Peter Alfke <peter.alfke@xilinx.com> wrote in article <353138D4.3998D4F@xilinx.com>... : > >I have five asynchronous pulse streams arriving at my logic device. : > >Right now they range from 40 Hz to 120 MHz, but that range is pretty : > >flexible. I would like to calculate the frequency of each stream. : > > : > >120 MHz is pushing the limits of the brute-force method (implement : > >counters clocked by the pulse stream, periodically compare them to a : > >real-time clock). Does anybody know of a more elegant solution? : > Thank : > >you for any ideas. : > : : > >I have five asynchronous pulse streams arriving at my logic device. : > >Right now they range from 40 Hz to 120 MHz, but that range is pretty : > >flexible. I would like to calculate the frequency of each stream. : > > : > >120 MHz is pushing the limits of the brute-force method (implement : > >counters clocked by the pulse stream, periodically compare them to a : > >real-time clock). Does anybody know of a more elegant solution? : > Thank : > >you for any ideas. : : 120 MHz is not pushing the state-of-the-art anymore. I just finished the : : design of a 6-digit frequency counter ( with direct drive to a 6-digit : LCD display, and with a 500-ms time base derived from a 32 kHz : oscillator, all in an XC40002XLPC84,) and it works reliably ( and : worst-case) at over 400 MHz. : It is not a synchronous, global-clock-based design, but a frequency : counter should not be designed that way anyhow. You can toggle a : flip-flop reliably and over temperature at 400 MHz, and that's all that : is required. : : In your particular case, I suggest some smarts that changes between : frequency count and period measurement adaptively. It depends how much : time you allot for capturing data, and what accuracy you are after, and : how stable your input signals are. Questions, questions... : : Peter Alfke, Xilinx Applications. for some nice ideas on very accurate frequency counters/period measurement, see the app note by HP. they cover a number of techniques including those on interpolation, iirc. their description of the circuits for the HP5370B is a must read. this is an old device but still very, very good, and the instruments are still in wide use. -- -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9909
"rk" <stellare@erols.com.NOSPAM> writes:
>Jacob:
>: >> Unfortunately, a wide disparity between
>: >> delays of signals of the same bus can cause problems. Especially
>: >> when the delays are on the order of the clock period.
>peter a.
>: >Fight like hell to avoid that problem, since it is a recipe for
>: >disaster.Intelligent timespecs should get you out of it.
>: >Otherwise get a faster device.
>daniel:
>: Typical Xilinx response, spend more money and buy a faster device.
>: If the problem is one of short paths due to clock skew a faster
>: device won't help one bit.
>rk:
>jacob, is your problem a result of variation of delays from signals on a
>bus or clock skew? i believe your post reference data delays, not clock
>skew as daniel commented. in general, for modern fpgas, clock skew
>problems [when the correct resources are used] have been eliminated. of
Peter was correct in his response. The question was posed a bit
strange, I suppose, because I referred to the clock as a 'signal.'
It is, in a sense, a clock skew problem but not because of the
capabilities of the device. I was generating an internal clock
and was not buffering it properly. The tools, unfortunately
were routing the crap out of the clock.
Incidentally, I'd prefer to keep the group on a constructive basis.
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9910Hi folks, Our Altera MAX+Plus II package is still for sale. The package is unused and still sealed. It's the full "Magnum" version including VHDL support, manual, CD-ROM, hardware dongle, maintainance (upgrades and tech support) and registration card. It cost over $7000 but we're seeking the highest offer. This is a good opportunity for a potential designer who's budget conscious. Thanks, - Chris cook2001@hotmail.com ps. We'd be happy to pay a finder's fee of 10% to anyone who can hook us up with a buyer. -- ------------------------------------------------------------------- Note: when replying, please remove the "_" prefix from the address.Article: 9911
I would suggest reading "The Two Faces of Tomorrow" by James P. Hogan. Daniel Lang dbl@hydra0.caltech.edu In article <352C307A.F383FBB5@earthlink.net>, Remove, "[no", "spm]", from, address. writes... >Naw read Neuromancer by William Gibson. It will all become clear. >Signed >Wintergreen > >Joseph H Allen wrote: > >> In article <35299fcd.2009650@news.megsinet.net>, <msimon@tefbbs.com> wrote: >> >> >You might try reading '1984' by George Orwell. >> >> No no, take a look at 'Star Trek' by Gene Rodenbury. >> >> >Eric Lussier <elussier@chat.carleton.ca> wrote: >> > >> >>I'm a third Computer Systems engineering student and I have to write a >> >>paper about the positive and negative effects of ICs on humanity. I'm >> >>thinking the only negative effect would be the environmental issues in >> >>producing chips. Unfortunetely it's not that easy to find books or >> >>websites that contain detailed info about this subject. Could someone >> >>please reffer me to a site or some books that may be able to help me >> >>out. >> >> >>Thanks in advance for any help that can be given. >> >> >>struggling student, >> >>Eric LussierArticle: 9912
Ray, Having used Altera for anything except my 16V8 and 22V10 designs since before Maxplus 2 came out (A+Plus) and when only the Classic series came out, I don't really disagree with most of what you said. I think the architecture is limiting in ways it shouldn't be. Altera seems to have finally learned though that the number of output enables needed is the number the user needs. That means an output enable per pin is necessary. Having said all that, what I don't understand is your final comment. >> Nevertheless, it is a popular device; probably because with its structure, it is tolerant to sloppy, hastily done and ill-conceived designs.<< I suspect there are many of us who feel our designs are none of those things eventhough they use Flex10k (or Flex8k) devices. I don't use VHDL so I cannot speak to that specifically. What I can say is that I have used Maxplus 2 and XACT 5.0. There is NO comparison, the Altera tools are far superior. As to the devices themselves, that is a more difficult comparison and one I won't make as it is application dependent. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9913
Hi, I am looking for tips, war stories, and successes from any of you out there who has used the Synplify/HDL Analyst Software from Synplicity, Inc. Thanks, in advance. james stine lehigh university jes6@lehigh.eduArticle: 9914
Hi, I have been using Altera's MAXPLUS for last three years. I have had some big problems in compiling packages for VHDL. That is, I wanted to use some defined packages (built-in library) for my VHDL code and MAXPLUS2 doesn't like it. The BIG difference in a compiler besides Altera's is that you get total IEEE-1993 compliance. This is the BIGGEST advantage in my opinion. It seems Altera wants you to program in AHDL instead of VHDL which in my opinion is a big problem since VHDL is very powerful and AHDL is not. james stine jes6@lehigh.edu Steve Dewey wrote: > I use Altera's MAXPLUS for all my CPLD/FPGA requirments. The version I have > has VHDL complier, fitter, timing simulator, programmer etc. I am a bit of a > newbie to this kind of work, but so far Maxplus has been perfectly adequate > for all my needs. > > What would be the benefit of using a 3rd party VHDL compiler ? > Would it allow a greater subset of VHDL to be compiled ? > (e.g. 1987 & 1993 VHDL varients ?) > > Would a third party compiler be more effecient, i.e. shorter compile time, > higher used logic density, faster device speed ? > > If this is the case, where would I find any metrics on which compiler is best > on the above criteria ? > > Why can't I take my Altera VHDL and run it on another _cheap_ vendor-specific > VHDL tool, eg cypress warp ? > > Sorry if these are obvious and reveal a lack of insight on my part. > > -- > Steve Dewey > Steve@s-deweynospam.demon.co.uk > Too boring to have an interesting or witty .sig file.Article: 9915
Princeton Information < www.princetoninformation.com > is seeking Ten (10) Senior Digital Design Engineers............ Digital FPGA Hardware Engineer -High Speed Digital Modem Technology Job Description: You will participate in the design and development of a flexible communications system breadboard utilizing FPGA's (ASIC) for Motorola's Celestri (tm) Modem Technology development program. These are specialized high-speed modems (Mbps) installed in satellites. Celestri is a multi-year, $13 billion project that will provide high-bandwidth packet switching - connections (e.g., internet) in outer SPACE!!! Celestial Data Communications for the 21st Century!!! BS/MS in Electrical Engineering +4 to 6 years of experience required. Familiarity with FPGA based design limitations and mitigation methods. Willingness to accept responsibility & technical challenge Ability to work independently and on a team Focus on customer satisfaction Location: Phoenix/ Chandler, AZ Duration: Full Time Salary and Temp to Permanent or out right contract consulting Pay Rate: Open See our Website: < www.princetoninformation.com > Email your resume TODAY!!! => < clientserver@msn.com > Princeton Information 1201 South Alma School #1125 Mesa, Arizona 85210 (602) 655-7600 FAX => (602) 655-7052Article: 9916
On Fri, 10 Apr 1998 23:44:35 -0500, Nick Hartl <"nhartl[no spm]"@earthlink.net> wrote: <snip> >Why would Altara make a tool that was very much like an industry standard, but >different? I am sure that there are two answers to this question. I'm not sure which two answers you have in mind. Here are two of mine: 1. Altera does not have to pay royalties to anyone for their own HDL. 2. Altera's check, compile, & implement software appears to be about 10 times as fast that in Xilinx's Foundation Basic Series software. I experimented with Foundation Basic Series last week. Its HDL (XABEL) is not included in the tutorials, not well documented otherwise, unstable (I had to reboot after each use because XABEL did not close itself down properly), and generated code requiring four times as much logic as the Altera software (400 Xilinx CLB's versus 199 Altera LC's] for my test module. That was after I recoded to avoid an XABEL bug which does not allow one to use large arithmetic comparisons, and which crashed my system (a Pentium 133 with 64 Mb of DRAM) by continually thrashing the disk after running 105 minutes. The Altera operation took 61 seconds for everything. The Xilinx operation (after recoding) took about 4 minutes for synthesis and 5 or 6 minutes (I didn't time in very precisely, but one phase took over 4 minutes) for a total of about 10 minutes. Xilinx tech support did find a way to decrease the logic generated by XABEL to 125 CLB's by altering a template file. That is about 1.25 times the equivalent Altera logic (199 LC's) resulting from compiling the Altera HDL file or the Xilinx logic [105 CLB's) generated by a VHDL compiler from a translated version of the Altera HDL file.Article: 9917
Sorry I neglected to mention the gate time in my early post. It's not too critical, around 1/2 second, like Peter's design. Peter Alfke: > : 120 MHz is not pushing the state-of-the-art anymore. I just finished the > : design of a 6-digit frequency counter ( with direct drive to a 6-digit > : LCD display, and with a 500-ms time base derived from a 32 kHz > : oscillator, all in an XC40002XLPC84,) and it works reliably ( and > : worst-case) at over 400 MHz. So you can reliably measure up to ~200 MHz (Nyquist) with the new parts? It sounds like this might not be too difficult a design after all. Time to order some new databooks... rk: > for some nice ideas on very accurate frequency counters/period measurement, > see the app note by HP. they cover a number of techniques including those > on interpolation, iirc. their description of the circuits for the HP5370B > is a must read. this is an old device but still very, very good, and the > instruments are still in wide use. I checked their web site, what a resource! In addition to the three or four on timing and jitter relevant to my question, I found one on temperature measurement that was really useful as well. I'll keep my eyes open for the one on the 5370B. Thanks for the recommendation! One final question: if I wanted to measure the jitter present on one of these signals (ranging from 60MHz - 120MHz), brute force would indicate that I need to use a 20x clock to measure +/- 5% jitter. Are there any inexpensive ($5 or so) parts I could purchase to make this possible? (obviously, dividing the signal won't work) Watching a good PLL's correction signal would be nice, but difficult to implement well... Thanks again for the very informative answers. - Scott (sbronson -a-t- opentv.com)Article: 9918
Hello, I am designing towards a XC4020E device using M1.4 tools under both the PC and unix. I have a couple questions concerning the use of the period definition in timing constraints. I have the following clock period settings defined: ts01=period:ff_8m:115ns:high:%50 ts02=period:ff_4m:ts01:*:2:low:%50 ts03=period:ff_2m:ts02:*:2:low:%50 I have two questions concerning the above definitions: 1. Because I have defined all three clocks in terms of each other will the xilinx software automatically constrain data paths that go from a ff_8m block to a ff_4m block? I figure this is too much to hope for but could eminate a few other timing constraints I have defined for these paths. The only reason I am lead to think that this may be possible is inclusion of fields that set which state a clock starts in. The only reason I can see for needing this information is to reference it to another clock. 2. Does the xilinx software make any assumptions about data paths coming from pads to a block that falls into one of the above three constraints? What about blocks going out to pads? Just wondering if I can eliminate a few lines of timing constraints. Thank you. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9919
Abstract submission deadline April 15!!!
VHDL International Users' Forum
October 26-28, 1998
Orlando, Florida
Call for Workshops, Tutorials and Papers
"Idea Factory: VHDL for Power Users"
http://www.vhdl.org/viuf
Are you up to the challenge? Could your VHDL-related perspective or
experience peak the interest of the industry elite? Do you have a
question of significance for the "power users" of the VHDL world? If
so, then the VIUF needs your help.
The Steering Committee for VIUF Fall 1998 is committed to promoting a
more active interchange of ideas and experiences among the
participants in our upcoming forum. We expect to achieve this by
utilizing a workshop and tutorial based format. Workshops will be
informal, but highly focused. Attendance to individual workshops will
be limited in order to facilitate open discussion. If you are an
experienced proponent of VHDL, we would value your insights and
contributions to this thought-provoking dialogue.
Workshop topics
Workshops may include a brief, but informative, presentation of the
subject matter by either an individual or small panel (no more than 20
minutes in duration), followed by a moderated discussion. Or,
workshops may be of the Q&A (question and answer) variety. Potential
workshop topics include (but are not limited to) those listed below.
A small number of topics will be selected for workshops based on the
submissions received.
Modeling Enhancements I: "Tweaks and Enhancements"
The focus of this workshop will be the small "deficiencies" in VHDL
that drive you nuts and make your job harder. What language
adjustments could (or should) be included in VHDL-200X to improve
productivity?
Modeling Enhancements II: "Challenges"
This workshop will focus on the larger issues. Given VHDL's existing
capabilities, will modifications in VHDL-200X better meet future
needs? Or, are more significant structural changes needed to
facilitate future designs?
VHDL at its limits: Switch-level and System-level Modeling
Current usage trends of VHDL appear to favor RTL/synthesis coding.
VHDL is applicable to a broader spectrum of design challenges. What
VHDL techniques and capabilities facilitate modeling above and below
the RTL level?
Large Project Management & Control
Systems on a chip and the increasing use of IP will require better
control of designs; design database verification is also required.
How can these tasks be accomplished? Will VHDL language changes
better
support these needs?
Design and Synthesis for FPGAs
Working with FPGAs begins to mimic the skills and techniques once
used
primarily in ASIC design. Will the use of HDLs will become more
prevalent in this process. Do any VHDL features enhance or inhibit
FPGA design?
Design for Reuse: IP Modeling
Some industry sources claim that verification requires up to 80% of a
design effort. With design sizes increasing and cycle times
decreasing, efficient designs re-use is necessary. How? What
features of VHDL can be used to enhance design re-use?
Testbenches and Testing
More complex designs and decreased verification time make efficient
and effective test methods a must. VHDL is a powerful tool for this.
Which VHDL techniques, methodologies, and tricks facilitate testing?
VHDL vs. Verilog: Truths and Myths
They share much in concept, but are significantly different. Is
common
evolution desirable, or should they each specialize? Most efficient
utilization? Can they handle tomorrow's design tasks? This workshop
strives to highlight their uses, not accentuate the battles of the
past.
Tutorials
In addition to focused workshops, this forum will offer a range of
tutorials (novice to expert level). Tutorials in support of any
workshop topics are of interest. Other tutorial topics include (but
are not limited to):
- Recent updates and new standards
- Behavioral Synthesis
- Hardware/Software Co-design and Co-verification
- Reconfigurable logic and dynamically reprogrammable FPGAs
- Advanced use of VHDL
- Getting up to speed with VHDL
Papers
A small number of technical papers pertaining to the practical
applications of VHDL will be selected. Potential topics for papers
include (but are not limited to):
- System-on-a-Chip Design: Case Studies
- Design methodologies and flows
- Advanced use of VHDL
- Analog and Mixed-Signal Integration
Submission Guidelines
The VIUF Fall 1998 Steering Committee invites you to submit an
extended abstract for a workshop presentation (panels welcome) and/or
tutorial, or a paper for the benefit of "power users" and novices
alike.
Workshop and tutorial submissions should include a 50-word abstract
and a 500-1000 word summary describing key concepts (and/or questions)
associated with the subject matter to be presented and/or discussed.
Each workshop submission should identify the workshop topic (see
above) under which it falls. Those submitting workshop and tutorial
abstracts will be required to provide a copy of any presentation
materials in machine readable form by the Final Material Submission
Deadline (see below).
Only full paper submissions will be accepted. Paper submissions
should describe key ideas, results, major technical contributions,
advantages, limitations, application environment and/or directions for
future work, as appropriate.
Each abstract or paper will undergo a thorough review by an
international panel of distinguished experts. Please send your
abstract and summary information to the Program Chair, Peter Ashenden,
via regular mail (see below) or via electronic mail (preferred) at:
petera@cs.adelaide.edu.au.
Important Dates:
Abstract Submission Deadline: April 15, 1998
Notification of Acceptance Sent: May 25, 1998
Final Material Submission Deadline: July 31, 1998
Conference Committee
Conference Chair
Yvonne T. Ryan
Leader's Edge
953 Mt Carmel Drive
San Jose, CA 95120
USA
Phone: 408-997-6028
Fax: 408-997-7481
Email: yryan@vhdl.org
Program Chair
Peter J. Ashenden
Dept. Computer Science
The University of Adelaide
Adelaide, SA 5005
Australia
Phone: +61 8 8303 4477
Fax: +61 8 8303 4366
Email: petera@cs.adelaide.edu.au
Workshops Chair
James Goeke
Eastman Kodak Co.
901 Elmgrove Road
Rochester, NY 14653
USA
Phone: 716-726-6571
Fax: 716-726-7881
Email: goeke@kodak.com
Tutorials Chair
Jose Torres
Viewlogic Systems, Inc.
47211 Lakeview Blvd
Fremont, CA 94538
USA
Phone: 510-659-0901
Fax: 510-659-0129
Email: jtorres@viewlogic.com
Design Contest Chair
Mike McCollough
Hughes Aircraft Co.
PO Box 902, RS/R1/A508
El Segundo, CA 90245
USA
Phone: 310-334-7085
Fax: 310-334-1243
Email: mikem@tcville.es.hac.com
Distributed Materials Chair
Matt Hsu
Shomiti Systems, Inc.
1800 Bering Drive
San Jose, CA 95112
USA
Phone: 408-437-3940
Fax: 408-437-4041
Email: matt@shomiti.com
Publicity Co-chairs
April Mitchell
SEVA Technologies, Inc.
9340 Carmel Mtn. Rd, Ste D
San Diego, CA 92129
USA
Phone: 619-538-6283
Fax: 619-538-4271
Email: april@seva.com
Nanette Collins
37 Symphony Road, Unit A
Boston, MA 02115
USA
Phone: 617-437-1822
Fax: 617-425-0340
Email: nanette@nvc.com
Forum Management
Conference Management Services (CMS)
528 Abrego Street, Suite 205
Monterey CA 93940
USA
Phone: 408-394-6384
Fax: 408-394-6382
Email: kjm@event-mgmt.com
Program Committee
Peter Ashenden - The University of Adelaide (Chair)
Matt Hsu - Shomiti Systems, Inc. (Distrib. Mat. Chair)
J. Bhasker - Lucent Technologies
Dennis Brophy - Mentor Graphics Corp.
Todd A. DeLong - The University of Virginia
Steve Drager - Air Force Research Laboratory
Wolfgang Ecker - Siemens Corporate Technology
Darrell Gibson - Bournemouth University
Bill Hanna - The Boeing Company
John Hillawi - DA Solutions
Michael McKinney - Texas Instruments, Inc.
Paul Menchini - Menchini & Associates
Gabe Moretti - Veribest, Inc.
Wolfgang Nebel - Universität Oldenburg
Serafin Olcoz - SIDSA
Greg Peterson - Air Force Research Laboratory
Mark Ronan - Northern Telecom Ltd.
Lance Thompson - IBM Corp.
John Willis - FTL Systems, Inc.
Philip Wilsey - The University of Cincinnati
Article: 9920In article <35324790.F8D59E12@eecs.lehigh.edu>, "James E. Stine, Jr." <jes6@eecs.lehigh.edu> wrote: >>It seems Altera wants you to program in AHDL instead of VHDL which in my opinion is a big problem since VHDL is very powerful and AHDL is not.<< Actually Altera is starting include VHDL or Verilog at no extra cost and allowed previous owners who didn't have it to upgrade for free. That would indicate that they do support and encourage VHDL or Verilog. I personally always write in AHDL. There are several reasons, the primary one being that I typically need the fastest speed grade of a device adn utilize it to near 100%. I find that I can get the rated performance or even higher using AHDL (since the performance is based on a 16 bit counter, it is possible to run faster). I have compared to VHDL on occasion and I get higher speeds at higher densities. To each their own. VHDL has its place, but AHDL is to VHDL what assembly is to C++. It all depends on what you are doing. On the other hand I used schematic entry for the only Xilinx design I ever did. No one I have convinced to try boolean level entry has ever gone back to schematic entry. There have been many. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9921
In article <352EECB1.1FA0@ids.net>, Ray Andraka <no_spam_randraka@ids.net> writes <about Altera 10K> > it is tolerant to sloppy, hastily done and ill-conceived >designs. Or in marketing-speak, it's "synthesis friendly". ;-) -- David Pashley < ------------------------ < < < ---------- Email: david@fpga.demon.co.uk | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | < < < Fax: +44 1280 700577 | --------------------------- < ------------------------------------------Article: 9922
Hi, Are you looking for information about the Texas Instruments TMS320C6x digital signal processors? Please check out my website: http://www.scs.ch/~andrew/c6x.html Here you'll find the latest documentation and silicon availability information. There is plenty of stuff about doing hardware and software design with these processors, some application notes and a comprehensive bug list. Also, stacks of info about commercially available 'C6x processor boards and lots of other stuff ..... Have a look and please send me any comments. Don't forget to join my mailing list if you want to be notified when the site is updated ... Cheers, Andrew Phillips Supercomputing Systems AG Zurich, SwitzerlandArticle: 9923
: rk: : > for some nice ideas on very accurate frequency counters/period measurement, : > see the app note by HP. they cover a number of techniques including those : > on interpolation, iirc. their description of the circuits for the HP5370B : > is a must read. this is an old device but still very, very good, and the : > instruments are still in wide use. scott: : I checked their web site, what a resource! In addition to the three or : four on timing and jitter relevant to my question, I found one on : temperature measurement that was really useful as well. I'll keep my : eyes open for the one on the 5370B. Thanks for the recommendation! rk: don't know if that's on the www. i got it before www invented. yes, i'm getting to be a geezer. let me know if you want me to dig it up and the doc number. i know i have it somewhere ... scott: : One final question: if I wanted to measure the jitter present on one of : these signals (ranging from 60MHz - 120MHz), brute force would indicate : that I need to use a 20x clock to measure +/- 5% jitter. Are there any : inexpensive ($5 or so) parts I could purchase to make this possible? : (obviously, dividing the signal won't work) Watching a good PLL's : correction signal would be nice, but difficult to implement well... rk: take a look at the way that the 5370B works. the idea is that you don't need a fast clock to meaure individual clock periods. the 5370B has a measely 500 MHz oscillator, iirc, and gets jitter measurements to < 20 pSec for real meaurements. There are other techniques, too, but the 5370B is the best of the instrument i use [day job] and is popular. Also, standford makes a more modern one, not as good performance if i recall. one odd note about the 5370B, fantastic freq and period measurement [and start/stop, of course], but it's limited to only 100 MHz. good luck, rkArticle: 9924
Hi Dave, It sounds like the guys at Viewlogic have developed a tool specifically for your purpose. Check out www.viewlogic.com/products/dxdm/html. DX DataManager provides data management for electronic engineering workgroups. Amongst its functions are revision control, release and configuration management of Work-in-Progress design data. Regards Chris Rottner In article <34fc3a8b.3807785@news.jps.net>, David Decker <mushh@jps.net> writes >I would like to use a version control system to support multiple >FPGA designers doing ViewLogic schematic capture to >Xilinx in under Win95. PVCS and similar programs are designed >to support software developers. As I am discovering, the main >deficiency of these systems when trying to use them for schematics, is >their inability to check directories in and out of version control. >They want to work with file lists. > >I would like to check out version 6 of a schematic as a unit. It >would consist of one sch\ directory with 100 .1 schematic files, >and a sym\ directory with 80 .1 symbol files. I think the .bit file >would best be included in the version,too. I would then like to >use ViewDraw to change the design in some respect, perhaps adding a >sub page. A place and rout would produce another .bit file. > >When I check this back into version control, I would like all >101 schematic and all 81 symbol files and the new .bit file to be >checked in without having to tell the version control system that I >added two files. I need to check schematics in as a unit. > >To complete the picture, other engineers would be prevented from >working on the FPGA that I was modifying, until I checked it back >in. I also need to combine multiple .bit files to make a PROM >image .exo hex file. I further need to combine two .exo files and >a microcode .hex file in a FLASH. The payoff of the version control >system, would be that the system would document what version of >all the schematics and microcode were in that FLASH, and be able >to reproduce any those files, if needed. > >If anyone knows of a system that can do this, or has another >workable system, I sure would be grateful for a tip. > >Since these version control systems seem to be limited to files, >I'm thinking of combining all .sch and .sym files and the .bit >file into one .tar file for check in, assuming I can find a DOS >version of TAR. TAR not using compression, I >believe would result in smaller diff or delta files between check >in versions than .zip would permit. > >Thanks for your help, > > >Dave Decker >Diablo Research Co. LLC > >Please use only one 'h' in mush. I'm trying to reduce the spam. > > > >"Animals . . . are not brethren they are not >underlings; they are other nations, >caught with ourselves in the net of life and time, >fellow prisoners of the splendor and travail of >the earth." >Henry Beston - The Outermost House -- Chris Rottner < ------------------------ < < < -------- Email: crottner@fpga.demon.co.uk | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | < < < Fax: +44 1280 700577 | --------------------------- < ------------------------------------------
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