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 12800

Article: 12800
Subject: Re: Xilinx mode pins.
From: olivier GALLAY <ogallay@cmp.memec.com>
Date: Fri, 30 Oct 1998 12:32:13 +0100
Links: << >>  << T >>  << A >>
Hooman Dadrassan wrote:
> 
> Hi,
> 
>     my problem is that I am running out of pins on my xilinx 4010 fpga
> and I want to
> use the mode pin M1 as  output and I beleive I should be able to do that
> based on
> xilinx databook indicating M1 as O (output) after configuration.
> I have tried pin LOC but I get error message while mapping in the M1.4
> tool.
> Does anybody know how I can do that.
> 
> Thanks,
> Hooman

Use MD1 component ( in the library ) instead of OPAD.
( Pins M0 and M2 , could also be uses as inputs : component MD0 and MD2
)

sorry for my english.
Article: 12801
Subject: Re: FPGA Decouple Capacitor values
From: ems@riverside-machines.com.NOSPAM
Date: Fri, 30 Oct 1998 11:54:20 GMT
Links: << >>  << T >>  << A >>
i don't think i'm making myself clear here. HJ's point is that you
should select the largest cap because, to paraphrase:

"...then  the  effective series inductance,  the  single specification
that defines the performance of these  parts  at high  frequencies, is
the same for both parts".

*but* this isn't relevant - we need performance at the frequencies of
interest, not "at high frequencies". the required specification is
actually the product of the nominal capacitor value, and the sum of
the inductances involved - dielectric, construction, packaging, trace
- ie. the specification that controls the SRF.

as a designer, your control over inductance is limited. an 0805 with a
good layout may give you 5nH; an 0508 with a excellent layout may give
you 2nH. but your choice of capacitor value ranges over a factor of
about 100 - you get much more control by selecting capacitance. 

obviously, you have to control inductance. but you must also select
capacitance to ensure that you have a low impedance at the required
frequency. there's no point using a 100n cap if it turns out that it
has a 10ohm impedance at your important frequency.

in short, it's *not* adequate to select the highest available
capacitance for a given package and layout, as HJ states - you have to
select the capacitor appropriately.

as for direct via connections, rather than explicit trace connections,
my point is that you don't know (or i don't, anyway) what actually
happens on the path from a capacitor terminal, through a via, to a
plane which is shared by lots of other logic, through another via, to
a power pin. it would probably take a supercomputer to model this lot.
it doesn't seem to me that you can simply model this as two capacitors
in parallel. so, why not take the easy route, and connect your chip
capacitor directly to the required pin? ok, it adds some inductance,
but you can arrange for this to have a minimal effect at the
frequencies of interest.

evan

Article: 12802
Subject: Re: 8051 VHDL Model
From: ems@riverside-machines.com.NOSPAM
Date: Fri, 30 Oct 1998 11:54:38 GMT
Links: << >>  << T >>  << A >>
On 29 Oct 1998 02:39:08 GMT, "Mankit Wong" <lsckwong@netvigator.com>
wrote:

>Hi there,
>
>Could anyone tell me where I can get 8051 VHDL Model for free in the
>Internet?
>
>Thanks,
>Kit

http://www.ee.umr.edu/~mrmayer/8051/

seems to be popular. you may also find some more on the VHDL faq:

http://vhdl.org/comp.lang.vhdl/

evan

Article: 12803
Subject: Re: FPGA Decouple Capacitor values
From: ems@riverside-machines.com.NOSPAM
Date: Fri, 30 Oct 1998 12:33:31 GMT
Links: << >>  << T >>  << A >>
On Fri, 30 Oct 1998 12:11:04 -0500, "Alan R. Sieving"
<asieving@mediaone.net> wrote:

>Table of Impedance (Ohms) at Freq (MHz)
>
>Part		10MHz	100	300	1000MHz
>
>A(102)		14	1.16	1.4	6
>B(103)	 	1.5	0.525	1.9	6
>C(104)	 	0.11	0.617	1.9	6
>D(104)	 	0.13	0.369	1.1	3.8
>E(684)	 	0.03	0.376	1.1	3.8

interesting results. i haven't tried spicap, but these are presumably
figures at the cap itself, and you don't get an option to add in
external inductances - is this right?

if this is the case, then it would be more informative to get
in-system figures. AVX's inductance figure for an 0805 is 1.4nH, and
i'm guessing that the 0612 is about 500pH. i'm also guessing that a
good layout, with direct plane connections, would give you an
additional 2nH, giving a total of 2.5nH for the 0612. the
high-frequency impedance goes as 2.pi.f.L, so it would increase by a
factor of maybe 5 for a given high frequency.

what's more interesting, though, is that the impedance curve would
rise more quickly from the SRF point, and so the high value caps would
look a lot less attractive. has anyone got the time/inclination to
plot this?

evan

