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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 9200

Article: 9200
Subject: Re: Correlation--Multichannel
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Sun, 01 Mar 1998 22:25:25 GMT
Links: << >>  << T >>  << A >>
On Fri, 27 Feb 1998 10:28:14 -0500, "Erik L. Kobal"
<erkobal@grail.cba.csuohio.edu> wrote:

>What we need to accomplish is this:  We need 16
>correlators for 16 channels.  Each correlator will need two FIR
>filters.  We are looking to have 40 taps in our application, but we
>would do fine with 32.  Each FIR filter must handle a throughput of 20

Even with fixed multiplication coefficients, this is going to be BIG.

<prophet mode on>
I have visions of many FPGAs for such an implementation.
<prophet mode off>

Count the multipliers, count the adders for the accumulation, yechh,
nasty. Wow, maybe we've found an application for that million gate
FPGA!

>MSPS.  In the Altera application notes on implementing FIR filters, I
>read that you can have serial or parallel FIR filters, or a hybrid of
>the two.  Also, the pplication notes mentioned that there are off the
>shelf FIR filters that can accomadate about 30 MSPS.  We would like to
>look into this as a possible solution instead of programming an FPGA to
>perform the same function.  Would anybody have any insight what would be
>the best way to go about this?  Any help would be greatly appreciated. 
>Thanks again!

Harris have standard FIR filters but they aint cheap. They typically
implement 8 or 16 tap filters, but the coefficients are truly
programmable, and sometimes double buffered for continuous operation.
I think they run to about 50MHz now.

Stuart
Article: 9201
Subject: Re: Correlation--Multichannel
From: "rk" <stellare@erols.com.NOSPAM>
Date: 1 Mar 1998 22:36:11 GMT
Links: << >>  << T >>  << A >>
<major major snip>

stu:
: Harris have standard FIR filters but they aint cheap. They typically
: implement 8 or 16 tap filters, but the coefficients are truly
: programmable, and sometimes double buffered for continuous operation.
: I think they run to about 50MHz now.

rk:
also, i think it was a company called Gray or Grey or something like that
had a 16-tap chip w/ 16-bit coefficients that ran fast, don't remember the
$.  but do remember bring along your extra power supply, not flea powered.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9202
Subject: FP problem in win/95
From: !!!n5mpa@mci2000.com!!! (Mike)
Date: Sun, 01 Mar 1998 23:46:43 GMT
Links: << >>  << T >>  << A >>
 When I installed FP 98 there is no directory for it listed in my
programs group.  I have made short cuts for fpexplorer and editor
but have no directory listing.  Does anyone have any suggestions?
I have reinstalled the program twice, but still no listings. Mike
Article: 9203
Subject: Re: The case for Linux and EDA
From: gogo@netcom.com (R. Mark Gogolewski)
Date: Mon, 2 Mar 1998 00:29:05 GMT
Links: << >>  << T >>  << A >>

The issue below of "how long will it take the suits to 
figure this out?" is compounded on both sides of the
equation:

  How many vendors are going to shell out porting/support 
  costs for a new OS without a customer promising the $$ 
  to buy it?

  How many customers are going to put up $$ for a tool 
  (and the machines, and the sys-admins) on a new OS 
  without a guarantee of other software being there 
  as well?

Linux as an EDA OS is caught in a _classic_ chicken-&-egg
problem.

Mark



