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 11100

Article: 11100
Subject: Re: Floorplanning Intro: Here's how I floorplan in VHDL
From: John McCluskey <jqm@cam.org>
Date: Sat, 18 Jul 1998 17:56:38 -0400
Links: << >>  << T >>  << A >>
-- (all previous threads clipped)

I've been floorplanning in VHDL for years.   The first serious design I did was
in 1995,
about 38K gates in a 40K gate ORCA device.   I had to implement a 64 bit
pipelined
bubble sort running at 50 MHz.   The only way to get it to route was to design 2
interlocking
hard macros and tile the array with them.   Even back in 95, the Exemplar tools
would
attach edif properties to black box cells instantiated in the code.   I just
wrote a VHDL
function to turn the (i,j) address of the hard macro into a character string, and
then attached
a LOC attribute to the cell instantiation inside a double loop.  The resulting
EDIF had each
hard macro instantiation include an EDIF property that gave the place & route
tool the
precise location for the hard macro.  The same principal applies to primitive
cells from
the schematic library.    Austin Franklin is perfectly correct when he says that
you have
to instantiate EVERYTHING that needs floorplanning.   I will go even further and
proclaim
that this is a superior method of design, as long as the primitive cells are
properly wrapped
up in a higher level component so that you don't actually see them in your user
code.  I have
since written VHDL functions that take some vector or block parameters and use
them
to compute vectors of location strings that get attached to a string of
flip-flops in a register.
Often, placing a few critical registers is enough to get the rest of the design
to fall into
place very nicely.

It's very easy actually, see the floorplanning example on my web page at
http://www.lucent.ca/fpga/register.htm#Floorplanning

But as before, floorplanning is something you resort to only when you really need
it.
I don't consider IO assignment to be floorplanning, and this is often all that
you need
to do to get a reasonable result.

John McCluskey
Lucent Technologies

P.S.   To Stuart Clubb.... I've got a working gray code counter for ORCA now.
It's pretty
fast.  A 12 bit counter runs at 150 MHz in a 3T30-6, and adding a synchronous
preload
function only drops it to down to 101 MHz.

Article: 11101
Subject: Re: Too much advertising in this news group?
From: ems@see_sig.com (ems)
Date: Sun, 19 Jul 1998 14:04:50 GMT
Links: << >>  << T >>  << A >>
On 18 Jul 1998 02:08:45 GMT, "Austin Franklin"
<darkroo5m@ix.netcom.com> wrote:

>I noticed the amount of personal, corporate and head hunter advertising in
>this news group has increased dramatically.
>
>Personally, I find all this advertising in VERY poor taste.  I do not
>believe it is in this groups charter to make this an advertising group, it
>IS a discussion group.
>
>Though people talking about new products, or web sites is great,
>advertising you offer some consulting service, or are a head hunter looking
>for names, I believe, is inappropriate.
>
>Any body else tired of all this advertising?

Yes, but there's not much you can do about this. Perhaps the best
thing you can do is to reply to their postings; these people rely on
goodwill and an unfavourable reply will soon shut them up. I've tried
this myself recently.

Head hunter postings can also be counter-productive. There was a
posting last month that gave me just enough information to be able to
do a search for the client, who turned out to be a couple of miles
down the road from me. So I contacted them directly, cutting out the
agency... :)

Evan (ems@nospam.riverside-machines.com)

Article: 11102
Subject: Re: Floorplanning Intro?
From: ems@see_sig.com (ems)
Date: Sun, 19 Jul 1998 14:05:46 GMT
Links: << >>  << T >>  << A >>
On Fri, 17 Jul 1998 16:32:51 -0400, Ray Andraka
<no_spam_randraka@ids.net> wrote:

> (HDL/schematic pros/cons snipped)

Agreed, in general, but I think you're seriously underselling the
simulation advantages of an HDL:

>  1) the ability to simulate the design behaviorally while the design is still
>just a concept

The real advantage is that you can write an entire testbench in your
HDL. Not just your device, but the system around it. You can then use
the same testbench for simulation at any stage of the implementation
process, assuming that you can sort out any name changes.
You can also write far more complex scenarios in your HDL than you
could in the scripting 'language' provided with your gate-level
simulator. If simulation is important to you, then my opinion would be
that you have no option other than to use an HDL.

Ok, this may (will) give you major floorplanning problems, and it may
be (very) time-consuming to produce a fast design. But at the end of
the day you can deliver a re-usable design, in an industry-standard
HDL, with a robust simulation package. The alternative is to deliver a
large number of schematics, and a questionable simulation, probably
produced with a mickey-mouse package which will be obsolete by the
time you have to modify the sources.

Evan (ems@nospam.riverside-machines.com)

Article: 11103
Subject: CRC Implementation
From: APS <resp@associatedpro.com>
Date: Sun, 19 Jul 1998 10:42:35 -0400
Links: << >>  << T >>  << A >>
Has anyone done any CRC-16 implementations in an FPGA? I am looking for
the CRC-CCITT implementaton in particular. Any help or pointers to
information at all would be appretiated?

Thanks in Advance,

Richard

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11104
Subject: Re: Floorplanning Intro?....seems to be HDL v schematics sort of ;-)
From: APS <resp@associatedpro.com>
Date: Sun, 19 Jul 1998 11:06:55 -0400
Links: << >>  << T >>  << A >>
Austin,

About the tristates... You are correct that they are free logic in the XILINX
architecture parts, but be aware that when porting to an ASIC or non tristate
part, that excesive use of tristates as muxes will blow the design size up when

the tristates are converted back to muxes. Also the work invloved and the
design route changes need to be considered.

Richard

Austin Franklin wrote:

> Everything Ray says is absolutely correct about this subject (that'll be $5
> Ray ;-).
>
> HDLs do not give a consistent platform for floorplanning unless you
> instantiate EVERYTHING you are going to floorplan.  Even then, if you
> fart...er change a line of code, you can change the entire structure of the
> output from the HDL.  Even different revisions of the HDL tools will change
> the names!
>
> I also agree with doing regular structures (registers, busses, counters,
> muxes...) in schematic, so you CAN floorplan then EASILY (and I believe it
> is far easier to read than HDL).  Overall it takes FAR LESS TIME than doing
> these things in HDLs.  I could care less what you want to do your random
> logic/state machines in, schemtaic or HDLs, but I STRONGLY advise doing
> regular structures in schematic.  It is not archiac, it is using the
> correct tool CORRECTLY for the job.
>
> More than half my contracts are from supposed HDL experts who, when
> designing for an FPGA, complain that it only runs at 10MHz, and they can't
> figure out why.  Funny how after I either instantiate everything to allow
> for 'pseudo' consistent naming conventions, and floorplan it, or change
> their wizardry HDL (cough cough) into schematics, and floorplan it, the
> design all of a sudden routes in minutes (as opposed to hours) and runs at
> over 2x-4x (I've seen as high as 10x) speed as the HDLs.
>
> Enough said...yes, floorplanning a 4028 (any Xilinx FPGA for that matter
> that the design uses regular structures) is very prudent.  Another gotcha
> (well, I guess not enough said) that most HDL designers fail on is to NOT
> use the internal tri-state busses as muxes for register I/O....YOU WANT TO
> USE THEM IF YOU CAN.  They are free logic (not counted in the parts gate
> count) AND they are fast, and can have a large number of
> sources/destinations on the 'bus'.
>
> Now, enough said...for now ;-)
>
> Austin Franklin
> darkroom@ix.netcom.com
>
> Ray Andraka <no_spam_randraka@ids.net> wrote in article
> <35AFB4F3.FD40122C@ids.net>...
> >
> >
> > Jan Gray wrote::
> >
> > > Is there an HDL to netlist synthesis tool that either --
> > > 1) supports placement constraint attributes on register declarations
> and/or
> > > on subexpressions? (not just pin-locking) or
> > > 2) uses systematic, repeatable names for generated elements of the
> > > synthesized netlist, enabling external placement constraints?  (It is
> not
> > > acceptable if a small change to the HDL source renames all the
> synthesized
> > > stuff, invalidating the external floorplan or guide files.)
> > >
> >
> > NOT YET.  My local Exemplar rep claims the new spectrum tool will be able
> to
> > carry placement info.  I haven't played with it yet, so I don't know.
> This is
> > the reason I still use and advocate schematic entry (I've been accused of
> > working in the dark ages and worse because of this...working in the dark
> maybe,
> > dark ages: I don't think so).  The fact is, if you do hierarchical
> schematics
> > right, you get just as much reuse (even to different architectures) and I
> think
> > more readability than the HDLs proport to have.  My schematic library
> consists
> > of a lot of 1 and 2 bit objects (including carry chain stuff) that I can
> quickly
> > stack to make arbitrary width doo-dads using the array command.
> >
> > After you cut through all the marketing BS, the only real advantages (and
> not
> > insignificant by any means) that HDLs have over schematics are
> >   1) the ability to simulate the design behaviorally while the design is
> still
> > just a concept, and
> >   2) the ability to browse an archived design without having a copy of
> the
> > schematic editor used to create the design.
> > everything else is just as easy to accomplish with a good schematic entry
> > habits. Current shortcomings of HDLs are
> >   1) readability suffers (this is the old a picture is worth a thousand
> > words...of course the schematics need to be done in a way that makes
> visual
> > sense-a 60 page flat schematic doesn't cut it).  The software world is
> > recognizing this and going toward all kinds of GUI's and visual this and
> that.
> > Meanwhile the hardware guys are moving away from pictoral representation
> in
> > favor of text.  Go figure.
> >   2) the HDLs currently provide no easy means to control placement in the
> > design, and
> >   3) a user has to understand the all the little quirks of the particular
> > version of the synthesis tool he is using to gain any sense of control
> over the
> > design implementation.
> >
> > I'd really like to have the two advantages I cited, but until the
> shortcomings
> > are addressed, I will prefer schematics because I get better results in
> less
> > time.  That means more money to me (much of my work is on a fixed price
> basis)
> >
> > > In lieu of these features, one approach would be to write and verify
> the
> > > entire design in an HDL, then reimplement the significant datapath
> modules
> > > using explicit instantiation and placement via schematics or netlist
> > > generator.  You get quick design, simulation, synthesis (target other
> > > devices), possibility of design reuse, *and* optimal use of FPGA
> resources
> > > so you can use a smaller slower cheaper device.
> > >
> > > I have been searching for this happy medium myself.  As I write on the
> > > pleasures of designing processors and systems-on-chip in FPGAs, I want
> to
> > > express the designs
> > > 1) in source code, that
> > > 2) can be simulated, and which
> > > 3) enables compilation to non-Xilinx devices, and
> > > 4) enables reuse of preexisting designs from other sources, and
> > > 5) uses device features as efficiently as does my netlist generator,
> e.g.
> > > which permits floorplanning.
> > >
> > > I'd like to use Verilog because of 1-4, anticipating a future Xilinx
> Student
> > > Edition with Verilog -- but I'm not willing to sacrifice my
> > > nice, half as large, twice as fast, quick-place-and-route datapaths!
> Any
> > > ideas?  Otherwise its going to be either a) 100% netlist generator
> > > (sacrificing 3-4) or b) Verilog + datapaths reimiplemented via netlist
> > > generator.
> >
> > Jan, the available cores are increasing, so it is becoming a little
> easier to
> > get the performance out of an HDL.  Often, a core library vendor will
> include
> > behavioral models (I think it is a requirement to be a xilinx alliance
> partner)
> > for VHDL and Verilog, a schematic symbol and a placed netlist.  Right now
> the
> > available library doesn't include enough functions to make it all work,
> but
> > maybe as the libraries grow?
> >
> >
> > --
> > -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
> >
> >
> >



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11105
Subject: Re: Floorplanning Intro?....seems to be HDL v schematics sort of ;-)
From: APS <resp@associatedpro.com>
Date: Sun, 19 Jul 1998 13:18:34 -0400
Links: << >>  << T >>  << A >>
Austin,

I am now very curious about floorplanning and creating HDL "BLOCKS" for
instantiating so that I can use the floorplanner. First off I assume that I
create a type of MACRO with the VHDL ? How exactl;y would this be done ?

I see the merrits of what you and Ray A. are saying, and have heard similar
sentiments from good designers like my friend Philip F. ,  I also am always
generating top level block flow diagrams which are essentially just my top
level VHDL files. It would be great if  this was automatically generated.

I work in an environment where:

1) Detailed Simulations are invariablly required.
2) Detailed back annotated timing is highly desired
3) Migration to Gate Arrays are inevitable. (HDLs are a big plus here)
4) Migration to ever changing FPGAs are inevitable (XILINX to ORCA to Altera to
ACTEl etc.)
The last two issues involve code reuse. This is another problem I see in using
device specific Macros. If I have a project which is heavily device dependent
(macros etc), It really ties me to a particular device. For real preformance,
it seems to me that this is where much of vendors are heading, creatuing device
specific "core" or macros, which are optimized for the specific technology of
the parts being used. The problem that crops up is that at any one point in
time a specific vendor may have a part that better fits the design. HDLs should
theoretically solve this problem, where you simply re-synthesize to the new
parts architecture. The problem being that using device specific macros
requires that a you find, or generate new macros in the new technology. This
not a real problem if you only do small macros for ram etc., but when the
majority of your design is geared towards these macros then your in for alot of
work, which in most cases is not practical for any reasonable schedule. It also
seems to me that the heavy macro use is roughly equivalent to tying together
schematic symbols using a VHDL netlist. The only reason to use the HDL over the
schematics is then to take advantage of the superior simulation properties.

Even with all the advantages you seem to point to, it still seems to me that
the future points to HDLs. For most general purpose designs which are pushing
the envelope of performance out of a part, the HDLs seem to be the way to go.
That being said, I also see a huge disconnect between synthesis code and actual
hardware implementation that does not seem to be easily overcome. Knowing how
each synthesis tool  and place and route tools implement specific language
constructs is still --for the most part-- a mystery to the average engineer.
Breaching that disconnect ( a disconnect that is easily overcome with schematic
tools) is hopefully where the developers of  HDL tool standards  will spend a
good chunk of time.

I have adopted this strategy so far for programmable logic developement:

1) Use HDL.
2) Do functional simulations with HDL simulators.
3) Keep HDL as general as possible and avoid device specific macros/cores
unless the design requirements push you towards them.
4) Stay with one vendor for most designs unless there is a HUGE reason to
switch. This rule keeps the device specfic macro problem to a minimum, and
allows for more code reuse and keeps your overall knowledge base focused,
allowing more time to understand the specific architecture of the vendor you
specialize in.
5) Use as much post route information as possible and constrain designs based
on that information in order to get the desired placement and routing. This
includes examining the placement are doing designs.

I really would like more information on the way some use HDL and Floorplanning
tools. I always assumed that the floorplaning would almost have to be done as a
last process. A process that would not allow easily code changes in the HDL
without redoing the floorplanning each time. I would really like to see the way
HDL and floorplanning is incorporated in a managable way.

Austin Franklin wrote:

> Everything Ray says is absolutely correct about this subject (that'll be $5
> Ray ;-).
>
> HDLs do not give a consistent platform for floorplanning unless you
> instantiate EVERYTHING you are going to floorplan.  Even then, if you
> fart...er change a line of code, you can change the entire structure of the
> output from the HDL.  Even different revisions of the HDL tools will change
> the names!
>
> I also agree with doing regular structures (registers, busses, counters,
> muxes...) in schematic, so you CAN floorplan then EASILY (and I believe it
> is far easier to read than HDL).  Overall it takes FAR LESS TIME than doing
> these things in HDLs.  I could care less what you want to do your random
> logic/state machines in, schemtaic or HDLs, but I STRONGLY advise doing
> regular structures in schematic.  It is not archiac, it is using the
> correct tool CORRECTLY for the job.
>
> More than half my contracts are from supposed HDL experts who, when
> designing for an FPGA, complain that it only runs at 10MHz, and they can't
> figure out why.  Funny how after I either instantiate everything to allow
> for 'pseudo' consistent naming conventions, and floorplan it, or change
> their wizardry HDL (cough cough) into schematics, and floorplan it, the
> design all of a sudden routes in minutes (as opposed to hours) and runs at
> over 2x-4x (I've seen as high as 10x) speed as the HDLs.
>
> Enough said...yes, floorplanning a 4028 (any Xilinx FPGA for that matter
> that the design uses regular structures) is very prudent.  Another gotcha
> (well, I guess not enough said) that most HDL designers fail on is to NOT
> use the internal tri-state busses as muxes for register I/O....YOU WANT TO
> USE THEM IF YOU CAN.  They are free logic (not counted in the parts gate
> count) AND they are fast, and can have a large number of
> sources/destinations on the 'bus'.
>
> Now, enough said...for now ;-)
>
> Austin Franklin
> darkroom@ix.netcom.com
>
> Ray Andraka <no_spam_randraka@ids.net> wrote in article
> <35AFB4F3.FD40122C@ids.net>...
> >
> >
> > Jan Gray wrote::
> >
> > > Is there an HDL to netlist synthesis tool that either --
> > > 1) supports placement constraint attributes on register declarations
> and/or
> > > on subexpressions? (not just pin-locking) or
> > > 2) uses systematic, repeatable names for generated elements of the
> > > synthesized netlist, enabling external placement constraints?  (It is
> not
> > > acceptable if a small change to the HDL source renames all the
> synthesized
> > > stuff, invalidating the external floorplan or guide files.)
> > >
> >
> > NOT YET.  My local Exemplar rep claims the new spectrum tool will be able
> to
> > carry placement info.  I haven't played with it yet, so I don't know.
> This is
> > the reason I still use and advocate schematic entry (I've been accused of
> > working in the dark ages and worse because of this...working in the dark
> maybe,
> > dark ages: I don't think so).  The fact is, if you do hierarchical
> schematics
> > right, you get just as much reuse (even to different architectures) and I
> think
> > more readability than the HDLs proport to have.  My schematic library
> consists
> > of a lot of 1 and 2 bit objects (including carry chain stuff) that I can
> quickly
> > stack to make arbitrary width doo-dads using the array command.
> >
> > After you cut through all the marketing BS, the only real advantages (and
> not
> > insignificant by any means) that HDLs have over schematics are
> >   1) the ability to simulate the design behaviorally while the design is
> still
> > just a concept, and
> >   2) the ability to browse an archived design without having a copy of
> the
> > schematic editor used to create the design.
> > everything else is just as easy to accomplish with a good schematic entry
> > habits. Current shortcomings of HDLs are
> >   1) readability suffers (this is the old a picture is worth a thousand
> > words...of course the schematics need to be done in a way that makes
> visual
> > sense-a 60 page flat schematic doesn't cut it).  The software world is
> > recognizing this and going toward all kinds of GUI's and visual this and
> that.
> > Meanwhile the hardware guys are moving away from pictoral representation
> in
> > favor of text.  Go figure.
> >   2) the HDLs currently provide no easy means to control placement in the
> > design, and
> >   3) a user has to understand the all the little quirks of the particular
> > version of the synthesis tool he is using to gain any sense of control
> over the
> > design implementation.
> >
> > I'd really like to have the two advantages I cited, but until the
> shortcomings
> > are addressed, I will prefer schematics because I get better results in
> less
> > time.  That means more money to me (much of my work is on a fixed price
> basis)
> >
> > > In lieu of these features, one approach would be to write and verify
> the
> > > entire design in an HDL, then reimplement the significant datapath
> modules
> > > using explicit instantiation and placement via schematics or netlist
> > > generator.  You get quick design, simulation, synthesis (target other
> > > devices), possibility of design reuse, *and* optimal use of FPGA
> resources
> > > so you can use a smaller slower cheaper device.
> > >
> > > I have been searching for this happy medium myself.  As I write on the
> > > pleasures of designing processors and systems-on-chip in FPGAs, I want
> to
> > > express the designs
> > > 1) in source code, that
> > > 2) can be simulated, and which
> > > 3) enables compilation to non-Xilinx devices, and
> > > 4) enables reuse of preexisting designs from other sources, and
> > > 5) uses device features as efficiently as does my netlist generator,
> e.g.
> > > which permits floorplanning.
> > >
> > > I'd like to use Verilog because of 1-4, anticipating a future Xilinx
> Student
> > > Edition with Verilog -- but I'm not willing to sacrifice my
> > > nice, half as large, twice as fast, quick-place-and-route datapaths!
> Any
> > > ideas?  Otherwise its going to be either a) 100% netlist generator
> > > (sacrificing 3-4) or b) Verilog + datapaths reimiplemented via netlist
> > > generator.
> >
> > Jan, the available cores are increasing, so it is becoming a little
> easier to
> > get the performance out of an HDL.  Often, a core library vendor will
> include
> > behavioral models (I think it is a requirement to be a xilinx alliance
> partner)
> > for VHDL and Verilog, a schematic symbol and a placed netlist.  Right now
> the
> > available library doesn't include enough functions to make it all work,
> but
> > maybe as the libraries grow?
> >
> >
> > --
> > -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
> >
> >
> >



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11106
Subject: Re: Too much advertising in this news group?
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Sun, 19 Jul 1998 11:07:41 -0700
Links: << >>  << T >>  << A >>
If everyone who has things to advertise does so, the technical content will
be overwhelmed, perhaps to the loss of our community.  What do you suppose
is an ethical course of action...?