Article: 12804
Subject: Re: FPGA Decouple Capacitor values
From: ems@riverside-machines.com.NOSPAM
Date: Fri, 30 Oct 1998 12:34:23 GMT
Links: << >>  << T >>  << A >>
On Fri, 30 Oct 1998 15:21:23 +0000, Jonathan Bromley
<jsebromley@brookes.ac.uk> wrote:

<snipped>

agreed, but if i can just clarify what i was originally suggesting -
point (8) of my first message included a via in the track from cap gnd
to device gnd; i suggested limited vias on pwr only, for noise
suppression reasons on high speed devices. you only had the summary in
the message you replied to.

i personally haven't clocked an FPGA above 67MHz, and my devices
currently have tracks and vias on both pwr and gnd.

second - my 'frequency of interest' is simply the clock speed. a lot
of internal charging and discharging is going on at the clock rate,
and i'm just generalising the bulk bypassing argument. agreed, the
current transients will have frequency components at much higher
rates, whatever their source, but you've got to start somewhere.

evan

Article: 12805
Subject: Re: Digital Sine Generator
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 30 Oct 1998 10:10:34 -0500
Links: << >>  << T >>  << A >>
As mentioned before, use CORDIC.  A cordic engine is about the same
complexity as a multiplier of the same width, and gives very good
accuracy.  An additional benefit is that it simultaneously generates both
sine and cosine.

Juergen Kahrs wrote:

> Yves Vandervennet wrote:
>
> >         does anybody know how to digitally realize a sine generator
> > other than sampling a sine period and storing it in a ROM ?
> > We have to integrate it in an FPGA. If anybody knows book references
> > on this subject, we would be happy for a very long time.
>
> Remember the sine is the solution of a simple differential
> equation. Turn the differential equation into a difference
> equation and you get
>
>   x2 = (2 - (2*pi*fsin/fsam) ** 2) x1 - x0
>
> A

--
-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: 12806
Subject: M0 M1 M2 * JTAG Programmer * Xchecker cable
From: Antonio Joaquim A Esteves <esteves@di.uminho.pt>
Date: Fri, 30 Oct 1998 15:15:17 +0000
Links: << >>  << T >>  << A >>
Hullo,

I have a question about the use of the M2,M1,M0 pins
of XC4013XL FPGAs. What are the correct assignement in the 
following situations:

- configuration with an SPROM (must be "000") ?

- configuration with F1.5 "JTAG Programmer" and serial Xchecker 
  cable (the manual of JTAG Programmer says "000") ???

- configuration with F1.5 "Hardware Debugger" and serial 
  Xchecker cable (must be "111") ?

Is it correct to connect /INIT pin of XC4kXL devices like it is 
described on the next scenarios ?

- when configuring on Asynchronous Peripheral Mode, /INIT is
  connected to Vcc with a 4.7K

- when configuring with "JTAG Programmer", /INIT is
  connected to GND with a 1K

- when configuring with an SPROM, /INIT is
  connected to Vcc with a 22K

The last question: Can we program a daisy chain with 4 XC9500 
CPLDs and 4 XC4013XL FPGAs with serial Xchecker cable ?

Thank you.

 -----------------------------------------------------
 Antonio J A Esteves 
 Dep Informatica, Universidade do Minho 
 Braga, Portugal
 E-mail: esteves@di.uminho.pt
 Web:    http://www.di.uminho.pt/~esteves/
 -----------------------------------------------------
Article: 12807
Subject: Re: FPGA Decouple Capacitor values
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Fri, 30 Oct 1998 15:21:23 +0000
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:
<amongst other things> 
> so, why not take the easy route, and connect your chip
> capacitor directly to the required pin? ok, it adds some inductance,
> but you can arrange for this to have a minimal effect at the
> frequencies of interest.

Sorry, I don't think this will do (as an argument - I concede it
often works OK in practice).  Lots of problems.

1)
What on earth (pun intended) do you mean by "frequency of 
interest"?   Decoupling on MOS LSI devices is primarily there
to supply the current transients that occur on switching edges.
These transients are _narrow_ (like you would not believe) and
their narrowness is _not_ a function of pulse repetition rate.
Ergo, spectrum of current through capacitor is exceedingly broad
(out to 1GHz in fairly ordinary modern logic families)
although of course it will have big peaks at multiples of your
pulse repetition rate.  At the highest of these frequencies
it is unquestionably the equivalent series inductance of the
various current paths which dominates.  At these high 
frerquencies, tiny capacitances will do the job of decoupling.

2) 
Traces from decoupling cap direct to device pin are often
a rather bad idea IMHO.  If the decoupling is there to support
switching transient currents that occur entirely _on-chip_ 
then you are in good shape - because you have soaked up all the
HF components of the device's supply current.  The (presumably 
rather inductive) path from the device/cap combination
to the nearest really solid ground point will be carrying
only slowly varying currents so its inductance doesn't hurt you.
BUT if, as is usually the case, some significant edge-related
transients flow into and out of the device's signal pins then
those same currents must flow from the supply into one or other
of the device's power pins.  If it's the ground pin, then no
amount of local decoupling will do.  The current transient,
flowing in the path from chip+cap to "real" ground, will move
the chip's ground away from "real" ground and this dropped 
voltage will appear in series with any inputs to the chip 
driven from devices whose output reference is the 
aforementioned "real" ground.  This is, more or less, the 
famous "ground bounce" problem.  You could hypothesise an 
ideal IC which had many nanofarads of supply bypass actually 
built on the chip (not very practical!) and it would still go
nowhere towards fixing this problem.