In article <6dcfi7$pui$1@user2.teleport.com>,
Phil Ptkwt Kristin <ptkwt@user2.teleport.com> wrote:
>In article <34F80FF7.221C764E@worldlink.nsp.net>,
>Jay Darmon  <jdarmon@worldlink.nsp.net> wrote:
>>In recent months there have been many successes for the Linux operating
>>system:
>
>[snippage of a lot of recent Linux accomplishments]
>
>Just to add my 2 cents:  I'm seeing positive articles on Linux all over
>the place these days - in the regular press, PC rags, there was even one
>on the MSNBC site recently.  Linux is competing with NT favorably in a lot
>of areas (and in some areas like web serving, its probably beating NT).
>
>>So far, though, the EDA market has been a tough one for Linux to move
>>into.  It seems that the engineers (the users of EDA apps ) are quite
>>willing to use Linux, but the EDA companies want to push NT.  The case
>>for EDA applications on Linux is compelling:
>>
>[snippage of a lot of good reasons to use Linux instead of NT]
>
>The case for Linux is indeed compelling.  The problem at this point is
>that we need to educate those who are 'in power' (ie those who control the
>purse strings).  Most marketing and management types (the suits) don't see
>more than about six inches in front of them when it comes to new trends
>like this (and even then it has to be spelled out to them in big, bold
>print :) so for the most part they've never even heard of Linux.
>
>Since Linux is THE fastest growing part of the UNIX world right now it is
>inevitable that more EDA companies will be supporting it in the future -
>the question is, how long will it take the suits to figure this out?
>
>>
>>In last week's EETimes (Desktop EDA column) another compelling reason
>>was given:  Using 'farms' (or clusters, see the links above) to speed
>>simulation.  SpeedSim is reporting some high profile customers are using
>>this approach.  As the article says this could be the killer EDA app for
>>Linux.  It is difficult to set up such clusters using NT and it is very
>>expensive to do it using traditional workstations.  Linux excells in
>>this area - which is why NASA and others are setting up such clusters as
>>a low cost alternative to supercomputers.
>>
>>Some point to the Exemplar experiment with Linux last year as evidence
>>that there is no demand for EDA tools on Linux.  I suspect that this is
>>the wrong conclusion based on the following:
>[snipped analysis of Leonardo for Linux experiment]
>>
>>The conclusion is that the Exemplar experiment was inconclusive.  Linux
>>could still be a very successful EDA platform.  Perhaps the companies
>>that are building Linux clusters for simulation will demand that other
>>parts of the tool chain be made available on Linux as well.
>
>A synthesis tool by itself on Linux was probably not the best tool to be
>there first - would have been much better to have had a simulator on Linux
>first (and as was pointed out, there are some available on Linux now).
>We can only hope that Exemplar will be willing to try the 'experiment'
>again, but this time with some better monitoring.
>
>There's also the Open-source route ('Open-source' being the new preferred
>name for free software - ie the source is readily available).  There is a
>group that is working on a free (open-source) VHDL simulator at:
>http://www.linuxeda.com/~freehdl
>
>and I've heard some rumblings about a GNU-CAD project (don't have a link) 
>that is trying to develop a schematic capture package.
>So if the companies won't listen, take it to the people!
>
> phil


