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
zeev@cadence.com (Zeev Yelin) wrote: >In article <4fqs7k$2tn@hacgate2.hac.com>, Lance Gin <c43lyg@dso.hac.com> wrote: > > >> >Just for the record, we're using the A3F release and XACT 5.1.1 on >> >Sun Solaris 2.5. Generally, once bashed into shape by my mate vi ;-) >> >the system works well. >> >I was told by Xilinx they are not yet ported to Solaris, and yet you tell >us casually on working on Solaris 2.5 !!! amazing. >how stable it is ? Share with us Lance. >thx >Zeev > >-- >Zeev Yelin, Cadence Design Systems(Israel) > hi zeev, i'm afraid you'll have to ask les hughes (l.j.hughes@greenwich.ac.uk) who made the comment which i quoted and you inadvertantly attributed to me. as for myself, i'm looking at an HP-UX or PC version of XACT. regards, -- ____________________________________________________________________________ Lance Gin "off the keyboard Delco Systems - GM Hughes Electronics over the bridge, OFC: 805.961.7737 FAX: 805.961.7329 through the gateway, C43LYG@dso.hac.com nothing but NET!" ____________________________________________________________________________Article: 2901
Peter Fenn writes... >We have recently purchased AT17C128 Serial PROMS to replace Xilinx >configuration PROMs, but do not have any apparent means to program these >new devices. > The EEPROM devices are supported by most 3rd party programmer companies - a copy of supported manufactures is available from Atmel's Fax-on-Demand (1-800-29-ATMEL) - document #663. >I have downloaded Atmels CONFIGURATOR application note describing the >programming spec, which now prompts me to ask the question "Is there not >a piece of programming software already already out there somewhere >that'll save me some time?" Atmel makes a simple programming board (ATDH2200 - $250) that plugs into the parallel port on any X86 PC and allows you to program the AT17Cxxx family of parts. It comes with the s/w you describe to read/write/verify the Atmel re-programmable serial configuration proms. The input data can come from a 17Cxxx device (which can be read from the board) or one of several industry standard file formats. I hope this helps - If you would like more information send me an e-mail with your snail-mail address or visit the Atmel home page http://www.atmel.com Regards Martin Mason ------------------------------------------------------------------------- | Martin Mason | Snr FPGA/17Cxxx Applications Engineer | | Atmel Corp. | (Work) martin@atmel.com | | 2125 O'Nel Drive | (Work2) fpga@atmel.com | | San Jose | (Fax) + (408) 436 4300 | | CA 95131 | (Tele) + (408) 436 4178 | ------------------------------------------------------------------------- | Visit http://www.atmel.com | 'kewl' thinks Martin, The Net Dude :] | -------------------------------------------------------------------------Article: 2902
Lance Gin wrote:
<..snippity snip...>
>
> >3/ Xilinx recommend XBlox. XBlocks models don't have timing characteristics.
>
> are you referring to models for use by the XACT XDELAY static TA tool?
> or perhaps you're referring to QuickPath? does xilinx have any plans to
> supply the models you need?
>From what I understand about this, the actual delays are route specific ie you only
get'em once you've apr'ed....
>
> >4/ TimSim8 (backannotation of routed design timing to "Schematic") does not modify
> >the source schematic (EDDM database) via a viewpoint. It generates another design
> >database in a separate directory. This presents a rather serious configuration
> >control problem.
>
Can't comment for other os /rels but A3F & 5.1.1 there's an option on the FNCSIM8 & TIMSIM8
forms that allow you to back-ann. the original schematic or generate a new one.
>
> >5/ An EDIF read licence is required, at the unreasonable price of ~£2000.
>
> how is this used in the mentor/XACT flow?
Mentor > edif > Xilinx XNF > edif > mentor
>
> >6/ XNFBA still does not work.
>
> we're new to the xilinx world. what's XNFBA?
I had to hack the /bin/sh scripts to get this to work.....
Bye,
Les.
--
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Les Hughes - Applications Group
Computing Services | Phone/Fax: +44 (0)181 331 8390 / 8566
University of Greenwich |
Woolwich, London SE18 6PF | E-Mail: L.J.Hughes@greenwich.ac.uk
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"I'm applying intelligence and observation to the situation..."
- Murray Walker
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Article: 2903I build a little programmer board (PC-parallel port) and wrote a small basic programm to burn these from a S1-S9 hex file (makeprom -f exo, in XACT) on a PC. Check out : ftp://ftp.cs.indiana.edu/pub/goo/eeprg We use this programmer to burn XC3000 config. proms. for our stiquito controller (http://www.cs.indiana.edu/robotics/colony.html). The software does not support changing the RESET/OE# polarity, but it shouldn't be hard to add. Let me know if you have problems... See ya, -ingo In article <4gre26$pv5@aztec.co.za>, Peter Fenn <peterf@electrosolv.co.za> wrote: >We have recently purchased AT17C128 Serial PROMS to replace Xilinx configuration >PROMs, but do not have any apparent means to program these new devices. > >I have downloaded Atmels CONFIGURATOR application note describing the programming >spec, which now prompts me to ask the question "Is there not a piece of programming >software already already out there somewhere that'll save me some time?" > >I imagine the serial bus protocol could be implemented relatively simply using a >couple've pins on a PC's parallel port interface... >-Is there such a program at a FTP site somewhere? > >Thanks in adavance. > >Regards > > >PETER FENN > >**************************************************** >* ____ ______________ * >* E L E C T R O | \ ELECTROSOLV cc * >* ==============| \ * >* | )======= ELECTRONICS * >* ==============| / S O L V & SOFTWARE * >* |___/ DESIGN GROUP * >* * >**************************************************** > > > -- /* Ingo Cyliax, cyliax@cs.indiana.edu, +1 812 333 4854, +1 812 855 6984 (day) */Article: 2904
Steve Casselman (sc@vcc.com) wrote: : VHDL and verilog are out since they are only : 2D (you can specify timing but you end up with a time wise flat : design)... <stuff deleted> : High level languages like C and fortran are naturally "time aware." : Steve Casselman : Virtual Computer Corporation Steve, Hunh? I'm not going to say that Verilog/VHDL are THE languages for configurable computing, but I think that I can boldly say, anything you can do in "C" I can do in Verilog better (with a couple of caveats, see below). First, Verilog/VHDL have all that's necessary to describe any algorithm that you could describe in C, at the same level of abstraction. Your Fibonacci number generator in C has four lines, my Verilog description has pretty much the same four lines. Second, unlike C, Verilog and VHDL were designed to be parallel languages. Third, Verilog and VHDL are much more "time aware", or maybe "time acknowledging" than C and Fortran. The big bugger limitation with Verilog that it is a real pain to describe mathematical functions that aren't unsigned two's complement. What if I want to do signed-magnitude, or signed-two's complement? You can't use the "*" or "+" and do that. I guess VHDL is more capable of that, but I staked my tent on the Verilog side of that war too long ago to change now. Of course, there are zillions of people who, when they have a clever idea for an application, start doodling C code on the back of envelopes. We can't ignore this installed base of brains and think they're all going become Verilog/VHDL hackers. But the big bugger problem with "C" is that its types are CPU machine types. You have to do everything with 32 bit integers, characters, and single and double precision floating point. That's a big deal for configurable computing because a lot of the win in FPGAs come when the types of data in the algorithm don't match the types in the available CPUs. Anybody who's written bit-oriented computations in C knows what a pain that can be. What's the solution? We've been playing with the idea that you use some syntactic sugar from C++ to solve the type problem with C. Create classes that simulate, using standard types like ints and chars, the behavior of a wide variety of data types. You can use operator overriding so designers can still say "a + b" even when a and b are 13 bit, fixed point, signed-magnitude numbers. The C++ compiler can be used to debug the procedure. The parser for the hardware compiler has to be a little more sophisticated and pick out those classes, and substitute the right hardware to implement those operations (ignoring how the underlying class implementation works.) Herman ------------------------------------------------ Herman Schmit, Research Engineer Department of Electical and Computer Engineering Carnegie Mellon University 5000 Forbes Ave. Pittsburgh PA 15213 Tel: (412) 268-6642 email: herman@ece.cmu.eduArticle: 2905
>>>>> "HS" == Herman Schmit <herman@galant.ece.cmu.edu> writes:
In article <4gv81c$802@fs7.ece.cmu.edu> herman@galant.ece.cmu.edu (Herman Schmit) writes:
HS> Steve Casselman (sc@vcc.com) wrote:
HS> : VHDL and verilog are out since they are only : 2D (you can
HS> specify timing but you end up with a time wise flat :
HS> design)...
HS> : High level languages like C and fortran are naturally "time
HS> aware."
HS> : Steve Casselman : Virtual Computer Corporation
HS> Steve,
HS> Hunh?
I also say, Huhhhh?
HS> I'm not going to say that Verilog/VHDL are THE languages for
HS> configurable computing, but I think that I can boldly say,
HS> anything you can do in "C" I can do in Verilog better (with a
HS> couple of caveats, see below). First, Verilog/VHDL have all
Here, here. While I am not advocating VHDL/Verilog as reconfigurable
computing languages, they support concurrency and C does not. That
makes them much more appropriate from a "time-awareness" point of
view. Configurable computing systems need to be programmed with
*parallel* programming languages (this is true for other computers, as
well. --oops, there goes my unbiased opinion :-)).
Steve may have been making a different point though, see below.
HS> The big bugger limitation with Verilog that it is a real pain
HS> to describe mathematical functions that aren't unsigned two's
HS> complement. What if I want to do signed-magnitude, or
HS> signed-two's complement? You can't use the "*" or "+" and do
HS> that. I guess VHDL is more capable of that, but I staked my
HS> tent on the Verilog side of that war too long ago to change
HS> now.
This can be done in VHDL with overloading. This is where the data
abstraction in VHDL can come in quite handy. Unfortunately, VHDL is
almost as verbose as COBOL. Not quite, but close. And, yes, I must
admit that I actually wrote a little COBOL years ago :-P. That
certainly looks wierd on my resume, I suppose. COBOL/Univac 11-08 and
VHDL synthesis. But I digress...
HS> hackers. But the big bugger problem with "C" is that its
HS> types are CPU machine types. You have to do everything with
HS> 32 bit integers, characters, and single and double precision
HS> floating point. That's a big deal for configurable computing
HS> because a lot of the win in FPGAs come when the types of data
HS> in the algorithm don't match the types in the available CPUs.
HS> Anybody who's written bit-oriented computations in C knows
HS> what a pain that can be.
Before VHDL was around I wrote quite a bit of bit-oriented stuff in C
and C++. What a pain that was. It was also quite slow. Now, I use
VHDL for that sort of stuff and it is great for describing bit-level
ops, systolic stuff, etc. Don't make me go back to C for hardware
description/simulation, pleeeaaaaaaseeeeee... :-)
HS> What's the solution? We've been playing with the idea that
HS> you use some syntactic sugar from C++ to solve the type
HS> problem with C. Create classes that simulate, using standard
HS> types like ints and chars, the behavior of a wide variety of
HS> data types. You can use operator overriding so designers can
If I understand your approach, this is similar to the DEC PRL stuff
and I think a number of other people have also advocated similar
approaches. How do you really simulate this without writing your own
event-driven simulator? A functional event-driven simulator is not a
big deal but it seems that you would need something along those lines,
right?. You are still dealing with a non-concurrent language, so how
do you simulate a general concurrent description? Overall, I think
that it is a reasonable approach. It has worked for a number of
people. And besides, who *simulates* FPGA designs, anyway? :-)
BTW, There *is* a problem with the specification of VHDL for RTR
(run-time reconfigurable) systems. VHDL is statically linked (well,
elaborated, anyway). There is no elegant way to describe hardware that
will be paged in at run-time with VHDL. Here at BYU we work on
systems that are demand-paged. That is, the FPGA hardware does not
know beforehand what circuit modules will be loaded. That is a
function of the application software and the data set. However, if
you wanted to describe such a system in VHDL, you would need to
enumerate all modules that *may* be loaded so that the entire system
can be elaborated prior to simulation (every circuit module would need
to be included in the elaboration step). One work-around is to
generate a new VHDL model from the software part of the application
that incorporates only those circuit modules that are referenced in
the software. This is still painful though. Dynamic linking may be of
some use (similar to what conventional linkers can do) --it could
resolve function calls to hardware at link time. Even this is
overkill, I suppose. Just because a module is referenced in the
software does not mean it will be loaded at run-time (it may be data
dependent). At any rate, the static elaboration of VHDL is what makes
it a bad fit for demand-paged hardware. Note that serial languages such
as C or C++ don't help either. The demand-paged approach really cries
out for a language with some form of lazy evaluation. Let me see,
lazy evaluation, parallel programming, hmmm, starts sounding like
a functional programming language. :-)
One final thing I wanted to ask was, why does VHDL (and even Verilog),
in general, get such a bad rap? Again, I'm not saying they are the
be-all, end-all of configurable computing languages, but they can be
quite effective under the right circumstances. And, my own experience
with the relative efficiency is that VHDL synthesis does a decent job.
Yeah, I know it is expensive and many cannot afford it. But, ignoring
the cost issue (which I think will be solved over time), VHDL works
surprisingly well for the things that I do. So, why do people seem to
dislike it so much?
Article: 2906How is Atmel doing it? I haven't had time to try out their latest "cache logic". Any takers out there. I got chased out of a meeting for suggesting such a thing:-).Article: 2907
In article <Dn8oyo.8L@seqp4.sequoia.com>, budwey@sequoia.com (Mike Budwey) wrote: > If a bus spec REQUIRES that data not change for 3ns (for example) after > the clock, I would call that a hold time. Why the bus spec may even > refer to it as t(DH)! > I was first addressing a semantic problem: We should distinguish between output DELAYS, be they max or min, and input REQUIREMENTS, and we should not use the same word for both. But that's just a tutorial comment. I am also the one who has been arguing for 25 years that set-up and hold-time requirements be called max parameters in the device data sheets ( not min). There is something to be said for logic clarity. But it's just semantics. Let's talk physics: When an IC manufacturer designs a chip that guarantees a worst-case delay over the operating range of less than 10 ns, it is extremely difficult to guarantee a min value of more than 2 ns, guaranteed over the operating range, and valid even after one or two generations of process improvements, when the "typical" delay has come down from 6 ns to 3 ns. ICs are getting faster, and everybody is happy about the shorter delays, but the min delays are also getting shorter. There is no free lunch. If the system designer cannot avoid external uncontrolled clock skew, then the only solution in the long run may be external deliberate and controlled clock skew between the driving clock and the receiving clock. Peter AlfkeArticle: 2908
Brad Taylor <blt@emf.net> wrote: > > If however, one needs floating point trancendental functions, divides, > atan2 or other complex functions, they can run more efficiently on an > FPGA by using the cordic algorithm. This creates 1 bit per clock > and can be pipelined to create a complete result every clock. I'd like > to see a DSP that could do 50 million atan()s per second. The precision of CORDIC vs iteration is not fixed at one bit, it depends on the algorithm. For example, vector magnitude gains 2 bits of accuracy for each iteration and the Log gains less than a bit. I presented a paper that highlighted a CORDIC vector magnitude processor in an FPGA at design SuperCOn '96. That paper is available on-line at my web site (http://www.ids.net/~randraka/) > > It must be noted however that real world problems can usually be > implemented without floats. The ecomomic advantage of 10-100 x > performance advantage might impel one to implement a solution as integer > math and to do the precision analysis. > This is certainly true. I've yet to see a DSP application that can't be solved using fixed point arithmetic and careful accounting of the precision. In some cases a block floating point scheme (where a whole block of data has the same exponent) can be used to increase the dynamic range with minimal effect on the hardware. Point is, there's very little that can't be done with fixed point and some thought. Looked at in the extreme, IEEE floating point is really 23 bit fixed point with an exponent. BTW Floating point brings its own set of problems regarding precision. > > > Also I supect that floats using bit serial math are relatively efficient. > Has anyone checked this out? It can be done, but in most cases is not worth the effort and in fact often would degrade the overall performance! > -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 mailto:randraka@ids.net http://www.ids.net/~randraka/ The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs. Services include complete design, development, simulation, and integration of these devices and the surrounding circuits. We also evaluate,troubleshoot, and improve existing designs. Please call or write for a free brochure.Article: 2909
Peter Alfke (peter@xilinx.com) wrote: : In article <Dn3uCy.25v@icon.rose.hp.com>, tak@core.rose.hp.com (Tom : Keaveny) wrote: : : > Note, that there are a number of "synchronous" bus spec's that mandate : > a non-zero hold time. : : Please let me suggest a more careful noemnclature: : : "Hold-time" is not an OUTPUT characteristic, : Semantics aside, busses like PCI, and processors such as the Intel 80960SB require at least 2 nsecs of hold time for input signals that they sample. If a PLD or FPGA is supplying the output drive signal, in these cases, they must have a minimum clock to output delay of 2 nsecs or more. Clock skew effects could increase the minimum delay requirement, depending upon layout and routing. It should be noted, that there are other ASICs that have even more severe hold time requirements for their inputs, and thus on minimum output delay for their input sources. If a designer has "0" or "nil" as a minimum output delay for a PLD or FPGA, the interface to these non-zero hold time ASICs can get quite messy (or the designer ignores the hold time spec and risks incorrect operation). As I mentioned previously in this thread, the two typical interface options are to: - add delay buffers to all output signals - use separate drive and receive clock edges The first alternative can consume significant power and space for datapath applications, and may not be feasible due to maximum output delay vs. input setup time considerations. The second alternative usually requires a circuit to effectively operate at 2-2.5 times its nominal operating frequency, and may have difficulty meeting the target input setup time spec as clock rates increase. Because of these factors, I still prefer to have minimum hold-time specifications to work with. == Tom Keaveny Hewlett Packard Co. "opinions are my own and not necessarily that of Hewlett Packard Co."Article: 2910
**** ANNOUNCEMENT **** IMMEDIATE RELEASE: 27th February 1996 Ringwood, UK DOULOS announce the launch of a Web Site designed for the VHDL and Verilog user. This Web site is an information channel to help the engineer in using High Level Design and synthesis technology. _______________ Check this out: _______________ for the engineer *new* to VHDL there's the DOULOS FAQ and the free PACEMAKER tutorial for the *regular* user there's the Tip of the Month and the Model of the Month for the *experienced* VHDL designer there's the Advanced VHDL Techniques section for ease of use and re-use there's the hierarchical index and the chronological Table of Contents Tim Pagden, Doulos specialist and the Web site designer, said "We wanted to provide a Web site that would be a wealth of real practical design-related information for HDL users as well as being a shop window for our own products and services." THIS MONTH on http://www.doulos.co.uk _________________________________________________________________________ ***TIP OF THE MONTH*** << A DISCUSSION OF A STRUCTURED APPROACH TO CODING SEQUENTIAL LOGIC FUNCTIONALITY IN PROCESSES >> plus << THE WRITING OF VHDL CODE FOR OPTIMAL SYNTHESIS >> ___________________________________________________________________________ ***MODEL OF THE MONTH*** describes how to design large memory blocks in VHDL, without being compromised by system virtual memory limits. ____________________________________________________________________________ DOULOS, Church Hatch, 22 Market Place, Ringwood BH24 1AW, Hampshire, UK Tel: +44 1425 471 223 Fax: +44 1425 471 573 Email: info@doulos.co.uk Web: http://www.doulos.co.ukArticle: 2911
Is there a netlist converter from Viewlogic WIR or Xilinx XNF from/to the SLIF or BLIF formats used by SIS? I have looked into eqn2xnf, but it's too limited for real circuits (no latches). Any hints are appreciated! - Andreas Koch -- Andreas Koch * PGP key on request * Email : koch@eis.cs.tu-bs.de Institut f"ur theoretische Informatik Phone : x49-531-391-2384 Abteilung Entwurf integrierter Schaltungen Phax : x49-531-391-5840 Gaussstr. 11, D-38106 Braunschweig, Germany Telex : 95 25 26Article: 2912
Peter Alfke (peter@xilinx.com) wrote: : In article <Dn8oyo.8L@seqp4.sequoia.com>, budwey@sequoia.com (Mike Budwey) : wrote: : > If a bus spec REQUIRES that data not change for 3ns (for example) after : > the clock, I would call that a hold time. Why the bus spec may even : > refer to it as t(DH)! : > : I was first addressing a semantic problem: We should distinguish between : output DELAYS, be they max or min, and input REQUIREMENTS, and we should : not use the same word for both. But that's just a tutorial comment. I am : also the one who has been arguing for 25 years that set-up and hold-time : requirements be called max parameters in the device data sheets ( not : min). There is something to be said for logic clarity. But it's just : semantics. Whether you call it a max or a min depends upon your perspective. What most data sheets are trying to say is "the user must guarantee that input data remains unchanged for a minimum time after the clock edge." Therefore, it's called a minimum hold time. It sounds like your perspective is more along the lines of "for this device to work in my system it cannot require data to remain for more than 3ns after the clock edge. That phrasing sounds more like a maximum hold time. Personally, I find it easier to relate to the first case, but I can understand the confusion. : Let's talk physics: : When an IC manufacturer designs a chip that guarantees a worst-case delay : over the operating range of less than 10 ns, it is extremely difficult to : guarantee a min value of more than 2 ns, guaranteed over the operating : range, and valid even after one or two generations of process : improvements, when the "typical" delay has come down from 6 ns to 3 ns. : ICs are getting faster, and everybody is happy about the shorter delays, : but the min delays are also getting shorter. There is no free lunch. : If the system designer cannot avoid external uncontrolled clock skew, then : the only solution in the long run may be external deliberate and : controlled clock skew between the driving clock and the receiving clock. Sure, but suppose all manufacturers specified parts with no minumum delay. It sure would be difficult to generate that external deliberate clock skew. Buffers couldn't be used to create skew or delay the output. One would require delay lines, programmable skew PLL clock generators, or multiphase clocks. Oh well, nobody (except the vendors) ever said it was going to be easy. Mike Budwey budwey@sequoia.comArticle: 2913
Tom Keaveny (tak@core.rose.hp.com) wrote: < stuff deleted > : It should be noted, that there are other ASICs that have even : more severe hold time requirements for their inputs, and thus on minimum : output delay for their input sources. : If a designer has "0" or "nil" as a minimum output delay for : a PLD or FPGA, the interface to these non-zero hold time ASICs can get : quite messy (or the designer ignores the hold time spec and risks : incorrect operation). As I mentioned previously in this thread, the : two typical interface options are to: : - add delay buffers to all output signals : - use separate drive and receive clock edges : The first alternative can consume significant power and space for : datapath applications, and may not be feasible due to maximum output delay : vs. input setup time considerations. It also requires you to find a vendor that will sell you a buffer with a guaranteed minimum delay! Hmmm, isn't this where we started? :-) : The second alternative usually requires a circuit to effectively operate : at 2-2.5 times its nominal operating frequency, and may have difficulty : meeting the target input setup time spec as clock rates increase. : Because of these factors, I still prefer to have minimum hold-time : specifications to work with. : Agreed. Mike Budwey budwey@sequoia.comArticle: 2914
> : High level languages like C and fortran are naturally "time aware." > > : Steve Casselman > : Virtual Computer Corporation > > Steve, > > Hunh? > > I'm not going to say that Verilog/VHDL are THE languages for > configurable computing, but I think that I can boldly say, anything > you can do in "C" I can do in Verilog better (with a couple of > Third, Verilog and VHDL are much more "time aware", or maybe "time > acknowledging" than C and Fortran. When I say "time aware" I don't mean "timing aware" I mean in standard HLLs first you do one subroutine then you do another. You bring in your program from the outside world and you execute it over a period of time. If I write a million lines of HLL I can execute it. In HDLs if I write a million lines of code I end up with one big part. With HLLs I time share a piece of hardware with HDLs I create a design that has to exist at the same time. > > The big bugger limitation with Verilog that it is a real pain to > describe mathematical functions that aren't unsigned two's complement. HDLs describe hardware HLLs describe algorithms. > > Of course, there are zillions of people who, when they have a clever > idea for an application, start doodling C code on the back of > envelopes. We can't ignore this installed base of brains and think > they're all going become Verilog/VHDL hackers. But the big bugger > problem with "C" is that its types are CPU machine types. You have to > do everything with 32 bit integers, characters, and single and double > precision floating point. That's a big deal for configurable > computing because a lot of the win in FPGAs come when the types of > data in the algorithm don't match the types in the available CPUs. > Anybody who's written bit-oriented computations in C knows what a pain > that can be. This is why I'd like to see C have a bit vector. bit my_varible[11];/* would be a 12 bit varible*/ > > What's the solution? We've been playing with the idea that you use > some syntactic sugar from C++ to solve the type problem with C. I see just the flip side. We take "syntactic sugar" HDLs and put them in C/C++. HLL need to be more "timing aware". If we came up with thing that could be add to HLLs that even HLL writer would want then everyone would writing code the would fit the reconfigurable model. I think every C writer would love to have a bit vector construct. We might even be able to get some things like this in acutal C standard. If we added a wait() and do wait() to C this would help MPP writer also. Steve CasselmanArticle: 2915
I have synthesized a PCI master and target (both VHDL and Verilog) for AT&T's ORCA FPGA and designed a working adapter card. I have also synthesized the models to XILINX's 4000E part and am currently trying to get it to run at speed. Has anyone else been able to get a XILINX master to run in a PCI motherboard? We sell PCI models and are trying to get them to run in as many FPGAs as possible. Charles Kaseff, Logic Innovations <ckaseff@logici.com> David Emrich <emrich@exemplar.com> wrote: >I would like to hear from people who have synthesized PCI models to >FPGAs. >======================================================================== >David Emrich Exemplar Logic, Inc. >emrich@exemplar.com 815 Atlantic Ave., Suite 105 > Alameda, CA 94501-2274 > USA >========================================================================Article: 2916
Has anyone out there ever tried to use Zycad's GF100K FPGA's. I have a feature list and short description on the family, but I really need to know how well the parts work and are they really as fast as Zycad claims? I'm looking for a fast, large, and reliable FPGA for pre-ASIC chip development. If anyone has any experience with them, please send me an e-mail at jennifer.pencis@amd.comArticle: 2917
Peter Alfke wrote:
>
> Let's talk physics:
>
> When an IC manufacturer designs a chip that guarantees a worst-case delay
> over the operating range of less than 10 ns, it is extremely difficult to
> guarantee a min value of more than 2 ns, guaranteed over the operating
> range, and valid even after one or two generations of process
> improvements, when the "typical" delay has come down from 6 ns to 3 ns.
> ICs are getting faster, and everybody is happy about the shorter delays,
> but the min delays are also getting shorter. There is no free lunch.
> If the system designer cannot avoid external uncontrolled clock skew, then
> the only solution in the long run may be external deliberate and
> controlled clock skew between the driving clock and the receiving clock.
>
> Peter Alfke
Not being an IC designer, I might be going out on a limb, but I would
say that it must be possible for a chip manufacture to guarantee
something like 3ns min delaye. For instance, PPR can set bits to adjust
the clock delay. If the fab shrinks, the delay can be maintained.
I'm not saying that 3ns hold time is necessarily required, just that a
consistant delay is possible if any one cared.
Without using hold time, I can't design legally with Xilinx FPGAs.
Xilinx E series data sheets now says that pins have 7ns set up and
0ns hold required. If I assume 0 ns min delay and I have .5ns clock skew
between parts (the best I can do using matched line lengths and clock
drivers), then I miss the time spec. As designers we assume certain
things are going to be legal. These include chip to chip communication,
using a common clock and on chip communication between registers.
Without a min delay, how do I guarantee that I can clock data between
two registers on chip since I know I will have a finite amount of
clock skew?
Currently I just assume that Xilinx chips will not fail in this fashion.
Brad Taylor
/==============<>==============\
| Brad Taylor |
| email home - blt@emf.net |
| voice home -(510) 601-5408 |
| fax home -(510) 601-5256 |
| |
\==============<>==============/
Article: 2918
Hello!!
I'm a student of VLSI-Design Automation Lab of
Pusan National University, Korea.
While researching a Logic emulator Tool with Xilinx Tool(XACT),
I encounter problems. So I want your advice.
For reference, my studying process is that.
step 1) Flow Schematics with WORKVIEWs
step 2) Create BIT file for each schematic using makebits.
step 3) Translate each bit file to a merging mcs file
using makeprom.
step 4) Download the mcs file into multiple XC4000 series chips,
in slave serial mode using Xchecker downloading cable.
The problem is the followings.
I had tried to download multiple chips by daisy-chain method.
but after downloading, I checked the chips and I found only a lead chip
was downloaded successfully.
I want to know that my method is correct or not .
Specially, I want to know each bit file merging for daisy-chained
multiple downloading.
Is its method using makeprom ?
Also,Do it load up from 0000 respectively in makeprom ?
Otherwise, Is promblem pin connection for multiple downloading ?
In my thought, each pin connection is correct.
The following are my board's configuration pin connection.
1. DONE signal connection
XCHECKER DOWNLOAD CABLE PIN
+--------------+
| DONE |
+--------+-----+
|
+------------+
| |
+--------+-------+ | +--------------+
| | | | |
| | | | |
| CHIP 1 | | | CHIP 2 |
| | | | |
| DONE | | | | ...
+-------------+--+ | +--------------+
| |
+-------+
2. INIT signal connection
+--------------+
| INIT |
+--------+-----+
|
+------------+
| |
+--------+-------+ | +--------------+
| | | | |
| | | | |
| | | | |
| | | | |
| INIT | | | | ...
+-------------+--+ | +--------------+
| |
+-------+
3. PROG signal connection
+--------------+
| PROG |
+--------+-----+
|
+------------+-------------------------+
| | |
+--------+-------+ | +--------------+ |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| PROG +----+ | PROG +---+ ...
+----------------+ +--------------+
I have used only four XC4005-6 PC84C chips.
I have been troubled by this problem for long time.
Please, your advise about this porblem.
Specially,Have you exprienced that Daisy-chained multiple downloading
using Xilinx 4000 series is performed successfully?
If so, please contact me and tell me your method.
Your advice will be greatly helpful to me.
Article: 2919A truly useful language for a reconfigurable computer should also be one that many potential users are already familiar with or provides little resistence to learn/apply. Thus, the ability to use C or C++ would provide an advantage over VHDL/Verilog. As part of our parallel programming research, we are developing a high level language (HLL) source code converter to an acyclic directed graph representation. Current HLLs include C, C++, and F77. The directed graph explicitly identifies inherent parallelism in the source code/algorithm and identifies all computational units required in a time-ordered fashion. To take advantage of FPGA implementation efficiencies such as fixed bit-size or bit-oriented operations, new types or classes could be defined in the C++ code and captured in the graph representation. Additionally, we can extend the C++ language for reconfigurable computer programming and add these language features to our C++ grammar. Let me hear your opinion. Rich rblazarus@tasc.comArticle: 2920
Where can I find the JEDEC Specification? ================================================= Disclaimer: My comments are not necessarily the opinion of my employer, myself, or anyone else. ------------------------------------------------- Peter Becker peb@trsvr.tr.unisys.com =================================================Article: 2921
Richard Lazarus <rblazarus@tasc.com> wrote: >A truly useful language for a reconfigurable computer should also be one >that many potential users are already familiar with or provides little >resistence to learn/apply. Thus, the ability to use C or C++ would >provide an advantage over VHDL/Verilog. >As part of our parallel programming research, we are developing a high >level language (HLL) source code converter to an acyclic directed graph >representation. Current HLLs include C, C++, and F77. The directed graph >explicitly identifies inherent parallelism in the source code/algorithm >and identifies all computational units required in a time-ordered >fashion. So, rather than use either of the two popular multi-threaded programming languages (VHDL and Verilog) for implementing your structure, you defined your own new extensions to a single-threaded language, and then develop a totally new set of compilers, debuggers, etc. etc. It took me 2 hours to teach VHDL theory (not all syntax, but the theory) to a group of industry programmers. Once you say it's a strongly-typed, multithreaded, concurrent programming language, they go "Oh, why didn't anybody say so?" and then it's just some new syntax that they have to learn. I think that this approach will generate much better results much faster than your approach. I'm not trying to slam you; it's just that if you're capable of tackling what you've proposed, you're smart enough that I want to see your efforts focused in the most productive way. I expect to be doing reconfigurable computing in a couple of years, and I want to see it have the best possible tools/languags it can. Regards, Erik JessenArticle: 2922
Space left for reflector people:) I've had talks about the newsgroup comp.arch.fpga (computer architectures based on fpgas) about all this talk about PLDs, converting fpgas into asics, antifuse parts and such. The above subjects do not belong in this news group! But we realize there is no other place for these people to go. So I think we should start a new news group called something like lsi.fpga or whatever would someone who knows how please try and give these people a home! I would vote for it! I'm sure enough people would vote for it (for example all the people who voted this news group should vote for it:) I might even post in the other news group. Steve CasselmanArticle: 2923
I have an existing ORCA 2C06 design that needs to be modified to work with a 3.3V memory chip. Has anyone tried driving 3.3V logic (bi-directional data bus) with 5V ORCA chips? Can it be done directly or do I need a resistor or translator? I could use the 2T15 part, but that would be overkill, and I need a clock to output delay of ~10ns.Article: 2924
On Tue, 27 Feb 1996 02:56:09 GMT, "** Atmel FPGA Apps. :-)" <martin@atmel.com> wrote: >Peter Fenn writes... >>I have downloaded Atmels CONFIGURATOR application note describing the >>programming spec, which now prompts me to ask the question "Is there not >>a piece of programming software already already out there somewhere >>that'll save me some time?" check the free implementation by Ingo Cyliax <cyliax@cs.indiana.edu> which is located in ftp://ftp.cs.indiana.edu/pub/goo/ It's done is QuickBasic, but it works. I'm working on a C implementation, and it's almost 100% done, but I'm still debugging it (lack of time prevents me from finishing it). One word of warning - Ingo's design used only a cable and a socket. My new software is compatible with Ingo's, but I prefer to use a 5V external power supply and not to take VCC from a data pin, like he does. I also came to the conclusion, that in order to get a RELIABLE board, you better place a buffer near your chip. You need an open collector buffer for the data line. >Atmel makes a simple programming board (ATDH2200 - $250) that plugs into >the parallel port on any X86 PC and allows you to program the AT17Cxxx >family of parts. It comes with the s/w you describe to read/write/verify >the Atmel re-programmable serial configuration proms. The input data can >come from a 17Cxxx device (which can be read from the board) or one of >several industry standard file formats. >I hope this helps - If you would like more information send me an e-mail >with your snail-mail address or visit the Atmel home page >http://www.atmel.com > >Regards > >Martin Mason > >------------------------------------------------------------------------- >| Martin Mason | Snr FPGA/17Cxxx Applications Engineer | >| Atmel Corp. | (Work) martin@atmel.com | >| 2125 O'Nel Drive | (Work2) fpga@atmel.com | >| San Jose | (Fax) + (408) 436 4300 | >| CA 95131 | (Tele) + (408) 436 4178 | >------------------------------------------------------------------------- >| Visit http://www.atmel.com | 'kewl' thinks Martin, The Net Dude :] | >------------------------------------------------------------------------- >
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