The sane solutions to this problem are:
a)
make all logic signals on the board DIFFERENTIAL so that small
movements of one device ground relative to another are 
insignificant - this is exactly how traditional ECL worked
b) 
minimise output slew rates so that off-chip capacitances
are charged as slowly as possible by changing signals -
this is the main motivation for going to low-swing logic systems,
because you can't increase the rise/fall time beyond, say, 20%
of a system clock period
c) 
aim for the lowest possible inductance between chip ground and
the system ground reference

Of these, only (c) is realistic for most people.  All the usual
rules of thumb - ground planes, thick ground traces, small SMT
chip packages - are important.  NOTE NOTE NOTE - bypass caps
don't come into it, not even a little bit!

Where the bypass caps do come into their own, of course, is in 
helping to keep the Vcc power line well behaved under these 
conditions. It seems to me that we have two problems to solve,
and that the solutions are almost conflicting.  We must supply
chip internal transient currents, which means caps as close to
the chip as possible - Evan's solution.  These currents can be 
huge on big VLSI devices with lots of internal nodes changing
state simultaneously and fast, which is why Intel recommend
24 separate 10nf caps for bypassing Pentium supplies - many 
parallel current paths so that their inductances hit you less.
Then we have to source the currents that are needed to charge
off-chip nodes as they change state.  The caps that source this
current _absolutely should not_ have their ground ends 
linked directly to chip ground pins, because that means the
currents flowing in them will also be flowing in the inductance
of the chip's ground track and will shift the chip's local
ground undesirably.  The cap _grounds_ should be returned
to the  ground plane by independent, short traces; the cap
_supply sides_ should be linked to their corresponding chip
power pin by the shortest possible traces.  Of course, using
the distributed C of closely adjacent power and ground planes
is a thoroughly good thing, as others have pointed out.

Moral:  There is no substitute for knowing WHERE YOUR 
TRANSIENT CURRENTS ARE FLOWING, and remembering that VOLTAGE 
SHIFTS ON INDIVIDUAL DEVICE GROUNDS IS A BAD THING.

Finally, of course, the total parallel capacitance between 
power and ground on the board should be big enough to soak up
any slower current pulses, so an earlier and rather apologetic
suggestion about 10uF near the power inlet connector is not
to be sneezed at.  But on a big and busy board you may well find
that the parallel sum of all the distributed bypass caps is
enough to spare you the trouble of an explicit bulk bypass cap.

I'm sure I've said stuff here that has been better stated
elsewhere, but I felt it was no bad thing to bring the 
discussion back to basics - in my experience this topic
generates an inordinate amount of eye-of-newt folklore-driven
comment, and a bit of simple circuit theory carefully applied
can go a long way to clearing the fog.

Jonathan Bromley
Article: 12808
Subject: Re: Schematic entry?
From: mench@mench.com
Date: 30 Oct 1998 15:49:52 GMT
Links: << >>  << T >>  << A >>
Ad Verschueren <ad@akebono.ics.ele.tue.nl> wrote:

> Hierarchy and stucture can (someone correct me if i'm wrong :-)
> *only* be represented with entities and components - whereas (the
> more complex) behaviour is captured in processes. Processes are
> 'flat' pieces of procedural code - although they can (and should) be
> structured, that is not the structure we are looking for...

Actually, you can also use block statements.

Paul

-- 
Paul Menchini          | mench@mench.com | "Se tu sarai solo,
Menchini & Associates  | www.mench.com   |  tu sarai tutto tuo."
P.O. Box 71767         | 919-479-1670[v] |   -- Leonardo Da Vinci
Durham, NC  27722-1767 | 919-479-1671[f] |
Article: 12809
Subject: Re: Altera MAXPLUS2 V9 slow .
From: "Eric Pearson" <ecp@focus-systems.nospam.on.ca>
Date: 30 Oct 1998 15:59:04 GMT
Links: << >>  << T >>  << A >>


Virtual <sxyzami@pacifier.com> wrote in article
<36380250.0@news.pacifier.com>...
> Eric Pearson <ecp@focus-systems.nospam.on.ca> wrote:
> > Has anyone noticed problems in re-compiling designs that worked in v8.0
of
> > maxplus2 under v9.01 and found comilation times went throught the roof
even
> > to the point excess ( I aborted after 100 hours v9 vs 1 hour under v8
).
> 
> You may want to perturb your design (timing constraint) a little bit.
> I have seen 100+ hours compile times with some 6.x version on a 
> design that normally compiled in 1 - 2 hours.   Changing the timing 
> by 0.1 Mhz fixed it. 
> 

At 92% utilization, adding any constraints other than pinouts makes the
design
unroutable (200+ hours) under v8. (200Mhz PPro, 256M). I realize that I'm
near the hairy edge of routability on the 10K130, but something is
'fundamentally wrong' with Maxplus2 v9.0 if it cannot route a design which
V8.0 can.

Please, Altera give me a switch to select the 'old' router versions!
One has to wonder what these maintenance fee's are going towards when they
are helping Altera create enhanced products which don't work on previous
designs.
Maybe I'm expected to archive the compiler along with the design files, as
well
as trying to recompile 100+ designs every 3 months as they do compiler
upgrades.
Dealing with bugs is challenging enough, just imagine calling tech support
for an
old version of software!

Eric Pearson
Article: 12810
Subject: Re: FPGA Decouple Capacitor values
From: bob@nospam.thanks (Bob Perlman)
Date: Fri, 30 Oct 1998 16:28:19 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 30 Oct 1998 11:54:20 GMT, ems@riverside-machines.com.NOSPAM
wrote:

>i don't think i'm making myself clear here. HJ's point is that you
>should select the largest cap because, to paraphrase:
>
>"...then  the  effective series inductance,  the  single specification
>that defines the performance of these  parts  at high  frequencies, is
>the same for both parts".
>
>*but* this isn't relevant - we need performance at the frequencies of
>interest, not "at high frequencies". the required specification is
>actually the product of the nominal capacitor value, and the sum of
>the inductances involved - dielectric, construction, packaging, trace
>- ie. the specification that controls the SRF.
>
>as a designer, your control over inductance is limited. an 0805 with a
>good layout may give you 5nH; an 0508 with a excellent layout may give
>you 2nH. but your choice of capacitor value ranges over a factor of
>about 100 - you get much more control by selecting capacitance. 
>

The point Howard Johnson is making---and correctly, I think--is that,
at very high frequencies beyond the point at which the impedance
bottoms out, the impedances of the .1uF and .001uF caps are the same,
because the impedances are dominated by the inductance at that point.

To picture an impedance curve, imagine a "V" shape that represents the
impedance vs. frequency for the 0.1uF capacitor.  Near the right-hand
(ascending) leg of the V, draw a diagonal that falls to the right and
intercepts the ascending leg, say, half-way up.  This second  V
describes the impedance of the .001uF capacitor.  (This isn't exactly
correct, but it's close.)  

What this graph shows us is that, at very high frequencies, the
impedance of the two devices is the same, and is determined by package
inductance.  (Some may object by pointing out that, at these
frequencies, the impedance is inductive.  Howard Johnson has a simple
answer for this: so what?  We care about the power-supply-to-ground
impedance; whether it's reactive in one direction or another isn't
going to matter nearly as much as the magnitude of that impedance.)
What's more, there's a range of frequencies for which the impedance of
the 0.1uF capacitor is lower than that of the 0.1uF cap.

I also agree with Howard Johnson's claim that it's better to sink
capacitor vias directly to the power and ground planes, rather than
try to connect the capacitors with traces to chip Vcc and ground pins.
I want a "sea" of capacitors with low-impedance connections to Vcc and
ground, not just one cap for a given Vcc/ground pin pair.

I guess I could appeal to authority here, and point out that Dr.
Johnson has been doing this stuff for years, and has written a
terrific book.  But the reason I believe in what he's recommending is
that I worked for years with a signal integrity engineer who
independently came up with the very same suggestions that Dr. Johnson
has made on bypassing.  We used those suggestions, built some very
large, high-speed boards, and found that they had Vcc and grounds that
were clean as a whistle; the boards worked great, too.

I think that most of the suggestions made in this thread will probably
work for moderate-to-high-speed logic, even if I don't consider the
suggestions ideal.  However, when speeds increase even further, watch
out!

Bob Perlman
Cambrian Design Works
Article: 12811
Subject: Re: FPGA Decouple Capacitor values
From: "Alan R. Sieving" <asieving@mediaone.net>
Date: Fri, 30 Oct 1998 12:11:04 -0500
Links: << >>  << T >>  << A >>
ems@riverside-.NOSPAM wrote:
> 
> i don't think i'm making myself clear here. HJ's point is that you
> should select the largest cap because, to paraphrase:
> 
> "...then  the  effective series inductance,  the  single specification
> that defines the performance of these  parts  at high  frequencies, is
> the same for both parts".
> 
> *but* this isn't relevant - we need performance at the frequencies of
> interest, not "at high frequencies". the required specification is
> actually the product of the nominal capacitor value, and the sum of
> the inductances involved - dielectric, construction, packaging, trace
> - ie. the specification that controls the SRF.

I've been wrestling with what kind of caps to use for an FPGA design
recently, and here are my thoughts.  (I went to H. Johnson's seminar,
and I highly recommend his seminar, book, and mailing list to anyone
interested in this topic.)

Basically, it seems there are four things we can control as designers:
	1) number of caps	more is usually better
	2) cap package		low inductance is better
	3) layout		" " "
	4) nominal cap value	more is often better.