At any rate, the folks that continue to post pure advertising could take
some initiative to minimize the dillutive effect.  For example,

1. pay to advertise on one of the fine FPGA web sites instead.

2. find/hire someone to digest and post a recurring ads message.  You'll get
more consistent reach.  This works beautifully on comp.compilers
(moderated).

3. try to achieve a common set of subject tag lines, e.g. "ad: job: " and
"ad: consulting: " etc.  But reread the first sentence of my posting.

4. perhaps the most effective advertising for consultants and design
services is to instead emulate the several experts who contribute so
profoundly to the technical dialog in this newsgroup.

ems wrote in message <35b1fcd3.16762706@news.dial.pipex.com>...
>Yes, but there's not much you can do about this. Perhaps the best
>thing you can do is to reply to their postings; these people rely on
>goodwill and an unfavourable reply will soon shut them up. I've tried
>this myself recently.


I stopped doing this when a single polite private reply was returned with
vitriol and then with a threat of legal action for my "persistent attacks"
on the head-hunter's business.  Apparently others complained directly to his
ISP who was going to pull the plug, and he blamed his situation on me.

Jan Gray



Article: 11107
Subject: Re: Shift Invarient Bit Transform
From: "Brad Smallridge" <manbike@smallridge.xo.com>
Date: Sun, 19 Jul 1998 15:54:25 -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 > 1100  corrected as pointed out by Rickman.
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:
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.
Brad Smallridge wrote:
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
Rickman wrote:
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?
Brad Smallridge answers:
OK. First I made a mistake. As Achim Gratz pointed out.
The bit patterns should be:
01100011010
11010011000
so the top pattern should shift 6 times to the left.
They would then both be equivalent at 11010011000.
And likewise the pattern:
01001100011
should shift left 10 times left and also be equivalent.
Should I be using the word rotate instead of shift?
So, you see, it's not merely looking for a leading 1.
And it seems to be more than looking for the longest
run of 1s also. Consider these strings:
01010100101
01001010101
And also I'm not necesarilly looking for an output number
that saves the bit pattern of the input. As I stated above,
there may be some compression involved, since many
patterns will transform to the same output signal.
Thanks,

Rick Collins:
I think I have it now. You want a mapping of the set of all inputs for a
given bit size to the set of "shift invariant equivalence" groups. This
is not so easy. To do this I suspect that you would need to define an
ordering sequence for your "shift invariant equivalent" groups. Then you
can map your input to the corresponding group by rotating it until it
matches the first member of the group.
For example, you could define your ordering to be in sequence of
magnatude of the binary value. This would provide you with an algorithm
of shifting the bit pattern so that the longest string of zeros is at
the left, if there is more than one string of zeros of equal maximal
length, then you shift to left justify the longest string of zeros with
the shortest string of ones on its right, and so on... This will
ultimately map all members of a "shift invariant equivalence" group
to a single bit pattern, which is what I think you are asking.
Now the trick is to identify an ordering sequence that will allow you
specify a simple algorithm which can be implemented in combinatoral
logic without a multi clock state machine. Some trick, huh?
I don't believe you will find a solution to this problem that will be
very easy to implement. I think all solutions will either take a great
deal of logic, or will require a lot of clock cycles to produce a
result. In the case of the latter, you can pipeline it to produce a
result on every clock cycle even though it may take many clocks for a
given result to work its way through the pipe (both lots of logic and
lots of clocks).
[The table] is not correct.  1001 maps to 1001 while 1100, 0110 and 0011
all map to 1100. In fact all four bit patterns should map to the same
"shift invarient equivalent" group.
When you say this transform can compress data, I don't think you will
get much compression. As I see it you will be compressing data from 2**n
using n bits to (2**n)/n using n - log2(n) bits for a savings of
(log2(n)/n) * 100%. For 32 bit words this is only 5/32 or about 15%. Is
that worth the trouble?
Does it sound like I understand your problem now?

