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 <mFBClCApTWd0EwEF@p2cl.demon.co.uk>, Steve Goodwin <steve@p2cl_DSPM.demon.co.uk> writes: > In article <652vrc$54c@src-news.pa.dec.com>, Hal Murray > <murray@pa.dec.com> writes > >I've built my share of kludgy logic, but I try real hard to avoid > >clocking things with a FF, especially one that might be metastable. > > I would be interested in how you avoid this situation. Consider a clump of logic all clocked with a common clock. I try hard to avoid clocking some more logic with the output of one of those FFs. First, that clock is delayed by a Tco and hence the cycle time of that part of the logic is tigher. Often, I don't have time for that. Besides, it adds another level of complication to think about when you are trying to check the timing. Besides, usually there is a better/simpler way to do it anyway. Metastability just makes an ugly area even worse. > My understanding is that as soon as you introduce into a circuit a clock > and an incoming signal thats not synch'd to that clock you involve > metastability. There *will* be times when the incoming signal > transitions at the wrong time. Yes. And if you ever see some kludge circuit that looks for metastable states and fixes them you have a sure sign of somebody who doesn't know what's going on. > In my case I use two D Type FF in series (or equivalent) and (as much as > I can <g>) make sure that the time between clock edges allows the first > FF to 'settle' with some kind of very high likelyhood of success. The old no-brains recipe for avoiding metastability is 2 FFs in a row. The key idea that falls through the cracks if you just copy the circuit by rote is that you need time between the clocks. The more the better. If you poke around in ap-notes you can usually get a good feel for what to expect. For things like FPGAs, the routing delays are important too. Roughly the Tco and setup and routing time all subtract from the settling time. If you put logic in there, the time to go through it subtracts off too. ---- The 2 FFs in a row recipe worked very well in the old ROM based state machine days. The time through the ROM was usually pretty large relative to the basic time of the FF. That turned into the settling time of FF-FF path. With PAL based state machines, you are probably using a FF in the PAL so you don't gain any settling time by leaving out the logic inbetween FFs.Article: 8176
Tom Bowns wrote: > > lzh@bd748.pku.edu.cn wrote: [...] > I'm not sure if he's still doing it, but Thomas Chaney has been, to me, > the Metastability-Meister. There's a paper he wrote in IEEE > transactions: "Measured Flip Flop Responses To Marginal Trigerring," > IEEE transactions on computers, volume C-32, No 12, December 1983. He > told me that at the university (I forget which one - it's been a few > years) they'll do metastability analysis of your system or device for a > nominal fee. Flip-Flop Metastability was a classroom demo at MIT in 1968. It also appears in the Dean of Electrical Engineering, Campbell Sear's book on Electronics. I'm sure there must be references to it in the old vacuum tube technology - perhaps a Hewlett-Packard app note on digital counters might talk about it. It has been around a long time. Best Regards, Mike CEO, Analog & Digital Design Automated Production Test http://www.csolve.net/~add/home.htm Hosting Jonathan Ramsey's Pascal TCP/IP for DOS: http://www.csolve.net/~add/zips/tcp.htmArticle: 8177
I just got Foundation Base version 1.3, and I entered a small test design: Took the preconfigured 16-bit adder, connected busses to it (2 input busses, 1 output bus) and bus-type pins (2 input, 1 output). Mapper issues warnings that about everything has been optimized away, and (consequently) router/placer complains about the design being empty. What gives? I *did* connect an output bus and a bus-type output pin (which should map into 16 pins), so how come this design can be optimized away? Any help appreciated. Gregor Glawitsch | Tel: ++43 (0)732 655 755 - 33 Utimaco Safe Concept GmbH | Fax: ++43 (0)732 655 755 - 5 Europaplatz 6 | email (office): Gregor.Glawitsch@utimaco.co.at A-4020 Linz, Austria | email (home) : Gregor.Glawitsch@magnet.atArticle: 8178
In article <EJszsq.3C5@world.std.com>, John Cooley <jcooley@world.std.com> writes > \ - / The Unexpected Results From A Hardware Design Contest: > _] [_ Verilog Won & VHDL Lost? -- You Be The Judge! Hmm. Credentials first: I'm a Verilog user for FPGA design, but I think VHDL is probably a better idea. Here's why. Given a module - even a fairly tricky one - like your example, that has a thoroughly well-defined interface to the outside world and fairly easy-to-define functionality, I could code it in a hacky software language like Forth or BASIC, or even assembler, and get it working, far faster than I could write it in Ada or C++. On the other hand, if I were trying to build a big system I would be happy to take the initial time penalty on small modules just in order to get the consistency and clarity of thought on the big picture that comes with using a strongly typed language that can do lots of checking of my semantics at compile time. Years ago, software engineers learned that software spends only a few percent of its life being written and gotten to work; it then spends a lot of time being read (by other programmers who would like to re-use it or just understand it) and fixed (because it was probably not right first time, and definitely not what you wanted first time). Languages with Draconian checking like Ada and VHDL make the writing more difficult but win handsomely on improved understanding and maintenance. Cooley's first-past-the-post hacking competition was good fun and instructive, but is not likely to win friends in the software engineering community; and all of us who use HDLs are going to need those friends, desperately, as our designs grow in complexity and the pressure to re-use them increases. -- Jonathan BromleyArticle: 8179
--------------E01ECD36940B02B8D05B91A4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Which manufacture of PGAs would make it possible for the hobbyist to
use this technology. Obviously the manufactures are mainly interested
in the big customers and so charge big bucks for their development
products. So far I've investigated Lattice, Altera & Xilinx and they
all have unrealistic prices for their design software. The cost of the
chips are relativly small ($10-$20 each). The cheapest design package
was around ($850 Australian). Maybe I haven't looked around enough,
but if anyone has managed to use re-programable PGAs for a home
project, then please direct me to a source.
I am interested in devices capable of In System Programable and In
System Configerable. This has led me to the following products
erase/program cycles
Lattice: ispLSI1000 series 1000
Altera: FLEX6000 series infinite
Altera: MAX7000 series 100
Xilinx: XC3000 series infinite
Philips: PZ5000 series 1000
Adam
--------------E01ECD36940B02B8D05B91A4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<TT>Which manufacture of PGAs would make it possible for the hobbyist to
use this technology. Obviously the manufactures are mainly interested in
the big customers and so charge big bucks for their development products.
So far I've investigated Lattice, Altera & Xilinx and they all
have unrealistic prices for their design software. The cost of the chips
are relativly small ($10-$20 each). The cheapest design package was around
($850 Australian). Maybe I haven't looked around enough, but if anyone
has managed to use re-programable PGAs for a home project, then please
direct me to a source.</TT><TT></TT>
<P><TT>I am interested in devices capable of In System Programable
and In System Configerable. This has led me to the following products</TT><TT></TT>
<P><TT>
erase/program cycles</TT>
<BR><TT> Lattice: ispLSI1000 series
1000</TT>
<BR><TT> Altera: FLEX6000 series
infinite</TT>
<BR><TT> Altera: MAX7000 series
100</TT>
<BR><TT> Xilinx: XC3000 series
infinite</TT>
<BR><TT> Philips: PZ5000 series
1000</TT>
<BR><TT></TT>
<BR><TT></TT> <TT></TT>
<P><TT>Adam</TT></HTML>
--------------E01ECD36940B02B8D05B91A4--
Article: 8180Ray Andraka wrote: > Often times, an entire data bus comes crosses a clock domain boundary. > In these cases, you cannot depend on all bits to be accepted by the > receiving clock domain on the same clock cycle. The solution is to > write the data into a register using the sending clock domain's clock. > SImultaneoulsy, set a flag to indicate data is available in the > register. Then you synchronize the valid flag and use that to read the > data from the mailbox register. I typically use a flop clocked by the > sending domain clock which toggles each time valid data is sent. A > simple state machine generates a data valid signal when it detects a > change in the state of the toggle flop. This is exactly the scheme I use as well. FPGA programs written with our C-based language Handel-C use one clock for the whole design so interfacing to external asynchronous signals has to be thought about. I designed our RC1000-II ISA plug-in card so that the FPGA designer doesn't have to think about this. Circuitry external to the FPGA contains a registered transceiver which stores all data transfers between the ISA bus and the FPGA (in both directions) and flags indicate when data is ready to be read. So the ISA bus and FPGA clock domains are completely decoupled. If a flag is sampled when it is changing state, metastability is possible for one clock period, but on the next clock edge the flag will definitely be stable. The RC1000-II also has an Industry Pack (IP) daughter card site for analogue and digital I/O with the outside world. When interfacing to this, the FPGA is clocked by the same clock as the IP so they are the same clock domain and there is no metastability problem. Regards, Charles. Charles Sweeney, Engineering Director, Embedded Solutions Ltd Tel/fax +44 1235 510456 <http://www.embedded-solutions.ltd.uk/> Email CharlesSweeney@compuserve.com or csweeney@embedded-solutions.ltd.uk 6 Main Road, East Hagbourne, Didcot, Oxfordshire. OX11 9LJ. UK.Article: 8181
Xilinx had the good manners to send an announcement of their hard-wired
PCI LogiCORE on their email list rather than this newsgroup, but one
aspect of the announcement is worthy of comment:
Begin quote of Xilinx Press Release
Pricing and Availability
Typical production pricing for a HardWire with a PCI
Target/Initiator LogiCORE module, two dual-port 32x16 FIFOs and up to
10,000 equivalent gates of customer specific logic in a 208-PQFP at
25,000 unit volumes is $19.50 A nominal Non-Recurring Engineering (NRE)
charge applies.
End quote
Being interpreted, this means that if you have half a megabuck to spend
on a minimum order quantity, you have the privelege of spending about
the same per device as you would pay to AMCC or PLX for similar
quantities of their PCI controllers.
Now what really would be nice from Xilinx is the PCI circuit hardwired,
the 10k gates or a few more programmable in the usual way, for the PCI
parameters to be loaded from the same 8-pin device as loads the logic
for the 10k gates, and all for the same price or less than AMCC and PLX
charge in small quantities.
Fond hoping?
Paul
(PS: Please excuse my tacking this onto an old thread, but the subject
line is appropriate.)
--
Paul Walker 4Links phone/fax
paul@walker.demon.co.uk P O Box 816, Two Mile Ash +44 1908
http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253
Article: 8182Article: 8183
Hi.
I need a digital PLL design that will be used for clockgeneration of a
modulated signal. The signal is biphase-mark encoded (digital audio -
s/pdif). I would like to support the following sampling rates: 32kHz,
44.1Khz, 48kHz, 64Khz, 88.2kHz and 96kHz. The modulated signal is
modulated between to frequency components; 32*fs and 64*fs, ie. the
absolute minium frequency is 32*fs, and maximum is 64*fs. I must
generate a clock with 128*fs.
To summarize I will need a Digital PLL with the following properties:
o Must generate a stable clock from the modulated signal with
the clock's edges syncronized to the signals edges.
o A slow loopfilter. The PLL does (or must) not be quick.
20ms to aquire lock is what I am thinking of.
o The PLL must lock to the signal's fundamental frequency and
with the aid of dividors (frequency multipliers) generate a
clock with 128*fs (or 4 times it's lock frequency).
o If possible, able to lock to any signal in the specified
range; 1MHz to 3MHz (=32KHz to 96KHz), without any
"external" settings.
Does anyone have an idea of how to implement this digitally (in an
Altera Flex10k)?
I have included very much information here, but my question is simply
this: Is there anyone who knows how to implement a digital PLL,
capable of locking to signals upto 4MHz and multipling it's
frequency with four?
Sincerey
Svein E. Seldal
Norwegain Univerity of Technology and Science.
email: [ s v e i n s e @ i n v a l i d . e d . n t n u . n o ]
Article: 8184On Mon, 24 Nov 1997 23:25:18 +0100, Tobias Hilpert <thilpert@osc.de> wrote: >Hello, > >I'm a student working on a FPGA-based module for image preprocessing on >a framegrabber (module: two XC4013E-2 both serial master configured + 4 >synchronous SRAM's 128kx8). > >For FPGA configuration I wanted to use ATMEL AT17C256 EEPROMS (for >in-system-programmability the AT17C256 data output and some other pin's >run through a multiplexer 74AC157; I used the circuitry described in the >ATMEL data sheet p.3-29). Unfortunately, the configuration process >doesn't finish correctly !!! I tried to change some pull-up/down >resistors without solving the problem :( . I also substituted the ATMEL >by the original Xilinx PROM and wonder: no config problems occurred (-> >there are no circuitry errors). >Some other students are using ATMEL AT17C128 devices for smaller XILINX >FPGA's without any problems. > First question: do the Atmel parts work if they are programmed by a programmer? I am using 4 AT17C256s (serially cascaded) to load a large Xilinx FPGA, and things work fine--unless I don't program the polarity bit correctly. I don't remember for sure, but the value to put at $8000 may not be the same as for Xilinx serial PROMs. I have not used the in-circuit program capability (though it sure would be nice for prototyping), so I can't help you there. Jason T. Wright Ericsson >snip > Tobias HilpertArticle: 8185
Clock multiply is always tricky, tho delays and XOR gates can double reasoably easily. It is best to start with a higher external clock. To lock at 128Fs, and do so slowly is doable. For this, you create a DIV 127.128.129 counter, then create a phase comparitor that produces a Go-Left / Go-Right signal ( ie a D-FF ), or a fancier one with a third HOLD state. You then Divide by 127 on LEFT, 129 on Right, and 129 on Hold. The effect is a slow phase 'walk', needing 64 cycles to correct a MAX 50% lock error This is 2mS. To reduce this further ( and improve noise immunity ) either add a vote counter to the Phase comparitor, and collect, for example, the last 16 cycles. The average of the Left.Right.Holds is applied to your counter. This can also produce an 'In-Lock' signal or Increase the Divn, to say, 1022,1023,1024 - but this takes the ref Clk up rather higher. In all cases, the phase jitter can never be less than 1 period of the fastest CLOCK - tho this is not normally a problem, since the FPGA is clocked anyway ! To get below this, you need a analog PLL. Svein E. Seldal wrote: > > Hi. > > I need a digital PLL design that will be used for clockgeneration of a > modulated signal. The signal is biphase-mark encoded (digital audio - > s/pdif). I would like to support the following sampling rates: 32kHz, > 44.1Khz, 48kHz, 64Khz, 88.2kHz and 96kHz. The modulated signal is > modulated between to frequency components; 32*fs and 64*fs, ie. the > absolute minium frequency is 32*fs, and maximum is 64*fs. I must > generate a clock with 128*fs. > > To summarize I will need a Digital PLL with the following properties: > > o Must generate a stable clock from the modulated signal with > the clock's edges syncronized to the signals edges. > o A slow loopfilter. The PLL does (or must) not be quick. > 20ms to aquire lock is what I am thinking of. > o The PLL must lock to the signal's fundamental frequency and > with the aid of dividors (frequency multipliers) generate a > clock with 128*fs (or 4 times it's lock frequency). > o If possible, able to lock to any signal in the specified > range; 1MHz to 3MHz (=32KHz to 96KHz), without any > "external" settings. > > Does anyone have an idea of how to implement this digitally (in an > Altera Flex10k)? > > I have included very much information here, but my question is simply > this: Is there anyone who knows how to implement a digital PLL, > capable of locking to signals upto 4MHz and multipling it's > frequency with four? > > Sincerey > > Svein E. Seldal > Norwegain Univerity of Technology and Science. > email: [ s v e i n s e @ i n v a l i d . e d . n t n u . n o ] -- ======= Manufacturers of Serious Design Tools for uC and PLD ========= = Optimising Modula-2 Structured Text compilers for ALL 80X51 variants = Reusable object modules, for i2c, SPI and SPL bus interfaces = Safe, Readable & Fast code - Step up from Assembler and C = Emulators / Programmers for ATMEL 89C1051, 2051, 89C51 89S8252 89C55 = *NEW* Bondout ICE for 89C51/89C52/89C55 = for more info, Email : DesignTools@xtra.co.nz Subject : c51ToolsArticle: 8186
I posted a message here last week about a router crash I was having when running Xilinx's M1. Within a couple of days two people from Xilinx got in touch, and asked for my sources. After another couple of days I was told that they'd found the bug, and were going to do a patch for M1.3 so that I could route the design. I got the patch on Monday morning (I think they must have worked through the weekend), and it fixed my problem. Amazed? I was... Evan ---------------------------------------------------------------- -- E.M. Shattock -- -- Riverside Machines Ltd. -- -- 19 De Freville Ave. tel: (+44) 1223 566083 -- -- Cambridge CB4 1HW fax: (+44) 1223 566983 -- -- UK mailto:ems@riverside-machines.com -- ----------------------------------------------------------------Article: 8187
Gregor Glawitsch wrote: > > I just got Foundation Base version 1.3, > and I entered a small test design: > Took the preconfigured 16-bit adder, connected busses to it > (2 input busses, 1 output bus) and bus-type pins (2 input, 1 > output). > > Mapper issues warnings that about everything has been > optimized away, and (consequently) router/placer > complains about the design being empty. > > What gives? > > I *did* connect an output bus and a bus-type output pin > (which should map into 16 pins), so how come this > design can be optimized away? > Look at the trim report to see what started the trimming if it is not obvious from looking at the design. If the trim log says loadless signal, it trims back. If it finds sourceless signals it'll trim forward. In otherwords, all the inputs have to be sourced by something (either other logic or an input pin). Alternatively, if the design is not complete, just shut off the trim unused signals dialog box so that none are trimmed. -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/~randrakaArticle: 8188
In case none of these suggestions work, be sure to check the lot numbers of your Atmel parts. It's been a while now since the bad lots were put out and distributors should have pulled them all, but there were problems with configuration on some early 17Cxxx devices. They'd take 30 seconds or so to configure, about 1000x slower than expected. You'd have to check the atmel web site for the application note that told how to identify the bad lots. If your parts were recently purchased then something else is probably to blame. If you're using Atmel's configurator board then ignore the $8000 information - that stuff is used by Data I/O and perhaps others. The cf.exe program uses a different technique. Incidentally, I'm using 17c256 parts and kicking my posterior because I have PLCC-20's when the parts are actually available as DIP-8's -- the internal documentation of cf.exe says that the datasheet was a misprint (it said that 256kbit part was not available in DIP-- it actually is available) On 26 Nov 1997 18:46:32 GMT, johna@dvorak.amd.com (John Archambeault) wrote: >In article <347b51d8.231064002@cnn.exu>, >Jason T. Wright <Jason.Wright@ebu.ericsson.com> wrote: >>On Mon, 24 Nov 1997 23:25:18 +0100, Tobias Hilpert <thilpert@osc.de> >>wrote: >> >>>Hello, >>> >>>I'm a student working on a FPGA-based module for image preprocessing on >>>a framegrabber (module: two XC4013E-2 both serial master configured + 4 >>>synchronous SRAM's 128kx8). >>> >>>For FPGA configuration I wanted to use ATMEL AT17C256 EEPROMS (for >>>in-system-programmability the AT17C256 data output and some other pin's >>>run through a multiplexer 74AC157; I used the circuitry described in the >>>ATMEL data sheet p.3-29). Unfortunately, the configuration process >>>doesn't finish correctly !!! I tried to change some pull-up/down >>>resistors without solving the problem :( . I also substituted the ATMEL >>>by the original Xilinx PROM and wonder: no config problems occurred (-> >>>there are no circuitry errors). >>>Some other students are using ATMEL AT17C128 devices for smaller XILINX >>>FPGA's without any problems. >>> > >Yes, thats what I was going to say, that the RESET/OE_ pin of the ATMEL >defaults to the opposite polarity of the Xilinx FPGA. Your prom burner should >have some options under its program menu for switching this polarity. > >Otherwise, I too haven't done any in-circuit programming with the ATMEL parts. > > - John >Article: 8189
Adam Seychell wrote: > > Which manufacture of PGAs would make it possible for the hobbyist to > use this technology. Obviously the manufactures are mainly interested > in the big customers and so charge big bucks for their development > products. So far I've investigated Lattice, Altera & Xilinx and they > all have unrealistic prices for their design software. The cost of the > chips are relativly small ($10-$20 each). The cheapest design package > was around ($850 Australian). Maybe I haven't looked around enough, > but if anyone has managed to use re-programable PGAs for a home > project, then please direct me to a source. lattice has a free version of their software, which is the data io synario package, on the databook cd-rom that they give out for free. it does the 1016 and the 2032, and i believe it also does the 22v10. here in the states it is very easy to talk to the f.a.e. at a major distributor, and get a copy of the more complete package for anywhere between $99 to $250 U.S. what makes the difference is the time of year. these guys have a quota of development systems they are supposed to get into the hands of customers. numbers count, making a profit takes a back seat. if you catch them at the end of the quarter, they are more likely to give you a good price, and at the end of the year - watch out! _______________________________________________________________________ Bob Engle rengle@ix.netcom.com Embedded Solutions Orlando, Florida FPGA and MPU contract engineering _______________________________________________________________________ "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered. My life is my own...." The Prisoner _______________________________________________________________________Article: 8190
Hello everybody, the theses of Stephan Gehring and myself are available from http://www.inf.ethz.ch/publications/diss.html Abstracts: Trianus ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th12188.abstract Hades ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th12276.abstract They describe a framework for digital circuit design using FPGAs (Trianus) and a place & route back-end for that framework for the Xilinx XC6200 RPU and a board with that chip. Read the abstracts first, before you decide to download the files. The described software is available from Virtual Computer Corporation as part of their HOTWorks PCI-board http://www.vcc.com and an older evaluation copy can be found via http://www.lola.ethz.ch in the section on Trianus. Check it out and send your comments either to ludwig@pa.dec.com (Stefan Ludwig) or gehring@interval.com (Stephan Gehring). Have fun, Stefan Ludwig Systems Research Center Digital Equipment Corporation 130 Lytton Ave Palo Alto, CA 94301-1044 USA Tel: ++1 650 853 2227 Fax: ++1 650 853 2104 E-Mail: ludwig@pa.dec.comArticle: 8191
I am trying to implement a bridge in a 4013PQ208 using VHDL (Synopsys v3.4) and its interface XSI to Xilinx, the problem I have is: I do not know how to minimice the reset delay, and if there is a dedicated pin for that porpouse. Thanks in advance. please send answer to leomise@teleco.upv.esArticle: 8192
In article <65d88l$2j0$2@reader1.ftn.net>, Greg Smith <htimsg@passport.ca> writes (about metastability and related things...) >Well, if I couldn't avoid it, yes. I remember seeing a >'74something9074' >something which was a metastability-reduced 7474 device. Yup, it was a 74something5074 actually, from Philips/Signetics. I got data sheets a few years ago. The deal was that the '5074 could not stop metastable events, but it would respond to them without irrational behaviour, but only with an extended clock-to-output propagation delay. In this way you could guarantee to avoid the oscillatory behaviour sometimes seen on the outputs of FFs during a metastable event. For some reason it never caught on. Must be something to do with it having been a good idea.... -- Jonathan BromleyArticle: 8193
CALL FOR PAPERS
1998 International Symposium on Physical Design (ISPD-98)
April 6-8, 1998, Embassy Suites Hotel, Monterey, CA
Sponsored by ACM SIGDA in cooperation with
IEEE Circuits and Systems Society and IEEE Computer Society
The International Symposium on Physical Design provides a forum to exchange
ideas and promote research on critical areas related to the physical design
of VLSI systems. All aspects of physical design, from interactions with
behavior- and logic-level synthesis, to back-end performance analysis and
verification, are within the scope of the Symposium. Target domains include
semi-custom and full-custom IC, MCM and FPGA based systems. The ACM/SIGDA
Physical Design Workshop evolved into this Symposium last year and was very
well-attended. Following its six predecessors, the 1998 symposium will
highlight key new directions and leading-edge theoretical and experimental
contributions to the field. Accepted papers will be published by the ACM Press
in the Symposium proceedings. Topics of interest include but are not limited
to:
Management of design data and constraints
Interactions with behavior-level synthesis flows
Interactions with logic-level (re-)synthesis flows
Analysis and management of power dissipation
Techniques for high-performance design
Floorplanning and building-block assembly
Estimation and point-tool modeling
Partitioning, placement and routing
Special structures for clock, power, or test
Compaction and layout verification
Performance analysis and physical verification
Physical design for manufacturability and yield
Mixed-signal and system-level issues
Physical design in parallel, distributed and Web environments
IMPORTANT DATES: Submission deadline December 5, 1997
Acceptance notification January 26, 1998
Camera-ready paper due February 23, 1998
SUBMISSION OF PAPERS:
Authors should submit full-length, original, unpublished papers (maximum 20
pages double spaced) along with an abstract of at most 200 words and contact
author information (name, street/mailing address, telephone/fax, e-mail).
Previously published papers or papers submitted for publication to other
conferences/journals will not be considered. Electronic submission via
uuencoded e-mail is encouraged and is the preferred submission mode. Please
email a single postscript file, formatted for 8 1/2" x 11" paper, compressed
with Unix "compress" or "gzip" to
ispd98@cs.utexas.edu
Alternatively, you may send ten (10) hardcopies of the paper to:
Prof. D.F. Wong, Technical Program Chair, ISPD-98
University of Texas at Austin, Department of Computer Sciences,
Austin, TX 78712, USA
SYMPOSIUM INFORMATION:
To obtain information regarding the Symposium or to be added to the Symposium
mailing list, please send e-mail to ispd98@ee.iastate.edu. The ISPD web page
is at http://www.ee.iastate.edu/~ispd98
SYMPOSIUM ORGANIZATION:
General Chair: M. Sarrafzadeh (Northwestern)
Past Chair: A. Kahng (UCLA)
Steering Committee: J. Cohoon (Virginia), S. DasGupta (IBM),
M. Marek-Sadowska (UCSB), B. Preas (Xerox),
E. Yoffa (IBM)
Program Committee: M. Alexander (WA State) C.-K. Cheng (UCSD)
J. Cong (UCLA) W. Dai (UC Santa Cruz)
J. Fishburn (Lucent) D. D. Hill (Synopsys)
J. A. G. Jess (Eindhoven) L. Jones (Motorola)
S. Kang (Illinois) Y.-L. Lin (Tsing Hua)
M. Pedram (USC) R. Rutenbar (CMU)
C. Sechen (Washington) M. Wiesel (Intel)
D. F. Wong (Texas), Chair T. Yoshimura (NEC)
Publication Chair: D. D. Hill (Synopsys)
Panel Chair: N. Sherwani (Intel)
Local Chair: R.-S. Tsay (Axis Systems)
Publicity Chair: S. Sapatnekar (Minnesota)
Treasurer: S. Souvannavong
Article: 8194
Jonathan Bromley <jseb@oxim.demon.co.uk> wrote:
>Cooley's first-past-the-post hacking competition was good fun
>and instructive, but is not likely to win friends in the
>software engineering community; and all of us who use HDLs are
>going to need those friends, desperately, as our designs grow
>in complexity and the pressure to re-use them increases.
>--
>Jonathan Bromley
Jonathan, the reason why I had the Verilog vs. VHDL design contest was because,
at the time, there was a very serious shortage of hard data comparing the
two languages with respect to what hardware designers actually do in their
day-to-day design activities. Everywhere I turned, whether it be the trade
press or at an engineer's conference, where all sorts of very strong and
very conflicting messages about Verilog and VHDL -- and the more I looked at
these views, the more I found them tainted by Hidden Agendas. For EDA vendors,
if you were from Cadence or Chronologic, there was a very strong pro-Verilog
bias because these people made their living selling Verilog compilers. If
you worked at Synopsys, Mentor, Viewlogic, or any of the other non-Cadence,
non-Chronologic EDA companies, their was a strong pro-VHDL bias basically
because these people wanted to break Cadence & Chronologic's simulator
monopoly in the EDA industry. The vast majority of American ASIC designers
liked Verilog because they had used it for years, knew how to make it do what
they wanted it to do, and weren't all that interested in learning a new
language just to do what they already could do with Verilog. The cluttered
mix of European ASIC designers didn't have as much Verilog investment because
Cadence hadn't really penetrated that market that well. In addition, they
couldn't collectively agree on any one European HDL because of all sorts of
national politics (and for simular reasons they didn't want to default to
a popular American HDL), so they seemed to begrudgingly agree that VHDL
was their HDL of choice even though there were no commercially available
simulators for it at the time.
I knew I wasn't going to make friends by doing this competition; but, then
again, I wasn't looking for friends -- I was looking for hard data. That's
why I set up the contest and then just let it happen. This is also why I
closed the write-up of the contest with "You Be The Judge" and then ran a
summary of the 273 letters I got back from the contest write-up a few months
afterwards. Yea, I do have personal opinions about Verilog & VHDL. Most
engineers do. What I tried very hard to do was to suppress my personal
views and let the contest and subsequent user response settle this issue.
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 5459 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 8195
John Cooley <jcooley@world.std.com> wrote:
>
> Trolling For DAC Dirt 6 Months Later
> ------------------------------------
>
> Suffering from great gobs of guilt at having not written a review
> of this year's DAC'97 in Anaheim, CA (especially after having had
> surveyed the users & vendors about their impressions of DAC'97), I'm
> writing a "penance" DAC Review over the Thanksgiving week.
>
> I already have all those e-mails from my first post-DAC'97 survey
> (and there's still quite a bit of useful info in them!), but, with it
> being 6 months later, I'd like to add a new twist. Now that 6 months
> have passed, please write me what you thought (and, yes, you'll be
> anonymous) about what you saw at DAC'97 & *whether it panned out now*.
>
> Did you see/buy something that appeared "hot" at DAC'97 only to find
> it a complete waste of time? What turned out to be the biggest lie
> you got from an EDA vendor at DAC'97 from your subsequent 6 months
> post-DAC'97 experience? It being 6 months later, what actually turned
> out to be the most useful thing/topic/tool/technique you got from
> DAC '97 or elsewhere? How about the big guys like Cadence, Mentor,
> Synopsys, Avanti? How about the many small EDA companies? Feel free
> to include all sorts of news & facts & opinions about what happened in
> the last 6 months in the EDA industry to support your views/conclusions!
I just wanted to drop a quick note to ESNUG readers to wish you a happy
Thanksgiving and to hope your family gatherings go well. I'm heading off
to a very small town in Vermont to see my folks. And even though I
originally said I'm going to write-up my 6-Months-After-DAC'97 DAC Review
over Thanksgiving, I've decided to put off writing it until the Tuesday
*after* Thanksgiving. (I just want to spend more time with my folks than
with a computer over Turkey Day break. In addition, the e-mails I recieved
for this review have been quite an eye opener for me. Whoa! These
insights taken 6 months afterwards have been, ...well..., pretty damn
insightful! -- and it's gunna be a hell of a lot of work compiling them.)
ANYWAY, why I'm saying all this isn't to get permission to be with my
folks over Thanksgiving (not hardly!) but to tell those last minute survey
responders that they now have until the Monday night after Thanksgiving to
share their views/insights/opinions for the "DAC'97 & Afterwards Review."
God bless, and I hope your holiday goes well.
- John Cooley
the ESNUG guy
-----------------------------------------------------------------------------
__)) "Glass ceilings? Name ANY ex-goat farmer who's made management!"
/_ oo
(_ \ Holliston Poor Farm - John Cooley
%// \" Holliston, MA 01746-6222 part time Sheep & ex-Goat Farmer
%%% $ jcooley@world.std.com full time contract ASIC & FPGA Designer
Article: 8196In article <347b51d8.231064002@cnn.exu>, Jason T. Wright <Jason.Wright@ebu.ericsson.com> wrote: >On Mon, 24 Nov 1997 23:25:18 +0100, Tobias Hilpert <thilpert@osc.de> >wrote: > >>Hello, >> >>I'm a student working on a FPGA-based module for image preprocessing on >>a framegrabber (module: two XC4013E-2 both serial master configured + 4 >>synchronous SRAM's 128kx8). >> >>For FPGA configuration I wanted to use ATMEL AT17C256 EEPROMS (for >>in-system-programmability the AT17C256 data output and some other pin's >>run through a multiplexer 74AC157; I used the circuitry described in the >>ATMEL data sheet p.3-29). Unfortunately, the configuration process >>doesn't finish correctly !!! I tried to change some pull-up/down >>resistors without solving the problem :( . I also substituted the ATMEL >>by the original Xilinx PROM and wonder: no config problems occurred (-> >>there are no circuitry errors). >>Some other students are using ATMEL AT17C128 devices for smaller XILINX >>FPGA's without any problems. >> Yes, thats what I was going to say, that the RESET/OE_ pin of the ATMEL defaults to the opposite polarity of the Xilinx FPGA. Your prom burner should have some options under its program menu for switching this polarity. Otherwise, I too haven't done any in-circuit programming with the ATMEL parts. - John -- John ArchambeaultArticle: 8197
Philips offers a free demo CD which has has pretty good software for the 32 macrocell Coolpld parts. Check out http://www.coolpld.com/ Unusually for the industry, they appear to want people to try (and buy) their parts without being inhibited by having to pay a "token" few hundred or thousand dollars for the privilege. regards, tom Adam Seychell wrote: > > Which manufacture of PGAs would make it possible for the hobbyist to > use this technology. Obviously the manufactures are mainly interested > in the big customers and so charge big bucks for their development > products. So far I've investigated Lattice, Altera & Xilinx and they > all have unrealistic prices for their design software. The cost of the (had to snip the rest)Article: 8198
Hi Guys! Recently i've read the dissertation of Andreas Koch, "Regular Datapaths on Field-Programmable Gate Arrays" which has some interesting facts about advanced floor-planning algorithms. The dissertation is located at: http://www.cs.tu-bs.de/eis/pdf/koch-thesis.pdf Does anybody know where to find the sources of their floor-planning program which they have used for comparision to the xlinix-ppr tool. Or does anybody else is working on implementations of advanced floor- planning algorithms ? Any help ? Thanks in Advance. Dirk DannhaeuserArticle: 8199
I am doing a research on FPGAs but I don't know anything about them. Can
anyone help me please.
Please reply to my mailing address directly.
Regards,
Ahmed Hassan
a.h.hussien@ieee.org
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