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 2900

Article: 2900
Subject: Re: Xilinx FPGA's with Mentor Tools?
From: Lance Gin <c43lyg@dso.hac.com>
Date: 27 Feb 1996 00:01:32 GMT
Links: << >>  << T >>  << A >>
zeev@cadence.com (Zeev Yelin) wrote:
>In article <4fqs7k$2tn@hacgate2.hac.com>, Lance Gin <c43lyg@dso.hac.com> wrote:
>
>
>> >Just for the record, we're using the A3F release and XACT 5.1.1 on 
>> >Sun Solaris 2.5. Generally, once bashed into shape by my mate vi ;-) 
>> >the system works well. 
>> 
>I was told by Xilinx they are not yet ported to Solaris, and yet you tell
>us  casually on working on Solaris 2.5  !!! amazing.
>how stable it is ? Share with us Lance.
>thx
>Zeev
>
>-- 
>Zeev Yelin, Cadence Design Systems(Israel)
>

hi zeev,

i'm afraid you'll have to ask les hughes (l.j.hughes@greenwich.ac.uk)
who made the comment which i quoted and you inadvertantly attributed
to me.

as for myself, i'm looking at an HP-UX or PC version of XACT. regards,


-- 
____________________________________________________________________________

Lance Gin                                              "off the keyboard
Delco Systems - GM Hughes Electronics                   over the bridge,
OFC: 805.961.7737  FAX: 805.961.7329                    through the gateway,
C43LYG@dso.hac.com                                      nothing but NET!"
____________________________________________________________________________




Article: 2901
Subject: Atmel Serial Configuration E2PROMs
From: "** Atmel FPGA Apps. :-)" <martin@atmel.com>
Date: Tue, 27 Feb 1996 02:56:09 GMT
Links: << >>  << T >>  << A >>
Peter Fenn writes...

>We have recently purchased AT17C128 Serial PROMS to replace Xilinx 
>configuration PROMs, but do not have any apparent means to program these 
>new devices.
>

The EEPROM devices are supported by most 3rd party programmer companies - 
a copy of supported manufactures is available from Atmel's Fax-on-Demand 
(1-800-29-ATMEL) - document #663.

 
>I have downloaded Atmels CONFIGURATOR application note describing the 
>programming spec, which now prompts me to ask the question "Is there not 
>a piece of programming software already already out there somewhere 
>that'll save me some time?"

Atmel makes a simple programming board (ATDH2200 - $250) that plugs into 
the parallel port on any X86 PC and allows you to program the AT17Cxxx 
family of parts.  It comes with the s/w you describe to read/write/verify 
the Atmel re-programmable serial configuration proms.  The input data can 
come from a 17Cxxx device (which can be read from the board) or one of 
several industry standard file formats.

I hope this helps - If you would like more information send me an e-mail 
with your snail-mail address or visit the Atmel home page 
http://www.atmel.com

Regards

Martin Mason

-------------------------------------------------------------------------
|       Martin Mason            | Snr FPGA/17Cxxx Applications Engineer |
|       Atmel Corp.             | (Work)         martin@atmel.com       |
|       2125 O'Nel Drive        | (Work2)          fpga@atmel.com       |
|       San Jose                | (Fax)         + (408) 436 4300        |
|       CA 95131                | (Tele)        + (408) 436 4178        |
-------------------------------------------------------------------------
| Visit http://www.atmel.com    | 'kewl' thinks Martin, The Net Dude :] | 
-------------------------------------------------------------------------



Article: 2902
Subject: Re: Xilinx FPGA's with Mentor Tools?
From: Les Hughes <L.J.Hughes@gre.ac.uk>
Date: Tue, 27 Feb 1996 09:10:28 +0000
Links: << >>  << T >>  << A >>
Lance Gin wrote:
<..snippity snip...>

> 
> >3/ Xilinx recommend XBlox. XBlocks models don't have timing characteristics.
> 
> are you referring to models for use by the XACT XDELAY static TA tool?
> or perhaps you're referring to QuickPath? does xilinx have any plans to
> supply the models you need?

>From what I understand about this, the actual delays are route specific ie you only
get'em once you've apr'ed....

> 
> >4/ TimSim8 (backannotation of routed design timing to "Schematic") does not modify
> >the source schematic (EDDM database) via a viewpoint. It generates another design
> >database in a separate directory. This presents a rather serious configuration
> >control problem.
> 

Can't comment for other os /rels but A3F & 5.1.1 there's an option on the FNCSIM8 & TIMSIM8
forms that allow you to back-ann. the original schematic or generate a new one.

> 
> >5/ An EDIF read licence is required, at the unreasonable price of ~2000.
> 
> how is this used in the mentor/XACT flow?

Mentor > edif > Xilinx XNF > edif > mentor

> 
> >6/ XNFBA still does not work.
> 
> we're new to the xilinx world. what's XNFBA?

I had to hack the /bin/sh scripts to get this to work.....


Bye,
Les.
 
-- 
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
                   Les Hughes - Applications Group 
 Computing Services           | Phone/Fax:  +44 (0)181 331 8390 / 8566
 University of Greenwich      |
 Woolwich,  London SE18 6PF   | E-Mail:     L.J.Hughes@greenwich.ac.uk

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"I'm applying intelligence and observation to the situation..."
						      - Murray Walker
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


Article: 2903
Subject: Re: Programming ATMEL config. PROMs ?
From: "Ingo Cyliax" <cyliax@cs.indiana.edu>
Date: Tue, 27 Feb 1996 09:00:40 -0500 (EST)
Links: << >>  << T >>  << A >>
I build a little programmer board (PC-parallel port) and wrote a small
basic programm to burn these from a S1-S9 hex file (makeprom -f exo, in
XACT) on a PC.