Brad Smallridge writes:
Yes. You got it.
It is more difficult then it seems. That's why I'm on the net.
And I believe a prioity encode, as Brian Drummond suggests,
is just another first one detector.
You are right about the table and I have corrected it
in this current post with credit to you.
I am not sure about your compression calculation. I am
not so good at decyphering log n type mathematics.
It seems to me that the compression should be enormous.
When I was working on a five bit table, and doing the
shift to maximise routine, the LSB was 0, all except
for the input vector 11111.  So this LSB has little information,
and could be dropped, if you transform 11111 to some unused
4 bit output, say 0001. So there is a 5 bit to 4 bit compression.
Does that hold with your formula?
I also had a thought the other night that I should take the ones
bit count as a start. Trouble with the 4 bit patterns appears
with the vectors 1100 and 1010. So I thought I should AND
all adjacent bits and count these outputs as well. That solves
the 4 bit pattern and also 5 bits ... I think. But eventually I will
run into bit patterns like this:
0110110000000
0110000110000
Where the ones count and the pairs of ones count is exactly the
same. So should I count pairs of zeroes too? Doesn't seem to be
getting me anywhere.





Article: 11108
Subject: Re: Too much advertising in this news group?
From: tcoonan@mindspring.com (Thomas A. Coonan)
Date: Mon, 20 Jul 1998 00:56:35 GMT
Links: << >>  << T >>  << A >>
I too, am concerned.  When the traffic on comp.lang.verilog escalates
to the noise of alt.tv.x-files - I know I'll be outta here.

I've always thought it fair that independents or small firms may
include a 4-5 line email signature trailer (with WWW site, phone #,
etc.), but for us to see it, they simply have to contribute to our
group with some good insightful replies.  Give and Take.  

tom coonan
tcoonan@mindspring.com
Scientific Atlanta
>I noticed the amount of personal, corporate and head hunter advertising in
>this news group has increased dramatically.
>
>Personally, I find all this advertising in VERY poor taste.  I do not
>believe it is in this groups charter to make this an advertising group, it
>IS a discussion group.
>
>Though people talking about new products, or web sites is great,
>advertising you offer some consulting service, or are a head hunter looking
>for names, I believe, is inappropriate.
>
>Any body else tired of all this advertising?
>
>Austin Franklin
>darkroom@ix.netcom.com
>

Article: 11109
Subject: Re: Too much advertising in this news group?
From: Gary Helbig <ghelbig@slip.net>
Date: Sun, 19 Jul 1998 18:15:55 -0700
Links: << >>  << T >>  << A >>
I'd like to toss my 2 cents in.

If an Altera FAE want to respond to my attacks on AHDL, or a Xilinx
engineer wants to correct a mis-representation of their product (there's
one that does, and his posts are useful), that's a good thing.  Of if
OrCAD would read the groups, and find out how many people are
complaining about bugs and non-support.

In otherwords, if a manufacturer or sales person is responding, rather
than generating, that's good.

And as far as head hunters go:  IMHO, I would never seek representation
for an individual or firm that was too dense to figure out that their
posts don't belong here.  Last time I checked, there was an
'xxx.jobs.xxx' group for just about every corner of the world.

Gary.

Jan Gray wrote:
> 
> If everyone who has things to advertise does so, the technical content will
> be overwhelmed, perhaps to the loss of our community.  What do you suppose
> is an ethical course of action...?
> 
> At any rate, the folks that continue to post pure advertising could take
> some initiative to minimize the dillutive effect.  For example,
> 
> 1. pay to advertise on one of the fine FPGA web sites instead.
> 
> 2. find/hire someone to digest and post a recurring ads message.  You'll get
> more consistent reach.  This works beautifully on comp.compilers
> (moderated).
> 
> 3. try to achieve a common set of subject tag lines, e.g. "ad: job: " and
> "ad: consulting: " etc.  But reread the first sentence of my posting.
> 
> 4. perhaps the most effective advertising for consultants and design
> services is to instead emulate the several experts who contribute so
> profoundly to the technical dialog in this newsgroup.
> 
> ems wrote in message <35b1fcd3.16762706@news.dial.pipex.com>...
> >Yes, but there's not much you can do about this. Perhaps the best
> >thing you can do is to reply to their postings; these people rely on
> >goodwill and an unfavourable reply will soon shut them up. I've tried
> >this myself recently.
> 
> I stopped doing this when a single polite private reply was returned with
> vitriol and then with a threat of legal action for my "persistent attacks"
> on the head-hunter's business.  Apparently others complained directly to his
> ISP who was going to pull the plug, and he blamed his situation on me.
> 
> Jan Gray
Article: 11110
Subject: Re: Shift Invarient Bit Transform
From: jhirbawi@yahoo.com
Date: Mon, 20 Jul 1998 02:48:58 GMT
Links: << >>  << T >>  << A >>
 In article <6ots61$6rp@masters0.InterNex.Net>,
   "Brad Smallridge" <manbike@smallridge.xo.com> wrote:

 > It seems to me that the compression should be enormous.
 > When I was working on a five bit table, and doing the
 > shift to maximise routine, the LSB was 0, all except
 > for the input vector 11111.  So this LSB has little information,
 > and could be dropped, if you transform 11111 to some unused
 > 4 bit output, say 0001. So there is a 5 bit to 4 bit compression.
 > Does that hold with your formula?

 The compression factor Rickman gives is correct; what it tells you is
 that the 2^n bit strings of length n will map to roughly 2^n/n possible
 patterns (equivalence classes). The number of possible patterns actually
 has a closed form solution and for n=1..32 is :

 [ 2, 3, 4, 6, 8, 14, 20, 36, 60, 108, 188, 352, 632, 1182, 2192, 4116, 7712,
   14602, 27596, 52488, 99880, 190746, 364724, 699252, 1342184, 2581428,
   4971068, 9587580, 18512792, 35792568, 69273668, 134219796 ]

 so for n=1 you have two patterns ("0" and "1"), for n=2 you have 3 ("00",
 "01","11"), for n=3 you have 4 ("000","001","011","111"); and so on. You
 can divide by 2^n to see the ratio. So no matter how you encode the outcome,
 there are about 2^n/n possible values.

 > I also had a thought the other night that I should take the ones
 > bit count as a start. Trouble with the 4 bit patterns appears
 > with the vectors 1100 and 1010. So I thought I should AND
 > all adjacent bits and count these outputs as well. That solves
 > the 4 bit pattern and also 5 bits ... I think. But eventually I will
 > run into bit patterns like this:
 > 0110110000000
 > 0110000110000
 > Where the ones count and the pairs of ones count is exactly the
 > same. So should I count pairs of zeroes too? Doesn't seem to be
 > getting me anywhere.

 This is actually along the lines of what you have to do : you need
 to find "shift-invariant functions" that give the same output for
 all inputs that are shifts of each other, *and* you need to find
 enough of these functions to completely distinguish between all
 posssible patterns. One such function is the number of 1's in the string,
 this function is enough for n=1,2,3; for n=4 you have two patterns that
 have the same number of 1's : ("0011" and "0101") so you need a function
 to distinguish between these two; the function :

    c1*c2 + c2*c3 + c3*c4 + c4*c1

 distinguishes between the two; it's 1 for "0011" and 0 for "0101". You
 can also see that it is invariant under rotation. Note that the number
 of 1's corresponds to the function : c1+c2+c3+c4. If you're interested
 in bit strings of length 4 then two functions are enough and you're done.
 Otherwise you keep adding functions as you need them. For example :

   c1*c2 + c2*c3 + c3*c4 + c4*c5 + c5*c1  or
   c1*c3 + c2*c4 + c3*c5 + c4*c1 + c5*c2  or

   c1*c2*c3 + c2*c3*c4 + ... (keep rotating the terms)

 can be used for larger n. There's probably a systematic way of adding
 these functions or even some kind of tranform (along the lines of a
 Fourier Transform which is realy a shift invariant tranform if you
 just look at the amplitude of the spectrum); this seems like a good
 question to post to one of the math groups.

 Jacob Hirbawi.


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11111
Subject: Re: Shift Invarient Bit Transform
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 19 Jul 1998 23:50:46 -0400
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> Brad Smallridge writes:
> Yes. You got it.
> It is more difficult then it seems. That's why I'm on the net.
> And I believe a prioity encode, as Brian Drummond suggests,
> is just another first one detector.
> You are right about the table and I have corrected it
> in this current post with credit to you.
> I am not sure about your compression calculation. I am
> not so good at decyphering log n type mathematics.
> It seems to me that the compression should be enormous.
> When I was working on a five bit table, and doing the
> shift to maximise routine, the LSB was 0, all except
> for the input vector 11111.  So this LSB has little information,
> and could be dropped, if you transform 11111 to some unused
> 4 bit output, say 0001. So there is a 5 bit to 4 bit compression.
> Does that hold with your formula?
> I also had a thought the other night that I should take the ones
> bit count as a start. Trouble with the 4 bit patterns appears
> with the vectors 1100 and 1010. So I thought I should AND
> all adjacent bits and count these outputs as well. That solves
> the 4 bit pattern and also 5 bits ... I think. But eventually I will
> run into bit patterns like this:
> 0110110000000
> 0110000110000
> Where the ones count and the pairs of ones count is exactly the
> same. So should I count pairs of zeroes too? Doesn't seem to be
> getting me anywhere.

