Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 11050

Article: 11050
Subject: Re: high-speed place and route
From: Jo Depreitere <jdp@elis.rug.ac.be>
Date: Wed, 15 Jul 1998 16:32:59 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: high-speed place and route
From: jsswartz@eecg.utoronto.ca (Jordan Swartz)
Date: 15 Jul 98 15:23:28 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: high-speed place and route
From: jsswartz@eecg.utoronto.ca (Jordan Swartz)
Date: 15 Jul 98 15:28:21 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: high-speed place and route
From: "Richard Iachetta" <iachetta@us.ibm.com>
Date: 15 Jul 1998 18:03:58 GMT
Links: << >>  << T >>  << A >>
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.com
Article: 11054
Subject: Re: Shift Invarient Bit Transform
From: "Gareth Baron" <Gareth.Baron@eng.efi.com>
Date: Wed, 15 Jul 1998 17:18:16 -0700
Links: << >>  << T >>  << A >>
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
Subject: Shift Invarient Bit Transform
From: "Brad Smallridge" <manbike@smallridge.xo.com>
Date: Wed, 15 Jul 1998 17:25:01 -0700
Links: << >>  << T >>  << A >>
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





Article: 11056
Subject: Re: Shift Invarient Bit Transform
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Jul 1998 21:02:33 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Shift Invarient Bit Transform
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Wed, 15 Jul 1998 21:32:53 -0400
Links: << >>  << T >>  << A >>


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
Subject: Re: Shift Invarient Bit Transform
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Wed, 15 Jul 1998 23:09:19 -0400
Links: << >>  << T >>  << A >>
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/~randraka


Article: 11059
Subject: Re: high-speed place and route
From: Jo Depreitere <jdp@elis.rug.ac.be>
Date: Thu, 16 Jul 1998 10:24:32 +0200
Links: << >>  << T >>  << A >>
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
Subject: Partial reprogramming
From: "Pawel E. Tomaszewicz" <ptomasze@tele.pw.edu.pl>
Date: Thu, 16 Jul 1998 11:40:21 +0200
Links: << >>  << T >>  << A >>
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# 9364632


Article: 11061
Subject: ++ TMS320C6x DSP info website ++
From: Andrew Phillips <andrew@scs.ch>
Date: Thu, 16 Jul 1998 14:12:00 +0200
Links: << >>  << T >>  << A >>
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, Switzerland
Article: 11062
Subject: Re: Shift Invarient Bit Transform
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 16 Jul 1998 08:42:47 -0400
Links: << >>  << T >>  << A >>
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/~randraka


Article: 11063
Subject: Floorplanning Intro?
From: Steven W Schlosser <schlos+@CMU.EDU>
Date: Thu, 16 Jul 1998 10:11:19 -0400
Links: << >>  << T >>  << A >>
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
Article: 11064
Subject: Bitfile for Xilinx PCI ping
From: akeiser@ews.uiuc.edu (keiser anthony lynn)
Date: 16 Jul 1998 14:29:23 GMT
Links: << >>  << T >>  << A >>
  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
Subject: Re: Floorplanning Intro?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 16 Jul 1998 11:44:39 -0400
Links: << >>  << T >>  << A >>


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/~randraka


Article: 11066
Subject: Re: Shift Invarient Bit Transform
From: brian@shapes.demon.co.uk (Brian Drummond)
Date: Thu, 16 Jul 1998 16:19:56 GMT
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 11067
Subject: Re: Shift Invarient Bit Transform
From: "Brad Smallridge" <manbike@smallridge.xo.com>
Date: Thu, 16 Jul 1998 12:41:57 -0700
Links: << >>  << T >>  << A >>


>>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.com





Article: 11068
Subject: Registration for 1998 Military and Aerospace Applications of Programmable Devices and Technologies Conference
From: rich katz <rich.katz@gsfc.nasa.gov>
Date: Thu, 16 Jul 1998 16:04:13 -0400
Links: << >>  << T >>  << A >>