Check out :

	ftp://ftp.cs.indiana.edu/pub/goo/eeprg

We use this programmer to burn XC3000 config. proms. for our stiquito
controller (http://www.cs.indiana.edu/robotics/colony.html). The software
does not support changing the RESET/OE# polarity, but it shouldn't be
hard to add. Let me know if you have problems...

See ya, -ingo

In article <4gre26$pv5@aztec.co.za>,
Peter Fenn  <peterf@electrosolv.co.za> wrote:
>We have recently purchased AT17C128 Serial PROMS to replace Xilinx configuration 
>PROMs, but do not have any apparent means to program these new devices.
>
>I have downloaded Atmels CONFIGURATOR application note describing the programming 
>spec, which now prompts me to ask the question "Is there not a piece of programming 
>software already already out there somewhere that'll save me some time?"
>
>I imagine the serial bus protocol could be implemented relatively simply using a 
>couple've pins on a PC's parallel port interface... 
>-Is there such a program at a FTP site somewhere? 
>
>Thanks in adavance.
>
>Regards
>
>
>PETER FENN
>
>****************************************************
>*                ____              ______________  *
>*  E L E C T R O |   \             ELECTROSOLV cc  *
>*  ==============|    \                            *  
>*                |     )=======      ELECTRONICS   * 
>*  ==============|    / S O L V      & SOFTWARE    *
>*                |___/               DESIGN GROUP  * 
>*                                                  * 
>****************************************************
>
>
>


-- 
/* Ingo Cyliax, cyliax@cs.indiana.edu, +1 812 333 4854, +1 812 855 6984 (day) */


Article: 2904
Subject: Re: Languages for reconfigurable computing.
From: herman@galant.ece.cmu.edu (Herman Schmit)
Date: 27 Feb 1996 15:29:48 GMT
Links: << >>  << T >>  << A >>

Steve Casselman (sc@vcc.com) wrote:

: VHDL and verilog are out since they are only
: 2D (you can specify timing but you end up with a time wise flat
: design)...

<stuff deleted>

: High level languages like C and fortran are naturally "time aware." 

: Steve Casselman
: Virtual Computer Corporation

Steve,

Hunh?

I'm not going to say that Verilog/VHDL are THE languages for
configurable computing, but I think that I can boldly say, anything
you can do in "C" I can do in Verilog better (with a couple of
caveats, see below).  First, Verilog/VHDL have all that's necessary to
describe any algorithm that you could describe in C, at the same level
of abstraction.  Your Fibonacci number generator in C has four lines,
my Verilog description has pretty much the same four lines.  Second,
unlike C, Verilog and VHDL were designed to be parallel languages.
Third, Verilog and VHDL are much more "time aware", or maybe "time
acknowledging" than C and Fortran.

The big bugger limitation with Verilog that it is a real pain to
describe mathematical functions that aren't unsigned two's complement.
What if I want to do signed-magnitude, or signed-two's complement?
You can't use the "*" or "+" and do that.  I guess VHDL is more
capable of that, but I staked my tent on the Verilog side of that war
too long ago to change now.

Of course, there are zillions of people who, when they have a clever
idea for an application, start doodling C code on the back of
envelopes.  We can't ignore this installed base of brains and think
they're all going become Verilog/VHDL hackers.  But the big bugger
problem with "C" is that its types are CPU machine types.  You have to
do everything with 32 bit integers, characters, and single and double
precision floating point.  That's a big deal for configurable
computing because a lot of the win in FPGAs come when the types of
data in the algorithm don't match the types in the available CPUs.
Anybody who's written bit-oriented computations in C knows what a pain
that can be.

What's the solution?  We've been playing with the idea that you use
some syntactic sugar from C++ to solve the type problem with C.
Create classes that simulate, using standard types like ints and
chars, the behavior of a wide variety of data types.  You can use
operator overriding so designers can still say "a + b" even when a and
b are 13 bit, fixed point, signed-magnitude numbers.  The C++ compiler
can be used to debug the procedure.  The parser for the hardware
compiler has to be a little more sophisticated and pick out those
classes, and substitute the right hardware to implement those
operations (ignoring how the underlying class implementation works.)

Herman

------------------------------------------------
Herman Schmit, Research Engineer
Department of Electical and Computer Engineering
Carnegie Mellon University
5000 Forbes Ave.
Pittsburgh PA 15213
Tel: (412) 268-6642
email: herman@ece.cmu.edu


Article: 2905
Subject: Re: Languages for reconfigurable computing.
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 27 Feb 1996 18:58:20 GMT
Links: << >>  << T >>  << A >>
>>>>> "HS" == Herman Schmit <herman@galant.ece.cmu.edu> writes:
In article <4gv81c$802@fs7.ece.cmu.edu> herman@galant.ece.cmu.edu (Herman Schmit) writes:

    HS> Steve Casselman (sc@vcc.com) wrote:

    HS> : VHDL and verilog are out since they are only : 2D (you can
    HS> specify timing but you end up with a time wise flat :
    HS> design)...

    HS> : High level languages like C and fortran are naturally "time
    HS> aware."

    HS> : Steve Casselman : Virtual Computer Corporation

    HS> Steve,

    HS> Hunh?

I also say, Huhhhh?

    HS> I'm not going to say that Verilog/VHDL are THE languages for
    HS> configurable computing, but I think that I can boldly say,
    HS> anything you can do in "C" I can do in Verilog better (with a
    HS> couple of caveats, see below).  First, Verilog/VHDL have all