Article: 9204
Subject: Help with ViewLogic 4
From: k.rozniak@XXX.ien.gda.pl (Krzysztof Rozniak)
Date: Mon, 02 Mar 1998 01:55:20 GMT
Links: << >>  << T >>  << A >>
I am using rather old version of VL as a front end for XACT6.
Does anybody know how to make VL 4.1.3 running under DOS7 (from W95)?
Works fine with DOS5.0 and QEMM6.0 as memory manager.
I spent a lot of time testing different configurations but I failed.
There is no (or I can't find) info about it on ViewLogic home page.
Any help will be appreciated.

--
Christopher Rozniak
Gdansk, Poland, Europe, Earth
E-mail: k.rozniak@XXX.ien.gda.pl
remove anty-spam XXX. to email
Article: 9205
Subject: Firmware Eng's WANTED: outstanding career opportunities
From: rtc@servtech.com (Bob Crotinger)
Date: Sun, 01 Mar 1998 21:41:28 -0500
Links: << >>  << T >>  << A >>
TITLE: DSP Eng/ Datacom  
   
REF #:  MD-DSPMODEM-98

LOCATION: Central NJ/Phil,MA,GA,NC,IL,CA, other locations available

REQUIREMENTS:   Jr & Sr positions available; 1+ yr exp implementing DSP
algorithms for embedded telephony/telecommunications systems.  Prior
firmware development exp w/ Intel: 80x86 or Motorola: Power PC processors
and TI: TMS320Cxx DSPs a plus.  Knowledge of data communications/networking
protocols (TCP/IP, SNMP, IP, X.25, ISDN...ect) a PLUS.
 
COMPANY PROFILE:    Exceptional growth opportunity with a predominate
leader in the telephony/telecommunications industry.  Great benfits,
compensation, stock options, and will relocate.  Will sponsor H1-visa
candidates already within the stattes.  
--------------------------------------------------------

Call:  Mike DeLaney: 800-248-7020  x260

Email (text resume) to: mdelaney@servtech.com
 
-------------------------------------------------------
National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with degreed engineers, dedicated exclusively to
placing Engineers nationwide.  If this position doesn't fit your
requirements, call me with your specific search criteria.

€ NES can identify  SELECT  engineering opportunities based on your
background, interests, and geographic requirements.  

€ Engineers representing Engineers - we are not a generalist thus being
very focused in the technical arena only.   And we know it better than
anyone else.
********************************************************

CALL ME...Mike DeLaney  800-248-7020 x260 or email me a number and time and
I will call you.
Article: 9206
Subject: Re: The case for Linux and EDA
From: yankee <yankee@yankee.com>
Date: Mon, 02 Mar 1998 09:04:50 -0600
Links: << >>  << T >>  << A >>
>    I think most engineers would find that UNIX tools are easier
> and more fluid to use.  Not to mention more stable and often
> faster than their NT counterparts.  At this point, the only
> reason I use Windows NT is because my board layout software
> (MicroSim Schematics/PCBoards) is Windows only.  I am
> contemplating moving away from that software as well, in
> favor of something that supports UNIX.
> 
>
 

I find just the opposite. I think UNIX is a pain in general, and an
antiquated system who's days are numbered, thank God. It appears that
the CAD/CAM world is starting to agree, and is rapidly porting over to
NT. In a couple years, UNIX will be on it's deathbed.
Article: 9207
Subject: constant coefficients
From: ERIK@csvax.CSUOHIO.EDU (Erik Kobal)
Date: 2 Mar 1998 15:05:43 GMT
Links: << >>  << T >>  << A >>

Article: 9208
Subject: Re: The case for Linux and EDA
From: svoiski@mcr.spb.ru
Date: Mon, 02 Mar 98 19:06:27 +0300
Links: << >>  << T >>  << A >>
> >    I think most engineers would find that UNIX tools are easier
> > and more fluid to use.  Not to mention more stable and often
> > faster than their NT counterparts.  At this point, the only
> > reason I use Windows NT is because my board layout software
> > (MicroSim Schematics/PCBoards) is Windows only.  I am
> > contemplating moving away from that software as well, in
> > favor of something that supports UNIX.
> >
> >
>
>
> I find just the opposite. I think UNIX is a pain in general, and an
> antiquated system who's days are numbered, thank God. It appears that
> the CAD/CAM world is starting to agree, and is rapidly porting over to
> NT. In a couple years, UNIX will be on it's deathbed.
>

Proprietary hardware is on the deathbed. Proprietary OSes must follow.

As for the ease of use:
Installation of RedHat 5.0 or Slackware 3.2 is actually easier than installation
of NT (well, until you recompile the kernel). It is finished in 10-15 minutes
by relatively inexperienced user. As a system administrator, I would greatly
prefer to work with 50 Linux machines than with 50 NT machines that I have
to now. Some NT "features" are ridiculous compare to Linux: memory
allocation and multitasking are inferior to "antiquated" Linux, and in
Windows95 they are non-existent.

Sorry for supporting this eternal flame. Windows is great for secretaries
and games, but CAD/CAE community deserves more stable and high-performance
system. And Linux is a very good candidate.


Mikhail Svoiski.


Article: 9209
Subject: Re: Correlation--Multichannel
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Mon, 02 Mar 1998 10:29:48 -0800
Links: << >>  << T >>  << A >>
Erik L. Kobal wrote:
> <snipped>
> more insight.  What we need to accomplish is this:  We need 16
> correlators for 16 channels.  Each correlator will need two FIR
> filters.  We are looking to have 40 taps in our application, but we
> would do fine with 32.  Each FIR filter must handle a throughput of 20
> MSPS. 

You could take a look at the VP256 from Mitel (formerly Plessey)
It does 16 taps at 40 MHz, 32 at 20, etc. Data sheets at
http://www.gpsemi.com/ under Product data/Video speed DSP.


-----------
Tom Burgess

National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 9210
Subject: Re: Correlation implementation...
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 02 Mar 1998 14:27:25 -0500
Links: << >>  << T >>  << A >>
Moti Barkan wrote:
> 
> Hello Ray,
> 
> Correlation is not like FIR. You must normalize!
> 
> It is possible but might be tricky.
> 
> Regards,
>                 Moti

True enough.  Nevertheless, the hardware for the correlation itself is
the same as the FIR.  The reference coefficients are normalized when
they are computed (as far as the circuit is concerned these are
precomputed constants).  If needed (depends on the nature of the input
stream), either the input stream can be 'normalized' using an AGC type
circuit, or the output can be scaled to compensate for the changes in
the input level.  Often, you are simply looking for the peak in the
correlation so the absolute levels are not important as long as the
correlator doesn't saturate.

-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: 9211
Subject: Re: Correlation--Multichannel
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 02 Mar 1998 14:59:08 -0500
Links: << >>  << T >>  << A >>
rk wrote:
> 
> <major major snip>
> 
> stu:
> : Harris have standard FIR filters but they aint cheap. They typically
> : implement 8 or 16 tap filters, but the coefficients are truly
> : programmable, and sometimes double buffered for continuous operation.
> : I think they run to about 50MHz now.
> 
> rk:
> also, i think it was a company called Gray or Grey or something like that
> had a 16-tap chip w/ 16-bit coefficients that ran fast, don't remember the
> $.  but do remember bring along your extra power supply, not flea powered.
> 
 You will actually get a more compact design using FPGAs than either of
the chips listed above.  The trick is in the implementation of the FIR
filter...The multiplication is done using a partial products trick that
greatly reduces the size of the resulting circuit.  A 32 tap by 8 bit
FIR will take somewhere about 300 CLBs to get 20 MHz in a -1 part.  You
could squeeze two into a 4020, and maybe even into a 4013 if you were
real careful with the floorplanning. Still, that is 40 chips! Xilinx is
introducing their Spartan line which is a die shrinked lite version of
the venerable 4k series at a price point supposedly around $20-40. 
THese would probably at least make your project affordable.  That would
be a heck-uv-alot cheaper than using the Harris/Gray/LSI Logic/TRW FIR
filter chips.

-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: 9212
Subject: VSI Meeting
From: sbaker@best.com (Stan Baker)
Date: Mon, 02 Mar 1998 21:19:18 GMT
Links: << >>  << T >>  << A >>
VSI Meeting Notice:

The VSI Alliance is holding its Spring North American Member Meeting
on March 25 in Santa Clara.  This is the day after IP98.

This is a member-only meeting.

The program includes 
-- tutorial about on-chip bus specifications, 
-- panel on the business/marketing implications of VSI specifications,

-- case histories of applying the VSI specifications,
-- breakfast and luncheon
-- breakout sessions for each of the six working groups
-- beer party

For more information go to http://www.vsi.org,

To register, send your name, title, company, division, email and phone
number to nancy@vsi.org.

The VSI Alliance is a non-profit corporation with over 150 member
companies developing interface specifications for the mix and match of
cores and macros on system-level chips.

Best regards,
Stan Baker
Executive Director
VSI Alliance
Sbaker@vsi.org

Article: 9213
Subject: Re: The case for Linux and EDA
From: "Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au>
Date: 2 Mar 1998 21:30:41 GMT
Links: << >>  << T >>  << A >>


yankee <yankee@yankee.com> wrote in article <34FACA92.7627@yankee.com>...
> >    I think most engineers would find that UNIX tools are easier
> > and more fluid to use.  Not to mention more stable and often
> > faster than their NT counterparts.  At this point, the only
> > reason I use Windows NT is because my board layout software
> > (MicroSim Schematics/PCBoards) is Windows only.  I am
> > contemplating moving away from that software as well, in
> > favor of something that supports UNIX.
> 
> I find just the opposite. I think UNIX is a pain in general, and an
> antiquated system who's days are numbered, thank God. 

I think that I would agree that the old school Unix vendors such as
DEC, HP Sun etc are having trouble. In comparision to the modern Intel
PCs, their machines are overpriced as is their proprietary software.

Linux however is FREE (CDROM as little as $20) maximises the potential
of the hardware, is far more stable than Win95 (I don't have much
experience 
with NT) and is infinitely configurable. My main gripe with Win95/NT is 
that the OS and all the software treats me like I'm a moron. Linux on the
other hand treats me like I'm a genius, and I like that.

> It appears that
> the CAD/CAM world is starting to agree, and is rapidly porting over to
> NT. 

Yep, they're porting away from expensive proprietary Unix platforms, not
porting to NT. Unfortunately Linux is still seen as unproven, but I feel 
confident that Linux will prove itself a valid alternative to NT for 
the high-end and technically savy user.


> In a couple years, UNIX will be on it's deathbed.

Redhat has some statistics which says that 2 million copies of Linux
were installed last year. Apple shipped 3.8 million machines in the same
peroid. That makes Linux almost as big as Apple and its growing fast.

Erik
Article: 9214
Subject: Re: ORCAD front End Tools
From: Jeff <me@home.sleeping>
Date: Mon, 02 Mar 1998 17:37:58 -0600
Links: << >>  << T >>  << A >>
Demitri Korsikov wrote:
> 
> I am thinking of purchasing ORCAD Express to use as a front
> end tool for XILINX M1 and Lattice CPLDs.
> 
> Anyone have advice on using these tools ?

I switched from Orcad SDT386 and Xilinx XACT to 
Orcad Express and Xilinx M1.

It's quite different, but once you get used to it...
it really seems to work quite well.

-- Jeff
Article: 9215
Subject: Re: Correlation--Multichannel
From: "rk" <stellare@erols.com.NOSPAM>
Date: 3 Mar 1998 00:07:23 GMT
Links: << >>  << T >>  << A >>
rk:
: > 
: > <major major snip>

stu:
: > : Harris have standard FIR filters but they aint cheap. They typically
: > : implement 8 or 16 tap filters, but the coefficients are truly
: > : programmable, and sometimes double buffered for continuous operation.
: > : I think they run to about 50MHz now.
 
rk:
: > also, i think it was a company called Gray or Grey or something like
that
: > had a 16-tap chip w/ 16-bit coefficients that ran fast, don't remember
the
: > $.  but do remember bring along your extra power supply, not flea
powered.
 

ray:
:  You will actually get a more compact design using FPGAs than either of
: the chips listed above.  The trick is in the implementation of the FIR
: filter...The multiplication is done using a partial products trick that

rk:
yup, we did and most of it is done in the fpga.  ok, i violated the fpga
union rules and used some *discrete chips* for some really fast logic
(wouldn't have been implemented in the super-duper dsp chips anyways) where
i needed very low skew and tight timing and wanted to avoid getting the
fast clock on the fpga global clock network for a few small circuits. 
perhaps the atmel stuff would have been nice with the clock system
allocated by columns and lots of registers on the front end of the machine.
 it came out small and it runs fast (w.r.t. the technology) and we didn't
even go all out for speed optimization to save a bit of power and design
time (after requirements kept oscillating, coded up the core in vhdl).

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9216
Subject: Re: Free FPGA tools???
From: "Walter Daniel Gallegos" <walter@chasque.apc.org>
Date: 3 Mar 1998 01:31:34 GMT
Links: << >>  << T >>  << A >>

You can also check at ETHZ, Prof. Wirth and your group work in LOLA a very
good and easy HDL, free too,

http://www.inf.ethz.ch.

Walter

Steven K. Knapp <sknapp@optimagic.com> escribió en artículo
<6cn9rp$7m2@dfw-ixnews8.ix.netcom.com>...
> We keep a mostly-complete listing of free and low-cost software packages
for
> programmable logic design on The Programmable Logic Jump Station.  See
> http://www.optimagic.com/lowcost.html .
> 
> Also, a few people have mentioned the Xilinx and Altera student edition
> books.  See http://www.optimagic.com/books.html for more information on
> these publications.
> 
> -----------------------------------------------------------
> Steven K. Knapp
> OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
> E-mail:  sknapp@optimagic.com
>    Web:  http://www.optimagic.com
> -----------------------------------------------------------
> 
> Scott Campbell wrote in message <34EA49C3.234548C8@sbee.sunysb.edu>...
> >Timothy Oconnell wrote:
> >
> >> In article <34DD1F0E.74AAA61B@ethergate.com>,
> >> &miker  <Don't, Hit, Reply, Use, the, Link> wrote:
> >> >
> >> >The problem with FPGAs is that I can't find any affordable tools to
> >> >program them.  Does anyone support their
> >> >programmable devices with free base development software?  I don't
need
> >> >anything more capable than PALASM.
> >> >
> >>
> >> I recently bought a book that included a CDROM with the student
edition
> >> of MAX+PLUS II 7.2 software from Altera.  The book wasn't exactly free
> >> (~90$) but I know that Altera gives the software away to Universities.
> >> I'm a strong believer in the Altera design environment.  This version
can
> >> only program the FLEX 10K20 and one other device but it's fully
> >> functional in every other respect: full VHDL, AHDL, schematic entry,
> >> simulation, timing, etc.
> >>
> >> If you want the book and publisher, let me know -- I don't have it
with
> me.
> >>
> >>                 Tim.
> >>                 University of Cincinnati
> >
> >This is a good book and a good tool.  Look at the following URL
> >for more information:
> >
> >http://www.altera.com/html/new/textbook.html
> >
> >Scott Campbell
> >
> >
> >
> 
> 
> 
Article: 9217
Subject: Questions about creating personal package
From: "C. F. Fung" <ecffung@ntu.edu.sg>
Date: 3 Mar 1998 02:00:06 GMT
Links: << >>  << T >>  << A >>
I am new to VHDL (on Altera MAX Plus II 8.0) and encountering the following
problem. I would appreicate it if anybody can give some help.

I need to write a VHDL package which contains many entity/architecture
pairs
as the commonly referenced components I am going to instantiate in my main
program. A sketch of the structure of such a package is as follows:-


use ieee;
use ieee.std_logic_1164.all;

package my_pkg is
	component comp1
		port(
			......
		);
	end component;
	component comp2
		port(
			......
		);
	end component;
end my_pkg;

-------------------------------------------------------------
use ieee;
use ieee.std_logic_1164.all;

entity comp1 is
	port(
		-- I/O ports for comp1
	);
end comp1;

architecture of behavior of comp1 is
begin
	-- behavior of comp1
end;

------------------------------------------------------------
use ieee;
use ieee.std_logic_1164.all;

entity comp2 is
	port(
		-- I/O ports for comp2
	);
end comp2;

architecture of behavior of comp2 is
begin
	-- behavior of comp2
end;
-------------------------------------------------------------

The Questions are:-
	
1)	What file name should I use to contain the listing given above? Should
it be my_pkg.vhd, comp1.vhd, comp2.vhd or something else?

2)	In my main program (in a separate file), how does it know where to 
find the component definitions defined in the above listing?