My guesstimate of compression comes from the number of "shift invariant
equivalence" (SIE) groups vs. the number of possible bit patterns for a
given number of bits. Obviously there are 2**n number of bit patterns.
Any given SIE group can be created by picking a starting pattern and
shifting through all the possible patterns until you have shifted by n
where the original pattern is guaranteed to repeat. Therefor, the
largest number of members of any given SIE group will be n, while many
will be less. The number of SIE groups will then be no less than 2**n/n. 

To find the amount of compression this will produce, consider the number
of bits to represent the compressed data; n vs. log2((2**n)/n) or
log2(2**n) - log2(n) or n - log2(n). This gives a relative savings of
log2(n)/n. If n is 32, then log2(n) is 5 and 5/32 is about 15%. And
remember that this is an upper limit which will never be reached! 15%
compression is not very big, and it is only useful if you don't care
about distinguishing between SIE group members. What would be the
application where this would apply?


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 11112
Subject: Re: Too much advertising in this news group?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 20 Jul 1998 00:03:48 -0400
Links: << >>  << T >>  << A >>
ems wrote:
> 
> On 18 Jul 1998 02:08:45 GMT, "Austin Franklin"
> <darkroo5m@ix.netcom.com> wrote:
> 
> >I noticed the amount of personal, corporate and head hunter advertising in
> >this news group has increased dramatically.
... snip ...
> >Any body else tired of all this advertising?
> 
> Yes, but there's not much you can do about this. Perhaps the best
> thing you can do is to reply to their postings; these people rely on
> goodwill and an unfavourable reply will soon shut them up. I've tried
> this myself recently.

I have tried this as well. There is one company (I won't mention their
name, but their initials are Kalman Saffran Associates, Inc. ;-) that is
posting spam to a couple of mailing lists that I am on. I send them a
reply for every posting that I get. When they contacted me by phone I
told the salesman what I thought of their marketing method. He insisted
that there was nothing improper with using the same marketing techniques
as chain letters, scam artists and smut peddlers. I don't think I will
be getting a follow up call. 


> Head hunter postings can also be counter-productive. There was a
> posting last month that gave me just enough information to be able to
> do a search for the client, who turned out to be a couple of miles
> down the road from me. So I contacted them directly, cutting out the
> agency... :)
> 
> Evan (ems@nospam.riverside-machines.com)


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 11113
Subject: How to write a VHDL counter of up & down
From: leslie.yip@asmpt.com
Date: Mon, 20 Jul 1998 07:54:15 GMT
Links: << >>  << T >>  << A >>
Hello Everybody

I don't know how to implement my previous ASIC-design counter with 2 edge
triggers -- up and down (up => increment the counter by 1; down [i.e. dn] =>
decrement the counter by 1) I used logic gates to implement this function but
it seems difficult to describe this with VHDL. I know that another writing of
up-down counter is to use a pin to control up/down and another is just a
clock for incrementing / decrementing the counter.

My 4-bit counter, however, uses four 4-bit counter to connect together by:
Carry => UP
('Carry' of lower-bit counter connected to 'UP' of another counter)
Borrow => DN

Below is a correct but unsynthesizable (by ViewLogic) code of 16-bit counter.
Could anyone tell me any idea?
Thanks a lot in advance.



-- Leslie Yip, ASM;     July, 17

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

Entity COUNTER is
  port( NRST:			in	std_logic;
        LOAD:			in	std_logic;
        ENABLE:			in	std_logic;
        UP,DN:			in	std_logic;
        BUSIN:			in	std_logic_vector(15 downto 0);

        CARRY,BORROW:		out	std_logic;
        CNTOUT:			out	std_logic_vector(15 downto 0)
	);