Here, here. While I am not advocating VHDL/Verilog as reconfigurable
computing languages, they support concurrency and C does not. That
makes them much more appropriate from a "time-awareness" point of
view. Configurable computing systems need to be programmed with
*parallel* programming languages (this is true for other computers, as
well. --oops, there goes my unbiased opinion :-)).

Steve may have been making a different point though, see below.

    HS> The big bugger limitation with Verilog that it is a real pain
    HS> to describe mathematical functions that aren't unsigned two's
    HS> complement.  What if I want to do signed-magnitude, or
    HS> signed-two's complement?  You can't use the "*" or "+" and do
    HS> that.  I guess VHDL is more capable of that, but I staked my
    HS> tent on the Verilog side of that war too long ago to change
    HS> now.

This can be done in VHDL with overloading.  This is where the data
abstraction in VHDL can come in quite handy.  Unfortunately, VHDL is
almost as verbose as COBOL. Not quite, but close. And, yes, I must
admit that I actually wrote a little COBOL years ago :-P. That
certainly looks wierd on my resume, I suppose.  COBOL/Univac 11-08 and
VHDL synthesis. But I digress...

    HS> hackers.  But the big bugger problem with "C" is that its
    HS> types are CPU machine types.  You have to do everything with
    HS> 32 bit integers, characters, and single and double precision
    HS> floating point.  That's a big deal for configurable computing
    HS> because a lot of the win in FPGAs come when the types of data
    HS> in the algorithm don't match the types in the available CPUs.
    HS> Anybody who's written bit-oriented computations in C knows
    HS> what a pain that can be.

Before VHDL was around I wrote quite a bit of bit-oriented stuff in C
and C++. What a pain that was. It was also quite slow.  Now, I use
VHDL for that sort of stuff and it is great for describing bit-level
ops, systolic stuff, etc. Don't make me go back to C for hardware
description/simulation, pleeeaaaaaaseeeeee... :-)

    HS> What's the solution?  We've been playing with the idea that
    HS> you use some syntactic sugar from C++ to solve the type
    HS> problem with C.  Create classes that simulate, using standard
    HS> types like ints and chars, the behavior of a wide variety of
    HS> data types.  You can use operator overriding so designers can

If I understand your approach, this is similar to the DEC PRL stuff
and I think a number of other people have also advocated similar
approaches. How do you really simulate this without writing your own
event-driven simulator? A functional event-driven simulator is not a
big deal but it seems that you would need something along those lines,
right?.  You are still dealing with a non-concurrent language, so how
do you simulate a general concurrent description?  Overall, I think
that it is a reasonable approach. It has worked for a number of
people. And besides, who *simulates* FPGA designs, anyway? :-)

BTW, There *is* a problem with the specification of VHDL for RTR
(run-time reconfigurable) systems. VHDL is statically linked (well,
elaborated, anyway). There is no elegant way to describe hardware that
will be paged in at run-time with VHDL.  Here at BYU we work on
systems that are demand-paged. That is, the FPGA hardware does not
know beforehand what circuit modules will be loaded. That is a
function of the application software and the data set.  However, if
you wanted to describe such a system in VHDL, you would need to
enumerate all modules that *may* be loaded so that the entire system
can be elaborated prior to simulation (every circuit module would need
to be included in the elaboration step). One work-around is to
generate a new VHDL model from the software part of the application
that incorporates only those circuit modules that are referenced in
the software. This is still painful though. Dynamic linking may be of
some use (similar to what conventional linkers can do) --it could
resolve function calls to hardware at link time. Even this is
overkill, I suppose. Just because a module is referenced in the
software does not mean it will be loaded at run-time (it may be data
dependent). At any rate, the static elaboration of VHDL is what makes
it a bad fit for demand-paged hardware. Note that serial languages such
as C or C++ don't help either.  The demand-paged approach really cries
out for a language with some form of lazy evaluation. Let me see, 
lazy evaluation, parallel programming, hmmm, starts sounding like
a functional programming language. :-)

One final thing I wanted to ask was, why does VHDL (and even Verilog),
in general, get such a bad rap? Again, I'm not saying they are the
be-all, end-all of configurable computing languages, but they can be
quite effective under the right circumstances. And, my own experience
with the relative efficiency is that VHDL synthesis does a decent job.
Yeah, I know it is expensive and many cannot afford it. But, ignoring
the cost issue (which I think will be solved over time), VHDL works
surprisingly well for the things that I do. So, why do people seem to
dislike it so much?






Article: 2906
Subject: Re: Languages for reconfigurable computing.
From: EPV <EPV@pcsi.cirrus.com>
Date: 27 Feb 1996 19:16:47 GMT
Links: << >>  << T >>  << A >>
How is Atmel doing it? I haven't had time to try out their latest "cache logic". Any 
takers out there. I got chased out of a meeting for suggesting such a thing:-).



Article: 2907
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: peter@xilinx.com (Peter Alfke)
Date: 27 Feb 1996 20:29:48 GMT
Links: << >>  << T >>  << A >>
In article <Dn8oyo.8L@seqp4.sequoia.com>, budwey@sequoia.com (Mike Budwey)
wrote:


> If a bus spec REQUIRES that data not change for 3ns (for example) after
> the clock, I would call that a hold time.  Why the bus spec may even
> refer to it as t(DH)!
> 
I was first addressing a semantic problem: We should distinguish between
output DELAYS, be they max or min, and input REQUIREMENTS, and we should
not use the same word for both. But that's just a tutorial comment. I am
also the one who has  been arguing for 25 years that set-up and hold-time
requirements be called max parameters in the device data sheets ( not
min). There is something to be said for logic clarity. But it's just
semantics.