Thanks for any help and comments.

C. Fung
Article: 9218
Subject: Debugging question.
From: janovetz@ews.uiuc.edu (Jacob W Janovetz)
Date: 3 Mar 1998 05:08:32 GMT
Links: << >>  << T >>  << A >>
Hello...

   I'm quite perplexed with a certain design I'm working on.  The
state machine is extremely simple and the speed is not pushing 
the device.  I'm using Leonardo for VHDL synthesis into a Xilinx 4000XL
FPGA.  Trouble comes in the normal execution of my state machine.
Certain items are not initialized as the code dictates they should
be.  The simulations come out perfectly.
   The perplexing part is that when I bring an internal signal out
to the package in order to observe it on a scope or logic analyzer,
the problem disappears so I can no longer observe it!  This happens
very consistently.  If a signal is brought out -- no trouble. 

   It seems similar to problems I've had with discrete logic where
a signal is left floating or has weird capacitive effects so that
placing a scope probe on the signal causes the trouble to disappear.

   Does anyone have any advice?  I'd appreciate it!  Something
that may be common with 4000XL devices that I don't know about?


    Cheers,
    Jake

--
   janovetz@uiuc.edu    | Once you have flown, you will walk the earth with
 University of Illinois | your eyes turned skyward, for there you have been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9219