end COUNTER;

architecture COUNTER_ARCH of COUNTER is
signal CNT: std_logic_vector(15 downto 0);


begin


process(NRST,LOAD,UP,DN)
begin

 if NRST = '0' then
  CNT <= (others=>'0');
  CARRY <= '0';
  BORROW <= '0';

 elsif LOAD='1' then
  CNT <= BUSIN;

 elsif UP='1' and UP'event and ENABLE = '1' then
    if CNT = "1111111111111111" then
      CARRY <= UP;
    else
      CARRY <= '0';
    end if;
  CNT <= CNT + 1;

 elsif DN='1' and DN'event and ENABLE = '1' then
   if CNT = "0000000000000000" then
      BORROW <= DN;
    else
      BORROW <= '0';
    end if;
  CNT <= CNT - 1;

 end if;
end process;


  CNTOUT <= CNT;



end COUNTER_ARCH;

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11114
Subject: Re: Xilinx Dynatext and NTFS ?
From: "Rudolf Muehlenbein" <rudolf.muehlenbein@germany.honeywell.com>
Date: Mon, 20 Jul 1998 10:57:01 +0200
Links: << >>  << T >>  << A >>
Hi,

I have xilinx alliance (M1.4 with viewlogic 7.4) on NT 4.0 SP3. No problems
with Dynatext!
But my Foundation System (only for tests of the entry tools on the same
maschine) has a few problems. Error messages without explain.

regards
Rudi.

George Pontis schrieb in Nachricht ...
>Has anyone got Foundation M1.4 DynaText Browser working with Windows NT
>4.0 (SP3). I am using NTFS, which may not be a tested configuration. All
>looks good until I try to open something. For example, Libraries Guide"
>under "Xilinx Books CD". The CDROM spins for a second, and then I get the
>message "Cannot open book ...". The same thing happens for all books
>whether on CD or disk.
>
>I have checked (and corrected) the paths in dynatext.ini, and they all
>make sense. With some very quick system file monitoring I see that
>DynaText is playing fast and loose with file and directory names. For
>example, it creates a directory using mixed upper/lower case names, and
>then accesses it using a different combination of upper and lower case.
>Not that this shouldn't work, but it is the type of thing that makes me
>suspect a problem when run under NTFS.
>
>It may be worth mentioning that Dynatext worked OK on this system in
>M1.3.
>--
>George Pontis
>
>(Replies to geo at z9 dot com.)


Article: 11115
Subject: Re: CRC Implementation
From: ems@see_sig.com (ems)
Date: Mon, 20 Jul 1998 11:13:55 GMT
Links: << >>  << T >>  << A >>
On Sun, 19 Jul 1998 10:42:35 -0400, APS <resp@associatedpro.com>
wrote:

>Has anyone done any CRC-16 implementations in an FPGA? I am looking for
>the CRC-CCITT implementaton in particular. Any help or pointers to
>information at all would be appretiated?

The first problem here is the phrase 'CRC-CCITT'. I don't know who
invented this term (it doesn't seem to have been the CCITT), and
what specifically they meant, but I take it to mean some subset of V41
and V42 (CCITT Blue Book, Volume VIII, Fascicle VIII.I,
recommendations V41 and V42, ISBN 92-61-03661-9). V41 and V42 agree
on a polynomial, but recommend different preset values for the
shift register. I think the most common implementation is to preset
the transmitter to all 1's, to invert the output, and for the receiver
to check for 0x1D0F (the V42 'typical implementation'). If you don't
want to do a parallel version, then the diagrams in the spec are all
you'll need.

If you want a parallel version, you'll have to decompose the
polynomial into a parallel form. This is pretty straightforward. One
very useful reference is one of AMD's TAXI app notes, which I've
unfortunately lost. You could also look up an EDN article by Krishna
Rallapalli (EDN, Sept.5/1978). I think this describes an old Fairchild
chip (74F401?). I've also got an old article by Jack Ganssle (1991) -
I don't know what the source is; probably EDN or Byte.

The next problem is that the CCITT describes a bit-serial algorithm,
and so there's an implicit endianism problem when you convert to
parallel. The articles I've seen generally ignore this (Ganssle's is
particularly bad, and wrong), and so they result in different
implementations (for instance, the receiver has to check for 0xF0B8
instead of 0x1D0F). A related problem is whether to transmit the high
byte of the result first, or second. The answer's easy if you've
actually got a bit- serial transmission medium - everything has to be
bit-big-endian (X25, for example, normally sends its data fields
little-endian, but sends the checksum big-endian).

However, if you're not responsible for the complete system, the
important thing is to check that everyone agrees on the transmission
format and check value - there's a good chance that the other guy will
have got it wrong.

The actual parallel hardware's pretty trivial. You can trade off the
number of delay levels against the logic complexity but, IIRC, you'll
end up with a total of 20-25 two, three, and four-in xor's.

Evan (ems@nospam.riverside-machines.com)

Article: 11116
Subject: Need info -> implementing high-speed multipliers
From: rjmyers@dseg.ti.com (Bob Myers)
Date: 20 Jul 1998 12:41:12 GMT
Links: << >>  << T >>  << A >>
I'm in a situation where I need to implement a high-speed
multiplier.  It's going to be a 12x12 unsigned multiply, 
producing a 24 bit result.  Would like to see if it can
be done in 5 clock cycles or less.  (Clock cycle will be
in the MHz range).

I'm targeting a Xilinx XC4062XL part.  I'm in the process
now of trying to debug the interface to a Xilinx CORE-gen'ed
multiplier that does the job in 5 clocks.

Any inputs welcomed.  I've already had someone suggest
looking at the Xilinx app note on a constant coefficient
multiplier.

Thanks,
Bob


Article: 11117
Subject: Re: Xilinx Dynatext and NTFS ?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 20 Jul 1998 08:50:51 -0400
Links: << >>  << T >>  << A >>
George,

Mine works fine under NT.  I too am using NTFS.  I installed the documention
disk on my hard drive.   I get book listings under Xilinx Books and Broswer
documentation only.  The others have blank book lists.  I open books
successfully.  Mine worked fine right out of the box, so I can't give you
tips on what to fix.

George Pontis wrote:

> Has anyone got Foundation M1.4 DynaText Browser working with Windows NT
> 4.0 (SP3). I am using NTFS, which may not be a tested configuration. All
> looks good until I try to open something. For example, Libraries Guide"
> under "Xilinx Books CD". The CDROM spins for a second, and then I get the
> message "Cannot open book ...". The same thing happens for all books
> whether on CD or disk.