Let's talk physics:

When an IC manufacturer designs a chip that guarantees a worst-case delay
over the operating range of less than 10 ns, it is extremely difficult to
guarantee a min value of more than 2 ns, guaranteed over the operating
range, and valid even after one or two generations of process
improvements, when the "typical" delay has come down from 6 ns to 3 ns.
ICs are getting faster, and everybody is happy about the shorter delays,
but the min delays are also getting shorter. There is no free lunch.
If the system designer cannot avoid external uncontrolled clock skew, then
the only solution in the long run may be external deliberate and
controlled clock skew between the driving clock and the receiving clock.

Peter Alfke


Article: 2908
Subject: Re: Floating Point and Reconfigurable Architectures
From: Ray Andraka <randraka@ids.net>
Date: 27 Feb 1996 22:54:13 GMT
Links: << >>  << T >>  << A >>
Brad Taylor <blt@emf.net> wrote:
>
 
> If however, one needs floating point trancendental functions, divides, 
> atan2 or other complex functions, they can run more efficiently on an 
> FPGA by using the cordic algorithm.  This creates 1 bit per clock
> and can be pipelined to create a complete result every clock.  I'd like
> to see a DSP that could do 50 million atan()s per second.

The precision of CORDIC vs iteration is not fixed at one bit, it depends 
on the algorithm.  For example, vector magnitude gains 2 bits of 
accuracy for each iteration and the Log gains less than a bit.  I 
presented a paper that highlighted a CORDIC vector magnitude processor
in an FPGA at design SuperCOn '96.  That paper is available on-line
at my web site (http://www.ids.net/~randraka/)
> 
> It must be noted however that real world problems can usually be 
> implemented without floats.  The ecomomic advantage of 10-100 x 
> performance advantage might impel one to implement a solution as integer 
> math and to do the precision analysis. 
> 
This is certainly true.  I've yet to see a DSP application that can't
be solved using fixed point arithmetic and careful accounting of
the precision.  In some cases a block floating point scheme (where
a whole block of data has the same exponent) can be used to increase
the dynamic range with minimal effect on the hardware.  Point is,
there's very little that can't be done with fixed point and some thought.
Looked at in the extreme, IEEE floating point is really 23 bit fixed
point with an exponent.  BTW Floating point brings its own set of 
problems regarding precision.  
>
> 
> Also I supect that floats using bit serial math are relatively efficient.
> Has anyone checked this out?  

It can be done, but in most cases is not worth the effort and in fact
often would degrade the overall performance!
> 
-Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930   FAX 401/884-7950
mailto:randraka@ids.net
http://www.ids.net/~randraka/
 
The Andraka Consulting Group is a digital hardware design firm 
specializing in high performance FPGA designs.  Services include 
complete design, development, simulation, and integration of these 
devices and the surrounding circuits.  We also evaluate,troubleshoot, 
and improve existing designs. Please call or write for a free 
brochure.



Article: 2909
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: tak@core.rose.hp.com (Tom Keaveny)
Date: Wed, 28 Feb 1996 00:10:16 GMT
Links: << >>  << T >>  << A >>
Peter Alfke (peter@xilinx.com) wrote:
: In article <Dn3uCy.25v@icon.rose.hp.com>, tak@core.rose.hp.com (Tom
: Keaveny) wrote:
: 
: > Note, that there are a number of "synchronous" bus spec's that mandate
: > a non-zero hold time.
: 
: Please let me suggest a more careful noemnclature:
: 
: "Hold-time" is not an OUTPUT characteristic,
: 

	Semantics aside, busses like PCI, and processors such as the
Intel 80960SB require at least 2 nsecs of hold time for input signals
that they sample.  If a PLD or FPGA is supplying the output drive signal,
in these cases, they must have a minimum clock to output delay
of 2 nsecs or more.   Clock skew effects could increase the minimum delay
requirement, depending upon layout and routing.

	It should be noted, that there are other ASICs that have even
more severe hold time requirements for their inputs, and thus on minimum
output delay for their input sources.

	If a designer has "0" or "nil" as a minimum output delay for
a PLD or FPGA, the interface to these non-zero hold time ASICs can get 
quite messy (or the designer ignores the hold time spec and risks
incorrect operation).  As I mentioned previously in this thread, the
two typical interface options are to:

		- add delay buffers to all output signals
		- use separate drive and receive clock edges

	The first alternative can consume significant power and space for
datapath applications, and may not be feasible due to maximum output delay
vs. input setup time considerations.

	The second alternative usually requires a circuit to effectively operate
at 2-2.5 times its nominal operating frequency, and may have difficulty
meeting the target input setup time spec as clock rates increase.  


	Because of these factors, I still prefer to have minimum hold-time 
specifications to work with.
	

==
Tom Keaveny
Hewlett Packard Co.
"opinions are my own and not necessarily that of Hewlett Packard Co."



Article: 2910
Subject: ANNOUNCE: VHDL Tips and Models on NEW Web Site
From: Linda Dawson <linda@doulos.co.uk>
Date: Wed, 28 Feb 1996 10:38:08 GMT
Links: << >>  << T >>  << A >>

		****	ANNOUNCEMENT	****

IMMEDIATE RELEASE: 27th February 1996			Ringwood, UK


DOULOS announce the launch of a Web Site designed for the VHDL and 
Verilog user. This Web site is an information channel to help the 
engineer in using High Level Design and synthesis technology.

_______________
Check this out:
_______________
 
	for the engineer *new* to VHDL 
			there's the DOULOS FAQ
			and the free PACEMAKER tutorial

	for the *regular* user
			there's the Tip of the Month
			and the Model of the Month

	for the *experienced* VHDL designer
			there's the Advanced VHDL Techniques
			section

	for ease of use and re-use
			there's the hierarchical index and
			the chronological Table of Contents

Tim Pagden, Doulos specialist and the Web site designer, said
"We wanted to provide a Web site that would be a wealth of real 
practical design-related information for HDL users as well as being
a shop window for our own products and services."




		THIS MONTH on http://www.doulos.co.uk
_________________________________________________________________________

			***TIP OF THE MONTH*** 

<<	A DISCUSSION OF A STRUCTURED APPROACH TO CODING SEQUENTIAL LOGIC 
	FUNCTIONALITY IN PROCESSES					>>

				plus	

<< 	THE WRITING OF VHDL CODE FOR OPTIMAL SYNTHESIS 			>>


___________________________________________________________________________

			***MODEL OF THE MONTH***

	describes how to design large memory blocks in VHDL, without 
	being compromised by system virtual memory limits.

____________________________________________________________________________


DOULOS, Church Hatch, 22 Market Place, Ringwood BH24 1AW, Hampshire, UK
Tel: +44 1425 471 223		Fax: +44 1425 471 573
Email: info@doulos.co.uk	Web: http://www.doulos.co.uk



Article: 2911
Subject: Viewlogic WIR or XNF from/to SLIF or BLIF?
From: koch@eis.cs.tu-bs.de (Andreas Koch)
Date: Wed, 28 Feb 1996 11:57:53 GMT
Links: << >>  << T >>  << A >>
Is there a netlist converter from Viewlogic WIR or Xilinx XNF from/to
the SLIF or BLIF formats used by SIS? I have looked into eqn2xnf, but
it's too limited for real circuits (no latches). Any hints are appreciated! 

- Andreas Koch
-- 
Andreas Koch         * PGP key on request *    Email  : koch@eis.cs.tu-bs.de
Institut f"ur theoretische Informatik          Phone  : x49-531-391-2384
Abteilung Entwurf integrierter Schaltungen     Phax   : x49-531-391-5840
Gaussstr. 11, D-38106 Braunschweig, Germany    Telex  : 95 25 26


Article: 2912
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: budwey@sequoia.com (Mike Budwey)
Date: Wed, 28 Feb 1996 18:09:51 GMT
Links: << >>  << T >>  << A >>
Peter Alfke (peter@xilinx.com) wrote:
: In article <Dn8oyo.8L@seqp4.sequoia.com>, budwey@sequoia.com (Mike Budwey)
: wrote:


: > If a bus spec REQUIRES that data not change for 3ns (for example) after
: > the clock, I would call that a hold time.  Why the bus spec may even
: > refer to it as t(DH)!
: > 
: I was first addressing a semantic problem: We should distinguish between
: output DELAYS, be they max or min, and input REQUIREMENTS, and we should
: not use the same word for both. But that's just a tutorial comment. I am
: also the one who has  been arguing for 25 years that set-up and hold-time
: requirements be called max parameters in the device data sheets ( not
: min). There is something to be said for logic clarity. But it's just
: semantics.

Whether you call it a max or a min depends upon your perspective.  What
most data sheets are trying to say is "the user must guarantee that
input data remains unchanged for a minimum time after the clock edge."
Therefore, it's called a minimum hold time.

It sounds like your perspective is more along the lines of "for this
device to work in my system it cannot require data to remain for more
than 3ns after the clock edge.  That phrasing sounds more like a
maximum hold time.

Personally, I find it easier to relate to the first case, but I can
understand the confusion.

: Let's talk physics:

: When an IC manufacturer designs a chip that guarantees a worst-case delay
: over the operating range of less than 10 ns, it is extremely difficult to
: guarantee a min value of more than 2 ns, guaranteed over the operating
: range, and valid even after one or two generations of process
: improvements, when the "typical" delay has come down from 6 ns to 3 ns.
: ICs are getting faster, and everybody is happy about the shorter delays,
: but the min delays are also getting shorter. There is no free lunch.
: If the system designer cannot avoid external uncontrolled clock skew, then
: the only solution in the long run may be external deliberate and
: controlled clock skew between the driving clock and the receiving clock.

Sure, but suppose all manufacturers specified parts with no minumum
delay.  It sure would be difficult to generate that external deliberate
clock skew.  Buffers couldn't be used to create skew or delay the
output.  One would require delay lines, programmable skew PLL clock
generators, or multiphase clocks.

Oh well, nobody (except the vendors) ever said it was going to be easy.

Mike Budwey	budwey@sequoia.com


Article: 2913
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: budwey@sequoia.com (Mike Budwey)
Date: Wed, 28 Feb 1996 18:14:42 GMT
Links: << >>  << T >>  << A >>
Tom Keaveny (tak@core.rose.hp.com) wrote:

< stuff deleted >

: 	It should be noted, that there are other ASICs that have even
: more severe hold time requirements for their inputs, and thus on minimum
: output delay for their input sources.

: 	If a designer has "0" or "nil" as a minimum output delay for
: a PLD or FPGA, the interface to these non-zero hold time ASICs can get 
: quite messy (or the designer ignores the hold time spec and risks
: incorrect operation).  As I mentioned previously in this thread, the
: two typical interface options are to:

: 		- add delay buffers to all output signals
: 		- use separate drive and receive clock edges

: 	The first alternative can consume significant power and space for
: datapath applications, and may not be feasible due to maximum output delay
: vs. input setup time considerations.

It also requires you to find a vendor that will sell you a buffer with
a guaranteed minimum delay!  Hmmm, isn't this where we started? :-)


: 	The second alternative usually requires a circuit to effectively operate
: at 2-2.5 times its nominal operating frequency, and may have difficulty
: meeting the target input setup time spec as clock rates increase.  


: 	Because of these factors, I still prefer to have minimum hold-time 
: specifications to work with.
: 	

Agreed.


Mike Budwey	budwey@sequoia.com


Article: 2914
Subject: High Level Languages
From: sc@vcc.com (Steve Casselman)
Date: Wed, 28 Feb 1996 18:54:57 GMT
Links: << >>  << T >>  << A >>
> : High level languages like C and fortran are naturally "time aware." 
> 
> : Steve Casselman
> : Virtual Computer Corporation
> 
> Steve,
> 
> Hunh?
> 
> I'm not going to say that Verilog/VHDL are THE languages for
> configurable computing, but I think that I can boldly say, anything
> you can do in "C" I can do in Verilog better (with a couple of
> Third, Verilog and VHDL are much more "time aware", or maybe "time
> acknowledging" than C and Fortran.
When I say "time aware" I don't mean "timing aware" I mean in standard
HLLs first you do one subroutine then you do another. You bring in your
program from the outside world and you execute it over a period of time.
If I write a million lines of HLL I can execute it. In HDLs if I write 
a million lines of code I end up with one big part. With HLLs I time share
a piece of hardware with HDLs I create a design that has to exist at
the same time.
> 
> The big bugger limitation with Verilog that it is a real pain to
> describe mathematical functions that aren't unsigned two's complement.
HDLs describe hardware HLLs describe algorithms.
> 
> Of course, there are zillions of people who, when they have a clever
> idea for an application, start doodling C code on the back of
> envelopes.  We can't ignore this installed base of brains and think
> they're all going become Verilog/VHDL hackers.  But the big bugger
> problem with "C" is that its types are CPU machine types.  You have to
> do everything with 32 bit integers, characters, and single and double
> precision floating point.  That's a big deal for configurable
> computing because a lot of the win in FPGAs come when the types of
> data in the algorithm don't match the types in the available CPUs.
> Anybody who's written bit-oriented computations in C knows what a pain
> that can be.
This is why I'd like to see C have a bit vector.
bit my_varible[11];/* would be a 12 bit varible*/
> 
> What's the solution?  We've been playing with the idea that you use
> some syntactic sugar from C++ to solve the type problem with C.

I see just the flip side. We take "syntactic sugar" HDLs and put
them in C/C++. HLL need to be more "timing aware". If we came up
with thing that could be add to HLLs that even HLL writer would
want then everyone would writing code the would fit the reconfigurable
model. I think every C writer would love to have a bit vector construct.
We might even be able to get some things like this in acutal C standard.
If we added a wait() and do wait() to C this would help MPP writer
also. 

Steve Casselman




Article: 2915
Subject: Re: PCI models synthesized to FPGAs?
From: news@logici.com
Date: Wed, 28 Feb 1996 19:01:41 GMT
Links: << >>  << T >>  << A >>
I have synthesized a PCI master and target (both VHDL and Verilog) for
AT&T's ORCA FPGA and designed a working adapter card.  I have also
synthesized the models to XILINX's 4000E part and am currently trying
to get it to run at speed.  Has anyone else been able to get a XILINX
master to run in a PCI motherboard?  We sell PCI models and are trying
to get them to run in as many FPGAs as possible.

Charles Kaseff,
Logic Innovations
<ckaseff@logici.com>
David Emrich <emrich@exemplar.com> wrote:

>I would like to hear from people who have synthesized PCI models to
>FPGAs.

>========================================================================
>David Emrich                                        Exemplar Logic, Inc.
>emrich@exemplar.com                         815 Atlantic Ave., Suite 105
>                                                 Alameda, CA  94501-2274
>                                                                     USA
>========================================================================





Article: 2916
Subject: Zycad GF100K FPGA's
From: Jenny Pencis <Jennifer.Penics@amd.com>
Date: Wed, 28 Feb 1996 23:22:44 GMT
Links: << >>  << T >>  << A >>
Has anyone out there ever tried to use Zycad's GF100K FPGA's.  I have a 
feature list and short description on the family, but I really need to 
know how well the parts work and are they really as fast as Zycad claims? 
 I'm looking for a fast, large, and reliable FPGA for pre-ASIC chip 
development.
If anyone has any experience with them, please send me an e-mail at 
jennifer.pencis@amd.com


Article: 2917
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: Brad Taylor <blt@emf.net>
Date: Wed, 28 Feb 1996 19:08:29 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>
> Let's talk physics:
> 
> When an IC manufacturer designs a chip that guarantees a worst-case delay
> over the operating range of less than 10 ns, it is extremely difficult to
> guarantee a min value of more than 2 ns, guaranteed over the operating
> range, and valid even after one or two generations of process
> improvements, when the "typical" delay has come down from 6 ns to 3 ns.
> ICs are getting faster, and everybody is happy about the shorter delays,
> but the min delays are also getting shorter. There is no free lunch.
> If the system designer cannot avoid external uncontrolled clock skew, then
> the only solution in the long run may be external deliberate and
> controlled clock skew between the driving clock and the receiving clock.
> 
> Peter Alfke

Not being an IC designer, I might be going out on a limb, but I would
say that it must be possible for a chip manufacture to guarantee 
something like 3ns min delaye.  For instance, PPR can set bits to adjust 
the clock delay. If the fab shrinks, the delay can be maintained. 
I'm not saying that 3ns hold time is necessarily required, just that a 
consistant delay is possible if any one cared. 

Without using hold time, I can't design legally with Xilinx FPGAs.
Xilinx E series data sheets now says that pins have 7ns set up and
0ns hold required. If I assume 0 ns min delay and I have .5ns clock skew
between parts (the best I can do using matched line lengths and clock 
drivers), then I miss the time spec.  As designers we assume certain 
things are going to be legal. These include chip to chip communication,
using a common clock and on chip communication between registers.  

Without a min delay, how do I guarantee that I can clock data between
two registers on chip since I know I will have a finite amount of 
clock skew?

Currently I just assume that Xilinx chips will not fail in this fashion.



Brad Taylor

 
                         /==============<>==============\
                         |  Brad Taylor                 |
                         |  email home - blt@emf.net    |
                         |  voice home -(510) 601-5408  |
                         |  fax   home -(510) 601-5256  |
                         |                              |
                         \==============<>==============/


Article: 2918
Subject: How to multiple-download with Xilinx 4005 ?
From: dhlee@pingpong (Grad. Lee Dae-Hee)
Date: 29 Feb 1996 11:52:54 GMT
Links: << >>  << T >>  << A >>
Hello!!

 I'm a student of VLSI-Design Automation Lab of 
 Pusan National University, Korea.
 While researching a Logic emulator Tool with Xilinx Tool(XACT),
 I encounter problems. So I want your advice.
 
 For reference, my studying process is that.
 
 	step 1) Flow Schematics with WORKVIEWs
 	step 2) Create BIT file for each schematic using makebits.
 	step 3) Translate each bit file to a merging mcs file 
 		using makeprom.
 	step 4) Download the mcs file into multiple XC4000 series chips,
 		in slave serial mode using Xchecker downloading cable.
 
 The problem is the followings.
 
	I had tried to download multiple chips by daisy-chain method.
 	but after downloading, I checked the chips and I found only a lead chip
 	was downloaded successfully.
 
 	I want to know that my method is correct or not .
 	Specially, I want to know each bit file merging for daisy-chained
 	multiple downloading.
 	Is its method using makeprom ?
	Also,Do it load up from 0000 respectively in makeprom ?
  	Otherwise, Is promblem pin connection for multiple downloading ?
 	In my thought, each pin connection is correct.
 	