Subject: Die Size Comparison of competing FPGAs
From: Kayvon Irani <kirani@cinenet.net>
Date: Mon, 02 Mar 1998 23:21:26 -0800
Links: << >>  << T >>  << A >>
    An article published in the Feb. 98 issue of  Altera's "News&Views"
claims that a Xilinx XC4062XL
    has twice the die size of an "equivalent" Altera device. For such a
large device such a great difference
    could mean a lot in terms of cost, yield, power consumption , etc..
Can any one confirm this apparent
    mismatch on the die size?

    Regards,
    Kayvon  Irani
    Los Angeles, Ca

Article: 9220
Subject: Spartan config. Mode
From: Laurent Gauch <laurent.gauch@eiv.vsnet.ch>
Date: Tue, 03 Mar 1998 11:31:34 +0100
Links: << >>  << T >>  << A >>
Spartan users,

I will use a XCS10 spartan in TQ144 package.
This spartan is almost pins compatible with XC4010E in TQ144 package. =


-------------------------------------------------
pad number          XCS10               XC4010E
                    in TQ144            in TQ144
                    pad name            pad name
-------------------------------------------------
P34                 Don't Connect       O(M1)
P36		    MODE                I(M0)
P38                 Don't Connect       I(M2)
P117                N.C. pin            I/O
-------------------------------------------------

