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
University of California (Berkeley) Extension announces "Electronic Packaging Technologies: BGA, CSP, Flip Chip and MCM-L" May 6-8, 1996 San Francisco Airport Area, California a comprehensive three-day course with an experienced world authority and author, Dr. John Lau. Lau is founder/ President of Express Packaging Systems, an author of over 100 technical publications and author/editor of nine books. The has 25 years of R&D Experience and was a technical editor of ASME Transactions, Journal of Electronic Packaging, and IEEE transactions on Components, Packaging and Manufacturing Technology. His books "Ball Grid Array Technology" and "Flip Chip Technologies", both published by McGraw-Hill Book Company and more than 300 pages of course notes will be provided to each enrolled participant. You will be able to apply material in this course in practical situations, and choose the right cost- effective high-performance packaging technique for your interconnection systems. Bring your technical problems to the seminar. Topics covered include IC trends, chip-level interconnects, conventional packages, emerging packages:BGAs, advanced packages:CSPs, Flip Chip Technologies (FTC), Multichip Module Technologies, future packaging directions, open discussions. Further information: For a brochure describing this course, send your postal address toArticle: 3026
Hi everyone. We're using the Actel Act2 family of FPGAs and I was wondering if anyone had any experiences with them (good or bad). The chip we're specifically using is the 1240A. It seems to be fairly capable but it has a lot of drive limitations, etc. Are these typical of other FPGA vendors? Any responses would be appreciated. Thanks. Dave Spencer starfire2@earthlink.netArticle: 3027
Thanks, John. We should learn our lesson from Quebec and not push the Verilog thing too hard. Still, I think, like Quebec, there will be more VHDL users who are bilingual. John WilliamsArticle: 3028
Mike Butts wrote: > > Examples like little arithmetic functions are well and good, > but real C programs have pointers. Pointers that can be > assigned to at run time, with run-time-computed values. > I'm certainly not a compiler expert, but those who are cite > pointer aliasing as a substantial impediment to automatic > parallelization of old code. > I agree, code with pointers will never be able to be fully parallelized. The situation is not entirely bleak however. It may be necessary to run old code (with pointers) on a FPGA based processor. This will be the case when it (the FPGA processor) is the only hardware available to run the code, and when real world constraints require you to run a pre-existing program. New code can simply avoid using global pointers. When pointers are used, there are a few things that can be done. - The sequential program might be accelerated up to the speed of a single memory port. This in itself can be a pretty agressive goal. - The width of the memory can be increased - The speed of the memory can be increased. - Caching can be implemented Sounds like as CPU eh. The main thing about pointers is that they physically refer to the address lines of a RAM. Everthing is fine as long as only one pointer is enabled at any point in time. This can be enforced by the C compiler. Of course multiple independent C programs can run concurrently, but ideally we want to have multiple memories, or pointers running concurrently within the same program. In is important to note that if the range of pointers could be restricted to a discrete memory space, then multiple pointers could be accessing different banks of memory at the same time. But C has no method of restricting pointer range except possibly that no pointer can point to data not declared as memory space, or malloced. If memory is malloced, then the pointer range is known if it can be traced to the pointer returned by malloc(). Array are not a problem, and they can usually be used instead of pointers in new code. This is because arrays have their range known at compile time. Thus the code int out[0x100][0x100][0x100]; int in0[0x100][0x100][0x100]; int in1[0x100][0x100][0x100]; ..... out[x][y][z]=in0[xx][yy][zz]+in1[xxx][yyy][zzz]; can run in one clock(pipelined) if out,in0 and in1 were allocated by the user-linker-compiler to be in different physical banks of memory. A common use of pointers is for indexing into tree structures. statements such as "a=****b;" are found. If the range of each pointer can be restricted, then this statement can be physically implemented in a set of 4 linked memories. When pipelined, the structure can run very fast. In summary, worst case is that pointers force a program to run at the speed of a single bank of memory, best case is that a system with N banks can run them all concurrently. You might note that a Quad Alpha using pointers into DRAM will run about as fast as a 286. If the FPGA based system has multiple banks of DRAM, it at least has a chance of running faster. Of course none of these issues have really been worked out and won't until we really do the work of writing a real C compiler for FPGA based systems. By the way, global pointers are a good example of a coding practice that generate a lot of unnecessary bugs. I hope I haven't bored you - Brad Taylor /===============================<>=================================\ | Brad Taylor blt@emf.net | \===============================<>=================================/Article: 3029
MB> Did I read someplace that Java has no pointers?
Java doesn't have explicit pointers. It has object references and
automatic memory management via heap and garbage collection. I looked at
the Java Virtual Machine for a while, trying to figure out whether it was
worthwhile to build an FPGA-based interpreter for Java. I concluded that
it probably wasn't because of the complexity of the memory management-
everything is dynamically allocated and all accesses are through
pointers.
BLT>It may be necessary to run old code (with pointers) on a FPGA based
BLT>processor. This will be the case when it (the FPGA processor) is the
BLT>only hardware available to run the code, and when real world
BLT>constraints require you to run a pre-existing program. New code can
BLT>simply avoid using global pointers.
I think it is an unlikely scenario (even for us hard core FPGA types :-)
that an FPGA processor is the only one available. There will *always* be
a 2/3/486 somewhere. I also don't hold out much hope for running dusty
deck C code on an FPGA if you want performance.
Optimization in the presence of general unrestricted pointers is not a
solved problem, though there was a flurry of interest in the compiler
community about this topic 5-6 years ago. I think a more interesting (and
tractable) but still difficult problem is to actually generate the hardware
that pipelines a loop, so that memory read/compute/write occur concurrently.
Are there any C-to-hardware compilers out there that do that?
Maya
----------------------------------------------------------
Maya B. Gokhale David Sarnoff Research Center
maya@sarnoff.com CN5300
Princeton, NJ 08543
609-734-3119
----------------------------------------------------------
Article: 3030Per the Subject line, several people have found parts of the XACT 6.0 system too slow. Here is some info and observations. I am not an employee of Xilinx, and so am clearly NOT speaking for them. I was an alpha and beta tester for this release and prior releases, and have some insight into how some of this stuff works. That info is covered by an NDA that I have signed with Xilinx, and I will not be drawing upon that info, nor is it relevant to this message. The info I present here is based on my own observations. All the below is with regard to the PC version, using the Viewlogic schematic capture, and simulation software, not the UNIX version. The WIR2XNF program metioned below is unique to the viewlogic version, ORCAD and other sch/sim packages do not use it. 1) Xilinx's goal for XACT STEP 6.0 seems to have been to make it far easier for a new user to get started with the tools, and focused on having everything run under windows. 2) a significant part of the software is still DOS based, and runs in dos-boxes under windows. 3) the prior two releases of XACT were V5.1 and V5.1.1. V5.1 had significant functionality improvements over V5.0, and V5.1.1 was primarilly the release that added the windows based Viewlogic ProSeries software. 4) underlying the XACT STEP 6.0 release is the V5.2 version of the programs, which include bug fixes and functionality improvements over the V5.1 release. (I am not aware of any such changes between 5.1 and 5.1.1) 5) as an active user of these systems (I designed over 150 FPGAs for my clients last year), it may be interesting to note that I ignored the 5.1.1 release of the software because I could not tollerate the drop in productivity that it caused. I feel the same way about the 6.0 release, but NOT the underlying V5.2 executables (except for WIR2XNF) 6) the drop in productivity (for me, not necessarilly for others) is a side effect of my design methodology, and project management style, not the execution time of the programs. Given the way I do designs, the V5.2 executeables all run about the same time as their prior V5.1 version, except for WIR2XNF. I do not use the XDM program, or the 6.0 design manager, because they do not give me the control I want over the tools, and the batch capabilities of building designs (multiple at a time) from automated scripts, including source control, simulation, timing analysis, and some automated documentation generation. My scripts also include some of my own sw that is used in intermediate stages of the flow. Typical users of the Xilinx products find the Xilinx provided automatic flows quite sufficient to produce good results. My mileage is different (and for me, better). Now.... on with the subject at hand.... Pierre Cluzel wrote: > I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several > years) and my first work has been to test the software with the tutorial > example CALC.1. > I have never experienced crashes during schematic editing but the > implementation software is very VERY SLOW . My machine configuration is > : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows > Version 3.1. > PPR running with DOS (xdm) takes about 2-3 min. to implement the > tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do > the same job in the Windows version...!! Georg Acher responded >Maybe you had just bad luck, PPR never does the same routing again >(except you set the seed=... option). If PPR is swapping all the time, >your disk cache (SMARTDRV) is maybe too big, so there's not much memory >left for PPR, that can cause 'trashing'... Then you should set the DOS-box >priority to 90-100, if you really want quick results. Philip Freidin writes: Actually, PPR does do the same routing unless the control variable router_effort is set to 3 ( or maybe 4, I'm not sure). The default is 2, and that will route the same way each time, given the same design and placement. it is not seed dependent. The swapping is a MUCH more likely scenario. This unfortunately is highly dependent on how you setup a DOS extended memory manager. for example, if you are using QEMM, it will try and supply both EMS and XMS services, and will default to 8 megabytes of XMS, regardless of whether you have 16Mb or 32 Mb of memory. I was unable to get the combination of Windows For Workgroups (WFW V3.11) , XACT STEP 6.0, and QEMM (V6, V6.02, V7, V7.5, I will never buy QEMM again, they can go shove their V8.0 upgrade offer where the sun doesnt .. ... ..) to work togther well enough to do any worthwhile testing. It ran extremely slow, like your 3 minute job that now takes an hour. I run WFW 3.11 and XACT STEP 6.0 with the himem.sys and emm386.exe and the the long place and route times went away and it ran in pretty much the same time as the older V5.1 programs. Georg's suggestion about thrashing is also possible. I like using the command mem /c to find out whats happening to my memory. This can also be real informative inside a DOS box in windows. Pierre Cluzel wrote: > Is my machine badly configured or Xactstep is really too slow ? Georg wrote >The new WIR2XNF.EXE is deadly slow, it takes about 5-10 times longer to >convert the files than in V5.1. My harddisk is heavy accessed (sounds like >the seek-tests...) and nothing helps to speed it up, no matter whether I >use DOS, WINDOS, even SMARTDRIVE with 16MB cache didn't help :-( No I use >the old WIR2XNF ;-) Philip Freidin writes: I found EXACTLY the same behaviour with WIR2XNF, 10 times slower than the prior version. As I said above, only WIR2XNF has this problem, the rest of the programs run about the same as the prior versions (which for me is acceptable). I also have solved the problem by continuing to use the V5.1 version of WIR2XNF. During the beta testing of the 6.0/5.2 version of the software, this was not the case, but unfortunately there were other issues that caused a change to the way WIR2XNF was built, and this change caused the execution time problem. I reported it to Xilinx, but unfortunately the CDs were already in mass production. Georg writes >That's my general complaint about the XACT-tools: They are too slow. Even >on a Pentium/100 it takes about 30-40 seconds from starting PPR until it >starts with placing. XNFPREP always needs 40s, no matter if it's just a >design with one gate or 4000 gates. The funny colorfull new 'flow manager' >is a nice gimmick, but when I have my makefile, I run it from DOS with >xmake, because it's faster... Philip Freidin writes: I have learnt to live with the start up times, and like Georg, i run my stuff under DOS, with batch files (which is fairly similar to xmake, only faster). Mike Siersema writes: >We used Xact 6.0 windows version and we discovered that it is too slow. >Upon the advice of industry experts utilizing FPGA's, we do not compile >our designs in the windows version because it is too slow. Philip Freidin writes: Who are these experts??? I want to meet some :-) Mike Siersema writes: >Futhermore, ProSim is not usable. Simulating in ProSim is a nightmare. >Some of our functional simulations (simulations done before routing) would >take 20 minutes to update on the screen and if you wanted to print the >waveform of zoom in to a specific time period, that would take another 20 >minutes to update. I called the Xilinx support line to confirm that this >windows version is too slow and they agreed. Philip Freidin writes: Prosim and Procapture are the V5.1.1 escape (sorry, release) that I mentioned above that I dont use. Much of the problems I had with Prosim were related to the above mentioned memory problems. When I fixed the memory problems, I found that Prosim ran almost exactly the same as the prior DOS version of the software (Viewlogic's version 4.13, released by Xilinx in V5.0, V5.1). Mike Siersema writes: >The solution to your problem is to use Workview 5.1.0 dos version for >your functional simulations and Procapture for your schematic capture. >You can use any dos editor for your ABEL files. You can compile and merge >in any dos version of Xact. Philip Freidin writes: Unfortunately Procapture has some functional problems that I cant live with. These are in the domain of the 'save as' command (previously the 'writeto' command) and the importing of design databases from prior versions. both of these are fundamentally broken. So I use the 4.13 (Xilinx V5.1) Viewdraw and viewsim, together with the V5.2 programs from the 5.2/6.0 release, all under DOS. Mike Siersema writes: >The real question is how will Xilinx create a more user friendly FPGA >compile and simulation system without compromising too much speed. If >they do not create better software, somebody will. I believe all the speed issues are DOS/Windows configuration related, and the actual run times are within a few percent of each other (except WIR2XNF). I am far more worried about the loss of functionality for the power user who relies on complex project scripts and other tools, as well as the management of legacy designs. I dont particularly want to keep a copy of each and every release around, because as the software is (like in hollywood) dumbed-down to make it easier for new users to use, mission critical capabilities are going by the wayside (i.e. batch control, backward compatibility, execution performance, ...) Lance Gin wrote: >bonjour pierre, >we are a new xilinx customer and are about to embark on the design of an >XC4025E (a relatively large xilinx device). i can't give you any details >since we don't have any experience yet. however, i can tell you that when >i called the xilinx tech hotline and asked for a platform recommendation, >they told me that they highly recommend we use xact 5.2 (unix) rather than >xact 6.0 (PC). apparantly, some customers have been experiencing performance >problems on P5 PC's with 64mb+ RAM. I do believe xilinx is recommending a >minimum of 64Mb RAM (don't know details on swap setup). hope this helps. Philip Freidin writes (again) And my recomendation is for a new user to use 6.0 to get familiar with the tools, and if it works for you, then keep going. if not then the 5.2 programs under DOS are also an option. I have done a 4025E designs on a Pentium (tm) 90MHz, with 32MB ram. I used 80% of the chip, almost no I/O and it took about an hour to place and route. it used 22MB of dynamic memory, ontop of the 3MB of baseline memory. Your mileage will vary. 64MB on a sun is probably somewhat safer. I dont have a 64MB PC to let you know how well the sw runs. Is this the longest article I have written???Article: 3031
ecla@world.std.com (alain arnaud) wrote: >Pierre Cluzel (cluzel@ipnl.in2p3.fr) wrote: >: I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several >: years) and my first work has been to test the software with the tutorial >: example CALC.1. >: I have never experienced crashes during schematic editing but the >: implementation software is very VERY SLOW . My machine configuration is >: : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows >: Version 3.1. >: PPR running with DOS (xdm) takes about 2-3 min. to implement the >: tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do >: the same job in the Windows version...!! >: Is my machine badly configured or Xactstep is really too slow ? >: Could some people do the same test and reply me the result for >: comparision and eventually modify my configuration files. > The max difference in performance between running under dos or > or window should be between 10-15%. that is xact5.2 under dos will > be that much faster on average than xact 6.0 under windows. > this seems that the problem is probably due to either low > conventional memory or a small swap space. Initial beta versions > of XACT 6.0 were 30% slower than xact5.2 but that got fixed before > the production release. > --Alain Arnaud Please tell me more, this guy has 32M Ram installled, so what conventional memory are you refering to, since Xilinx has always used memory extenders? We too have had to put version 6.0 away because it was so slow. So please tell me what machine and what your settings were/are to get performance that is only 10-15% slower. BTW, just for grins explain why it's acceptable to have it (version 6.0) run slower under any conditions. Thanks.Article: 3032
In article <4id1dg$caj@bolivia.it.earthlink.net>,
David F. Spencer <starfire2@earthlink.net> wrote:
>Hi everyone.
>
>We're using the Actel Act2 family of FPGAs and I was wondering if anyone
>had any experiences with them (good or bad). The chip we're
>specifically using is the 1240A. It seems to be fairly capable but it
>has a lot of drive limitations, etc. Are these typical of other FPGA
>vendors?
>
Hi David...
I have had good experiences with the Act2 parts. Once you get over the
hurdle of "non-reprogramable", they are an excellent workhorse part.
We often use 100% of the logic modules and implement brand new designs
into fixed PCBs (no pinout problems). The P&R software works well.
The simple cell structure (4 input mux) is easy to optimize your design
for. Although we only push the parts to 40+ Mhz, there is lots of
headroom especially with their new XL parts (half the price, twice the
speed ;)..
We did spend some upfront work on dealing with the long input hold and
output delay timing. Turns out that a minimum pin2pin path closely
tracks the clock tree prop delay. Using a cheap PLL gives us an easily
integratable part (but puts bounds on freq range).
Guess I'm an advocate
Eric Pearson.
>
--
Eric Pearson -- Focus Systems -- Waterloo, Ontario
ecp@focus-systems.on.ca (519) 746-4918
"We Engineer Innovative Imaging Solutions"
Article: 3033In article <4hnr7o$svp@solaris.cc.vt.edu>, >Has anyone considered C's bit-field members? Sure, they're only valid in struct >declarations, but if the user is going to explicitly code for 13-bit values, he/she >can cope with accessing a structure's member. > >The following is valid ANSI C code: [...] I always thought that Ada covered this area very well. It even permits specification of floating AND fixed point. See Chapter 13 of the Ada LRM. -- Steve -- 3/18/96Article: 3034
In article <4hnpp3$ems@fs7.ece.cmu.edu>, Herman Schmit <herman@galant.ece.cmu.edu> wrote: >Steve Casselman (sc@temp.vcc.com) wrote: >: > From: ejessen@ix.netcom.com (Erik Jessen) >: > >: > 1) Try implementing everything in VHDL, > >: This is fine for new programs but I want to be able to port the >: "billions and billions" of lines of code already out there. > >Steve, > >Abandon all hope of porting compute-intensive code to reconfigurable >machines. I've looked at a lot of integer-oriented, compute-intensive >algorithms, and although you can often get whiz-bang speed-ups using >FPGAs, you can't do it from the C code written for a CPU. The more >compute-critical something is, the more people pound on it, and the >more machine-specific the code gets. [...] I agree that using "dusty deck" code may not be a good idea. But one of the interesting aspects of reconfigurable logic based computing is that you don't have to map an algorithm to a sequence of arbitrary operations (instructions). You can start with the high level (and hopefully simple) algorithm, and map it directly to the hardware. The "sound bite" here is that you can map the architecture to the algorithm. Instruction set processors require that you map the algorithm to the architecture. The former should be simpler and more efficient. -- Another Steve -- 3/18/96Article: 3035
We have a couple of small design projects where we use the in-circuit reconfigurable CPLDs MAX9320 and MAX9560 from Altera. Everything works fine until we are trying to download the design data via the Bitblaster. It seems like the download is extremely sensible to noise since we observed that only 1 out of 5 download attempts succeed (as reported by post-download verification of the MAX+plusII v6.0 programmer). We allready added small capacitors to the download wires (50 pF) and - as suggested by Altera support - also added pull-up/pull-down and serial resistors. None of these measures improved the robustness of the download procedure. Naturally, we tried several devices and boards so that device or board defects are not to blame for the troubles. Has anybody faced this kind of problem before or has an idea what may cause the problems? Thanks, Andre' -- --------------------------------------------------------------------------- Andre' Klindworth Universitaet Hamburg, FB Informatik klindwor@informatik.uni-hamburg.de Vogt-Koelln-Str.30, D-22527 Hamburg http://tech-www.informatik.uni-hamburg.de/Personal/klindwor/Klindworth.htmlArticle: 3036
I know Xilinx people read/participate here regularly. Would they like
to comment on the issue discussed please?
---------------------------------------------------
Oleg Sheynin |Fisher & Paykel
sheynin@fp.co.nz |Production Machinery Ltd.
|PSC Section
Phone +64-9-535 0676 |P.O. Box 58-223, Greenmount
Fax +64-9-535 0661 |Auckland, New Zealand
---------------------------------------------------
Article: 3037In article <4ijvmj$ado@rzsun02.rrz.uni-hamburg.de> klindwor@tech17.informatik.uni-hamburg.de (Andre Klindworth) writes: > >We have a couple of small design projects where we use the >in-circuit reconfigurable CPLDs MAX9320 and MAX9560 from >Altera. Everything works fine until we are trying to download >the design data via the Bitblaster. It seems like the download >is extremely sensible to noise since we observed that only 1 >out of 5 download attempts succeed (as reported by post-download verification >of the MAX+plusII v6.0 programmer). We allready added small >capacitors to the download wires (50 pF) and - as suggested by >Altera support - also added pull-up/pull-down and serial resistors. >None of these measures improved the robustness of the download >procedure. Naturally, we tried several devices and boards so that >device or board defects are not to blame for the troubles. >Thanks, >Andre' Go get a fast scope (500 MHz DSO), ground it with a very short line to the chip ground, and then look at the rising AND falling edges of the configuration clock signal, at the chip pins. Set the scope fast enough to see 2 to 4 nS weirdness during the rising and falling edges. If you see anything other than monotonic transitions, then this is where to start. You may need to either terminate the clock line, or buffer it locally to the CPLD. You should also check the data transitions, with regard to setup and hold to the clock's rising edge. Check also any pin that starts or resets the programming function, and make sure they dont have glitches on them. Also check VCC and make sure it is clean, and within spec. Monitor it (at the chip) during configuration. Good luck Philip FreidinArticle: 3038
We use Altera MAX9000 CPLDs for a couple of designs, but have a lot of troubles with downloading the configuration data via the Bitblaster. On average, only one out of 5 programming attempts succeed. 80% of the downloads end up with a "Device not in socket" or verification errors. We allready added small capacitors (50 pF) an serial as well as pull-up/pull-down transistors to the download wires, but none of these measures increased the robustness of the programming procedure. Naturally, we tried different boards to exclude device or board errors. Has anybody experienced similar problems or has an idea what may go wrong? Any help/suggestions appreciated. Cheers, Andre'. -- --------------------------------------------------------------------------- Andre' Klindworth Universitaet Hamburg, FB Informatik klindwor@informatik.uni-hamburg.de Vogt-Koelln-Str.30, D-22527 Hamburg http://tech-www.informatik.uni-hamburg.de/Personal/klindwor/Klindworth.htmlArticle: 3039
Last week, Herman Schmit <herman@galant.ece.cmu.edu> posted an article with
a simple integer square root function written in C and Verilog. Just for
fun, I thought I'd try the C version out with the Transmogrifier C compiler.
I made the minimal changes necessary to re-write it in tmcc's subset of C.
The modified source is below. I then had to fix not one, but two bugs in
the compiler (good example, Herman!).
I compiled the program for 3 different sizes of inputs and outputs, and
used Altera's MaxPlus 6.0 to fit the netlist into one of their new 10K50
parts. These are the results, according to MaxPlus:
Input bits/Output bits LCs FFs cycle time (ns)
32/16 1275 263 278
16/8 626 135 172
8/4 289 71 127
An LC is what Altera calls a 4 bit lookup table and FF combination.
Approximately one half of a Xilinx 4000 CLB.
The cycle time is pretty long, since the compiler is trying to cram these three
cascaded additions, a subtraction and an optional addition all into the
same cycle:
n = (u + u + v) << l2;
n += u2;
if (n <= N) {
u += v;
I also tried adding some statements to the program to break up that long
combinational path, hoping to decrease the cycle time (while increasing
the number of cycles). That version of the code is also below, and the
results are:
Input bits/Output bits LCs FFs cycle time (ns)
32/16 1249 298 155
16/8 610 154 96
8/4 283 82 60
In the first, minimally modified version, the circuit does a square root in
roughly 2 * log2(input) cycles. In the second version, the circuit takes
roughly 4 * log2(input) cycles.
So now, does anyone have a Verilog compiler that can handle Herman's Verilog
version ? The only Verilog compiler I can find here is a rather old one
of Exemplar's, and it won't synthesize while statements. I'd be interested
in any results.
Here is the tmcc code for the first version of the circuit, in the 32/16 size
(32 bit arguments, 16 bit results):
/****************************************************************************
*
* Filename: binomial.c
* Original Author: Peter Heinrich, Dr Dobbs Journal, April 1996.
*
*****************************************************************************/
#pragma intbits 16
int
sqroot(N)
#pragma intbits 32
int N;
{
int l2, t, u, v, u2, n;
if (2 > N)
return N;
t = N;
l2 = 0;
while (t >>= 2)
l2++;
u = 1 << l2;
v = u;
u2 = u << l2;
while (l2--) {
v >>= 1;
n = (u + u + v) << l2;
n += u2;
if (n <= N) {
u += v;
u2 = n;
}
}
return (u);
}
main() {
int i,t;
outputport(t);
while(1) {
i = 4;
while(i<50) {
t = sqroot(i);
i++;
}
t = sqroot(0xffffffff);
}
}
Here is the modified version with a faster clock, but more clock cycles:
/****************************************************************************
*
* Filename: binomial.c
* Original Author: Peter Heinrich, Dr Dobbs Journal, April 1996.
*
*****************************************************************************/
#define TICK while(0);
#pragma intbits 16
int
sqroot(N)
#pragma intbits 32
int N;
{
int l2, t, u, v, u2, n;
if (2 > N)
return N;
t = N;
l2 = 0;
while (t >>= 2)
l2++;
u = 1 << l2;
v = u;
u2 = u << l2;
while (l2--) {
v >>= 1;
n = (u + u + v) << l2;
TICK;
n += u2;
TICK;
if (n <= N) {
u += v;
u2 = n;
}
}
return (u);
}
main() {
int i,t;
outputport(t);
while(1) {
i = 4;
while(i<50) {
t = sqroot(i);
i++;
}
t = sqroot(0xffffffff);
}
}
And here, in case anyone wants to try a Verilog compiler, is Herman's Verilog:
module main;
function [15:0] sqroot;
input [31:0] N;
reg [31:0] l2, t, u, v, u2, n;
if (2 > N)
sqroot = N[15:0];
else
begin
l2 = 0;
t = N;
t = t >> 2;
while(t > 0)
begin
l2 = l2 + 1;
t = t >> 2;
end
u = 1 << l2;
v = u;
u2 = u << l2;
while (l2>0)
begin
l2 = l2 - 1;
v = v >> 1;
n = (u + u + v) << l2;
n = n + u2;
if (n <= N)
begin
u = u + v;
u2 = n;
end
end
sqroot = u[15:0];
end
endfunction
reg [31:0] i,t;
initial
begin
for(i= 4; i<50; i=i+1)
begin
t = sqroot(i);
$display("%d\t%d", i, t);
end
$display("%d\t%d\n", 32'hffffffff, sqroot(32'hffffffff));
end
endmodule
Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmcc
Article: 3040
In article <826915707.26778@codemast.demon.co.uk>
RichAp@codemast.demon.co.uk "Richard Aplin" writes:
"ejessen@ix.netcom.com (Erik Jessen) wrote:
"
">Altera has software that will do the auto-partitioning for you.
"
"Hmmm. I did a design about 3-4 years ago that used an Altera EPM7256, and
"eventually overflowed it. The software routed it onto two chips, but the bugger
"_never_ worked. I spent ages hand-wiring a new 2-chip prototype, about three
"times longer triple-checking EVERY connection, and it simply did nothing. It
"wasn't a speed problem, it wasn't a race condition, I even got some other guys
"in the states to build one, and I never did find out what the problem was. The
"solution? I re-did the whole thing using Actel FPGAs, which got it all on one
"chip, ran faster, and saved the project.
"
"Never bothered with Altera for anything except glue logic since. Mind you, the
"FLEX series might be ok.
"
"Just my $0.02.
"
I don't think you're being fair to Altera. Working on this
unforgiving basis, most people would run out of vendors quite early
in their careers!
Auspy looks to be a good partitioning system for Xilinx. Other
vendors are MINC (IST) who do good partitioning for Xilinx, Actel,
Altera FLEX, AMD MACH and Crosspoint; and ACEO, who I don't know
much about.
The main problem with partitioning is that the pin-to-logic ratio of
today's FPGAs is too small, so don't expect to get the high device
utilization that a single device solution affords, since the
partitioner runs out of IO pins way before other device resources.
However, in situations where filling isn't really an issue (such as
ASIC prototyping), it's a valuable technique.
David Pashley
Article: 3041
Yves Bernard wrote:
> En ce moment, je suis en train d'évaluer ce produit pour des applications
> avec PLD de la compagnie ATMEL comme la famille 750 et 1500.
>
> J'ai effectué des tests pour voir si le même projet conçu graphiquement
> (Senario) ou par des équations (ABEL-HDL) aurait les mêmes résultats.
> <snip summary ABEL good for little PLDs, Schematics may be good for FPGA>
>
> Néanmoins, il y a une chose qui m'a beaucoup choqué du produit: La
> librairie de gates ne comprenait pas d'inverseur tri-state ou de "CMOS
> transmission GATE" aussi appelé "complementary pair"
Pardon responding in English, my French is too rusty and whatever I
say may be quite unreadable.
I work on Synario and submitted an enhancement request based on my translation:
=========================
Bug BUGno12572 synario10 Enclosure 1 of 1
Library
Found off comp.arch.fpga 3/15/96
Yves Bernard <elexrnd@CAM.ORG
Neanmoins, il y a une chose qui m'a beaucoup choque du produit: La
librairie de gates ne comprenait pas d'inverseur tri-state ou de "CMOS
transmission GATE" aussi appele "complementary pair"
Loosely translated with my rusty old french:
There is one large problem with the product: The
library of gates does not have tri-state inverters or the "CMOS
transmission gate" also called "complementary pair"
=======================
I can't promise you when the libares will be corrected, but we heard you.
We presently have the following systems available in Synario
Schematics
ABEL
VHDL
You can mix them somewhat, that is, you can have a hierarchical set of
schematics with VHDL or ABEL modules in them.
I consider ABEL to be like Assembly language, it was designed for PLDs
and has all sorts of tricks in it to handle the types of feedbacks
and logic seen in PLDs as you have mentioned.
Using a language like VHDL allows you to write more complex systems
but at the exspense of having less control over the details (like writing
in C++.
Schematics tend to be a mixed bag. We support libraries to map designs
directly to particular FPGA devices. But if you use our "Generic" library,
you may lose some fine tuning of details but we can ususally remap
your design quickly to a totally different FPGA architectures.
We are in a constant cycle of improving our system and we gladly
accept enhancement requests like these.
You could submit ideas etc directly to us at dsa@data-io.com
We also have a web page http://www.data-io.com that is presently
undergoing a rebuild but you can request a 30-day evaluation system
through it.
(its our true shipping product with a limited-time security key).
Adam Zilinskas
aez@data-io.com
http://www.data-io.com/~aez/
Article: 3042
Dear Colleagues,
Enclosed below is the advance program for the 1996 ACM/SIGDA
Physical Design Workshop, which is co-sponsored the U.S. National
Science Foundation.
This year's workshop will emphasize deep-submicron and
high-performance issues, and will also feature a special track on
micro electromechanical systems (MEMS), chaired by Ken Gabriel of ARPA.
Please note that the the hotel room reservation deadline is March 24
so please reserve your hotel room soon.
For more information, please see our WWW home page at:
http://www.cs.virginia.edu/~pdw96/
Please pass along this advance program to your collagues.
Thanks,
Gabe
======================================================
Name: Prof. Gabriel Robins
General Chair, PDW'96
U.S. Mail: Department of Computer Science
Thornton Hall
University of Virginia
Charlottesville, VA 22903-2442
Phone: (804) 982-2207
FAX: (804) 982-2214
E-mail: robins@cs.virginia.edu
WWW: http://www.cs.virginia.edu/~robins/
======================================================
=============================================================================
ADVANCE PROGRAM
Fifth ACM/SIGDA Physical Design Workshop
April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA
http://www.cs.virginia.edu/~pdw96/
The ACM/SIGDA Physical Design Workshop (PDW'96) provides a relaxed
atmosphere for exchange of ideas and promotes research in critical
subareas of physical design for VLSI systems.
This year's workshop emphasizes deep-submicron and high-performance
issues, and also provides a special focus on opportunities in CAD for
micro electromechanical systems (MEMS). There are four outstanding
panel sessions:
(1) future needs and directions for deep-submicron physical design,
(2) physical design needs for MEMS,
(3) manufacturing and yield issues in physical design, and
(4) critical disconnects in design views, data modeling, and back-end
flows (e.g., for physical verification).
There are also many outstanding technical paper sessions.
Free-flowing discussion will be promoted through the limited workshop
attendance, the poster session and the "open commentary" mechanism in
each technical session, as well as a concluding open problems session.
During the workshop, a benchmarks competition will occur in the areas
of netlist partitioning and performance-driven cell placement.
=============================================================================
SUNDAY, APRIL 14
=============================================================================
6:00pm-8:30pm: Registration
(the registration desk will also be open 8:00am-5:00pm on Monday
and 8:00am-12:00pm on Tuesday)
7:00pm-8:30pm: Reception (refreshments provided)
=============================================================================
MONDAY, APRIL 15
=============================================================================
8:30am-8:40am: Welcome
8:40am-10:00am: Session 1, Timing-Driven Interconnect Resynthesis
Interconnect Layout Optimization by Simultaneous Steiner Tree
Construction and Buffer Insertion, T. Okamoto and J. Cong (UC Los Angeles)
Simultaneous Routing and Buffer Insertion for High Performance
Interconnect, J. Lillis, C.-K. Cheng and T.-T. Lin (UC San Diego)
Timing Optimization by Redundancy Addition/Removal, L. Entrena, E. Olias
and J. Uceda (U. Carlos III of Madrid and U. Politecnica of Madrid)
Open Commentary - Moderators: D. Hill (Synopsys),
P. Suaris (Interconnectix)
10:00am-10:20am: Break
10:20am-12:00pm: Session 2, Interconnect Optimization
Optimal Wire-Sizing Formula Under Elmore Delay Model,
C. P. Chen, Y. P. Chen and D. F. Wong (U. Texas Austin)
Reducing Coupled Noise During Routing, A. Vittal and M. Marek-Sadowska
(UC Santa Barbara)
Simultaneous Transistor and Interconnect Sizing Using General
Dominance Property, J. Cong and L. He (UC Los Angeles)
Hierarchical Clock-Network Optimization, D. Lehther, S. Pullela,
D. Blaauw and S. Ganguly (Somerset Design Center and Motorola)
Open Commentary - Moderators: D. Hill (Synopsys),
M. Lorenzetti (Mentor)
12:00pm-2:00pm: Lunch
Workshop Keynote Address: Prof. C. L. Liu, U. of Illinois
Algorithmic Aspects of Physical Design of VLSI Circuits
2:00pm-2:45pm: Session 3, A Tutorial Overview of MEMS
Speaker: K. Gabriel (ARPA)
2:45pm-3:00pm: Break
3:00pm-4:15pm: Session 4, Physical Design for MEMS
Physical Design for Surface Micromachined MEMS, Gary K. Fedder and
Tamal Mukherjee (Carnegie-Mellon U.)
Physical Design Support for MCNC/MUMPS, R. Mahadevan (MCNC)
Synthesis and Extraction for MEMS Design, E. Berg, N. Lo and
K. Pister (UC Los Angeles)
4:15pm-4:30pm: Break
4:30pm-6:00pm: Session 5, Panel: Physical Design Needs for MEMS
Moderator: K. Pister (UC Los Angeles)
Panelists include:
S. Bart (Analog Devices)
G. Fedder (Carnegie-Mellon U.)
K. Gabriel (ARPA)
I. Getreu (Analogy)
R. Grafton (NSF)
R. Mahadevan (MCNC)
J. Tanner (Tanner Research)
6:00pm-8:00pm: Dinner
8:00pm-9:30pm: Session 6, Panel: Deep-Submicron Physical Design:
Future Needs and Directions
Panelists include:
T. C. Lee (former VP Eng, SVR; President/CEO, Neo Paradigm Labs)
L. Scheffer (Architect, Cadence)
W. Vercruysse (UltraSPARC III CAD Manager, Sun)
M. Wiesel (Design Manager, Intel)
T. Yin (VP R&D, Avant!)
=============================================================================
TUESDAY, APRIL 16
=============================================================================
8:30am-9:50am: Session 7, Partitioning
VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement
Techniques, S. Dutt and W. Y. Deng (U. Minnesota and LSI Logic)
A Hybrid Multilevel/Genetic Approach for Circuit Partitioning,
C. J. Alpert, L. Hagen and A. B. Kahng (UC Los Angeles and Cadence)
Min-Cut Replication for Delay Reduction, J. Hwang and A. El Gamal
(Xilinx and Stanford U.)
Open Commentary - Moderators: J. Frankle (Xilinx),
L. Scheffer (Cadence)
9:30am-10:10am: Break
10:10am-11:50am: Session 8, Topics in Hierarchical Design
Two-Dimensional Datapath Regularity Extraction, R. Nijssen and
J. Jess (TU Eindhoven)
Hierarchical Net Length Estimation, G. Zimmermann (U. Kaiserslautern)
Exploring the Design Space for Building-Block Placements Considering
Area, Aspect Ratio, Path Delay and Routing Congestion, H. Esbensen and
E. S. Kuh (UC Berkeley)
Genetic Simulated Annealing and Application to Non-Slicing Floorplan
Design, S. Koakutsu, M. Kang and W. W.-M. Dai (Chiba U. and UC Santa Cruz)
Open Commentary
11:50pm-1:30pm: Lunch
1:30pm-3:00pm: Session 9, Poster Session
Physical Layout for Three-Dimensional FPGAs, M. J. Alexander, J. P.
Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins (U. of Virginia)
Efficient Area Minimization for Dynamic CMOS Circuits, B. Basaran
and R. Rutenbar (Carnegie-Mellon U.)
A Fast Technique for Timing-Driven Placement Re-engineering,
M. Hossain, B. Thumma and S. Ashtaputre (Compass Design Automation)
Computer Aided Micro-Machining for Wet Etch Fabrication,
M. K. Long, J. W. Burdick and T. J. Hubbard (Caltech)
Over-the-Cell Routing with Vertical Floating Pins, I. Peters, P. Molitor
and M. Weber (U. Halle and Deuretzbacher Research GmbH)
Congestion- Balanced Placement for FPGAs, R. Sun, R. Gupta and C. L. Liu
(Altera and U. Illinois)
Fanout Problems in FPGA, K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu
(UC Santa Barbara and Actel)
An Optimal Pairing and Chaining Algorithm for Layout Generation,
J. Velasco, X. Marin, R. P. Llopis and J. Carrabina (IMB-CNM
U. Autonoma de Barcelona, Philips Research Labs Eindhoven)
Clock-Delayed Domino in Adder and Random Logic Design, G. Yee and
C. Sechen (U. Washington)
3:00pm-4:00pm: Session 10, Manufacturing/Yield Issues I
Layout Design for Yield and Reliability, K. P. Wang, M. Marek-Sadowska
and W. Maly (UC Santa Barbara and Carnegie-Mellon U.)
Yield Optimization in Physical Design, V. Chiluvuri (Motorola)
(invited survey paper)
4:00pm-4:15pm: Break
4:15pm-5:45pm: Session 11, Panel: Manufacturing/Yield Issues II
Panelists include:
V. Chiluvuri (Motorola)
I. Koren (U. Massachusetts Amherst)
J. Burns (IBM Watson Research Center)
W. Maly (Carnegie-Mellon U.)
5:45pm-7:30pm: Dinner
7:30pm-9:30pm: Session 12, Panel: Design Views, Data Modeling and
Flows: Critical Disconnects
A Talk by C. Sechen (U. Washington)
A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph
and Tile Expansion Approach, H.-P. Tseng and C. Sechen (U. Washington)
A Multi-Layer Chip-Level Global Route, L.-C. E. Liu and C. Sechen
(U. Washington)
Panelists include:
W. W.-M. Dai (UC Santa Cruz, VP Ultima Interconnect Technologies)
L. Jones (Motorola)
D. Lapotin (IBM Austin Research Center)
E. Nequist (VP R&D, Cooper & Chyan)
R. Rohrer (Chief Scientist, Avant!)
P. Sandborn (VP, Savantage)
=============================================================================
WEDNESDAY, APRIL 17
=============================================================================
8:30am-9:50am: Session 13, Performance-Driven Design
A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven
Placement Problems, G. Tellez, D. A. Knol and M. Sarrafzadeh
(Northwestern U.)
Reduced Sensitivity of Clock Skew Scheduling to Technology Variations,
J. L. Neves and E. G. Friedman (U. Rochester)
Multi-Layer Pin Assignment for Macro Cell Circuits, L.-C. E. Liu and
C. Sechen (U. Washington)
Open Commentary
9:50pm-10:10pm: Break
10:10am-11:30am: Session 14, Topics in Layout
Constraint Relaxation in Graph-Based Compaction, S. K. Dong, P. Pan,
C. Y. Lo and C. L. Liu (Silicon Graphics, Clarkson U., Lucent, U. Illinois)
An O(n) Algorithm for Transistor Stacking with Performance Constraints,
B. Basaran and R. Rutenbar (Carnegie-Mellon U.)
Efficient Standard Cell Generation When Diffusion Strapping is Required,
B. Guan and C. Sechen (Silicon Graphics and U. Washington)
Open Commentary - Moderator: A. Domic (Cadence)
11:30am-12:00pm: Session 15, Open Problems
Moderators: A. B. Kahng (UC Los Angeles), B. Preas (Xerox PARC)
12:00pm-2:00pm: Lunch (and benchmark competition results)
2:00pm: Workshop adjourns
=============================================================================
TRAVEL AND ACCOMODATIONS
=============================================================================
PDW '96 is being held at the Sheraton Reston in Reston, Virginia, near
Washington, D.C. The hotel is minutes from Dulles International
Airport (IAD), and 24-hour courtesy shuttles are available from the
airport to the hotel. The area is also served by Washington National
Airport (DCA), about 20 miles away, and Baltimore-Washington
International Airport (BWI), about 50 miles away.
The Sheraton Reston is located at:
11810 Sunrise Valley Drive
Reston, Virginia 22091
phone: 703-620-9000
fax: 703-860-1594
reservations: 800-392-ROOM
*** Please make your room reservation directly with the Reston ***
*** Sheraton hotel. ***
Driving directions from Dulles Airport: take the Washington Dulles
Access and Toll Road (route 267) to the Reston Parkway Exit (3). Turn
right at the light after paying toll. Take the next left onto Sunrise
Valley Drive, and continue for a couple blocks to the Sheraton (on
your left).
A block of rooms is being held for the nights of Sunday through
Wednesday (April 14 through April 17). Room rates are $95 per night
for single occupancy, and $105 per night for double occupancy. The
number of rooms available at these rates is limited, and they are only
being held through March 24 (so early registration is highly recommended).
The Washington D.C. weather tends to be chilly in April, so warm dress
is suggested for the outdoors.
=============================================================================
SIGHTSEEING AND ATTRACTIONS
=============================================================================
The Nation's Capitol offers much in the way of sightseeing. The most
popular destinations are located in downtown Washington D.C.,
surrounding several square miles of park area known as the "National
Mall." There is no charge to visit the National Memorials located on
the Mall, which include the Washington Monument, where you may ascend
555 feet to an observation post; the Lincoln Memorial, whose design
adorns the back of the US penny; the Jefferson Memorial, which
includes a 19-foot bronze statue of Thomas Jefferson; and the Vietnam
Memorial, a long wall of black Indian granite dedicated in 1982.
The Smithsonian Institution (telephone (202) 357-2700) operates a
number of superb museums that flank the National Mall, including:
Freer Gallery of Art (Asian and 19th and 20th-century American art)
Hirshhorn Museum and Sculpture Garden (modern and contemporary art)
National Air and Space Museum (history of aviation and space exploration)
National Museum of African Art (collection and study of African art)
National Museum of American Art (paintings, graphics, and photography)
National Museum of American History (technology and culture in America)
National Museum of Natural History (history of the natural world)
National Portrait Gallery (portraits of distinguished americans)
National Postal Museum (history of postal communication and philately)
Sackler Gallery of Asian art (from ancient to present)
Other attractions and tours around the D.C. area include (please call
the numbers below for schedules):
Arlington National Cemetary (703) 697-2131
Bureau of Engraving and Printing (202) 622-2000
Congressional buildings (202) 225-6827
FBI Headquarters (202) 324-3447
Library of Congress (202) 707-5000
National Aquarium (202) 482-2825
National Archives (202) 501-5000
National Zoological Park (202) 673-4821
The Pentagon (703) 695-1776
Supreme Court (202) 479-3030
Treasury Department (202) 622-2000
The White House (202) 456-7041
There are a number of reasonably priced eating places on the Mall; the
East Wing of National Gallery and the Air and Space Museums offer good
food and a place to sit down after sightseeing. Provisions will be
made for low-cost transportation to and from the Mall and downtown
Washington D.C., so bring your camera and strolling shoes and enjoy
our Nation's Capital!
=============================================================================
WORKSHOP ORGANIZATION
=============================================================================
General Chair:
G. Robins (U. of Virginia)
Technical Program Committee:
C. K. Cheng (UC San Diego)
J. P. Cohoon (U. of Virginia)
J. Cong (UC Los Angeles)
A. Domic (Cadence)
J. Frankle (Xilinx)
E. Friedman (Rochester)
D. Hill (Synopsys)
L. Jones (Motorola)
A. B. Kahng (UC Los Angeles, Chair)
Y.-L. Lin (Tsing Hua)
K. Pister (UC Los Angeles)
M. Marek-Sadowska (UC Santa Barbara)
C. Sechen (Washington)
R.-S. Tsay (Avant!)
G. Zimmermann (Kaiserslautern)
Steering Committee:
M. Lorenzetti (Mentor Graphics)
B. Preas (Xerox PARC)
Keynote Address:
C. L. Liu (Illinois)
Benchmarks Co-Chairs:
F. Brglez (NCSU)
W. Swartz (TimberWolf Systems)
Local Arrangements Chair:
M. J. Alexander (U. of Virginia)
Treasurer:
S. B. Souvannavong (HIMA)
Publicity Chair:
J. L. Ganley (Cadence)
Sponsors:
ACM / SIGDA
U.S. National Science Foundation
Avant! Corporation
=============================================================================
WORKSHOP REGISTRATION
=============================================================================
Fifth ACM/SIGDA Physical Design Workshop
April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA
Name: _______________________________________________________________
Company/University: _________________________________________________
Title: ______________________________________________________________
Address: ____________________________________________________________
City: _________________________________________ State: ______________
Phone: ____________________________ Email: __________________________
Registration Fees (Includes All Meals)
Advance (Through April 1) Late (After April 1/On-Site)
ACM Members __ $355 __ $440
Non-ACM __ $455 __ $540
Students __ $250 __ $250
ACM Membership Number: _____________________________
Dietary restrictions, if any: ______________________
Special needs: _____________________________________
The registration fee includes the workshop proceedings and all meals
(i.e., 3 breakfasts, 3 lunches, and 2 dinners), refreshments during
breaks, and a reception on Sunday evening. The total number of
attendees is limited (registrations will be returned if the workshop
is oversubscribed).
*** Note: Hotel reservations must be made directly with the Sheraton ***
*** (see above). ***
The only acceptable forms of payment are checks (personal, company,
and certified/bank checks) in US funds drawn on a US bank and made
payable to "1996 Physical Design Workshop" (credit cards will not be
accepted). Payment must accompany your registration. No FAX or Email
registrations will be processed.
Please mail your payment (checks only) along with this registration form to:
Sally Souvannavong, Treasurer
1996 ACM/SIGDA Physical Design Workshop
Department of Computer Science
Thornton Hall
University of Virginia
Charlottesville, VA 22903-2442 USA
Phone: (804) 982-2200
Email: pdw96@cs.virginia.edu
Cancellations must be in writing and must be received by March 31, 1996.
=============================================================================
The Latex and postscript versions of this advanced program may be
obtained from http://www.cs.virginia.edu/~pdw96/
=============================================================================
Article: 3043I'm looking for an FPGA or EPLD to replace about a dozen CMOS MSI and SSI parts. I expect to need about 40 I/Os. A very important requirement is that the power consumption falls to typical static CMOS levels (tens of microamps) when the clock is stopped. I've noticed that the Altera Classic EP910 and EP1810 seem to meet this requirement (in non-turbo mode), but I'm wondering if there are others I should consider. Availability of bare die and a few Schmitt inputs would be significant bonuses, too. Any suggestions are appreciated. Thanks, Joe -- Joe Hass | library clever_sigs; | My opinions are my own kjhass@sandia.gov | use rock_and_roll.verses.ALL; | not Sandia's and Sandia National Labs | use lineprinter.art.ALL; | not the DOE'sArticle: 3044
My experience is with Altera. Typically I see the 8K designs compile and place and route in about 10-15 minutes for an 81188. (somewhere between an 4010 and a 4013). The SW is a real 32-bit application on the PC. I have a P90 and 32 Mbyte of RAM, with a 32 Mbyte swap space, running NT. For me, time is money. TArticle: 3045
IMPORTANT NEWS Re: DSP World Expo & Data Acquisition Expo. '96
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Due to the continued growth and success of DSP World Expo. and
Data Acquisition Expo. significant changes have been made in the
schedule for the '96 event, and in our organization.
New Dates and Location for ICSPAT'96 & DSP World Expo.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ICSSPAT'96 - DSP World Expo. and Data Acquisition Expo. '96
October 8-10, 1996 in Boston, MA
World Trade Center
To lern more about these developments you can reference the press
release on DSPnet. http://www.dspnet.com under the events section
--------------------------------------------------------------------
Call for Papers
____________________________________________________________________
Technical Review Committee: | ***** CALL FOR PAPERS *****
__________________________ |
|
Dr. David Almagor | ICSPAT 96
National Semiconductor, USA |
| The 7th International Conference on
| Signal Processing Applications & Technology
Dr. Filiz Basbug |
Coherent Comm. Systems, USA | featuring
|
Mr. John Carbone | DSP WORLD EXPO & Data Acquisition Expo
Orincon, USA |
|
Dr. Sathish Chandran, | Boston MA, USA
Univ. of Nottingham, UK |
|
Dr. Aziz Chihoub |
Siemens Corp. Research, USA | Application Areas:
| ~~~~~~~~~~~~~~~~~
Dr. Prabhakar Chitrapu |
Dialogic Corp., USA | Active Noise Control, Adaptive DSP Algorithms,
| Advanced TV Technology, Aerospace, ASIC DSPs,
Mr. Jerry Doty | Audio, Automotive, Biomedical, Comm & Telephony
DSP Software Eng., USA | Consumer Products, Data Acquisition, Data Comm.
| Digital Filter Implementation, DSP Algorithms,
Mr. John Edwards | DSP Architectures, DSP Machines, DSP Software
Loughboro Sound Images, UK | Tools, DSP Technology, Geophysical, HLL Tools,
| Image Analysis, Image Coding, Image Understand-
Dr. Mohammed El-Sharkawy | ing, Industrial Applications, Industrial Control
Purdue University, USA | Instrumentation & Testing, Multi-processor Arch
| Multimedia, Native Signal Processing, Neural Net
Mr. Jose Fridman | Parallel Processing, Radar, Radio SATCOM & NAV,
Northeastern Univ., USA | Rapid Prototyping, Robotics, Soft. Programming,
| Software Tools, Specialized Applications, Speech
Dr. Mark Grosen | Processing,Transportation, Underwater/SONAR,
Spectron Microsystems,USA | Virtual Reality, VLSI Architectures.
| ...... and more.
Dr. Pierre Jouvelot |
ENSMP, France | Mail, Fax, email 400-word abstract
| by April 22, 1996 to:
Mr. James M. Kresse |
JKJ Associates, USA |
| Miller Freeman
Dr. Sen Kuo | 600 Harrison Street
Northern Illinois Univ, USA | San Francisco,CA 94107
| Tel: (415)356-3391
Mr. Noam Levine | Fax: (415)905-2220
Analog Devices, USA | E-mail: dsp@mfi.com
|
Dr. Jian Lu | Attention: Megan Forrester
L. Livermore Lab., USA |
|
Mr. Stuart McGarrity | To be eligible for consideration, abstracts must
3L LTD, UK | include the name, address, telephone, fax and e-mail
| (when available) of each author.
Dr. Peter Nagy |
Nat'l Def. Res. Est. Sweden | E-mail submissions should come in simple text format
| (not encoded)
Mr. Jay Reimer |
Texas Instruments, USA |
| Please include suggested application area:
Dr.Hemchandra Shertukde |
University of Hartford, USA | (If your abstract is accepted, the final area
| of applications will be determined by the
Mr. Peter Siy | technical review committee)
White Mountain DSP, USA |
|
Dr. Tarun Soni |
NASA-Ames Res. Ctr.., USA | Papers presented in conference will be published
| in ICSPAT's Proceedings.
Dr. Tomohiko Taniguchi |
Fujitsu Labs. Ltd., Japan | -----------------------------------------------
|
Mr. Theodore C. Tanner, Jr. |
National Semiconductor, USA | ICSPAT - DSP World EXPO
|
Mr. Jonathan Thorn | World Trade Center
Texas Instruments, USA |
| October 7-10, 1996
Mr. Vojin Zivojnovic, |
Aachen Univ. of Tec. Ger. | Boston, MA USA
Article: 3046In article <sheynin.119.000D65E4@fp.co.nz> sheynin@fp.co.nz (OS) writes: >From: sheynin@fp.co.nz (OS) >Subject: Re: Xact6.o too slow >Date: Mon, 18 Mar 1996 13:23:47 >I know Xilinx people read/participate here regularly. Would they like >to comment on the issue discussed please? Since this was posted two days ago, I assume they are waiting for a job to finish routing before responding. :-) Steve. ---------------------------------------------------------- Very funny Scotty ! Now beam down my clothes. Steve Baldwin At work : baldwins@fp.co.nz Development Engineer in life : steveb@kcbbs.gen.nz Fisher & Paykel PSC 4/18 Fencible Dr, Howick ph. +64 9 535-0679 Auckland, New Zealand fax. +64 9 535-0661 I speak for myself. The company thinks my opinions suck. ----------------------------------------------------------Article: 3047
Joe Hass wrote: > > I'm looking for an FPGA or EPLD to replace about a dozen CMOS > MSI and SSI parts. I expect to need about 40 I/Os. A very > important requirement is that the power consumption falls to > typical static CMOS levels (tens of microamps) when the clock > is stopped. I've noticed that the Altera Classic EP910 and > EP1810 seem to meet this requirement (in non-turbo mode), but > I'm wondering if there are others I should consider. > Xilinx XC3000L (3.3V) family parts have the lowest spec'd Q currents I've seen (30uA max), and unlike the Altera EPxxx parts, their operating currents are a product of gate count and the switching frequency of those gates (like CMOS MSI and SSI). XC3000A (5V) are around 500uA Q. The Altera parts actually turn themselves off after some period (100ns or so I think) of inactivity on all inputs. When any input changes state, the entire part comes back to life at full operating current. So if you have a single input clocking at 10MHz the part will draw full rated power, even if the rest of the device is quiet. Altera does have SRAM based FPGA's similar in nature to the Xilinx parts, but I don't know their Q currents. There are some true "zero-power" PALS out there, but they aren't as dense as you require. Actel's antifuse parts are also low/linear power consumers, but I think (not sure) their Q currents are similar to XC3000A. QuickLogic may be in the same class. In general you will find that SRAM and (Anti)Fuse based FPGA's have low Q currents and EPROM/Flash based FPGA's do not. Remember that the SRAM based parts must be loaded from some external source and that's another Q current you must consider. Xilinx has app notes describing how to unpower the configuration PROM after configuration, so it's Q current can be eliminated. If you find something else in the range of the XC3000L let me know, I have interest in ultra-low power designs as well. Regards, ScottArticle: 3048
drg@cs.toronto.edu wrote:
> Last week, Herman Schmit <herman@galant.ece.cmu.edu> posted an article with
> a simple integer square root function written in C and Verilog. Just for
> fun, I thought I'd try the C version out with the Transmogrifier C compiler.
>
> I made the minimal changes necessary to re-write it in tmcc's subset of C.
> The modified source is below. I then had to fix not one, but two bugs in
> the compiler (good example, Herman!).
>
> I compiled the program for 3 different sizes of inputs and outputs, and
> used Altera's MaxPlus 6.0 to fit the netlist into one of their new 10K50
> parts. These are the results, according to MaxPlus:
>
> Input bits/Output bits LCs FFs cycle time (ns)
>
> 32/16 1275 263 278
> 16/8 626 135 172
> 8/4 289 71 127
On the other hand, if you spend a couple of hours to analyze the
algorithm and code it in a form that works well with FPGAs,
you get a circuit (for the 16/8 case) that fits into 12 PFUs
(about 48 Altera LCs) in an ORCA chip and can run at 20ns cycle
times. Here is a register shorthand summary of the circuit.
It consists of a 4-bit counter, a 24-bit registered mux, an 8-bit register,
and a 10-bit subtracter. A C-language coding of the algorithm
is at the end of this article.
Bit[3:0] := Count4 <Reset=LOAD> <Clken=/Bit3> // Hold at count==8
N[15:0] := LOAD ? Din[15:0] : N[13:0],0,0 // 16-bit mux
N[23:16] := Carry ? Sub[7:0] : N[21:14] // 8-bit mux
R[7:0] := R[6:0],Carry;
<Reset=LOAD> <Clken=/Bit3> // 8-bit register
Sub[9:0] == N[23:14] - R[7:0],0,1; <Cout=Carry>// 10-bit subtract
What does this demonstrate? Many people have suggested that a goal
is to compile "dusty-deck" code into FPGAs and capitalize on the
zillions of lines of C that already exist. I think that it's very
unlikely that this is a useful goal. I think most people will be
willing to do substantial work to make their algorithms run
much-much faster.
Eperiments on theoretical physicists have shown them willing to
learn new programming languages (C instead of FORTRAN) and re-code
their algorithms if the speed up is significant.
Here is the C code:
#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)
{ 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 (Rt);
}
main()
{ unsigned int I,R;
for (I=255; I--;)
{ R= Root(I*I);
if (I>=30 && I<40) printf("I= %3d I*I= %6d R=%3d\n",I,I*I,R);
if (R != I) printf("Error: Root was %d should be %d\n",R,I); }
}
Article: 3049I wrote: > On the other hand, if you spend a couple of hours to analyze the > algorithm and code it in a form that works well with FPGAs, > you get a circuit (for the 16/8 case) that fits into 12 PFUs > (about 48 Altera LCs) in an ORCA chip and can run at 20ns cycle > times. And if you're willing to risk looking like a complete geek, you might observe that you could completely unroll the loop and come up with a circuit that uses 24 ORCA PFUs and computes the full 16/8-bit square root in 87 ns. (This circuit relies heavily on the ORCA FE-MUX and would translate to about 140 Altera LCs or 70 Xilinx-4000 CLBs)
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