The following are my  board's configuration pin connection. 

1. DONE signal connection

     XCHECKER DOWNLOAD CABLE PIN
      +--------------+
      |      DONE    |
      +--------+-----+
	       |
	       +------------+
	       |	    |
      +--------+-------+    |	   +--------------+
      | 	       |    |	   |		  |
      | 	       |    |	   |		  |
      |  CHIP 1        |    |	   |  CHIP 2	  |
      | 	       |    |	   |		  |
      | 	  DONE |    |	   |		  |     ...  
      +-------------+--+    |	   +--------------+
		    |	    |
		    +-------+

2. INIT signal connection

      +--------------+
      |      INIT    |
      +--------+-----+
	       |
	       +------------+
	       |	    |
      +--------+-------+    |	   +--------------+
      | 	       |    |	   |		  |
      | 	       |    |	   |		  |
      | 	       |    |	   |		  |
      | 	       |    |	   |		  |
      | 	  INIT |    |	   |		  |    ...
      +-------------+--+    |	   +--------------+
		    |	    |
		    +-------+

3. PROG  signal connection

      +--------------+
      |      PROG    |
      +--------+-----+
	       |
	       +------------+-------------------------+
	       |	    |			      |
      +--------+-------+    |	   +--------------+   |
      | 	       |    |	   |		  |   |
      | 	       |    |	   |		  |   |
      | 	       |    |	   |		  |   |
      | 	       |    |	   |		  |   |
      | 	  PROG +----+	   |	     PROG +---+   ...
      +----------------+	   +--------------+


