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
Jordan Swartz wrote: > > Does anyone have some "real" BIG benchmark circuits? http://vlsicad.cs.ucla.edu/~cheese/ispd98.html -- ====================================================================== name : Jo Depreitere | "Real stupidity defeats artificial e-mail : jdp@elis.rug.ac.be | intelligence every time" (T. Pratchett) ======================================================================Article: 11051
Thanks for your response. Philip Freidin wrote: > > While some of the following may seem somewhat negative, please keep in > mind that your post asks about level of interest in your resarch, and > what we as end users would be willing to pay. Therefore, given the > reality of what silicon is actually available, your above statement that > your target is similar to XC4000EX/XL, indicates that it is not identical > to XC4000EX/XL. That means it does not exist. True, if we wanted to sell a commercial tool if would have to target the XC4000E/XL exactly.(otherwise it would be useless.) To investigate routing algorithms (the purpose of my MSEE) it wasn't necessary to capture a "real" architecture exactly. Technically, it would not have been difficult to capture the XC4000E/XL exactly, it would just take a lot of time to figure out the location of every single switch.(not really what I wanted to spend my research time doing.) The simplifications we made were mainly with logic block architecture and the I/O pad connections, which don't affect the routing problem too much. We did capture most of routing architecture. Of course, we cannot even try to compare to commercial tools such as Xilinx's M1. We do compare to one of the best academic routers available, VPR (www.eecg.toronto.edu/~vaughn/vpr/vpr.html), which we target to the exact same architecture. > > > Probably not. 20% is about a speed grade, and that can cost 20% to 30% on > the chips. I only have to do place and route "once", but I pay for the > silicon over and over. If one looks at the time spent doing a project, > the place and route time is only an issue if you are waiting for it. I > might spend several days to a week doing some part of a design and then > do a trial place and route. As I have posted recently on another thread, > this typically is 1.5 hours for a fairly full 4062 (about 4600 LUTs). > Since I seem to have basically linear route time to design size, I could > expect to see this go up to 6 to 10 hours if we are talking about 20000 > LUTs. One of the reasons I do trial place and routes it to detect > placement/floorplanning errors, and timing challenges. So maybe what you > are proposing to create would suit me for the trials (yes I would prefer > 5 minutes to 10 hours to find out that I have a timing problem), but I > would still want all the available performance the chip can deliver, so a > final route with a tool that doesn't sacrifice performance would still be > needed. It seems that a lot of designers would only use a high-speed tool during the design/prototyping stage, and then switch the slower, high-quality tool for the final compile.Article: 11052
Thanks for the pointer to the benchmark page. Unfortunately, all of the functionality information has been removed, making it very difficult to technology map these circuits. Jordan Swartz. Jo Depreitere wrote: > > Jordan Swartz wrote: > > > > Does anyone have some "real" BIG benchmark circuits? > > http://vlsicad.cs.ucla.edu/~cheese/ispd98.html > > -- > ====================================================================== > name : Jo Depreitere | "Real stupidity defeats artificial > e-mail : jdp@elis.rug.ac.be | intelligence every time" (T. Pratchett) > ======================================================================Article: 11053
Jordan Swartz <jsswartz@eecg.utoronto.ca> wrote in article <35ACC96F.81B02965@eecg.utoronto.ca>... >It seems that a lot of designers would only use a high-speed tool during the >design/prototyping stage, and then switch the slower, high-quality tool >for the final compile. I think the problem with this methodology is that you don't know if the high-quality tool will get your timing where it needs to be until it is too late possibly. For example, say you use the fast router all throughout the design/prototype all the while assuming that the slow router will meet your timing in the end, then you are in trouble when it doesn't because you may have to go back and re-architect the design to make it faster. That invalidates the work you did on with the prototype because it was a different archtecture. Placement and routing can only improve your timing so much. Many timing fixes involve logic changes, some big and some small; the sooner you know about needing them, the better. All that being said, I think that improved routing algorithms is a great research area! There is a lot of room for improvement in what you are calling "high quality" tools both in speed and quality of results. Place and route is a very difficult problem in general and I sure hope that the current state of the art tools are not the best that are possible. A great deal more intelligence needs to be put into these tools. Another area of improvement is to somehow build into the synthesis/place/route algorithms the ability to make quick deltas off of an existing design. For example, the last Xilinx project I did it took about 15 or so hours for synthesis/place/route if I made major changes or if I just literally changed one gate. I liken this to building an entire skyscraper and at the end you realize one of the lightbulbs doesn't fit the fixture on the 45th floor. What's the solution? Tear down the entire building to the foundation and start again, this timing making sure to put the correct light fixture on the 45th floor. P.S. I know Xilinx has a feature called Guide Design that is supposed to use your last version as a guide to speed up place and route but it doesn't work. -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 11054
It looks similar to 4b/5b encoding. It might be usefull looking up that topic on the web as I think (IIRC) there is an XOR solution to this. [snip] >Below is a four bit example although our requirements are for something >larger: >Input > Transform >0000 > 0000 >0001 > 1000 >0010 > 1000 >0011 > 1100 >0100 > 1000 >0101 > 1010 >0110 > 1100 >0111 > 1110 >1000 > 1000 >1001 > 1001 >1010 > 1010 >1011 > 1011 >1100 > 1100 >1101 > 1101 >1110 > 1110 >1111 > 1111 [snip]Article: 11055
I need a hardware implementation to find a unique number for a bit pattern that is shifted. Below is a four bit example although our requirements are for something larger: Input > Transform 0000 > 0000 0001 > 1000 0010 > 1000 0011 > 1100 0100 > 1000 0101 > 1010 0110 > 1100 0111 > 1110 1000 > 1000 1001 > 1001 1010 > 1010 1011 > 1011 1100 > 1100 1101 > 1101 1110 > 1110 1111 > 1111 Obvisously, all I did here was to shift the input pattern until it maximised. The output of the transform is shift invarient, ie. 0001 maps to the same number as 0100. We are considering doing this,shifting and testing for max, however, it takes a lot of clock cycles. I would rather have a logic gate solution. A look-up-table approach is too costly for the input width we have in mind. The transform can also compress data, for example, the 4 bit example above has 16 input vectors and maps to only 10 outputs. Thanks in Advance, Brad Smallridge www.sightech.comArticle: 11056
Brad Smallridge wrote: > > I need a hardware implementation to find a unique number for a bit pattern > that is shifted. > Below is a four bit example although our requirements are for something > larger: > Input > Transform > 0000 > 0000 > 0001 > 1000 > 0010 > 1000 > 0011 > 1100 > 0100 > 1000 > 0101 > 1010 > 0110 > 1100 > 0111 > 1110 > 1000 > 1000 > 1001 > 1001 > 1010 > 1010 > 1011 > 1011 > 1100 > 1100 > 1101 > 1101 > 1110 > 1110 > 1111 > 1111 > Obvisously, all I did here was to shift the input pattern until it > maximised. The output of the transform is shift invarient, ie. 0001 maps to > the same number as 0100. We are considering doing this,shifting and testing > for max, however, it takes a lot of clock cycles. I would rather have a > logic gate solution. A look-up-table approach is too costly for the input > width we have in mind. The transform can also compress data, for example, > the 4 bit example above has 16 input vectors and maps to only 10 outputs. > Thanks in Advance, > Brad Smallridge > www.sightech.com -- This is a problem that has been designed many times before. This is the same as the normalization step in a floating point add/sub. You count the leading zeros in the mantissa and shift left the result. This consists of two circuits; one to count the leading zeros, and a barrel shifter to shift the data by the count amount. The barrel shifter is trivial to design although it will take a lot of gates to implement as the word size gets large. I don't remember the best way to design the leading zero counter, but I can suggest one that will work. The brute force method is to add the zeros one bit at a time masking all bits after a one is detected... (be sure to view with a monospaced font) MSB LSB | | | | | | | +--O +--O +--O +--O | |---|-|--R->---|-|--R->---|-|--R--> o o o ---|-|--R->---| | | | | | | | | | | | | INV NOR NOR NOR NOR NOR | __|__ __|__ __|__ __|__ __|__ SHIFT | | | | | | | | | | | COUNT +-| + |===>| + |===>| + |===> ==| + |===>| + |===> |_____| |_____| |_____| |_____| |_____| OUTPUT The count that comes out will be 5 bits wide. This will have a slow ripple time. But that can be sped up by performing parts of the computation in parallel like a carry look ahead adder. It would take too long to draw the ascii art, but by doing the calcs in parallel, I figure that you can do a 16 bit version of this circuit in 17 CLBs with a max 6 CLB delay in a Xilinx 4000 series part. This could run at about 40 to 50 MHz as a rough guess. Of course it can run faster if you can tolerate pipeline delays, over 100 MHz. If you need more help with this, please email me. Perhaps I can find some references for you. Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 11057
Brad Smallridge wrote: > I need a hardware implementation to find a unique number for a bit pattern > that is shifted. Below is a four bit example although our requirements are for > something larger: > Input > Transform > 0000 > 0000 > 0001 > 1000 > 0010 > 1000 > 0011 > 1100 > 0100 > 1000 > 0101 > 1010 > 0110 > 1100 > 0111 > 1110 > 1000 > 1000 > 1001 > 1001 > 1010 > 1010 > 1011 > 1011 > 1100 > 1100 > 1101 > 1101 > 1110 > 1110 > 1111 > 1111 > Obvisously, all I did here was to shift the input pattern until it > maximised. The output of the transform is shift invarient, ie. 0001 maps to > the same number as 0100. We are considering doing this,shifting and testing > for max, however, it takes a lot of clock cycles. I would rather have a > logic gate solution. A look-up-table approach is too costly for the input > width we have in mind. The transform can also compress data, for example, > the 4 bit example above has 16 input vectors and maps to only 10 outputs. > Thanks in Advance, > Brad Smallridge > www.sightech.com Brad, This is basically the same as normalization for floating point. What you need to do is find the position of the first one in the input, encode it, then use that code to control an arithmetic barrel shift. The first one detect can be done quickly using the carry logic in a Xilinx 4kE part. For an 8 bit recoder, you are looking at about 20 CLBs, and 16 bits is about 44 CLBs. Pipelined, this baby should sing along with a data rate of around 95 Mhz for 16 bits in a -1 part (the speed is limited by the length of the carry chain) if you floorplan the design. If you want to use more CLBs, you can improve the pipelined speed to over 120 MHz. Hope this helps! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka Andraka Consulting Group, Inc is a hardware design firm specializing in high performance FPGA designs for signal processing, computing and control applications. Recent designs include radar signal processing, physical modeling and imaging applications.Article: 11058
Some clarification here. The first one detect can be done using a tree structure built out of 4-LUTs. The tree is log4(n+1) deep followed by the encode. For the xilinx 4K architecture, the carry chain is more compact and provides a faster combinatorial result for reasonable data widths. However, if you are willing to accept additional pipeline latency and a higher CLB count, the 4-LUT tree can be made very fast by using the registers at each level. Using this scheme, the data rate can be well over 120 MHz in a -1 part, more or less independent of the data width (there is some slowing down due to longer routes in the tree for wider data, but none for the logic between registers). The carry chain propagation is opposite the arithmetic chain, so in 4kEX and 4kXL parts the data bits have to be reversed (which is a real pain in the tail for floating point designs). The CLB counts listed in the previous post are for the complete circuit. > Brad, > This is basically the same as normalization for floating point. What you need > to do is find the position of the first one in the input, encode it, then use > that code to control an arithmetic barrel shift. The first one detect can be > done quickly using the carry logic in a Xilinx 4kE part. For an 8 bit recoder, > you are looking at about 20 CLBs, and 16 bits is about 44 CLBs. Pipelined, this > baby should sing along with a data rate of around 95 Mhz for 16 bits in a -1 > part (the speed is limited by the length of the carry chain) if you floorplan > the design. If you want to use more CLBs, you can improve the pipelined speed > to over 120 MHz. Hope this helps! > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11059
Jordan Swartz wrote: > > Thanks for the pointer to the benchmark page. Unfortunately, all of > the functionality information has been removed, making it very > difficult to technology map these circuits. You have a point there. Maybe you could contact the author of the paper who might have a reference to the "functional" circuits. If so, let me know too ;) -- ====================================================================== name : Jo Depreitere | "Real stupidity defeats artificial e-mail : jdp@elis.rug.ac.be | intelligence every time" (T. Pratchett) ======================================================================Article: 11060
Hello, I'm looking for information about FPGA devices with partial reprograming. I found one DL6000 from Dynachip. I heard about programme/family chip called "Raphael" from Xilinx. Where can I find any info about it? Regards, Pawel E. Tomaszewicz Warsaw University of Technology phone: +48 22 6607894 Institute of Telecommunications fax: +48 22 8254950 Nowowiejska 15/19 email: ptomasze@tele.pw.edu.pl 00-665 Warsaw, POLAND ICQ# 9364632Article: 11061
Hi, Looking for good info about the Texas Instruments TMS320C6x DSPs? Please check out my website: http://www.scs.ch/~andrew/c6x.html Here you'll find: - latest documentation and silicon availability info. - heaps of stuff about HW and SW design with these DSPs - application notes - comprehensive bug list - commercially available 'C6x processor boards and lots of other stuff ..... Have a look and please send me any comments. Don't forget to join my mailing list if you want to be notified when the site is updated ... Cheers, Andrew Phillips Supercomputing Systems AG Zurich, SwitzerlandArticle: 11062
Actually, You can roll the first-one detect into the barrel shift if you set up the shifter so that the shifts get progressively smaller. If this is the case then an OR gate sensing the top n bits before each level in the barrel shift is used to control the shift at that level. For the case Brad presented, the first level of barrel shift shifts the input by 2 bits if the two msbs of the input are zero or passes it unchanged if not. The next level shifts the input by one bit if the msb out of the first shift is a zero, or passes it unchanged if it is a one. This can be extended to the number of bits required. Fully pipelined, this will run at the 120MHz + data rates I advertised in my previous posts. The 16 bit case then takes about 36 CLBs and the worst case path is through 5 or 6 CLBs depending on how you do the leading bit sense for the first shift. I've used this circuit both in Xilinx and Altera with very good results. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11063
Hi! I'm looking for an introduction to floorplanning for FPGA designs. Can anyone suggest a good reference? I'm designing for a Xilinx 4028EX using Synplify and Xilinx M1.4.12 for NT. Thanks! -steveArticle: 11064
Greetings, I am working on an application that uses the Xilinx PCI LogiCore and a XC4013E-PQ208-2 to provide a PCI interface for a video capture/processing card. I was wondering if anyone had the 'ping' bit file for this component and package combination so I could see if my Linux box can even deal with this before I dive head-first into it. Also, any personal tales of sorrow or success dealing with the PCI LogiCore would be appreciated. Thanks in advance. -- Tony L. Keiser The Department of Electrical and Computer Engineering The University of Illinois in Urbana-Champaign <a href="http://www.students.uiuc.edu/~akeiser">Lame Page</a>Article: 11065
Steven W Schlosser wrote: > Hi! > > I'm looking for an introduction to floorplanning for FPGA > designs. Can anyone suggest a good reference? I'm designing for a > Xilinx 4028EX using Synplify and Xilinx M1.4.12 for NT. Thanks! > > -steve I can't say that I've seen any literature on the art of floorplanning. Unfortunately really good floorplanning is more of an art than a science. That should not discourage the neophyte however, as even basic floorplanning can have dramatic results. The goal is of course to place the logic in ways that make the routing easier, less congested and shorter. As a starting point, you might let the tool do the place and route. After it is finished, read the placed design into the floorplan tool and start looking for ways you can improve the layout. The first thing you will probably notice is how awful the automatic placers really are. For Xilinx designs you will have to get a hold of XACT6. There is a beta floorplanner for M1.4, but it is really not ready for prime time yet. In my opinion, there is not enough info supplied with the beta floorplanner for someone who is not already familiar with the xact6 floorplanner to use it. Anyway, get a copy of xact 6 and look at the on-line documentation for the floorplanner. Play with the tool using a simple design (a design with some RPMs and loose logic is probably the best) with an eye toward minimimizing the complexity of the interconnect. The Altera MAX PLUS tools also have a floorplanner, which I think is a little harder to use than the xilinx one. Fortunately, the routing structure on the Altera device makes it less sensitve to having a good floorplan (and less capable for really high performance stuff). Beyond playing with a few designs, I can't really offer any advice. Floorplanning is rather like putting together a jigsaw puzzle, except that there are a large number of solutions. Because of that, it takes a little bit of an artist's eye to do it well. When you get down to it, I find that some people have a knack for it, while others just don't. To be honest, most of us who advocate floorplanning have been doing it long before the floorplan tools were available (we used up a lot of graph paper and pencils). Play with the tools on as many designs as you can. As you gain familiarity with the architecture and the tool, you will start to recognize what works and what doesn't. As with the arts, there is no substitute for natural talent. Fortunately, engineers tend to be good puzzle solvers, so there is hope. I'm sorry I couldn't offer more help than this. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11066
On Wed, 15 Jul 1998 17:25:01 -0700, "Brad Smallridge" <manbike@smallridge.xo.com> wrote: >I need a hardware implementation to find a unique number for a bit pattern >that is shifted. >Below is a four bit example although our requirements are for something >larger: >Input > Transform >0000 > 0000 >0001 > 1000 >Obvisously, all I did here was to shift the input pattern until it >maximised. The output of the transform is shift invarient, ie. 0001 maps to >the same number as 0100. We are considering doing this,shifting and testing >for max, however, it takes a lot of clock cycles. Priority encoder controlling a barrel shifter. Fast and (using n-level m-way muxes for the barrel shift) fairly cheap. If you need help with the priority encoder, look at the 74148. - BrianArticle: 11067
>>Brad Smallridge wrote: >> I need a hardware implementation to find a unique number for a bit pattern that is shifted. >> Below is a four bit example although our requirements are for something larger: >> Input > Transform >> 0000 > 0000 >> 0001 > 1000 >> 0010 > 1000 >> 0011 > 1100 >> 0100 > 1000 >> 0101 > 1010 >> 0110 > 1100 >> 0111 > 1110 >> 1000 > 1000 >> 1001 > 1001 >> 1010 > 1010 >> 1011 > 1011 >> 1100 > 1100 >> 1101 > 1101 >> 1110 > 1110 >> 1111 > 1111 >> Obvisously, all I did here was to shift the input pattern until it maximised. >> The output of the transform is shift invarient, ie. 0001 maps to >> the same number as 0100. >> We are considering doing this,shifting and testing >> for max, however, it takes a lot of clock cycles. I would rather have a >> logic gate solution. A look-up-table approach is too costly for the input >> width we have in mind. >> The transform can also compress data, for example, >> the 4 bit example above has 16 input vectors and maps to only 10 outputs. >> Thanks in Advance, >> Brad Smallridge >> www.sightech.com >Rickman wrote in message <35AD5129.9D2E0F6D@yahoo.com>... >This is a problem that has been designed many times before. This is the >same as the normalization step in a floating point add/sub. You count >the leading zeros in the mantissa and shift left the result. This >consists of two circuits; one to count the leading zeros, and a barrel >shifter to shift the data by the count amount. The barrel shifter is >trivial to design although it will take a lot of gates to implement as >the word size gets large. I don't remember the best way to design the >leading zero counter, but I can suggest one that will work. > >The brute force method is to add the zeros one bit at a time masking all >bits after a one is detected... (be sure to view with a monospaced font) > >MSB LSB > | | | | | | > | +--O +--O +--O +--O | > |---|-|--R->---|-|--R->---|-|--R--> o o o ---|-|--R->---| | > | | | | | | | | | | | >INV NOR NOR NOR NOR NOR > | __|__ __|__ __|__ __|__ __|__ SHIFT > | | | | | | | | | | | COUNT > +-| + |===>| + |===>| + |===> ==| + |===>| + |===> > |_____| |_____| |_____| |_____| |_____| OUTPUT > >The count that comes out will be 5 bits wide. This will have a slow >ripple time. But that can be sped up by performing parts of the >computation in parallel like a carry look ahead adder. > >It would take too long to draw the ascii art, but by doing the calcs in >parallel, I figure that you can do a 16 bit version of this circuit in >17 CLBs with a max 6 CLB delay in a Xilinx 4000 series part. This could >run at about 40 to 50 MHz as a rough guess. Of course it can run faster >if you can tolerate pipeline delays, over 100 MHz. > >If you need more help with this, please email me. Perhaps I can find >some references for you. > >Rick Collins >rickman@XYwriteme.com > >remove the XY to email me. Hmm. Good start but consider these two bit fields: 01100011010 01101011000 which, would shift only once according to your algorithm, but are non-the-less shift invarient equivalent. Brad Smallridge www.sightech.comArticle: 11068
--------------90284AF4547CB53A4A041A61
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Registration for
1998 Military and Aerospace Applications of
Programmable Devices and Technologies Conference
The conference will address devices, technologies, usage, reliability,
fault tolerance, radiation susceptibility, and applications of
programmable devices and adaptive computing systems in military and
aerospace systems. The technical program will consist of oral technical
presentations, a poster session, as well as industrial exhibits. The
conference will be held at the NASA Goddard Space Flight Center in
Greenbelt, Maryland.
Conference information, including the registration form, local
accommodations, and a preliminary program with author abstracts are
available at:
http://rk.gsfc.nasa.gov
Additionally, we have 4 excellent invited speakers (abstracts available
on-line):
Dennis Andrucyk - NASA/Goddard Space Flight Center
"Achieving the Earth Science Vision"
Janet L. Barth - NASA/GSFC
"An Overview of the Radiation Environment for
Spaceflight Electronics"
John Birkner - VP, Co-founder, QuickLogic Corp
"From Simple PALs to High-Speed, High-Density Leading
Edge FPGA's, Their Technologies and Applications"
Jose Munoz - DARPA, Adaptive Computing Systems
"DARPA'S Adaptive Computing Systems (ACS) Program"
The conference will be divided into 4 sessions:
1. Military & Aerospace Applications
2. Devices
3. Adaptive Computing
4. Radiation Effects
General Conference topics include the following:
- Programmable Technologies and State-of-the-Art Devices
A. COTS and MIL/AERO
B. New Technology Development
C. Adaptive Computing Systems
- Radiation Effects, Device Reliability and Element Characteristics
- Device Architecture, Performance, and Capabilities
- Applications and Novel Techniques for Military and Spaceflight
Circuits.
A. Signal Processing
B. High-Speed Designs
C. System Impact of State-of-the-Art Technologies
D. Reconfigurable Processing
E. Low Power Designs
F. Advanced Packaging
- Use of COTS Devices in the Military and Spaceflight Environment
A. PEMS
B. Shielding, Latchup Protection
C. SEE including SEFI and Destructive Effects
D. System Protection
- Testing and Analysis Techniques
- Performance Results
- Use of Programmables in Critical Systems
- Software Tools for Design/Analysis
A. Synthesis
B. Macro Generators
C. Timing Analysis and Simulation
D. Redundancy, Fault Tolerance, and SEU-Hardening
PRELIMINARY CONFERENCE SCHEDULE
September 14 NASA/GSFC Tours
Evening Registration, Happy Hour
September 15 Day 1 Technical Sessions and Industrial Exhibits
Dinner
September 16 Day 2 Technical Sessions and Industrial Exhibits
The conference is sponsored by: NASA/GSFC, JHU/Applied Physics
Laboratory, NSA, and the NASA Radiation Effects Program.
For more information on the conference please see
http://rk.gsfc.nasa.gov
Local Arrangements:
Janet Jew
janet.jew@gsfc.nasa.gov
Tel: (301) 286-5533
(301) 286-8884
Conference Chair:
Richard Katz
NASA Goddard Space Flight Center
rich.katz@gsfc.nasa.gov
Tel: (301) 286-9705
Conference Co-Chairs:
Alan W. Hunsberger
NSA
awhunsb@alpha.ncsc.mil
Tel: (301) 688-0292
Ann Darrin
Johns Hopkins University/Applied Physics Laboratory
ann.darrin@jhuapl.edu
Tel: (240) 228-4952
Ken A. LaBel
NASA Goddard Space Flight Center
ken.label@gsfc.nasa.gov
Tel: (301) 286-9936
--------------90284AF4547CB53A4A041A61
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<TT>
Registration for</TT><TT></TT>
<P><TT>
1998 Military and Aerospace Applications of</TT><TT></TT>
<P><TT>
Programmable Devices and Technologies Conference</TT>
<BR><TT></TT> <TT></TT>
<P><TT>The conference will address devices, technologies, usage, reliability,
fault tolerance, radiation susceptibility, and applications of programmable
devices and adaptive computing systems in military and aerospace systems.
The technical program will consist of oral technical presentations, a poster
session, as well as industrial exhibits. The conference will be held
at the NASA Goddard Space Flight Center in Greenbelt, Maryland.</TT><TT></TT>
<P><TT>Conference information, including the registration form, local accommodations,
and a preliminary program with author abstracts are available at:</TT><TT></TT>
<P><TT>
<A HREF="http://rk.gsfc.nasa.gov">http://rk.gsfc.nasa.gov</A></TT><TT></TT>
<P><TT>Additionally, we have 4 excellent invited speakers (abstracts available
on-line):</TT><TT></TT>
<P><TT> Dennis Andrucyk - NASA/Goddard
Space Flight Center</TT>
<BR><TT> </TT>
<BR><TT>
"Achieving the Earth Science Vision"</TT><TT></TT>
<P><TT> Janet L. Barth - NASA/GSFC</TT><TT></TT>
<P><TT>
"An Overview of the Radiation Environment for Spaceflight Electronics"</TT><TT></TT>
<P><TT> John Birkner - VP, Co-founder,
QuickLogic Corp</TT><TT></TT>
<P><TT>
"From Simple PALs to High-Speed, High-Density Leading Edge FPGA's, Their
Technologies and Applications"</TT><TT></TT>
<P><TT> Jose Munoz - DARPA, Adaptive
Computing Systems</TT><TT></TT>
<P><TT>
"DARPA'S Adaptive Computing Systems (ACS) Program"</TT><TT></TT>
<P><TT>The conference will be divided into 4 sessions:</TT><TT></TT>
<P><TT> 1. Military & Aerospace
Applications</TT><TT></TT>
<P><TT> 2. Devices</TT><TT></TT>
<P><TT> 3. Adaptive Computing</TT><TT></TT>
<P><TT> 4. Radiation Effects</TT>
<BR><TT></TT>
<BR><TT></TT> <TT></TT>
<P><TT>General Conference topics include the following:</TT><TT></TT>
<P><TT> - Programmable Technologies and State-of-the-Art
Devices</TT>
<BR><TT>
A. COTS and MIL/AERO</TT>
<BR><TT>
B. New Technology Development</TT>
<BR><TT>
C. Adaptive Computing Systems</TT><TT></TT>
<P><TT> - Radiation Effects, Device Reliability and Element
Characteristics</TT><TT></TT>
<P><TT> - Device Architecture, Performance, and Capabilities</TT><TT></TT>
<P><TT> - Applications and Novel Techniques for Military
and Spaceflight Circuits.</TT>
<BR><TT>
A. Signal Processing</TT>
<BR><TT>
B. High-Speed Designs</TT>
<BR><TT>
C. System Impact of State-of-the-Art Technologies</TT>
<BR><TT>
D. Reconfigurable Processing</TT>
<BR><TT>
E. Low Power Designs</TT>
<BR><TT>
F. Advanced Packaging</TT><TT></TT>
<P><TT> - Use of COTS Devices in the Military and Spaceflight
Environment</TT>
<BR><TT>
A. PEMS</TT>
<BR><TT>
B. Shielding, Latchup Protection</TT>
<BR><TT>
C. SEE including SEFI and Destructive Effects</TT>
<BR><TT>
D. System Protection</TT><TT></TT>
<P><TT> - Testing and Analysis Techniques</TT><TT></TT>
<P><TT> - Performance Results</TT><TT></TT>
<P><TT> - Use of Programmables in Critical Systems</TT><TT></TT>
<P><TT> - Software Tools for Design/Analysis</TT>
<BR><TT>
A. Synthesis</TT>
<BR><TT>
B. Macro Generators</TT>
<BR><TT>
C. Timing Analysis and Simulation</TT>
<BR><TT>
D. Redundancy, Fault Tolerance, and SEU-Hardening</TT>
<BR><TT></TT> <TT></TT>
<P><TT>PRELIMINARY CONFERENCE SCHEDULE</TT><TT></TT>
<P><TT>September 14 NASA/GSFC Tours</TT>
<BR><TT>
Evening Registration, Happy Hour</TT><TT></TT>
<P><TT>September 15 Day 1 Technical Sessions and Industrial
Exhibits</TT>
<BR><TT>
Dinner</TT><TT></TT>
<P><TT>September 16 Day 2 Technical Sessions and Industrial
Exhibits</TT>
<BR><TT></TT> <TT></TT>
<P><TT>The conference is sponsored by: NASA/GSFC, JHU/Applied Physics Laboratory,
NSA, and the NASA Radiation Effects Program.</TT>
<BR><TT></TT> <TT></TT>
<P><TT>For more information on the conference please see</TT><TT></TT>
<P><TT> <A HREF="http://rk.gsfc.nasa.gov">http://rk.gsfc.nasa.gov</A></TT>
<BR><TT> </TT><TT></TT>
<P><TT>Local Arrangements:</TT><TT></TT>
<P><TT>Janet Jew</TT>
<BR><TT>janet.jew@gsfc.nasa.gov</TT>
<BR><TT>Tel: (301) 286-5533</TT>
<BR><TT> (301) 286-8884</TT>
<BR><TT></TT> <TT></TT>
<P><TT>Conference Chair:</TT><TT></TT>
<P><TT>Richard Katz</TT>
<BR><TT>NASA Goddard Space Flight Center</TT>
<BR><TT>rich.katz@gsfc.nasa.gov</TT>
<BR><TT>Tel: (301) 286-9705</TT><TT></TT>
<P><TT>Conference Co-Chairs:</TT><TT></TT>
<P><TT>Alan W. Hunsberger</TT>
<BR><TT>NSA</TT>
<BR><TT>awhunsb@alpha.ncsc.mil</TT>
<BR><TT>Tel: (301) 688-0292</TT><TT></TT>
<P><TT>Ann Darrin</TT>
<BR><TT>Johns Hopkins University/Applied Physics Laboratory</TT>
<BR><TT>ann.darrin@jhuapl.edu</TT>
<BR><TT>Tel: (240) 228-4952</TT><TT></TT>
<P><TT>Ken A. LaBel</TT>
<BR><TT>NASA Goddard Space Flight Center</TT>
<BR><TT>ken.label@gsfc.nasa.gov</TT>
<BR><TT>Tel: (301) 286-9936</TT>
<BR><TT></TT> </HTML>
--------------90284AF4547CB53A4A041A61--
Article: 11069While I agree with Ray Andraka's response I just wanted to point out one thing. Why floorplan a 4028? The M1 routing engine combined with all the routing resource in the 4028 make floorplanning a questionable effort. Bigger Parts or old 4025s I can see but a 4028????? Some good timing constraints to drive the placement should be sufficient in most cases. Ray Andraka wrote: > Steven W Schlosser wrote: > > > Hi! > > > > I'm looking for an introduction to floorplanning for FPGA > > designs. Can anyone suggest a good reference? I'm designing for a > > Xilinx 4028EX using Synplify and Xilinx M1.4.12 for NT. Thanks! > > > > -steve > > I can't say that I've seen any literature on the art of floorplanning. > Unfortunately really good floorplanning is more of an art than a > science. That should not discourage the neophyte however, as even basic > floorplanning can have dramatic results. The goal is of course to place > the logic in ways that make the routing easier, less congested and > shorArticle: 11070
Carl Christensen <carl@philipsdvs.com> writes: > > Why floorplan a 4028? The M1 routing engine combined with all the routing > resource in the 4028 make floorplanning a questionable effort. Bigger Parts > or old 4025s I can see but a 4028????? > The design fits fine, but one portion has some really high fanout which is pushing the routing delays way way up. Right now it's being routed pretty dumbly and i was looking for ways of laying some things out more intelligently by hand. -steveArticle: 11071
Brad Smallridge wrote: > > >>Brad Smallridge wrote: > >> I need a hardware implementation to find a unique number for a bit > pattern that is shifted. > >> Below is a four bit example although our requirements are for something > larger: > >> Input > Transform > >> 0000 > 0000 > >> 0001 > 1000 > >> 0010 > 1000 > >> 0011 > 1100 > >> 0100 > 1000 > >> 0101 > 1010 > >> 0110 > 1100 > >> 0111 > 1110 > >> 1000 > 1000 > >> 1001 > 1001 > >> 1010 > 1010 > >> 1011 > 1011 > >> 1100 > 1100 > >> 1101 > 1101 > >> 1110 > 1110 > >> 1111 > 1111 > >> Obvisously, all I did here was to shift the input pattern until it > maximised. > >> The output of the transform is shift invarient, ie. 0001 maps to > >> the same number as 0100. > >> We are considering doing this,shifting and testing > >> for max, however, it takes a lot of clock cycles. I would rather have a > >> logic gate solution. A look-up-table approach is too costly for the input > >> width we have in mind. > >> The transform can also compress data, for example, > >> the 4 bit example above has 16 input vectors and maps to only 10 outputs. > >> Thanks in Advance, > >> Brad Smallridge > >> www.sightech.com > > >Rickman wrote in message <35AD5129.9D2E0F6D@yahoo.com>... > >This is a problem that has been designed many times before. This is the > >same as the normalization step in a floating point add/sub. You count > >the leading zeros in the mantissa and shift left the result. This > >consists of two circuits; one to count the leading zeros, and a barrel > >shifter to shift the data by the count amount. The barrel shifter is > >trivial to design although it will take a lot of gates to implement as > >the word size gets large. I don't remember the best way to design the > >leading zero counter, but I can suggest one that will work. > > > >The brute force method is to add the zeros one bit at a time masking all > >bits after a one is detected... (be sure to view with a monospaced font) > > > >MSB LSB > > | | | | | | > > | +--O +--O +--O +--O | > > |---|-|--R->---|-|--R->---|-|--R--> o o o ---|-|--R->---| | > > | | | | | | | | | | | > >INV NOR NOR NOR NOR NOR > > | __|__ __|__ __|__ __|__ __|__ SHIFT > > | | | | | | | | | | | COUNT > > +-| + |===>| + |===>| + |===> ==| + |===>| + |===> > > |_____| |_____| |_____| |_____| |_____| OUTPUT > > > >The count that comes out will be 5 bits wide. This will have a slow > >ripple time. But that can be sped up by performing parts of the > >computation in parallel like a carry look ahead adder. ...yadda, yadda, yadda... > Hmm. Good start but consider these two bit fields: > 01100011010 > 01101011000 > which, would shift only once according to your algorithm, > but are non-the-less shift invarient equivalent. > Brad Smallridge > www.sightech.com Brad, I may not understand your question. I thought you were asking for an IMPLEMENTAION of your agorithm to shift a bit pattern so that the most significant "one" bit ended up in the MSb posistion. I don't understand what you are saying about the two patterns above being "shift invarient equivalent". Can you explain that a little more? What result would you like to produce from the above patterns? -- Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 11072
Carl Christensen wrote: > While I agree with Ray Andraka's response I just wanted to point out one > thing. > > Why floorplan a 4028? The M1 routing engine combined with all the routing > resource in the 4028 make floorplanning a questionable effort. Bigger Parts > or old 4025s I can see but a 4028????? > Because the placement algorithm does a lousy job. If you don't believe me, run through a place and route on a simple data path design and then look at it in the floorplanner. The human brain is still the best placement engine out there. Even some basic floorplanning can provide a sizable advantage over the automatic placement in terms of timing, route congestion, repeatability of timing from route to route, and the time the router needs to work to get a solution. The routing improvements in the newer 4K families was added because the routing in the 4KE wasn't sufficient for automatically placed and routed designs in the larger parts. SInce the new families are much larger, the routing becomes more critical. Adherence to timing constraints in the placer seems to be based on the manhattan distance between CLBs. Unfortunately, as the route gets congested, the route by the shortest means is often blocked, forcing the route through more pips (read slower). Because of this, timing constraints alone will not guarantee a good placement. By lining up clbs properly, much of the routing congestion can be eliminated, resulting in a faster, cleaner design. One of the hidden advantages of floorplanning is that it forces the designer to consider the target architecture to some degree. Too many guys out there just throw a design at the tool with no regard as to how it will fit in the device. They're also the ones who complain FPGAs are too slow, think FPGAs are too hard to work with, and call our favorite vendor things like "xistinks". All that said, if you are like 80% of the FPGA users out there, you are not pushing the devices for speed or density. M1 was designed so you could just push the buttons and not think about your design. Just don't complain that the part isn't fast/big enough for you! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11073
"Brad Smallridge" <manbike@smallridge.xo.com> writes:
> Hmm. Good start but consider these two bit fields:
> 01100011010
> 01101011000
> which, would shift only once according to your algorithm,
> but are non-the-less shift invarient equivalent.
Maybe I'm blind, but I can't see this. Shifting once gives:
11000110100
11010110000
Now the only way to "maximize" as you put it is starting to rotate.
But rotating the original numbers doesn't yield an equality. If in
fact you meant:
1100011010
1101011000
then I could see that they were rotation invariant equivalent by
rotating the first bit field by five.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 11074Hi, I know this might not be the correct place for this mail and I apologise in advance if it is of no interest to you. I am considering setting up a VHDL contract development business and am trying to get a feel for how much interest this would generate amongst the various hardware development companies. I am pricipally concerned with the UK but would be interested in any opions of anyone else where. Does anyone think this is a viable business? Would anyone use such a business? etc. Initailly I would be thinking of 2 or 3 senior VHDL developers from a background of Altera and ASIC development. Any thoughts Thanks for your time
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