Rather than using my own guesstimates, I went to AVX's web site,
and used their SPICAP software
(http://www.avxcorp.com/software/asp/spicap/spicap.htm)
to graph the impedance of several caps.  I encourage you to
try this yourself, but here is a summary of my results:

Parts I tried:
	A = .001 uF 0805 X7R  (08053C102...)
	B = .01 uF 0805 X7R   (08053C103...)
	C = .1  uF 0805 X7R   (08053C104...)
	D = .1  uF 0612 X7R   (06123C104...)
	E = .68 uF 0612 X7R   (0612YC684...)  
		(E is 16V part, others are 25V)

Place your bets on which part(s) are better...

Table of Impedance (Ohms) at Freq (MHz)

Part		10MHz	100	300	1000MHz

A(102)		14	1.16	1.4	6
B(103)	 	1.5	0.525	1.9	6
C(104)	 	0.11	0.617	1.9	6
D(104)	 	0.13	0.369	1.1	3.8
E(684)	 	0.03	0.376	1.1	3.8


It seems to me that I don't give up too much at the high end
by choosing a cap that has more capacitance, and that it helps
at the low end.  Also, it seems clear that the wider 0612 parts
are better.  To my understanding, HJ's claim holds true.

For those who are interested, here is the resonant frequency and
approximate impedance at that frequency
Part		SRF		Z@SRF
A(102)		159 MHz		0.65 Ohms
B(103)		 50		0.24
C(104)		 16		0.07
D(104)		 21		0.07
E(684)		  8		0.03

I'll admit that you may be able to find a cap that works better
at a given frequency by paying attention to SRF, but for general
decoupling, I'm going to stick to the AVX 0612 package with the
whopping 0.68uF capacitance.

Cheers-

-Alan Sieving
Article: 12812
Subject: Re: New free FPGA CPU
From: timolmst@cyberramp.net
Date: Fri, 30 Oct 1998 18:10:09 GMT
Links: << >>  << T >>  << A >>
HI,

This project intrigues me. You must be commended for actuaoy doing it.
I've been "thinking" about doing something similar for a coupole of
years, but haven't done anything. You have. Congrats!

I was thinking of doing something like this to get into VHDL. I wonder
how tough it would be to do it in VHDL. I expect that it would not be
as compact as your schematic based version, but may be easier to add
features to. Comments?

>- Do the first address calculation for the operate instructions, jump
>  indirect, push and pop during decode (would reduce these by one cycle). 
>  The cost is decode being done in series with ALU operation, so the
>  frequency would be lower.  Also, the immediate instructions would be one
>  cycle longer unless I add a seperate incrementor for the PC (right now the
>  ALU does it).

Did you impliment the PC as a latch, or a counter? If you haev enough
flip-flops you could pipeline the PC. Impliment the PC as a counter
that feeds a latch. Clock them both at the same time. You xfer the
"new" PC to the latch, and increment it at the same time.



Tim Olmstead
email : timolmst@cyberramp.net
Visit the unofficial CP/M web site.
MAIN SITE AT            : http://cws86.kyamk.fi/mirrors/cpm
PRIMARY US MIRROR AT    : http://www.mathcs.emory.edu/~cfs/cpm
SECONDARY US MIRROR AT  : http://CPM.INTERFUN.NET
Article: 12813
Subject: Re: New free FPGA CPU
From: jmccarty@sun1307.spd.dsccc.com (Mike McCarty)
Date: 30 Oct 1998 19:39:02 GMT
Links: << >>  << T >>  << A >>
In article <3639ffe4.2028025@newshost.cyberramp.net>,
 <timolmst@cyberramp.net> wrote:
)HI,
)
)This project intrigues me. You must be commended for actuaoy doing it.
)I've been "thinking" about doing something similar for a coupole of
)years, but haven't done anything. You have. Congrats!

[snip]

Um, I found it interesting, but wonder how practical it is. The chips cost
$15 each, and I can get an 8031 which has twice the address space for
$3.95 in single quantity. And they don't require special programmers.

Mike
-- 
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.
Article: 12814
Subject: Re: Xilinx mode pins.
From: Steve Casselman <sc@vcc.com>
Date: Fri, 30 Oct 1998 11:53:39 -0800
Links: << >>  << T >>  << A >>
Be careful about using M0, M1, or M2 if
you plan to use the spartan. M1.5 will
not let you use the mode pins for anything.

If you have not used init you might think
about that.

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12815
Subject: Re: New free FPGA CPU
From: timothy.mccaffrey@spam2filter.unisys.com.takethisoff (Tim McCaffrey)
Date: 30 Oct 1998 19:54:58 GMT
Links: << >>  << T >>  << A >>
Does the stack pointer grow down or up?

I would like to see a subtract from stack pointer, 
for temporaries allocation (this assumes that stack
grows down).

A subtract reverse can be useful on a register
limited architecture like this.

I can't see anyway to get the stack pointer easily
into the accumlator(?).  This could help, especially
when testing for stack overflows and such.