I have used  only four XC4005-6 PC84C chips. 
I have been troubled by this problem for long time.


Please, your advise about this porblem.
Specially,Have you exprienced that Daisy-chained multiple downloading
using Xilinx 4000 series is performed successfully? 
If so, please contact me and tell me your method.

Your advice will be greatly helpful to me.



Article: 2919
Subject: Re: Languages for reconfigurable computing.
From: Richard Lazarus <rblazarus@tasc.com>
Date: Thu, 29 Feb 1996 09:03:32 -0800
Links: << >>  << T >>  << A >>
A truly useful language for a reconfigurable computer should also be one 
that many potential users are already familiar with or provides little 
resistence to learn/apply. Thus, the ability to use C or C++ would 
provide an advantage over VHDL/Verilog. 

As part of our parallel programming research, we are developing a high 
level language (HLL) source code converter to an acyclic directed graph 
representation. Current HLLs include C, C++, and F77. The directed graph 
explicitly identifies inherent parallelism in the source code/algorithm 
and identifies all computational units required in a time-ordered 
fashion.  

To take advantage of FPGA implementation efficiencies such as fixed 
bit-size or bit-oriented operations, new types or classes could be 
defined in the C++ code and captured in the graph representation. 
Additionally, we can extend the C++ language for reconfigurable computer 
programming and add these language features to our C++ grammar.