--------------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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Registration for</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1998 Military and Aerospace Applications of</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Programmable Devices and Technologies Conference</TT>
<BR><TT></TT>&nbsp;<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.&nbsp;
The technical program will consist of oral technical presentations, a poster
session, as well as industrial exhibits.&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dennis Andrucyk - NASA/Goddard
Space Flight Center</TT>
<BR><TT>&nbsp;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Achieving the Earth Science Vision"</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Janet L. Barth - NASA/GSFC</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"An Overview of the Radiation Environment for Spaceflight Electronics"</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John Birkner - VP, Co-founder,
QuickLogic Corp</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"From Simple PALs to High-Speed, High-Density Leading Edge FPGA's, Their
Technologies and Applications"</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jose Munoz - DARPA, Adaptive
Computing Systems</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Military &amp; Aerospace
Applications</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. Devices</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. Adaptive Computing</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. Radiation Effects</TT>
<BR><TT></TT>&nbsp;
<BR><TT></TT>&nbsp;<TT></TT>

<P><TT>General Conference topics include the following:</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Programmable Technologies and State-of-the-Art
Devices</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A. COTS and MIL/AERO</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
B. New Technology Development</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C. Adaptive Computing Systems</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Radiation Effects, Device Reliability and Element
Characteristics</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Device Architecture, Performance, and Capabilities</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Applications and Novel Techniques for Military
and Spaceflight Circuits.</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A. Signal Processing</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
B. High-Speed Designs</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C. System Impact of State-of-the-Art Technologies</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
D. Reconfigurable Processing</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E. Low Power Designs</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
F. Advanced Packaging</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Use of COTS Devices in the Military and Spaceflight
Environment</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A. PEMS</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
B. Shielding, Latchup Protection</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C. SEE including SEFI and Destructive Effects</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
D. System Protection</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Testing and Analysis Techniques</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Performance Results</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Use of Programmables in Critical Systems</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp; - Software Tools for Design/Analysis</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A. Synthesis</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
B. Macro Generators</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C. Timing Analysis and Simulation</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
D. Redundancy, Fault Tolerance, and SEU-Hardening</TT>
<BR><TT></TT>&nbsp;<TT></TT>

<P><TT>PRELIMINARY CONFERENCE SCHEDULE</TT><TT></TT>

<P><TT>September 14&nbsp;&nbsp;&nbsp; NASA/GSFC Tours</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Evening Registration, Happy Hour</TT><TT></TT>

<P><TT>September 15&nbsp;&nbsp;&nbsp; Day 1 Technical Sessions and Industrial
Exhibits</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Dinner</TT><TT></TT>

<P><TT>September 16&nbsp;&nbsp;&nbsp; Day 2 Technical Sessions and Industrial
Exhibits</TT>
<BR><TT></TT>&nbsp;<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>&nbsp;<TT></TT>

<P><TT>For more information on the conference please see</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://rk.gsfc.nasa.gov">http://rk.gsfc.nasa.gov</A></TT>
<BR><TT>&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp; (301) 286-8884</TT>
<BR><TT></TT>&nbsp;<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>&nbsp;</HTML>

--------------90284AF4547CB53A4A041A61--

Article: 11069
Subject: Re: Floorplanning Intro?
From: Carl Christensen <carl@philipsdvs.com>
Date: Thu, 16 Jul 1998 15:35:20 -0600
Links: << >>  << T >>  << A >>
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?????

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
> shor

Article: 11070
Subject: Re: Floorplanning Intro?
From: Steven W Schlosser <schlos+@CMU.EDU>
Date: Thu, 16 Jul 1998 18:14:50 -0400
Links: << >>  << T >>  << A >>
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.

-steve
Article: 11071
Subject: Re: Shift Invarient Bit Transform
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 16 Jul 1998 20:19:37 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Floorplanning Intro?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 17 Jul 1998 00:29:10 -0400
Links: << >>  << T >>  << A >>


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/~randraka


Article: 11073
Subject: Re: Shift Invarient Bit Transform
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 17 Jul 1998 09:27:59 +0200
Links: << >>  << T >>  << A >>
"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: 11074
Subject: VHDL contract company
From: "Greenwood Systems" <greenwoodsys@yahoo.com>
Date: Fri, 17 Jul 1998 09:04:54 +0100
Links: << >>  << T >>  << A >>
Hi,
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search