I would like to see more specific semantics of the
instructions, like which ones set which flags, for instance.

Would it be possible to use the INC/DEC as semaphore lock?

It may be useful to have another flag bit which can be
seen by the outside world, which could be used as a "supervisor"
mode flag with an appropriate external MMU (or internal on a bigger
FPGA).  However, I haven't thought this through.

In any case, congratulations!

					Tim McCaffrey



Article: 12816
Subject: Re: 3.3V PCI without clamp diodes.
From: Steve Casselman <sc@vcc.com>
Date: Fri, 30 Oct 1998 12:00:38 -0800
Links: << >>  << T >>  << A >>
jai wrote:

> Hi.
> Has anyone used a FPGA to interface to a 3.3V PCI bus without
> connecting  any clamping diodes to the 3.3V rail. I know this is against
> the PCI spec but since some FPGA's ie.Altera's 6000 devices and Xilinx
> devices (without compromising 5v I/O tolerance) do not facilitate this.
>
> Tx,
> Jai.

The Xilinx 4000X{L,LT,V} have seperate voltages for the I/O
so if you use 3.3v on the I/Os you should have no problem.
The Virtex has control over different banks so half the I/Os
could be 3.3v and others 5V (or many others).

I have not used this on a 3.3v system but the HOT2 board
can be configured to do this.

http://www.vcc.com/Hotii.html

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12817
Subject: Re: New free FPGA CPU
From: David Kessner <davidk@peakaudio.com>
Date: Fri, 30 Oct 1998 13:58:30 -0700
Links: << >>  << T >>  << A >>
Mike McCarty wrote:

> Um, I found it interesting, but wonder how practical it is. The chips cost
> $15 each, and I can get an 8031 which has twice the address space for
> $3.95 in single quantity. And they don't require special programmers.

It is very practical-- given some conditions.  When you start
looking at not just the CPU, but the entire system, then there
are lots of places that a small CPU like this would work wonders.
Here's an example:

Let's say that you are designing an intelligent ethernet bridge.
You have two ethernet jacks and you want to filter and bridge
ethernet packets between them.  If you used this with
"standard" shelf chips you would need a reasonably fast CPU,
two ethernet controllers, some RAM, and some ROM.

The CPU might cost $20 because you need a fast one to
keep up with dual 100 mbps ethernet and move all that
data around.  You'll need a fair amount of 32-bit wide
RAM, and some Flash to store the program.  Including
the ethernet controllers, you're looking at $70 to $90,
depending on the exact configuration.

But if you designed an FPGA to do the same thing, the FPGA
could replace the CPU, both ethernet controllers, and the
Flash.  You would still need RAM, but not as much/wide.
You could easily fit this into a 40 Kgate chip that
costs on the order of $40 (Xilinx Spartan XCS40, for
example).  The total cost would be much smaller ($40
vs. $70) and the size would be less too.

For this to work, you would use a small custom CPU
to do the packet filtering and the actual data movement
would be done with dedicated logic (not by the CPU).
This would be much more efficent since the CPU could
have special "filtering and data moving" opcodes that
would speed up the process.  This, combined with
the data moving logic, would be the reason why an 8
bit CPU could replace a 32 bit CPU in the traditional
approach.

This is just one example of how a custom CPU would
outperform a typical uC in price/performance.

(I'll agree that the proper solution to the ethernet bridge
is to use one of the many bridge chips on the market,
but this is only an example and you can brew up your
own application that is similar...)

Hope this helps!

David Kessner
davidk@peakaudio.com