Let me hear your opinion.
Rich

rblazarus@tasc.com


Article: 2920
Subject: JEDEC Specification?
From: peb@trsvr.tr.unisys.com (Pete Becker)
Date: Thu, 29 Feb 1996 17:20:40 GMT
Links: << >>  << T >>  << A >>
Where can I find the JEDEC Specification?

=================================================
Disclaimer: My comments are not necessarily the
opinion of my employer, myself, or anyone else.
-------------------------------------------------
  Peter Becker
  peb@trsvr.tr.unisys.com
=================================================


Article: 2921
Subject: Re: Languages for reconfigurable computing.
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Thu, 29 Feb 1996 18:26:39 GMT
Links: << >>  << T >>  << A >>
Richard Lazarus <rblazarus@tasc.com> wrote:

>A truly useful language for a reconfigurable computer should also be one 
>that many potential users are already familiar with or provides little 
>resistence to learn/apply. Thus, the ability to use C or C++ would 
>provide an advantage over VHDL/Verilog. 

>As part of our parallel programming research, we are developing a high 
>level language (HLL) source code converter to an acyclic directed graph 
>representation. Current HLLs include C, C++, and F77. The directed graph 
>explicitly identifies inherent parallelism in the source code/algorithm 
>and identifies all computational units required in a time-ordered 
>fashion.  

