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
i) As far as I know, 256k is the largest part. But you can daisy-chain them without problem. ii) How to program the parts is described in 'FPGA Configuration E2PROM Programming Specification' and can be found on the Web. With a little imagination you can easily build a programmer for these parts: a) in system placed b) daisy-chainded Best regards ErwinArticle: 8601
> actually, i downloaded the statecad demo version and find it, so far, a > really nice way to work as you can concentrate on the problem solving and > not the mechanism of a state machine. i draw the state diagrams in the > tool the same way that i do on a piece of paper and it has a nice graphical > simulation capability too. anybody have any detailed experience with this > tool or any other similar tools? Let me know if you can make a PCI target and master state machine that runs at 33MHz in a -3 4013 part with it, then I'll be impressed ;-) P.S. Oh, don't forget to provide logic to make up for the /STOP-/FRAME Intel chip set bug that requires 5 destinations for the raw /FRAME signal...see if you can make timing for that...was that a 7ns setup? I certainly do not like to have to design state machines in schematic but due to most of these tools not having any feedback from the place and route tools, they do not arrange the logic in the most optimal way to achieve speed. I found that I end up fussing with HDLs (and their compilers) to compile the way I want them to. It seems to always be faster to do high speed logic in schematic. Now, if speed is not a problem, then HDLs can be quite useful. Austin Franklin darkroom@ix.netcom.comArticle: 8602
My vote on the schematics vs. HDL question (We are voting aren't we?)
While it would be nice to be able to use an HDL for FPGA design, there
are still a number of problems that make it impractical. Primarily, HDL
doesn't give the tight mapping control necessary for dense, high speed
designs.
Ideally, we will see a hybrid of HDL/schematic entry which allows data
paths to be expressed graphically while control logic expressed as text.
I've been using something like this for about 4 years now and wouldn't
trade it for anything else. It's an extension to Viewlogic that allows
you to put logic equations right on a schematic page. An example
schematic can be found at:
http://eseserver1.fnal.gov/eseproj/trigger/fpga2c6x.pdf
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 8603
Pasquale Corsonello <pascor@nwdeis1.unical.it>
> Does anyone know a source for hardware systems computing square root
> using self-timed asinchronous approach?
Here's an algorithm written in C to simulate both a synchronous and
asynchronous hardware implementations in an FPGA.
-------------------------------------------------------------------------
--- ----------------- // Synchronous Sqrt simulates the following
hardware // N[15:0] := LOAD ? Din[15:0] : N[13:0],0,0 # 16-bit 2-1
Registered Mux // N[23:16]:= Carry ? Sub[7:0] : N[21:14] # 8-bit 2-1
Registered Mux // R[7:0] := R[6:0],Carry; <Reset=LOAD> # 8-bit Shift
Register // Sub[9:0]== (N[23:14]-R[7:0],0,1) <Cout=Carry> # 10-bit adder
#include <stdio.h>
void Printb(char *S, long A) // Bit print function for diagnostics
{ int I;
for (I=32; I--;) if (A&(1L<<I)) putchar('1'); else putchar('0');
printf(" %8lx %s\n",A,S);
}
int Root(unsigned int N) // Iterative (Synchronous) version
{ int Bit=8; // Bit counter
long N_reg= N; // Simulate 24-bit N register
long R_reg=0; // Simulate 10-bit Root register as bits 23:14
long Tmp; // Temporary
long Rt=0; // Root
while (Bit--) { R_reg = (Rt<<16)|0x4000; // Note this is for free in
FPGA Tmp= (N_reg-R_reg); // Note only 10-bit subtractor (23:14) needed
if (Tmp >= 0) // If next bit is a 1 (carry-out of subtractor) { N_reg=
Tmp << 2; // Accept subtraction and shift N_reg Rt= (Rt << 1)|1; } //
Shift 1 into result else { N_reg= N_reg<<2; // Ignore subtraction, but
shift Rt= (Rt << 1) ; } // Shift 0 into result } return ((int)Rt);
}
int Unrolled(unsigned int N) // Unrolled loop (Asynchronous) version
{ int T; // Temp
int R=0; // Root
int A; // Intermediate result
// We can fit the logic for the first two stages into 2 ORCA PFUs
// with one level of delay. These lookup tables simulate this.
int RTABLE[16]={0,1,1,1,2,2,2,2,2,3,3,3,3,3,3,3}; // 2-bit root
int ATABLE[16]={0,0,1,2,0,1,2,3,4,0,1,2,3,4,5,6}; // 3-bit result
#define SubMux(Mask) /* Simulate subtractor followed by Mux */ \
{ T= A - ((R<<2) + 1); /* Subtraction */ \
R<<=1; /* Shift Root to accept next bit */ \
if (T >= 0) { R|=1; A=T; } /* Mux: select old A or T */ \
A &= Mask; } /* Constrain A to current data width */
A= ATABLE[N>>12]; // Do first 2 stages in lookup table
R= RTABLE[N>>12];
A= (A<<2)|((N>>10)&3); SubMux(0x00f); // Stage 3: 4-bit adder
A= (A<<2)|((N>> 8)&3); SubMux(0x01f); // Stage 4: 5-bit adder
A= (A<<2)|((N>> 6)&3); SubMux(0x03f);
A= (A<<2)|((N>> 4)&3); SubMux(0x07f);
A= (A<<2)|((N>> 2)&3); SubMux(0x0ff);
A= (A<<2)|( N&3 ); SubMux(0x1ff);
return(R);
}
main() { unsigned int I,R; for (I=256; I--;) { R= Unrolled(I*I); if
(I>=30 && I<40) printf("I= %3d I*I= %6d R=%3d\n",I,I*I,R); // Print
samples data if (R != I) printf("Error: Root was %d should be
%d\n",R,I); // Check all combinations } return(0); }
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 8604I can only offer conjecture about why the 10mA standby current is being consumed. I have a hunch that it is a result of some tweaking to get higher speed devices. Maybe your supposition about sense amp currents might be on the right trail. Since the 10mA standby current is quoted as a "typical" value, it is most probably not valid as a worst-case figure across temperature. I am concerned about how much the standby current will increase when I begin testing at my upper temperature spec. of 85 Celsius. I'm hoping that I'm not required to jump ship to an Altera competitor. But I guess that I need to start looking at alternative vendors who offer good software like Altera with devices similar in size to the Altera 10K100. I will be using the embedded memory on the Altera device so that it is another requirement I must satisfy. ------------------------------------------------------------------------------- richard katz wrote: > dwtdw <dwtdw@tulsa.oklahoma.net> wrote in article > <34B6AB45.98333AE7@tulsa.oklahoma.net>... > : Attention Altera FLEX10K users: > : > : Is anyone else concerned about the imminent increase in Standby > Current > : for the 10K100A from only 0.5mA to 10mA??? > : > : I design mobile/battery-powered products and this increase is > gigantic > : relative to my > : overall power budget. Is there anyone else designing mobile, > : battery-powered, and/or > : other products which require low-power consumption or do I have the > only > : application > : that is power critical? > : > : It seems like Altera could continue to offer a low-power version of > the > : device for those > : who need it. Maybe something like a 10K100AL? > > out of curiousity (and an attempt to get some technical stuff > discussed > here), do you know where the power is going in the chip? 10 mA is a > pile > of current if you're doing low-powered stuff and yes, i do that sort > of > design too. most of the fpga's that i use consume < 1 mA for > Iccstdby, > with many models running around 130 uA or so. for a cmos part, 10 mA > suggests that they're running some oscillators, sense amps w/ bias > currents, or just have poor quality parts. any other ideas? also, i > assume that the 10 mA spec is for the inputs at cmos levels. is that > number over temperature? > > just a thought or two, > > -------------------------------------------------------------- > rk > > "there's nothing like real data to screw up a great theory" > - me (modified from original, slightly more colorful version) > --------------------------------------------------------------Article: 8605
Folks,
We at Atmel relised that this may be a problem and didn't like the
alternatives much either - so we have put a feature on our AT17C010 and
AT17C512 ISP serial configuration memories to help simplify the system
design at system power-up. The 512K and 1MBit EEPROM configurators have a
system friendly READY pin that signifies when the power supply has reached a
good voltage level - this Configurator open collector o/p can be used to
hold FPGAs (inc. Xilinx and our AT40K
http://www.atmel.com/atmel/products/prod3.htm) in RESET until the power
suply is seen as good - the voltage trip level is crude - but is all you
need in most cases - oh and it's a 'free' feature on our parts. For more
details check out :
http://www.atmel.com/atmel/products/prod22.htm
Martin Mason
Atmel corp.
Article: 8606Erwin Oertli wrote in article <69d7u6$h6a@neptune.ethz.ch>... >i) As far as I know, 256k is the largest part. But you can daisy-chain them >without problem. > Now available upto 1MBit http://www.atmel.com/atmel/products/prod182.htm >ii) How to program the parts is described in 'FPGA Configuration E2PROM >Programming Specification' and can be found on the Web. http://www.atmel.com/atmel/products/prod183.htm > >With a little imagination you can easily build a programmer for these parts: >a) in system placed >b) daisy-chainded Happy to help: e-mail configurator@atmel.com for more details. Martin Mason Atmel corp. > >Best regards >Erwin > > >Article: 8607
--------------CC9C2FB45BC7F4C0D1E93A0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lars wrote: > Hi, > does anyone where I can find a VHDL model for Synchronous DRAM? Check out the synopsys homepage http://www.synopsys.com -- Sincerely, Robert Paley --------------CC9C2FB45BC7F4C0D1E93A0F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Lars wrote: <BLOCKQUOTE TYPE=CITE>Hi, <BR>does anyone where I can find a VHDL model for Synchronous DRAM?</BLOCKQUOTE> Check out the synopsys homepage <P><A HREF="http://www.synopsys.com">http://www.synopsys.com</A> <PRE>-- Sincerely, Robert Paley</PRE> </HTML> --------------CC9C2FB45BC7F4C0D1E93A0F--Article: 8608
In article <884284415.1093926925@dejanews.com>, jhon@geocities.com wrote: >Does anybody know how to connect an Altera Flex10k device to a PC >Parallel Port, particularly the electrical specifications do to this (not >to program the device, but to exchange data between PC and Flex10k). > >Thank you in advance. > >-------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet Depends on what you want. Standard unidirectional PC to EPLD is easy (look in any PC book). If you want bidirectional you have to decide on 4 bit (old type parallel port using control lines for input) or 8 bit (newer bidirectional or IEEE 1284 compatible port). There are some good web pages on parallel ports, try this one : http://www.geocities.com/SiliconValley/Bay/8302/parallel.htm Take care to terminate signals properly. I have found that some cards oscillate wildly if you don't. (Say a 100R series resistor and a 240R resistor to +5V or something like that). NicArticle: 8609
Austin Franklin <dark7room@ix.netcom.com> wrote in article <MPG.f23ef00e507139f989680@nntp.ix.netcom.com>... : > actually, i downloaded the statecad demo version and find it, so far, a : > really nice way to work as you can concentrate on the problem solving and : > not the mechanism of a state machine. i draw the state diagrams in the : > tool the same way that i do on a piece of paper and it has a nice graphical : > simulation capability too. anybody have any detailed experience with this : > tool or any other similar tools? : : Let me know if you can make a PCI target and master state machine that : runs at 33MHz in a -3 4013 part with it, then I'll be impressed ;-) P.S. : Oh, don't forget to provide logic to make up for the /STOP-/FRAME Intel : chip set bug that requires 5 destinations for the raw /FRAME signal...see : if you can make timing for that...was that a 7ns setup? well, guess i can't really impress you, sorry. as for high performance logic, HDL's and graphical designs are probably not the way to go, they can't seem to beat a good humanoid yet. my designs, as i posted earlier, tend to be a mixture of schematics, output of macro generators, and vhdl. the type used for each block depends, of course, on the block. now, while i haven't seen either great device efficiency or performance from the HDL compilers (and have from macro generators, btw), i have used them to save a lot of drafting time and some tedious logic minimization and state machine design. and for certain blocks, which may be conceptually not that bad but are of reasonable size and have reasonable performance requirements, they can save many, many hours of work. and as stu pointed out, the designs are more portable, which can also save quite a bit of labor when it's time to move to another device. for the highest performance designs, or other exceptional conditions (i.e., micropower, radiation-hardness, etc.) i'm in agreement, HDL's are not the optimal way to go. i've witnessed engineers, working on a pci target, spend FAR too much time on the design, with rather wide performance swings from each compilation-P&R cycle, which they couldn't control. : I certainly do not like to have to design state machines in schematic but : due to most of these tools not having any feedback from the place and : route tools, they do not arrange the logic in the most optimal way to : achieve speed. interestingly, husby@fnal.gov comments on control logic expressed as text: >: My vote on the schematics vs. HDL question (We are voting aren't we?) >: >: While it would be nice to be able to use an HDL for FPGA design, there >: are still a number of problems that make it impractical. Primarily, HDL >: doesn't give the tight mapping control necessary for dense, high speed >: designs. >: >: Ideally, we will see a hybrid of HDL/schematic entry which allows data >: paths to be expressed graphically while control logic expressed as text. >: I've been using something like this for about 4 years now and wouldn't >: trade it for anything else. It's an extension to Viewlogic that allows >: you to put logic equations right on a schematic page. An example >: schematic can be found at: >: http://eseserver1.fnal.gov/eseproj/trigger/fpga2c6x.pdf back to austin: : I found that I end up fussing with HDLs (and their compilers) to compile : the way I want them to. It seems to always be faster to do high speed : logic in schematic. Now, if speed is not a problem, then HDLs can be : quite useful. agreed - for many parts of a design, or even entire designs (just did one at day job, complex sequencer @ 2.5 MHz) speed is not an issue, but managing complex machines or design time is. that is where a tool such as state cad may be of use. have any experience with it or it's competitors? i've continued to do some sample designs and found that relatively complex state machines can be designed quite quickly and simulated easily too. i haven't experimented with moving the "synthesizable" code directly into my vhdl compiler - anyone have experience with that? (big fear that tool integration could take more work than designing with pencil and berols template). Chris Tscharner, US Dept of Defense, adds a few comments about HDL's and their simulation capabilities: This is one of the great things about having a whole simulation environment based on Verilog or VHDL. I have one common language to do simulation in, be it RTL, structural extract from a schematic, or whatever. If you are using Altera, MaxPlu2 will output structural Verilog and accompanying timing SDF for your post-route design. In the case of both Xilinx (M1) and Lucent (Foundry) you can use ngd2ver to do the same thing. I believe all will basically mirror the structure of your design, so things like skew are simulated. Modules to model the primitives are included - you can use anyone's simulator. For pre-layout simulation of schematics, there should be a tool available to generate the needed netlist (example: Viewlogic Powerview uses their Verilnet tool to extract Verilog). -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8610
Hi All, I'd be interested in hearing from anybody who is using Orcad Express for FPGA design; especially if they are using VHDL. Does this tool work for you? Do you think the VHDL language implementation is complete enough? Yada, yada yada. Thanks in advance, ErikArticle: 8611
In article <01bd1f47$36532680$7780accf@default> "richard katz" <stellare@erols.com.NOSPAM> writes: >Philip typed here, possibly a tad too fast: >: I believe that Richards problems with rampant clock skews are because he >: is not using Xilinx global clock buffers. >Me types here, possibly too early in the morning, slightly insulted. :-) No insult was intended. I'm sorry. It was meant as humor, since I knew you were using Actel chips. >so, i can repeat my question, possibly the fpga manufacturers can answer: >do the models that they supply model clock skew in the logic simulation >accurately enough for timing analysis? I suspect that the answer will be no, because the timing information that the place and route tools that I am familiar with, only report worstcase delays, and usually for the situation that generates longest delays, which is high temp, and low voltage. Skews that are derived from such info are not the worst case, which is when a long clock delay is at its worst, while simultaneously, some other clock delay is at better than its worst. The situation is exacerbated by the issue that you are doing stuff at (I believe) low temperature, for which the FPGA timing analyzers do not report temperature based delay info. Sorry again for the un-intended insult. Philip FreidinArticle: 8612
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_| _|
_| _|
_| _|_|_|_| _|_|_|_| _| _| _|_|_|_| _|_|_|_| _|
_| _| _| _| _| _| _| _| _| _| _|
_| _| _| _| _| _| _| _| _| _|
_| _|_|_| _|_|_|_| _| _|_|_|_| _|_|_|_| _|
_| _| _| _| _| _| _| _|
_| _| _| _| _| _| _| _|
_| _| _| _|_|_|_| _|_|_|_| _|_|_|_| _|
_| _|
_| _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
F P L '98
E I G H T H I N T E R N A T I O N A L W O R K S H O P
on
FIELD PROGRAMMABLE LOGIC AND APPLICATIONS
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_| _|
_| August 31 - September 2, 1998 (Monday - Wednesday) _|
_| _|
_| Tallinn Technical University , Estonia _|
_| _|
_| http://www.ttu.ee/fpl98 _|
_| _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
C A L L F O R P A P E R S
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_| _|
_| Paper Deadline March 7, 1998 _|
_| _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
AIM: FROM TINKERTOY TO PARALLEL COMPUTING PARADIGM
The methodology of reconfigurable circuits and systems is evolving from
tinkertoy approach to an:
Innovative Parallel Computing Paradigm which combines computing in
time with computing in space. The aim of this workshop is to bring
together workers from throughout the world for a wide ranging
discussion of all forms of field programmable logic, particularly
field programmable gate arrays and complex programmable logic devices,
and their applications. It is intended to discuss the increasing range
of device types, industrial applications, advanced design tool
development, research applications, novel system architectures and
educational experiences. The workshop will include regular
presentations, posters and discussion sessions, and it is expected
that most of the delegates will wish to make some contribution to one
or more of these. The workshop is the eighth in a series of workshops
which were held in Oxford (1991, 1993 and 1995), Vienna (1992), Prague
(1994), Darmstadt (1996) and London (1997).
CALL FOR CONTRIBUTIONS
Contributions are invited for regular presentation, poster and
discussion sessions. Prospective authors are invited to submit an
abstract of at least 500 words or a full paper of about 10 pages by
7 March 1998
to the Program Chairman. Please send also your full correspondence address,
including e-mail, and fax, and a list of (at most) 5 one-line
statements that best encapsulate the essence of your proposed
contribution. Submissions by e-mail to: abakus@informatik.uni-kl.de in
postscript format (ghostscript-compatible) are highly encouraged.
Notification of acceptance will be posted by 15 May 1998 and final
papers must be received by 15 June 1998 to guarantee distribution at
the workshop. The workshop proceedings will be published by
Springer. For the publication of accepted papers, an electronic as
well as a camera-ready version of the paper and the registration of at
least one author will be required. Potential exhibitors and tutorial
presenters are also invited to contact the Program Chairman. The
official conference language as well as the language of submissions
and accepted papers will be English.
SCOPE
Workshop topics include, but are not restricted to:
- Novel device, machine and system architectures
- New software and hardware development tools
- Run-time reconfigurable and partially reconfigurable designs
- High-level design and compilation research
- Industrial applications and experiences
- Trade-offs between devices, architectures and technologies
- Benchmarking and profiling
- Applications from a wide variety of areas
- Reconfigurable custom computing machines
- Hardware/Software Co-Design using field programmable devices
- Evolvable and adaptable systems
- ASIC emulators, hardware modellers and compiled accelerators
- Fault modelling, testability methods and reliability issues
- Educational experiences and opportunities
- Reconfigurable accelerators and their applications
- Speed-up effects - survey and analysis
- Testing of reconfigurable circuits
GENERAL CHAIRMAN
Prof. Andres Keevallik
Tallinn Technical University
Raja 15
Tallinn EE-0026
Estonia
Phone: +372-6104440
Fax: +372-6202246
email: akeev@cc.ttu.ee
http://www.ttu.ee/fpl98
PROGRAM CHAIRMAN
Prof. Reiner W. Hartenstein
University of Kaiserslautern
P. O. Box 3049
D-67653 Kaiserslautern
Germany
Phone: +49 631 205-2606
Fax: +49 631 205-2640
email: hartenst@rhrk.uni-kl.de
http://xputers.informatik.uni-kl.de/FPL/index_fpl.html
PROGRAM COMMITTEE
Doug Amos, Altera, UK
Peter Athanas, Virginia Tech, USA
Samary Baranov, Ben Gurion U. Negev,Israel
Stephen Brown, U. of Toronto, CA
Klaus Buchenrieder, Siemens AG, FRG
Steven Casselman, VCC, USA
Bernard Courtois, INPG, Grenoble, France
Carl Ebeling, U. of Washington, USA
Norbert Fristacky, Slovak Technical U., SK
Manfred Glesner, TH Darmstadt, FRG
John Gray, Xilinx, UK
Herbert Gruenbacher, Vienna U., Austria
Reiner Hartenstein, U. of Kaiserslautern, FRG
Brad Hutchings, Brigham Young U., UAS
Udo Kebschull, U. of Tuebingen, FRG
Andres Keevallik, Tallinn Technical U., Estonia
Wayne Luk, Imperial College, UK
Patrick Lysaght, U. of Strathclyde, Scotland
Toshiaki Miyazaki, NTT Laboratories, Japan
Will Moore, Oxford U., UK
Wolfgang Nebel, U. of Oldenburg, FRG
Paolo Prinetto, Politecnico di Torino, Italy
Jonathan Rose, U. of Toronto, Canada
Zoran Salcic, U. of Auckland, New Zealand
Eduardo B. Scalvinoni, U. Autnoma de Madrid, Spain
Michal Servit, Czech T. U., Czech Republic
Marc Shand, Digital Systems Research Center, USA
Steve Trimberger, Xilinx, USA
LOCAL DETAILS
The workshop will be held from 1st to 3rd September, 1998 at the
National Library of Estonia near the center of Tallinn, the capital of
the Republic of Estonia. Tallinn lies in the Northern Europe, in the
northeast of the Baltic sea region. The good geographical location of
Tallinn has favored its becoming an important harbor and a center of
industry and trade.
The workshop is organized by Tallinn Technical University which is
situated about 5 km from the center of city.
FURTHER INFORMATION AND REGISTRATION
All the latest information about FPL'98 as well as registration info
can be accessed via a WWW-page. The URL for this document is:
http://www.ttu.ee/fpl98
Article: 8613> and as stu pointed out, the designs are > more portable, I hear a lot about porting designs to other technologies, yet I personally have never done that....and...I don't know anyone who has either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe it is as prevelant as the proponents of portable design methodologies have like 'us' to believe... And...why aren't schematics portable? Mine are (for the most part...). I make hierarchical one bit symobols for elements like flops, I/O elements etc, and these are all that has to change from technology to technology. I've developed an entire library of different combinations or elements and pin counts for I/O elements (say 16 bit bi-directional flop in, tri-state out...) and for registers and counters and tri-state buffers and muxes and... Random logic is a bit more difficult, but you can do a global change on the symbol named AND3B2 to what ever the new technology name is...it really does't take that long. AustinArticle: 8614
dark7room@ix.netcom.com (Austin Franklin) wrote: >> and as stu pointed out, the designs are >> more portable, > >I hear a lot about porting designs to other technologies, yet I >personally have never done that....and...I don't know anyone who has >either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe >it is as prevelant as the proponents of portable design methodologies >have like 'us' to believe... It can work, I 'ported' a recent CPLD design between Xilinx, Altera and Lattice at design time. Identical source (unless you have to resort to vendor specify design tweaks). Identical testbench with a few ifdefs to work around tool idiosyncrasies. Being able to easily fit and test a design in parts from different vendors gives a lot of insight into their architecture and your design. Cheers Terry...Article: 8615
On Tue, 13 Jan 1998 10:06:11 -0500, dark7room@ix.netcom.com (Austin Franklin) wrote: >I hear a lot about porting designs to other technologies, yet I >personally have never done that....and...I don't know anyone who has Have you ever had reason to want to do it? Have you ever had a need to do it? Have you ever thought : "Hell, there must be a better way." >either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe >it is as prevelant as the proponents of portable design methodologies >have like 'us' to believe... I see it almost all the time. HDL based customers who have specific design requirements tend now to use HDL's and then pick the architecture that's right for the job in hand. They base their decision on: 1 Does the part do the job? 2 Is it available? 3 How much is it. Answer yes to 1 and 2, and then you decide who wins on price. Payback on your tools is usually rapid. I do not know many large programmable logic users who does not have at least two vendors that they use as appropriate. I've seen some with four or five. Here's an example, a company last year recently switched over 300K+ gates from a mixture of Xilinx and Actel, to ORCA. The evaluation of the FPGA architecture took about 3 weeks, and in that time key elements like parallel 32 bit CRC's, complex state machines, discrete FIFO's etc. were benchmarked. System clock speed is 66 MHz. Absolutely no schematics were used, although some instantiation was done to help in the XOR term generation (because ORCA does an 11 input cascaded XOR in one level of logic with use of a PFU gate). This was kept heirarchical to ensure swift transition should ORCA have crapped out. Macro-block generators such as Lucent's SCUBA were used to generate device specific blocks such as ROM's and (DP)RAM's for tables and FIFOs and instantiated as components. Eventually a new prototype board was up and running in around 5 weeks after the decision had been made to convert to ORCA. Design flow was all VHDL with simulation pre and post synthesis & P&R. So in this design... Plus sides of HDL design methodology ------------------------------------ Customer is free to find a solution that meets his needs. (Performance and power consumption were key) Customer is not beholden to one manufacturer. Customer is not beholden to one manufacturer. (needs saying twice) Design manageability within a large team is improved. Speed of simulation at a more abstract level. Testbenches that can be interactive and self documenting. Design change flexibility and manageability. Time to board, time to market. Down sides of HDL design methodology ------------------------------------ Good QOR tools have a higher purchase price than schematics. But IMHO a lower cost of ownership when the above plus points are considered. Engineers who don't know HDL feel threatened with new technology. Sometimes not suitable where you really push the edge, but this is becoming very much less of an issue. Little benefit at low density. Sometimes tricky in syntax and synthesis implementation, but that's why we have stepping simulators isn't it? OK, so this wasn't what many would consider a "normal" design, but if you believe the marketing hype (translation : Bullshit), we'll all be able to use 1M gate FPGAs at $1 per 5K gates by next year. Therefore we'll all need higher level tools. Perhaps even moving to the higher level of system block (schematic?) visualisation before design task assignment to multiple engineers? Stuart -- For Email remove "die.spammer." from the addressArticle: 8616
I'd like to know if there's any way, using a 10K50 part, to compile a CSFIFO block into the part and not let it use the EABs. What I need to do is generate a register-only implementation of the FIFO for later compatibility with an ASIC process. Also, is there any way to generate a VHDL/EDIF/Verilog output file without all of those delay cells? Thanks, Greg Hoffman hoffman@adichi.comArticle: 8617
1) What are the main differences between Xilinx and Altera FPGAs? 2) Are there features in which Xilinx or Altera excells? 3) Are there specific applications where a specific vendor is recommended? 4) Are there articles in professional publications which compare different FPGA manufacturers? Do you know of any in particular? DanArticle: 8618
It has come to my attention that the 4000E series xilinx have a series problem when it comes to using the ram elements. It is my understanding that if the write clock signal is held high for more than a millisecond, permanent damage to the device can be caused. This is suppose to be true even if only a single ram device is held in this state. My only question is: 1. Is it possible to avoid this burn out if the write enable signal is held low if a clock failure is detected, or is a gate on the clock signal, not a preffered practice, required? I am still amazed that this is possible. I never thought a simple clock failure could possibly cause physical damage to a device. -- Ryan Herbst ryan@amaroq.com KF6CDD http://www.amaroq.com/ryan/ rherbst@verilink.com PGP Public Key: ftp://ftp.amaroq.com/rherbst.asc GCS GE GS d-- -p+ c++(++++) l+++ u++ s--/-- n--(---) h-- !f g+ t+Article: 8619
We are looking for some information about the way SRAM-based programming is done in FPGA designs. Specifically, what sorts of circuit design structures are used to create the programming cells, how are they given the programming data, and what is the organization and distribution of the cells throughout the chip? ie, is there typically a bank of SRAM on chip that is routed to each programmable element, or is the memory element adjacent to or a part of the programmable element? We are looking for VLSI design information (CMOS process) or any pointers to books, papers, etc that might have this sort of information. Most of the papers that we have cover the various types of CLBs and some cover the interconnect, but we have found very little containing specific VLSI implementation details. We welcome any advice, pointers, or communication on this aspect, or any aspect of the design. Sincerely, Mark Willey (willey@etla.ml.org) Gun Unsal (unsal@leland.stanford.edu) If you want to know: We are doing a custom VLSI design of an FPGA using a new type of CLB which we believe has never been implemented in silicon before. This device will be fabricated and tested. The CLB is described in a paper by Chih-Chang Lin, Malgorzata Marek-Sadowska, and Duane Gatlin, "On Designing Universal Logic Blocks and Their Application to FPGA Design", IEEE TRANSACTIONS ON COMPUTER-AIDED DEISGN OF INTEGRATED CIRCUITS AND SYSTEMS. VOL. 16, No. 5, MAY 1997. This is an academic project and will have full disclosure.Article: 8620
Impressive. But unless I am wrong, this is based on the Newton-Raphson method ((N/a)+a)/2 with a fixed number of iterations. That is what the unrolled loop is about. So the accuracy depends strongly on the initial guess. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 8621
Hi all. Has anyone used both Xilinx Foundation class tools and Viewlogic Workview Office? Which one do you prefer? I have used the latter but was not able to evaluate Foundation so your help will be appreciated. Please answer with e-mail to : nmo@teletel.gr Thank you, Nikos.Article: 8622
Hi all,
I'm looking at Jam. Has anyone any advice. I downloaded the kit but
it would not decompress. (I've fallen at the first hurdle).
Any comments wecome.
Billy Bagshaw
bill@highwater.co.uk
Article: 8623> >I hear a lot about porting designs to other technologies, yet I > >personally have never done that....and...I don't know anyone who has > > Have you ever had reason to want to do it? > Have you ever had a need to do it? > Have you ever thought : "Hell, there must be a better way." No to all three ;-) The 'better way' is to understand the problem at hand and pick the correct tools and parts to meet the task before hand. > >either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe > >it is as prevelant as the proponents of portable design methodologies > >have like 'us' to believe... > > I see it almost all the time. 12 years of ASIC/FPGA consulting....100+ designs, 47 customers, never seen it. > HDL based customers who have specific > design requirements tend now to use HDL's and then pick the > architecture that's right for the job in hand. They base their > decision on: Whether the design is HDL or schematic based does not mean it does or doesn't have specific design requirements. <snip> > <snip> System clock speed is > 66 MHz. One can heavily pipeline a design and achieve higher clock speeds, and this is generally the technique with any FPGA. 66MHz usually means only one level of logic between flops, and very localized routing. Usually, the entire design does no run at 66MHz, as there are usually many multi- cycle paths. > Absolutely no schematics were used, although some > instantiation was done to help in the XOR term generation (because > ORCA does an 11 input cascaded XOR in one level of logic with use of a > PFU gate). Whether schematic or HDL there will always be device specific elements that should be understood and will require some special attention. > This was kept heirarchical to ensure swift transition > should ORCA have crapped out. Macro-block generators such as Lucent's > SCUBA were used to generate device specific blocks such as ROM's and > (DP)RAM's for tables and FIFOs and instantiated as components. Schematics can (and should) be done heirarchically, and high level 'macros' can (and should) be used in schematics too. <snip> > So in this design... > > Plus sides of HDL design methodology > ------------------------------------ > Customer is free to find a solution that meets his needs. (Performance > and power consumption were key) And why is this not true when using schematics? > Customer is not beholden to one manufacturer. > Customer is not beholden to one manufacturer. (needs saying twice) And also why is this not true when using schematics? > Design manageability within a large team is improved. Same? > Speed of simulation at a more abstract level. Don't quite know what you mean by this... > Testbenches that can be interactive and self documenting. > Design change flexibility and manageability. > Time to board, time to market. I use VHDL to provide bus functional models, and in some cases, an entire simulation environment, whether my design is done in entirely schematic, HDL or some combination of both... ANY design can be done poorly, or well, depending on the person doing it, whether it is done in HDL or schematic. I have seen designs that were done in HDL that were done so miserably, as I have seen schematics done just as badly. I have also seen very very well done HDL and schematics. That doesn't make one better than the other, it makes one implementer better than the other though... > Down sides of HDL design methodology > ------------------------------------ > Good QOR tools have a higher purchase price than schematics. But IMHO > a lower cost of ownership when the above plus points are considered. Agreed. > Engineers who don't know HDL feel threatened with new technology. I have not see this to be the case. > Sometimes not suitable where you really push the edge, but this is > becoming very much less of an issue. Agreed. <snip> > Therefore > we'll all need higher level tools. Perhaps even moving to the higher > level of system block (schematic?) visualisation before design task > assignment to multiple engineers? But anyone I know who is worth their weight does their designs this way today.... Schematic or HDL has nothing to do with partitioning the design so multiple people can work on it simultaneously. I'm really confused as to why you believe the design methodology you state is unique to HDL. There is not one aspect of it that does not apply to schematic design entry too. Personally, I believe data path is far better in schematic than HDL. There is NO way of documenting data path in HDL so it is more understandable than schematic. HDL is certainly better for state machines and usually for random logic, I have no problem with that. I have had to convert HDL blocks into schematics due to speed and density requirements. Until there is a way of providing feedback from the place and route tools to the HDL compiler, there is no way the HDL compiler can know how to partition and implement the design to make timing optimally. One major problem I have had with HDLs is they are NOT consistent in what they produce as output. I do not want to play guessing games with the compiler. I believe a good engineer has a good toolbox, consisting of many design methodologies, and a very good understanding of their use. S/he also has to have a good understanding of the problem at hand, and the architecture benefits/problems with the components involved. Unless you want to rely on dumb luck, that is. Austin Franklin darkroom@ix.netcom.comArticle: 8624
In article <34BC9B39.4AA2@teletel.gr>, Nikos <nmo@teletel.gr> wrote: >Hi all. > >Has anyone used both Xilinx Foundation class tools and Viewlogic >Workview Office? Which one do you prefer? I have used the latter >but was not able to evaluate Foundation so your help will be >appreciated. > I have used Foundation probably as oftern as Workview Office (Powerview 6.0 as well). If you are mainly concerned about targetting Xilinx devices Foundation is definitely the way to go. The VHDL-Schematic Interface is one of the best I have seen (the best being Mentor Graphics). Soon Foundation will have Synopsys FPGA Express integrated in its package making it an even more ambitious tool. The only problem with foundation is its simulator. Viewsim has the edge but no by a wide margin. >Please answer with e-mail to : nmo@teletel.gr > >Thank you, > >Nikos.
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