Article: 12818
Subject: Re: $B$40FFb(J
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Fri, 30 Oct 1998 14:13:43 -0700
Links: << >>  << T >>  << A >>
$B%F%l%SElD.3t<02q wrote in message <01be042b$13f3c440$LocalHost@thc>...
>$B!A$40FFb!A(J
>$B!!$I!<$b!"=i$a$^$7$F!"%F%l%SElD.3t<02q<R$N>kK\$H$$$$$^$9!#(J
>$B$5$F!"$3$N$?$S!"J@<R!"%F%l%SElD.$,H/9T$7$F$*$j$^$9>pJs;o(J
>$B!V7n4)!&%F%l%SElD.$@$h$j!W$H$$$$$^$9!"%a!<%k>pJs;o$N$40FFb$r(J
>$B$5$;$F$$$?$@$$$F$*$j$^$9!#(J
>$B!!>pJs;o$NFbMF$O!"2<5-$NDL$j$G$9!#(J
>
>$B5-(J
>$B!!!Z>pJs;o$NFbMF![(J
>$BFI<T$+$i$N>pJs(J
>$B%F%l%SEl5~7ONs$GJ|AwCf$N%"%K%aHVAH>pJs(J
>$B%F%l%SEl5~7ONs$GJ|AwCf$N!"$=$NB>$NHVAH>pJs(J
>$BFI<T$+$i$N46A[$d!"$40U8+(J
>$BF`NI8)$N>pJs(J
>$B$=$NB>$$$m$$$m(J
>
>$B!!!!$3$N!">pJs;o!V7n4)!&%F%l%SElD.$@$h$j!W9XFI$r$44uK>$5$l$^$9J}$O!"(J
>$B!&;aL>(J
>$B!&6a$/$K$"$k%F%l%SEl5~7ONs!J2<5-;2>H!K!"(J
>$B!!!!!!%F%l%SEl5~!"%F%l%SKL3$F;!"%F%l%S0&CN!"%F%l%SBg:e!"(J
>$B!!!!!!%F%l%S$;$H$&$A!"#T#V#Q(J
>$B!&$"$J$?$N$$$A$P$s9%$-$J%F%l%S6I$H$=$N%A%c%s%M%k(J
>$B!&$"$J$?$N%a!<%k%"%I%l%9(J
>$B!!!!!!!!!!!!!!!!!!$rL@5-$N>e2<5-$N%a!<%k%"%I%l%9$^$G$h$m$7$/$*4j$$$7$^$9
!#(J
>$B!!!!!!!!!!!!!!!!!!!!(JTv-higashimachi@ma3.justnet.ne.jp
>


What he said!

--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520-318-8191
apeters@noao.edu



Article: 12819
Subject: Re: New free FPGA CPU
From: jmccarty@sun1307.spd.dsccc.com (Mike McCarty)
Date: 30 Oct 1998 21:43:26 GMT
Links: << >>  << T >>  << A >>
In article <363A2875.F80C4B0B@peakaudio.com>,
David Kessner  <davidk@peakaudio.com> wrote:
)Mike McCarty wrote:

[snip]

)This is just one example of how a custom CPU would
)outperform a typical uC in price/performance.
)
)(I'll agree that the proper solution to the ethernet bridge
)is to use one of the many bridge chips on the market,
)but this is only an example and you can brew up your
)own application that is similar...)
)
)Hope this helps!

No, it didn't. If you look, you'll see that I work for a major
manufacturer of telephony equipment. So I fully understand the use of
specialty little CPUs made from programmable logic, having used them a
few times myself.

I wanted to know about *this* device. It doesn't seem to excel at
anything, so I don't see the particular advantage to it, and it isn't
cheap (for the hobbiest types).

Mike
-- 
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.
Article: 12820
Subject: Re: 3.3V PCI without clamp diodes.
From: Steve Casselman <sc@vcc.com>
Date: Fri, 30 Oct 1998 14:04:38 -0800
Links: << >>  << T >>  << A >>
Steve Casselman wrote:

> jai wrote:
>
> > Hi.
> > Has anyone used a FPGA to interface to a 3.3V PCI bus without
> > connecting  any clamping diodes to the 3.3V rail. I know this is against
> > the PCI spec but since some FPGA's ie.Altera's 6000 devices and Xilinx
> > devices (without compromising 5v I/O tolerance) do not facilitate this.
> >
> > Tx,
> > Jai.
>
> The Xilinx 4000X{L,LT,V} have seperate voltages for the I/O
> so if you use 3.3v on the I/Os you should have no problem.
> The Virtex has control over different banks so half the I/Os
> could be 3.3v and others 5V (or many others).
>
> I have not used this on a 3.3v system but the HOT2 board
> can be configured to do this.
>
> http://www.vcc.com/Hotii.html
>

I have to correct myself that the Virtex has
5V tolerant I/Os.

http://www.xilinx.com/partinfo/databook.htm#virtex




--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12821
Subject: Design Your Own Processor(tm)
From: msimon@tefbbs.com
Date: Fri, 30 Oct 1998 22:16:09 GMT
Links: << >>  << T >>  << A >>
We have added a few experiments and a lot of doc to the  www site.

See the sig at the bottom.

=================================================================
Design Your Own Processor(tm) Tools are aimed at people who want to
develop and debug custom processors and associated application
software. Advanced logic development is also possible with these
tools.

Design Your Own Processor(tm) is an ICE box for custom FPGA
processors. You can develop the software and simulate your processor
with our tools. No need for your own running hardware.

Design Your Own Processor(tm) Tools consists of two assembled and
tested boards.

A Z-80 control processor running a modified fig-Forth at 8MHz clock
speed. 

And an FPGA board that has an 84 pin PLCC socket suitable for  a
Xilinx XC4000XL series FPGA. Other Mfg.s FPGA boards will be available
in the future.

All PALs, EPROMs, and Clocks in a can are socketed with high quality
machine tool gold or gold inlayed sockets.

Detailed specifications:

Z-80 control board:

Z-80 processor
32K x 8 EPROM socketed.
32K x 8 RAM 20nS or better
Z8530 dual serial ports with dual crystals
  one port is a DB-9 RS-232 port and the other 
  port is RS-485. The crystals are 3.686 MHz
  and 4.9152 MHz  
There are 3 8255 parallel ports. 72 lines
8254 Counter/Timer Chip
A high speed bi-directional parallel data port 
  DB-25 printer port compatible
  (If the processor could keep up this
   could concieveably run at 10 MHz)
Two I2C serial ports interfaced through
   two six pin power connectors. 
A serial 2K x 8 EEPROM ( connects to
   one of the I2C ports )
A power on reset chip that can be used as a 
   watchdog timer. A reset button.

FPGA board

Xilinx XC4005XL or XC4010XL socketed FPGA.
  suitable for any 4000 series 84 pin PLCC
32K x 16 SRAM 20nS or better connected directly
   to the FPGA, loadable by the Z-80 control
   processor 32K x 8 of the RAM can be used
   to load the FPGA vectors.
32K x 4 SRAM 20ns or better for breakpoint
   control. (allows 4 different breakpoint 
   maps.)

A 16 x 16 output from the FPGA connector can 
  be used as port or additional RAM interface.

The control processor can read AND write to all 
  address and data lines. Allowing quick debugging 
  of logic as well as processor projects.

The FORTH scripting language has been extended 
to do the following:
  MCS hex loader to load FPGA setup into RAM
  Commands to load the FPGA from the RAM
  Commands to start the FPGA clocking
  Single step the FPGA
  Turn on the high speed FPGA clock
  Set a breakpoint
  Clear a breakpoint

The software requires no knowledge of FORTH
  although advanced users will certainly
  want to make use of its features.  

Documentation of ALL the hardware and software plus experiments are
provided or available on  various WWW sites. In addition a Z-80
assembler  and a CP/M simulator that it runs under are available for
those that want to change the control processor operation.
 Free of course.

Simon

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12822
Subject: Re: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5
From: Steve Casselman <sc@vcc.com>
Date: Fri, 30 Oct 1998 14:28:51 -0800
Links: << >>  << T >>  << A >>
I've noticed that  M1.5 is way faster in compilation than
M1.4. This is really important for me since after I place
and route I usually just throw the design into the
part and test it our little program called test commander.


As far as clock speeds I find that you can really improve
your performance by editing the design in the epic editor.
Just get the design editor up (and turn off rotues in the
layer visibility then click apply) and get the post cmd
window working -- under view->post cmd... Now open
the asynchronous delay report and copy the exact name
of the signal with the max delay. Then go to the command
window and type "select " then paste the the exact net name
and hit return. Then "delete" then !s (which selects the signal
again) then autoroute. You can select the signal (!s) and type
"delay" and you should see a smaller delay. What happends is
(at least I think) that the epic uses lots of routing resources
with no regard for utilization.


--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12823
Subject: Re: New free FPGA CPU
From: David Kessner <davidk@peakaudio.com>
Date: Fri, 30 Oct 1998 16:00:48 -0700
Links: << >>  << T >>  << A >>
Mike McCarty wrote:

> > Hope this helps!
>
> No, it didn't. If you look, you'll see that I work for a major
> manufacturer of telephony equipment. So I fully understand the use of
> specialty little CPUs made from programmable logic, having used them a
> few times myself.
>
> I wanted to know about *this* device. It doesn't seem to excel at
> anything, so I don't see the particular advantage to it, and it isn't
> cheap (for the hobbiest types).

Well then... You're right.  *This* device, as is, is not particularly
cost effective for any application other than a learning experience.
Slightly, modified as I already pointed out, it becomes very useful.
But as is, well...

I, for one, appriciate this guys efforts and that he was willing to
share it with the net.  When I designed my own VHDL CPU
some time ago, I was looking for just this same thing and couldn't
find it.  If only this sort of thing was available then!

So, this guys CPU is just about as useless as that "Forever LED
Flasher" that has been mentioned recently.  But, each of them are
building blocks for larger things that can be extremely useful.

David Kessner
davidk@peakaudio.com


Article: 12824
Subject: Re: New free FPGA CPU
From: msimon@tefbbs.com
Date: Fri, 30 Oct 1998 23:48:39 GMT
Links: << >>  << T >>  << A >>
It is possible to impliment a nice RISC type 16 bit stack machine in a
$27 XC4005XL.

Don't forget FPGAs are still coming down the learning curve and the
8051 is not.

In any case its educational. 

The performance should be about 10X to 20X the 8051. Possibly more.

I'm working on it now and will publish the results here.

Simon
================================================================
jmccarty@sun1307.spd.dsccc.com (Mike McCarty) wrote:

>In article <3639ffe4.2028025@newshost.cyberramp.net>,
> <timolmst@cyberramp.net> wrote:
>)HI,
>)
>)This project intrigues me. You must be commended for actuaoy doing it.
>)I've been "thinking" about doing something similar for a coupole of
>)years, but haven't done anything. You have. Congrats!
>
>[snip]
>
>Um, I found it interesting, but wonder how practical it is. The chips cost
>$15 each, and I can get an 8031 which has twice the address space for
>$3.95 in single quantity. And they don't require special programmers.
>
>Mike
>-- 
>----
>char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
>This message made from 100% recycled bits.
>I don't speak for Alcatel      <- They make me say that.

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm


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