So, rather than use either of the two popular multi-threaded
programming languages (VHDL and Verilog) for implementing your
structure, you defined your own new extensions to a single-threaded
language, and then develop a totally new set of compilers, debuggers,
etc. etc.

It took me 2 hours to teach VHDL theory (not all syntax, but the
theory) to a group of industry programmers.  Once you say it's a
strongly-typed, multithreaded, concurrent programming language, they
go "Oh, why didn't anybody say so?" and then it's just some new syntax
that they have to learn.

I think that this approach will generate much better results much
faster than your approach.

I'm not trying to slam you; it's just that if you're capable of
tackling what you've proposed, you're smart enough that I want to see
your efforts focused in the most productive way.  I expect to be doing
reconfigurable computing in a couple of years, and I want to see it
have the best possible tools/languags it can.

Regards,
Erik Jessen



Article: 2922
Subject: Re: Comp.Arch.FPGA
From: sc@vcc.com (Steve Casselman)
Date: Thu, 29 Feb 1996 18:34:50 GMT
Links: << >>  << T >>  << A >>

Space left for reflector people:)































I've had talks about the newsgroup comp.arch.fpga (computer
architectures based on fpgas) about all this talk about 
PLDs, converting fpgas into asics, antifuse parts and such.
The above subjects do not belong in this news group! But
we realize there is no other place for these people to go.
So I think we should start a new news group called something
like lsi.fpga or whatever would someone who knows how please
try and give these people a home! I would vote for it! I'm sure
enough people would vote for it (for example all the people who 
voted this news group should vote for it:) I might even post
in the other news group.

Steve Casselman


Article: 2923
Subject: ORCA and 3.3V logic
From: husby@fnal.gov (Don Husby)
Date: 29 Feb 1996 18:57:17 GMT
Links: << >>  << T >>  << A >>

I have an existing ORCA 2C06 design that needs to be modified to work with a
3.3V memory chip.  Has anyone tried driving 3.3V logic (bi-directional 
data bus) with 5V ORCA chips?
Can it be done directly or do I need a resistor or translator?

I could use the 2T15 part, but that would be overkill, and I need a clock
to output delay of ~10ns.



Article: 2924
Subject: Re: Atmel Serial Configuration E2PROMs
From: fink@post.tau.ac.il (Udi Finkelstein)
Date: Fri, 01 Mar 1996 10:00:11 GMT
Links: << >>  << T >>  << A >>
On Tue, 27 Feb 1996 02:56:09 GMT, "** Atmel FPGA Apps. :-)"
<martin@atmel.com> wrote:

>Peter Fenn writes...
>>I have downloaded Atmels CONFIGURATOR application note describing the 
>>programming spec, which now prompts me to ask the question "Is there not 
>>a piece of programming software already already out there somewhere 
>>that'll save me some time?"

check the free implementation by Ingo Cyliax <cyliax@cs.indiana.edu>

which is located in
ftp://ftp.cs.indiana.edu/pub/goo/

It's done is QuickBasic, but it works. I'm working on a C
implementation, and it's almost 100% done, but I'm still debugging it
(lack of time prevents me from finishing it).

One word of warning - Ingo's design used only a cable and a socket. My
new software is compatible with Ingo's, but I prefer to use a 5V
external power supply and not to take VCC from a data pin, like he
does. I also came to the conclusion, that in order to get a RELIABLE
board, you better place a buffer near your chip. You need an open
collector buffer for the data line.


>Atmel makes a simple programming board (ATDH2200 - $250) that plugs into 
>the parallel port on any X86 PC and allows you to program the AT17Cxxx 
>family of parts.  It comes with the s/w you describe to read/write/verify 
>the Atmel re-programmable serial configuration proms.  The input data can 
>come from a 17Cxxx device (which can be read from the board) or one of 
>several industry standard file formats.

>I hope this helps - If you would like more information send me an e-mail 
>with your snail-mail address or visit the Atmel home page 
>http://www.atmel.com
>
>Regards
>
>Martin Mason
>
>-------------------------------------------------------------------------
>|       Martin Mason            | Snr FPGA/17Cxxx Applications Engineer |
>|       Atmel Corp.             | (Work)         martin@atmel.com       |
>|       2125 O'Nel Drive        | (Work2)          fpga@atmel.com       |
>|       San Jose                | (Fax)         + (408) 436 4300        |
>|       CA 95131                | (Tele)        + (408) 436 4178        |
>-------------------------------------------------------------------------
>| Visit http://www.atmel.com    | 'kewl' thinks Martin, The Net Dude :] | 
>-------------------------------------------------------------------------
>





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