--
-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: 11118
Subject: Old Contace Information
From: Edward Pickering <edward.pickering@stud.umist.ac.uk>
Date: Mon, 20 Jul 1998 14:21:26 +0100
Links: << >>  << T >>  << A >>
Does anyone happen to know what has happened to either Crosspoint
Solutions or Concurrent Logic?

I'm currently doing some research, and can't seem to find anything out
about them. Chances are that they went bust or got taken over, but a
definate confirmation would be useful.

My thanks in advance...

Edward Pickering
UMIST

Article: 11119
Subject: Old Contace Information
From: Edward Pickering <edward.pickering@stud.umist.ac.uk>
Date: Mon, 20 Jul 1998 14:23:02 +0100
Links: << >>  << T >>  << A >>
Does anyone happen to know what has happened to either Crosspoint
Solutions or Concurrent Logic?

I'm currently doing some research, and can't seem to find anything out
about them. Chances are that they went bust or got taken over, but a
definate confirmation would be useful.

My thanks in advance...

Edward Pickering
UMIST

Article: 11120
Subject: Old Contace Information
From: Edward Pickering <edward.pickering@stud.umist.ac.uk>
Date: Mon, 20 Jul 1998 14:23:26 +0100
Links: << >>  << T >>  << A >>
Does anyone happen to know what has happened to either Crosspoint
Solutions or Concurrent Logic?

I'm currently doing some research, and can't seem to find anything out
about them. Chances are that they went bust or got taken over, but a
definate confirmation would be useful.

My thanks in advance...

Edward Pickering
UMIST

Article: 11121
Subject: Re: Partial reprogramming
From: husby@fnal.gov (Don Husby)
Date: Mon, 20 Jul 1998 13:40:51 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <no_spam_randraka@ids.net> wrote:
> There are 4 devices that are currently on the market that I am aware of
> that handle partial reconfiguration:  Atmel AT40K series, Atmel AT6K
> series, Dynachip DL6K series and Xilinx 6200.  Motorola's part could too,
> but they just killed their FPGA line a few weeks ago, and National
> Semiconductor has a series of parts that do it, but so far they are not
> selling them to the general public.

Lucent Orca parts are partially reconfigurable.
Each configuration frame has an 11-bit address which
provides random access to the configuration.  There are 500 to 1500 frames
per chip.

Article: 11122
Subject: Re: Need info -> implementing high-speed multipliers
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 20 Jul 1998 09:46:03 -0400
Links: << >>  << T >>  << A >>
Bob,
I've got a 12x12 in unsigned, signed and partially signed flavors that
is pipelined 5 clocks and is good to about 50 MHz in a 40xxE-2. The
footprint fits in a 14hx13w rectangle. I believe the xilinx logic core
generator generates one that is similar.  The multiplier uses the
technique you learned for long hand multiplication in grade school, in
that one input is multiplied separately by each 2-bit 'digit' of the
other input, and then those partial products are summed with the
appropriate amounts of shift.  Each partial multiplies the other input
by either 0, 1, 2, or 3 depending on the value of the two bits.  The
first stage of my pipeline unconditionally computes 3x the A input by
adding a shifted version of the input to itself.  This stage also passes
the 1x A input delayed by a clock. The next level in the pipeline is a
set of 4:1 multiplexers controlled by pairs of bits in the B input.  The
multiplexers select either 0, the 1x A input, the 1x A input left
shifted (2x), or the 3x A input.  Thus the multiplexers with the common
3x logic forms a set of fast cheap 2xn multipliers.  This by the way is
where mine differs from the xilinx logicore macro (the xilinx macro may
have since been updated).  The xilinx macro rolls the 3x adder into the
multiplexer, which results in slightly less area, but also reduces the
performance by about 15% due to the high fanout and carry chain being in
the same combinatorial path. The remaining 3 pipeline stages make up a
registered adder tree that simply adds the partial products from the
muxes together to obtain the full monty.

If you only need to do the multiplication at around 1MHz, and you can
obtain a higher clock why not use a radix serial by parallel multiply?
It would take considerably less real estate to do.

Bob Myers wrote:

> I'm in a situation where I need to implement a high-speed
> multiplier.  It's going to be a 12x12 unsigned multiply,
> producing a 24 bit result.  Would like to see if it can
> be done in 5 clock cycles or less.  (Clock cycle will be
> in the MHz range).
>
> I'm targeting a Xilinx XC4062XL part.  I'm in the process
> now of trying to debug the interface to a Xilinx CORE-gen'ed
> multiplier that does the job in 5 clocks.
>
> Any inputs welcomed.  I've already had someone suggest
> looking at the Xilinx app note on a constant coefficient
> multiplier.

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

The Andraka Consulting Group is a digital hardware design firm
specializing in high performance FPGA designs for signal processing,
computing and control applications.

Article: 11123
Subject: Re: Old Contace Information
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 20 Jul 1998 10:10:12 -0400
Links: << >>  << T >>  << A >>


Edward Pickering wrote:

> Does anyone happen to know what has happened to either Crosspoint
> Solutions or Concurrent Logic?
>
> I'm currently doing some research, and can't seem to find anything out
> about them. Chances are that they went bust or got taken over, but a
> definate confirmation would be useful.
>
> My thanks in advance...
>
> Edward Pickering
> UMIST

Concurrent sold to national semiconductor and Atmel (I don't recall the
legal stuff).  Any way, the Atmel 6K devices are the concurrent
architecture with a few minor changes.

--
-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: 11124
Subject: Re: Partial reprogramming
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 20 Jul 1998 10:11:15 -0400
Links: << >>  << T >>  << A >>


Don Husby wrote:

> Ray Andraka <no_spam_randraka@ids.net> wrote:
> > There are 4 devices that are currently on the market that I am aware of
> > that handle partial reconfiguration:  Atmel AT40K series, Atmel AT6K
> > series, Dynachip DL6K series and Xilinx 6200.  Motorola's part could too,
> > but they just killed their FPGA line a few weeks ago, and National
> > Semiconductor has a series of parts that do it, but so far they are not
> > selling them to the general public.
>
> Lucent Orca parts are partially reconfigurable.
> Each configuration frame has an 11-bit address which
> provides random access to the configuration.  There are 500 to 1500 frames
> per chip.

See, even I learn something new everyday!


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




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