I will design a compatible PCB (XCS10 and XC4010E in TQ144).
FPGAs are used in Master Serial Mode (MODE=3D0 or M0,M1,M2=3D0).

My question: =

How understand the 'Don't Connect' term? To design a pin compatible PCB, =

I must use a jumper to disconnect P34 and P38 (XCS10)or not.

Thank you, Laurent

_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ =

Laurent Gauch		      =

Ecole d'Ing=E9nieurs du Valais (EIV / ISW)
Route du Rawyl 47
1950 Sion, Switzerland
Tel:    ++41 (0)27 32 43 363
Fax:    ++41 (0)27 32 43 315
E-mail: laurent.gauch@eiv.vsnet.ch
http://www.eiv.ch/universel/gc/electro/micro/index.htm
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
Article: 9221
Subject: Xilinx XC5206 driving dedicated input pins
From: Gunnar Alm <Gunnar.Alm@enea.se>
Date: Tue, 03 Mar 1998 16:47:40 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7446A28D34037C8DA86258BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Have anyone experienced a XC5206 (or similar) driving dedicated input
pins? The drive is/seems logically connected to some other signal (e.g.
driven high when input X is high but tristated when input X is low.

Any bells ringing?

Regards,
/Gunnar Alm

-- 
 Gunnar Alm             Mobile: +46 70 551 1619
 Enea Data AB           Tel:    +46  8 638 5000
 Box 232, Nytorpsv 5B   Fax:    +46  8 638 5050
 S-183 23 TABY, Sweden  eMail: Gunnar.Alm@enea.se
--------------7446A28D34037C8DA86258BE
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Gunnar Alm
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Gunnar Alm
n:              Alm;Gunnar
org:            Enea Data AB
adr:            Box 232;;183 23 TABY;Stockholm;;;Sweden
email;internet: Gunnar.Alm@enea.se
tel;work:       +46 70 551 1619
tel;fax:        +46 8 638 5050
tel;home:       +46 8 512 416 19
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------7446A28D34037C8DA86258BE--

Article: 9222
Subject: Re: Xilinx Info.
From: Ed McCauley <zzNOSPAMBottomLine@eclipse.net>
Date: Tue, 03 Mar 1998 12:11:33 -0500
Links: << >>  << T >>  << A >>
>    Concerning your remarks about simulation of backannotated
> FPGA designs, I agree with you for the most part.  However,
> backannotation usually provides worst case timing into the
> simulation.  Therefore, if it works in the simulator, it should
> work in the lab.  I have found instances where a particular
> design may meet timing on one FPGA and not on another.  These,
> of course, would be pushing the limits, but it has happened.

One should note that back annotated timing is ONLY WORST CASE!  It is not how
the circuit will actually perform timing-wise.

Our approach is a functional simulation followed by static timing analysis after
implementation.  This assumes a 100% synchronous design of course.


--
Ed McCauley
Bottom Line Technologies Inc.
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA
       (908) 996-0817
FAX:   (908) 996-0817


Article: 9223
Subject: Version Control for schematics?
From: mushh@jps.net (David Decker)
Date: Tue, 03 Mar 1998 17:23:39 GMT
Links: << >>  << T >>  << A >>
I would like to use a version control system to support multiple 
FPGA designers doing ViewLogic schematic capture to 
Xilinx in under Win95. PVCS and similar programs are designed 
to support software developers. As I am discovering, the main 
deficiency of these systems when trying to use them for schematics, is
their inability to check directories in and out of version control.
They want to work with file lists.

I would like to check out version 6 of a schematic as a unit. It 
would consist of one sch\  directory with 100 .1 schematic files, 
and a sym\ directory with 80 .1 symbol files. I think the .bit file 
would best be included in the version,too.  I would then like to 
use ViewDraw to change the design in some respect, perhaps adding a 
sub page. A place and rout would produce another .bit file. 

When I check this back into version control, I would like all 
101 schematic and all 81 symbol files and the new .bit file to be 
checked in without having to tell the version control system that I 
added two files. I need to check schematics in as a unit.

To complete the picture, other engineers would be prevented from 
working on the FPGA that I was modifying, until I checked it back 
in. I also need to combine multiple .bit files to make a PROM 
image .exo hex file. I further need to combine two .exo files and 
a microcode .hex file in a FLASH. The payoff of the version control 
system, would be that the system would document what version of 
all the schematics and microcode were in that FLASH, and be able 
to reproduce any those files, if needed.

If anyone knows of a system that can do this, or has another 
workable system, I sure would be grateful for a tip. 

Since these version control systems seem to be limited to files, 
I'm thinking of combining all .sch and .sym files and the .bit 
file into one .tar file for check in, assuming I can find a DOS
version of TAR. TAR not using compression, I 
believe would result in smaller diff or delta files between check 
in versions than .zip would permit.

Thanks for your help,


Dave Decker
Diablo Research Co. LLC

Please use only one 'h' in mush. I'm trying to reduce the spam.



"Animals .  .  . are not brethren they are not 
underlings;  they are other nations, 
caught with ourselves in the net of life and time, 
fellow prisoners of the splendor and travail of 
the earth."
Henry Beston -  The Outermost House
Article: 9224
Subject: Re: Xilinx X3000: Does XACT6 accept the "L" or "SC=n" attribs?
From: "reno" <falkenberg@stagetec.com>
Date: Tue, 3 Mar 1998 19:00:57 +0100
Links: << >>  << T >>  << A >>
think you're right regarding 'L' (don't know 'SC' :( )
-a good workaround could be the weight attribute 'W=', although it's not
very useful for XC3K families
-another good way is to constrain the location of critical CLBs and use the
'P' pinlock or 'MAP=PLO/PLC' attribute on CLBMAP symbols (B and C inputs are
best for longlines in old 3K) and hope software understands your thoughts
-horizontal longlines can be forced by placing 'dummy'-TBUFs
-best way is using XDE

sorry, it's long time ago I was using XACT/3K
hope I could help you
reno:)

Peter schrieb in Nachricht <34f28d22.63979507@news.netcomuk.co.uk>...
>Hello,
>
>Sorry for the repost but nobody seems to know the answer to this
>simple question.
>
>I have been using Viewlogic 4 (DOS) and XACT6 PPR (DOS) for XC3000
>designs.
>
>I have been attaching the above attrobutes to nets in the circuit, to
>force allocation to either Long Lines or to specify a maximum skew
>time, respectively. These are described in the Xilinx Viewdraw/LCA
>docs.
>
>I have seen some strange problems, never present in the old APR, and
>it has occurred to me that XACT6/PPR might be ignoring these net
>attributes.
>
>I know that the Xilinx preferred method today is timespecs, but this
>is a nice simple way to do it.
>
>
>Peter.
>
>Return address is invalid to help stop junk mail.
>E-mail replies to z80@digiXYZserve.com but
>remove the XYZ.




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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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