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 19375

Article: 19375
Subject: Re: Speed grade
From: Davide Falchieri <davide.falchieri@bo.infn.it>
Date: Fri, 17 Dec 1999 09:38:35 +0100
Links: << >>  << T >>  << A >>
Hi,
  this is a very interesting matter. Still I haven't understood the way
you reach different speed grades in the same FPGA family. For example I
am involved in a project using the FPGA XC4025E-4. What is the physical
difference with XC4025E-3 and -2 ? Are they implemented using a
different technology ?

Thanks.

Regards,
    Davide




_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
                                                      
                      Davide Falchieri                
           Physics Department, Bologna University     
        40127,Viale Berti Pichat 6/2, Bologna(ITALY)      
          TEL:+39-051-2095077, FAX:+39-051-2095297          
           URL:http://sunvlsi4.bo.infn.it/~davide     
            mailto:davide.falchieri@bo.infn.it     
                                                      
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Article: 19376
Subject: Re: Speed grade
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Fri, 17 Dec 1999 10:32:03 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>  [ explanation on former physicalrelationship to speed grade ]
> You have to look up the
> individual parameters. Maybe the logic gets much faster, but the interconnect
> less so. Or it's ( more rarely) the other way around. But you can be assured
> that no parameter in a better speed grade is ever slower than it was in the
> slower speed grade. So we guarantee monotonicity, but that's all.
> Don't equate a -2 in one family with a -2 in another family, although in the
> XC4000 series, this is pretty close.
> I think this reasoning holds for our competitors as well. We are all in the
> same boat.

Note that within the same family some timing parameters depend on the 
chip size, namely those associated with routing along a chip dimension
(or half ..)
Especially in the XILINX 4k family the usage of the long lines 
(e.g. for tristate busses) gets slower in larger devices. 
(This is obvious).
In ALTERA FLEX 10K devices nearly all routing uses wires of chip
dimension, 
thus if you integrate two smaller designs into a larger device 
you have to go to a better, say more expensive speed grade. 
Otherwise your design will be propably much slower. 
In XILINX 4k devices most routing resources have a fixed size and do not 
depend in speed from the chip size.

If you want to know pin2pin delays you must specify the distance of the
pins.

Andreas
(having applied FLEX 10k and XC4kXV)

-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
                             quiz, papers, VHDL, music
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 19377
Subject: Http://members.home.nl/stoelie
From: http://members.home.nl/stoelie <stoelie@home.nl>
Date: Fri, 17 Dec 1999 12:06:35 GMT
Links: << >>  << T >>  << A >>
http://members.home.nl/stoelie

http://members.home.nl/stoelie

a good page for all !

Article: 19378
Subject: Re: Xilinx FPGA Editor...does it really work?
From: Ray Andraka <randraka@ids.net>
Date: Fri, 17 Dec 1999 09:14:36 -0500
Links: << >>  << T >>  << A >>


a@z.com wrote:

> Hi Austin,
>
> First use File/Main Properties to turn the Edit Mode to Read Write (it is Read
> Only by default).
>
> Then zoom in to your CLB (Ctrl-Right Click - and by the way zoom out is
> Shift-Ctrl-Right Click!) and select your CLB pin. Then find your net in the
> All Nets List (you can sort them by name) and Shith-Click to select it (if you
> just Click the pin will be deselected). Press the add button and wait. Then
> wait some more and when you least expect it your pin will be connected to that
> net. Of course, you must first configure the CLB pin and then add it to the
> net, otherwise it will just give you an error. You can also add multiple pins
> to a net this way (using Shift-Click).
>
> Now for the CLB equation problem. Select the CLB, press the editblock button
> and in the Block Editor window the F= toolbar button. Edit Feqn and Geqn and
> press the Save Changes and Closes Window toolbar button. It works for me.
>

For the equations you need to call the pins A1 - A4, not F1 to F4.  Also, you need
to check the check box on the LUT to set it as a LUT before it will accept the
equations.

> By the way, what I have described is valid for the M2.1i FPGA Editor, the
> M1.5i EPIC Design Editor, of NeoCAD origin, although similar is a different
> beast (which never realy worked). The M2.1i version is a complete rewrite and
> crashes less. I agree that the user interface is a bit strange.
>

Less is a relative term.  It still crashes way more than any of the XACT tools
ever did.

> Catalin Baetoniu
>
> Austin Franklin wrote:
>
> > I have a Virtex design, I just wanted to add a damn pin to, and for the
> > life of me, even following the documentation..I just can't get it to work.
> > I want to add the SR pin of a CLB to an existing net...and it asks me for
> > the name of the net...and I type it, and it says it already exists...which
> > is true...but duh, it's what I want.
> >
> > Also, I tried editing the equations in the CLB, and I can put in 0 or 1,
> > but not F4 ANYTHING but 0 or 1.
> >
> > Is this tool just sadly broken, or just too obtuse for a somewhat
> > intelligent 12 year Xilinx veteran to use?  I never had this kind of
> > difficulty with the non-NeoCAD based editor...

The answer is yes.  The editor is a little obtuse, especially for those of us who
have used XDE in past lives.  Then again, XDE was no model of user friendliness
either.  I think we've probably forgotten the learning curve that went with XDE.
On the other hand, XDE didn't crash the way the 2.1 editor still does.

Frankly, I've been getting quite frustrated with the M2.1 tools for 'expert mode'
design, especially for Virtex.  I hate spending my time chasing tool problems.


--
-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: 19379
Subject: Re: CIC Filters in FPGA
From: Ray Andraka <randraka@ids.net>
Date: Fri, 17 Dec 1999 09:22:37 -0500
Links: << >>  << T >>  << A >>
CIC is just a rearrangement of the equation for a boxcar filter to get a
recursive implementation.  A boxcar is an FIR filter with all the coefficients
set to unity (sometimes called a moving average filter).  Hogenauer's paper
introduces the filters and goes into considerable discussion on errors caused by
truncation.  I found it a somewhat less than easy read.  Marvin Frerking's DSP
in Communications text (kluwer) has a much more readable discussion on CIC
filters.

These work pretty well in FPGAs if the sinc spectral response suits your
application.  They are really handy for high order interpolation and
decimation.  If you cascade several, you do need to watch the wordsize.  You
have to be extremely careful about truncating or your integrator will overflow.

Dave Decker wrote:

> Eugene B. Hogenauer's paper, 'An Economical Class of Digital Filters
> for Decimation and Interpolation' was published in:
> IEEE Transactions on Acoustics, Speech, and Signal Processing, Vol.
> ASSP-29, NO. 2, April 1981.
>
> The Cascaded Integrator-Comb (CIC) filters work well in FPGAs whenever
> you have to interpolate or decimate 2's compliment signals while
> lowpass filtering them at the same time. The filters give the response
> of FIR filters with all the coefficients set to 1. These are also
> called 'box car' filters because their impulse response looks like a
> rectangular box car. This type of filter requires no real
> multiplication, which makes them relatively small and well suited for
> FPGAs.
>
> The CIC implementation avoids the use of long shift register delay
> lines you might think would be necessary for such a filter. This
> efficiency is compounded because of the decimation/interpolation
> especially when the CIC stages are cascaded.
>
> The architecture consists of accumulators, subtractors, and a small
> number of pipeline delays. A 'must have' addition to your DSP bag of
> tricks.
>
> Dave Decker
> Diablo Research Co. LLC
>
> On Thu, 25 Nov 1999 10:57:12 GMT, "Mariotto" <mariotto@libero.it>
> wrote:
>
> >Where I could find information on realizations of CIC filters supposed from
> >E.B. Hogenauer in FPGA?
> >Thank you.
> >
> >Claudio Casagrande
> >
> >e-mail:mariotto@libero.it
> >
> >



--
-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: 19380
Subject: JEDEC
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Fri, 17 Dec 1999 06:38:16 -0800
Links: << >>  << T >>  << A >>
Hi friends,
where can i find JEDEC standarts?
with best regards,


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Article: 19381
Subject: Re: VirtexE availability?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 17 Dec 1999 15:41:27 +0000
Links: << >>  << T >>  << A >>


jeffrey j cook wrote:

> Well I'm looking for the XCV50E,150E or 300E.  This is simply for a small
> project and I only require about 24-48 of them.
>
>
> Jeffrey J. Cook
> University of Illinois Computer Engineering Student
> jjcook@uiuc.edu
>

According to my Avnet rep the only parts available now are the XCV300E &
XCV1500E.


Article: 19382
Subject: Re: How to include SpartanXL code in C souce code?
From: "John Janusson" <jjanusson@nospami-o.com>
Date: Fri, 17 Dec 1999 15:49:30 GMT
Links: << >>  << T >>  << A >>
Søren Lambæk wrote in message ...
>Hi
>
<snip>
>My question is can someone point me in the right direction on how to
include
>the FPGA code in the C source kode of
>the microcontroller SW.
>
>Regards
>Søren Lambæk


I did this by:

1) Making a motorola s-record file for you Xilinx data using the prom
formatter program
2) Running that s-rec file thru a utility that converts it to a 'C' data
structure...  I found a program that does this on http://www.wotsit.org/ in
a file called srec (see attached, also).  It's source code, so you'll need a
'C' compiler for your PC...
3) Include that file in your microcontroller software and write a routine to
bit-bash the Spartan's configuration port...  I found it helpful to be able
to compare my design with the signals from the Xilinx parallel cable...

Good Luck,
John








begin 666 srec.zip
M4$L#!!0``@`(`+%63R1 >O RB!4``*%(```(````<W)E8RYT>'3%6WMSVLB6
M_W^JYCOT>"H).$"0`!O;=^:N[9B-:Q)/-B0[LSM)3<FB`56$Q.KAQTWRW?=W
M3G?KA41()G4'0C!2]^GS?G5KVGTEW3":Q=]_1V^!5W>JKXE)&*V<I&MNT.M\
MZ:Q]+_B/]](+XB3JI:F[%JU7X4)&YEY;1'(=QHF<"2<03I1XKB_%;>0EB0P8
MTO6]6+DS=[GX814FJ[7_0Q0&!"00OWDSZ?MMD2R=1,B[M>]X`> LPUOQ(DS"
M*/0=AF!0C %?BCGCB05[0KQ>>K%PPY6,Q3P*5\(1:>#=B15063L+B1%784[.
M2@:)AW7#N;A=>NY2W,@HUA?>T#P`B]?2]>9>#CV6+DUB*!B7+*68G/X7#77$
MM9<(/PP6&'L*XH,PN%^%*7!)UD#577HWD@:Z:11A:?]>\0/,7(@X3!?+!!-_
M6TH@$/# >9@&LPZOH9<5MY[O8XH`<USPQE.(T B]0"^7);VFKR[.6\.VJ+S>
M7%W^+D:]OFCU!T]LZ\EX<XB>608'LJ;=2"G(W(-DW3"(O3B)B1<.L/R_5 :N
MI%_,.<?W[W,),9S3Z?GEI7"73N2X"10'B@0&Q+TR<$.G+^.8% (\B02@.[Y(
ME @/QU"E!)+V`HP*%LFR5\3T-5@"0%@`N!BP,> F2TQP%/8>XQV$(O86`<3L
M.H2\$\QPC4&M68-3WXDTL)5S3V@Y<9RNH!35%1<RD!%P5"0S4XH<"WT_O#TN
M3GK<W7@]>=+=\2*]'N>P/HKD?BWQY4)O$GP[LUE$_,.?A=?,29S"3PQ?2O<]
MZ!$?ORU>.32A,%,JQ++OVEV(0/K*KF0L<XV(Q4S&;N2!S=#K(I *.'!7,[8U
M[7?$U,+'QF> SPB?0WS&'0BN'L;TJ-TKWE%<VQ'%6S+3M>-%[.AF]2MX`<:N
M(\G>D!S$4MXY,YC%"BIRX_BI[(B9%\.6[YM)56@QK2LX1'(6N?$0!FP!Y $4
M,WIEQF<Z8*@:=@Z()V*\A;I%%*9KV4 5F<<74-8@0/)8&C48BO*_=)&UDQ$C
MZTQ"6%L]!#_$@HQ)"$^^"J-[18EV!L8Y,ZAZ"#.YE@%\0JC8%Z2K:^4NE%\)
MI OLG.B>L%B&35 *E) /$W:7IF?$I3% #0O,[31P50QJ)AX4)S+G'3'D<0U0
MBI/'A<DE3<\]@-()T>UW#X:[:?O..K&A$3&E!L .H:^9DTJ2+%SGVM?J`&U5
M+F&=(,(UV9KRN0B2%0O(W-N_T:X_;]:^=.*D$'<2UCJCM4@`.)%9^Y*R%%QN
M9AF1IJ<QB"JS@>3U%D24"P& `A=6SGOR,^F:H;('ZC1#T$JG]+-LPW%%%A<.
MS%P[;3)O&:V\P"$4*3"#DT@A8;.2\ZU+BI[W%6?FD83!9M();SZ7E$D9B 9<
M&+7BMM*:B@,JT$BY8X"%L/8LI11$))$3Q"LOYAP0-D^D)$ZTD"5]C>^1W:X$
M4CTB@-UNO*8LZ-KSO>3>B$(#2Q*"O(["1>2L2@$QI*LW2'EI^*K"IVE?Z#2<
M75HEW&'A1]/^(R1O=Z/!H-_6CD_+H9RQE5Z97TT#> C6\"S30D+D&SG\2T9A
MW `#B_;Q,HLNI4-Y4<'\3(YE-.%SN,P\XH+VY.RR.4WBK#B]KE6CIM<J<%8Z
MS: \FXV]WU7>*6Y6X&9XX2R%$R*HO5VFHH#(?$2<.9NO7M[4(RHR[<B#2-Y\
M2QP`SBLC\?DYF;/&-(-#OSLXR-!POA")1-XEY [)%S:S@9V+-K],<X2J"%&3
M0L5P4Y4?'.$;P-PN,98R_!#U"[FF8@@NQ(>&0)X[7B[CV"77Q$)M(*X3-TE$
M4V*4@%A7$4;,B=QGHBH#J4% @Z^48TU,(19&6)O<)(7IW# 8L8+$JY[,VN;)
M,B?P:&H9?V9IU]* B4EQLJD;T;B<@35I[.N-9+.H)I4\I $&S2_!G]H[4FL;
M:NV_2NW@WTUMB=[!CO0.#+V#OTKO\&^4[FA':D>&VM$WTF6VV28@L#\W#!(4
MAW&>KW';0U?$- *2BDRSKQ;,FIQ+F,;^?9Z[Z+87DBQ"+@@++*TJPN&.K#DT
MK#G\$M:4Z(L3ZLK $\D[Z:99-ZX9AHXZ%>;NKDGUY!>('^](_-@0/_[;B1_\
M->)+Y!_M2/Z1(?_H;R??_B;D7_Q^^N+E\XL*.Y;A;8",&CFL:@N#(:CP_&(?
MD+N#U(*LSV:F_?X!)=G#\7 XLJVSNB&6-: A]G@TL8?XV)9MVP>G-,L>VD?X
M'MN#PW/[M'&RQ?-I( \^H$G6>#086_9@:-'?UJ!QLMT?6A>\RO!B:&,"`<2*
M0P9H#T^/1G;MY/YAOT^86\/AQ=/A4>V@$8\83L9U-X_X9G]R7F;=:V[V5%K2
ME(&AEE)\[U!#/:*,1'O"CKH_*H+1(N)62T"J7=M5H\4RN":Z(#]2VJ4*F/AX
M0[:8PE]&$=A4J'?I!3.H""NV*BP=75C5*V:&4^EJ_X"_GA5R/5QJF;\/VJ5U
M>)<E]NX:NHZ5%F,+B68A=6YK&C?5M]^G?V)"G,Z!5)IB;$8=+C,Y%6YJ;H 1
M((:Z(%5:AV/5OV*4GG7$4Q7E7HFNV'OV]-7>)F+6628YTQ'JU6E0%">YBFP1
M;46MZP1KU0J6'8D:UT!WR#L?JK\)(=5DM%7:!AN2QZ5,\M;1INCKEPZ\`"X2
M)4Y%_IV\RB `P$A\M@G9$=:!;J523]4+J)5*Q)M&IK4%AA%1)U>TKU2S$RI^
M/,V*[5U3U=G@(B^2>2=+-:>UY%57NAY.)K5-"=EC,9H(>\C_V\*RZ?^#4Z9C
M2-?M(_Y[+.R!.#P74^^.Y+";<99DP_UH-Z&=,L7SAN9W-;DE)$]W,9$8JAO,
M=+//@[+G#E5(*L%UP 8[20FA?+4=.(T[JP*X+8.9Z3Z9M5EO`(*&C.Q.V4O3
M]B)U@WW3]B??CLFYZ69Y0_\P7[4()$=@R;EVUBC&LD=VG<<??;G'']4YAE&M
M8U!Y^S;/4++AXHY%+@*]_ULUETT'T2\XB$%-:$B6D92[Z=^V6#"LK(JPGJ\[
MW-4O)6R1:KL?%E]PH7%6N*B6K1=_2<B<C'?1^"P+^ *Y']7)_:A6[J9MW9C,
M-H3[OTVF_5*_V43S8H^IG^/1;^^DRYN)?5-R/CFOEYD^P'*)3-\GKNCDH'R.
M1=^]^+VK[NI4/''>RU@WGZ/5AC@?=S__$E.B@,[!;'H:4=Q:5YONGX<ISBB6
MG9-3V)C\<:>V:>M'\@UL+"IKVX33`'D+<N)4BQV@5;94$THR0$T+;%G&%).O
MR61:4#;.&;;":69'WZ+(DI>C[>UP=EJEA+5X2NP]V^PG-TS>;8G24M II>9?
M-#5?Z*-X(M[B0Z^WA;^SW]G(8W$FSL6I?K_&^QG>O5Z/O\^%*;E.`Y.7EUS?
M,5>4>#T]Z_<O#OJ3T<1"'6M;%E631X<73U&YG>,S/"_/,?/PAX7J;H :\; _
MZ4\LO =X'^(]R2O%8YI =>9D<M$O7-4P)A.-$Q_8*NY,%8Z&_?G"<Z-P'86T
MR1_J/."EVJ=;Z6WNY^'"<__LB*G*>"[4YF-'_"(#I,E+\;Q'Q7Z4(-,]&A]V
M,)UR,%=VGSF^KS3V<GIV)?I=:] =C5'3'W2SO.(E[?Y1,S]&^G$CD3PB[5[!
M@Y(+4D8;KQU@)WS:@XS4*:B#H7C/RM;3%,(-7X<WM O)>Z$N<E:JJ8(PH3UH
M-^7C4W)%VZDB3CEKTM%41TI'N5X^LB47O-O,P<K4S-=I@JFSD$&^#\);/I#'
ML8OG>V:36J>]W6_X(GA/]I4<36VO<KH8:8!+OVG_- 2R#E44YIA@Y9 :[2Q^
M_]W^/D;HSB\B$Q\'Y'S6^Y?,3XO0(DY M,H[5R+*G[V93"__]\)XTAX#HGD,
M0V^J!>:((R$#OK\7TB,N4XY0J'SR*$>)#B%D*@^5^9HVT\)9J[T=SDO/D?A$
M#N\LIP&=& !6=,PP5KA<!FN(B#;.8[%*X8]1A@`0C3!:\^+T]^>75Q=\_E$%
M3<*;E.T'`L%@5#V=)E#HXWQ++?)<\<)]Y<B.N/"A.U'89:L0+Y#ITY(=K._V
M<@APA_*XX*7.P_5]Y"V6"6SD:)BMILY2%H2H\1'.C>/Y?/1#[P:OTVL?Z^TY
M5'KMZ2.<@'!+3 F2>YJY0"' )P1)&3W)'3:HZ"-*#L,UI<CX3YT-$<6E&1 O
MK\_U\:XX2I?;9>A+!ACP&4 2!#&4OA-UR-20168`*%[@^JDJ_?:??/_=C_JW
M^$><S+RPM_RY<LWWKC<NTBD$OLA:?Z[V.RM;XNJ !# +X,]>0C76H-AEVF+!
M*\_DG,:\/'_ZZU2#>A.XS<"\N;@/4_ S2/@,*VMKF":D573.ETR+SI^P_0#)
M%,5E)!69@&W6.[N\.GWU/X)Q(++FN*Z0J(O+3_9U*G8W/E!'5Q/)<$LT&-L;
M'EDCNSQ[./Z%-,2Y";U9YKB6X7I-=#$,Z<=R2W($&*?!/7F.. Q8X5I@:5>#
MDK,VHT6QKPZC@]%H<%"!1J;.&I*Q4^&!1'?./-$PM#4*>W10Q>AY=G:-S3<F
M"1CK%H^%)333_],/KQU?"7QR^?Q"["/,P7>]?-81^Y"=^OO$@'V&X.93Y&.-
M)H 4[;2,::R"E'D7/A2V?YW.3\\[%2*A.B[OBBOWAS&(.SR;1NPO81- &XKY
MD[AZ\_SY26GV,W77S#+>S_A.I3JD^G!:"ZDL39F%<O)S7X<OM?-L#DLI.I23
M)!B,ONJ?GI[_\0ZH[)4<IXB18M+UM\&'M\'>B5X5X1M%"Z)MP9H0.L@!Q!(H
M7[4T8T3[I$:;GH:ZA-#=%YIFE/'[[UA/Z0!GBT BHKL=[E0G!B8NW?SQ#OGI
M!\5*&N9VMB?X%!OE:JU Q(A])!(C"]TGN3K9#@!#4C^AR)2D<399(>6#ZI=0
M`9]5X0^MN.].5. /E%XB*%R!Q?V3"N WY$LA-L3A2/K0&<5(,8>#I^L%S<Y\
M1D!.0WF2G A:R%-KE@.@V"??_1)*5KFIL.>;YR>Y">IAK& 4`]6Q^47*OD-U
M7PS]WKS%0A(__"0&HKWANY ,>+/@4:(?$+C?9E8TYT-.SAKZG,Q;>V]B2.M8
M/(B/A3)>H0T7*ME1ZM!_!U7+9\H[+VE9YLHGDWD#GU]_@9 D!3Q$N@#1;24K
M"!!!+6&\!.0UIY$MM8[UKB/VHCVBL_V3,ES1;D2<,$99ZC/]O)XBGFEX$!?1
M[QCXFW38&W0H%#/O5<'1)AQO"<>V^!H<"V*I1W)0@^2@B=D+R<%2^S':@?>E
M0SE'K\QQ-AQ0XCKD.'&!LLT_D[:.(YWL@B7:7TS7BH&:G):<NT)HNP(--VA2
M9@XLE9V?-'B*ER&[+DHP%U[ )]$I4)$!5\+ [1)<AK<D$8)3;D'Q0.4&<<PI
MEZA_]#9XU!8?/^J?%[].2-S*X/AI&%/-\ZH@F,59]'@?Q&==YDMV0V3\SXWS
M*36F6 W-^EC^X4/\%J O"J,B)?0N3_VPV>HJ"NZ"('"MPNV_S&@:Y562VZAZ
MYU/Y)^4[%73*=)/><JGIZ*/%<,DJ`PRJ`BR=5-8^_O'CD\T4SHW4`66&PRZT
M`0IQU>B94331;CX'> TVO2]G#_#M(1+$:]\)WNMZIVZE_4R=-T+2:W/>F*7/
M..OTH@EE"J" 5$@!#.I*+Y4N%?K10CV.4 OP0\,)[!U4A,R.\7TPH[TX9,J!
M*EQ^PA72GV9.9E[."+*CJ*I3M$S9FH=\JM&0!O\!_KR2Z] D"D;)^$J-FGPJ
M"^M"67JMQA:G%A JFX!6A,>/R?^>U+L">HQ.I0M\_+C.F15=_VFBDE(F03V9
M5Y 1;2-Q&P<Y6:*>&;P*;_E9`#I2JM)5G2COFX#$NN.XI#LZSR5240-SQVH%
M&>O>:JFP,CE2AMEOR*&56FOTKQW*<'0WPHGSTDXE[H8ZK>!SRL'ALG7.;^6!
MJ=7*<_JNNM^F4J3=*81JHRB9R2!MHD2W#5?:,/TS04X9`F'%<28/WMN#FS@0
MI?#V8ZX2G.&'LY2>\%/RXCT1UZ'#.EG]+OCIP'-S9+\G5(/7B]DH,^%Q#]&$
M_UAO<V?UZ#J,$D<]#_"$<D]Z_C0*46.NU!.(&1BE3'JI7,S&82NJ]1%[;K9W
M5+?)4ODOM39*]F#$V&(T]MNF""I+E+Y#2,K<%>WNICAU'< )-A2D5<F\V\K4
M];(<&&G4AK"5K)^(X0ER>.%UNR:9!GV4L?".L0*YF2JK#+ZTNDKMVPHOA*1\
M<*S5Q]<ZO->_>]"WRY^XZBAUD8"JN:474ZI=^&F7?P[:%1 >!31+_%/L037%
ML=CKT'>[&GNNV+!7L/5YPM*DIUA*A!<%Z-<8(D*53^FPB4"U%OBIE*:R<\G<
MDJFS,0O%IT\^2:=3>>U<1&+OTPE;6P&)075-4UM]^J(#_;KBGJ0!/]9\G 78
M_\X[B1Q:X](#M/K0?"'M9DQC;D>;QT?4W1R.-]<[K6J7_\;QO5EQYU!W)$^C
M19PU+DV((F^<;8SJ9;GYEOI^\>DE,D*&\HI#LP;D\78^E]>D/L>B#U6.4]?E
MTS'<GZ)B..NF59H-I2)<Y)V!LB52$^7Y25T!# )79YV""A8/.-"TCGFTZZ%2
M%/WD9%$?]WGQD\9R0$;%)S K>L2%NU[DJK,!X*KRP&7QB35(6LN\B$U('NNJ
M4X=-#BR\D1&-$RVB$1;K+HGHMEZE""^!,ER=-/=52-2J79ZQ3D5A]C?PY.ZR
M!=^@\PR*:3D`VB CUVP'A2=(S+.F):>MQ4J/@HA'UJ/C^JJ%#E-!C\MG8XO$
M4.R-8X2S><OT;?:FU@-XO:%_!RM^:.3PD%4&N")(V]4<7.66+6'U<Q=&ENH[
M"\$5$(DF/V2S*1VH^&"C4+ SO*F)66)F.>'/X@XSPVYBACW\&F;8Q(R#KV&&
MM8T9]E9F##>8,?@Z9@R:F#&POX89`V+&^&N886]CQF K,T8;S!A^*3.0_3KP
MJ,<-Q;TN$AUZJ#&EDYP=NY,]^M"K-$<507U1VXI2O/@Y:_FW<PX,B .TV#S#
M7NT6QB9(\*:B6<R41R8A4BX[0SFDG<);+Y8=%7>XU\U[2Z@;DDIU7@CO@C9C
M8\D[.!GC$.<H\',')JLCV;O3L=)R9<,!@NMDD^R1&E3K_ S/LY1:S;K&-YNN
M*H_)ED_",$\C3%9H(?$3__A)P\</E&2;V;_64%--/A;>O@U%A9J2BK*K9L4#
M)E-*VND0ZE+>H<!9>/KIZ9)X%76/J\EC6SG]2O<)"/YLU%1W?("RQIB+?=V%
M(B0)E).?J]DH9/?SNK.R=AYQ`(US%\I-2HE+L>XTZ&6D6$4M'&9V2+DTF6$F
M!F6/N;Z87B3GY8A3/XL\42^8>7'W)AM=;L(D$=65>F"F_?JP<KY@T;:VM.*F
M*AF:I[YI:A"(3^8,X_\#4$L!`A0`% `"``@`L59/)$!Z\#*(%0``H4@```@`
M`````````0`@`+:!`````'-R96,N='AT4$L%!@`````!``$`-@```*X5````
!````
`
end

Article: 19383
Subject: Re: JEDEC
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 17 Dec 1999 10:17:07 -0700
Links: << >>  << T >>  << A >>
Bonio Lopez wrote in message
<034f2f50.5d2a433f@usw-ex0102-009.remarq.com>...
>Hi friends,
>where can i find JEDEC standarts?


Would you believe:

http://www.jedec.org/

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

The secret of Slurm is on a need-to-know basis.



Article: 19384
Subject: Re: Speed grade
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 17 Dec 1999 09:41:50 -0800
Links: << >>  << T >>  << A >>


Davide Falchieri wrote:

> Hi,
>   this is a very interesting matter. Still I haven't understood the way
> you reach different speed grades in the same FPGA family. For example I
> am involved in a project using the FPGA XC4025E-4. What is the physical
> difference with XC4025E-3 and -2 ? Are they implemented using a
> different technology ?
>

There is no "physical difference" between devices with the same
designation ( and made at the same time ) but different speed designators.
Speed grades are created by testing the packaged devives and "binning"
them, i.e. depending on the test results, feeding them into separate
containers. It's just a selection process.
Modern processing has a very narrow spread, which means that there is not
much speed difference between the fastest and the slowest parts in a
manufacturing run. This creates an interesting problem:
Our industry often has no yield to the slowest spec, all parts are faster.
But there are orders for slow parts. So everybody solves this problem by
down-binning, i.e. marking a fast part as slow, and selling it at the
usually lower price of a slow part.
To the buyer, this may look like a bargain, getting a Porsche for the
price of a VW. But it can get the design in trouble if "dirty asynchronous
tricks" were used.
Always assume that the part you buy tomorrow may be faster than the one
you bought yesterday.  That's why we are advocating synchronous design
methods...

Peter Alfke, Xilinx Applications

Article: 19385
Subject: Global buffer insertion (Synplify/Flex10K)
From: Matt Gavin <mtgavin@collins.rockwell.com>
Date: Fri, 17 Dec 1999 11:52:44 -0600
Links: << >>  << T >>  << A >>
Gurus,

I am encountering some difficulties with inserting global buffers
on internal clocks in my FPGA design. My current flow is Synplify
for synthesis, then Altera MaxPlusII to target a Flex10K FPGA.

It appears that Synplify will NOT automatically insert a global
buffer onto an internal clock, for my Flex10K, even if it finds
the internal clock. (IT DOES seem to do this for Xilinx FPGA's,
though! The Xilinx global buffer gets embedded right into the output
EDIF. Not so for Flex10K.)  Is there a way to make Synplify do this
automatically for all target devices?  (A Flex10K has 4 global buffers
that may be used for internal signals.)

Of course, this global buffer insertion can be done manually in
MaxPlusII, but it is quite cumbersome, for a couple reasons.
First, the (MaxPlusII internal) name of the net is not known
until you get through the fitter, and the .rpt file is output, stating
the (names of the) inferred clocks. Only then can you insert a statement

in the <design>.acf file, inserting a global buffer onto some
oddly-named
net like "core~239~7."  Then, you have to re-run maxPlusII just so it
recognizes your global buffer!

Secondly, of course this MaxPlusII name will change if you go back
through the flow and resynthesize. Then you have to repeat the process
to find the *new* MaxPlusII name for your internal clock!  Then
modify your .acf file, and re-run again!

Any ideas? Can I get Synplify to insert the buffer manually, for
Flex10K?
And if not, is there a way to refer to my internal clock by the same
name every time through the flow, in MaxPlusII.

Thanks for any ideas.

Matt Gavin


Article: 19386
Subject: Simulation of Virtex-XDW
From: "Mark Hillers" <Mark.Hillers@Informatik.Uni-Oldenburg.DE>
Date: Fri, 17 Dec 1999 19:43:06 +0000
Links: << >>  << T >>  << A >>
Hi there,

I have some problem simulating XDW components for Virtex-FPGAs.

I am synthesizing my design with Synopsys Behavioral Compiler and
Synopsys Design Compiler.
Simulating behavioral- and rt-level (behavioral-compiler-"schedule"d)
works well. Even the backannotated vhdl-output from xilinx's
design-manager  works correctly, but the simulation of  the
synopsys-"compile"d rt-level-code produces messages like

Warning: vhdlsim,105:

/TB_E/BSPMULT_INST/MUL_NS_UNS_106_MUL_51/MU04/LA0_11/A_LUTI/COMPONENT
was
    not instanced because it is unbound.

where

   A_LUTI : DWLUT2 port map( I0 => A(23), I1 => B0, O => SUM_4_port);

and DWLUT2 is

   component DWLUT2
      port( I0, I1 : in std_logic;  O : out std_logic);
   end component;

Unfortunately this component is not available in all our SYNOPSYS and
XILINX directory trees.

When forcing the use of normal DW-components instead of XDW-components
all simulation-levels work without problems.

Has anyone advice?

Greetings
Mark


Article: 19387
Subject: Re: Speed grade
From: Ray Andraka <randraka@ids.net>
Date: Fri, 17 Dec 1999 16:28:53 -0500
Links: << >>  << T >>  << A >>
I had a boss several years ago that had a big sign hung in his office that
read "SPEED KILLS".  He had been burned by several projects which started
failing new production runs of old designs because of those very same
asynchronous dirty tricks.

Peter Alfke wrote:

> Davide Falchieri wrote:
>
> > Hi,
> >   this is a very interesting matter. Still I haven't understood the way
> > you reach different speed grades in the same FPGA family. For example I
> > am involved in a project using the FPGA XC4025E-4. What is the physical
> > difference with XC4025E-3 and -2 ? Are they implemented using a
> > different technology ?
> >
>
> There is no "physical difference" between devices with the same
> designation ( and made at the same time ) but different speed designators.
> Speed grades are created by testing the packaged devives and "binning"
> them, i.e. depending on the test results, feeding them into separate
> containers. It's just a selection process.
> Modern processing has a very narrow spread, which means that there is not
> much speed difference between the fastest and the slowest parts in a
> manufacturing run. This creates an interesting problem:
> Our industry often has no yield to the slowest spec, all parts are faster.
> But there are orders for slow parts. So everybody solves this problem by
> down-binning, i.e. marking a fast part as slow, and selling it at the
> usually lower price of a slow part.
> To the buyer, this may look like a bargain, getting a Porsche for the
> price of a VW. But it can get the design in trouble if "dirty asynchronous
> tricks" were used.
> Always assume that the part you buy tomorrow may be faster than the one
> you bought yesterday.  That's why we are advocating synchronous design
> methods...
>
> Peter Alfke, Xilinx Applications



--
-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: 19388
Subject: Altera Quartus 99.10
From: "Michael Helduser" <helduser@isptechinc.com>
Date: Fri, 17 Dec 1999 16:37:10 -0500
Links: << >>  << T >>  << A >>
Is anyone else running Altera's Quartus 99.10 SP1 under Windows NT 4.0 SP4
and having miserable problems? If I try tweaking any design options  I
consistently get internal errors during compiles . Tech Support doesn't say
much except that "it" will be fixed in the next release?

I reverted back to 99.06 SP 2 and am having none of the problems I had using
99.10.

Just curious.


Article: 19389
Subject: Re: Altera Quartus 99.10
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Fri, 17 Dec 1999 21:48:43 GMT
Links: << >>  << T >>  << A >>
> Is anyone else running Altera's Quartus 99.10 SP1 under Windows NT 4.0 SP4
> and having miserable problems? If I try tweaking any design options  I
> consistently get internal errors during compiles . Tech Support doesn't
say
> much except that "it" will be fixed in the next release?
>
> I reverted back to 99.06 SP 2 and am having none of the problems I had
using
> 99.10.

I just took a crap, and it spelt Q U A R T U S.

No, all joking aside here, I have had ENDLESS problems with it crashing
using
99.10 SP1 under NT 4.0 SP4. I turfed the SP1 and went back to old 99.10. I
only had 2 crashes today....a new record.

Trust me my friend...those internal errors arn't going anywhere fast....

My other tip for you....I was talking with Tech support, and they said the
best thing is to run the tool with TCL scripts. I figured that was the route
I was going to have to take anyway - that Timing Wizard does not nearly
constrain the stuff I need, etc.

If your problems were "solved" using 99.06 SP2, then I might have to give
that a try. Thanks for the tip.

Regards,
Xanatos


Article: 19390
Subject: Virtex boards
From: Oh Sheau Pyng <ASSPOh@ntu.edu.sg>
Date: Sat, 18 Dec 1999 09:56:22 +0800
Links: << >>  << T >>  << A >>
thanks bill.

spyng

> ----------
> From: 	Bill Blyth[SMTP:bb@alphadata.co.uk]
> Posted At: 	Thursday, December 16, 1999 6:09 PM
> Posted To: 	comp.arch.fpga
> Conversation: 	Virtex boards
> Subject: 	Re: Virtex boards
> 
> The RC1000-PP and ADC-RC1000 are identical. The board was designed by
> Alpha Data for Embedded Solutions to support their Handel-C compiler
> and is sold by both companies.
> 
> Alpha Data specialise in design of hardware and produce the ADM-XRC
> mezzanine card which also supports Virtex from V400 to V1000 and
> Virtex-
> e.
> 
> In article
> <0CF260C495FED111A6610000F866308D07D13C9D@mail3.ntu.edu.sg>,
>   Oh Sheau Pyng <ASSPOh@ntu.edu.sg> wrote:
> > hi,
> >   "Rc1000-pp" from embedded system look actually the same board as
> the
> > one in Alpha Data "ADC-RC1000", even the technical brief is
> idenitical.
> >
> >   Any one know whats the different ? Is the design from Alpha Data
> or
> > Embedded System?
> >   I have order one "ADC-RC000" with a xcv1000 from Alpha Data, which
> > have not arrived yet.
> >
> > spyng
> >
> > > ----------
> > > From: 	unknown@bits.bris.ac.uk (Address not
> > > verified)[SMTP:unknown@bits.bris.ac.uk] on behalf of Tim
> > > Tyler[SMTP:tt@cryogen.com]
> > > Reply To: 	tt@cryogen.com
> > > Posted At: 	Wednesday, December 15, 1999 3:05 AM
> > > Posted To: 	comp.arch.fpga
> > > Conversation: 	Virtex boards
> > > Subject: 	Re: Virtex boards
> > >
> > > Daryl Bradley <dwb105@nospam.ohm.york.ac.uk> wrote:
> > >
> > > [snip 3 VCC boards]
> > >
> > > : We have just ordered a PCI based XCV1000 board form embedded
> > > solutions -
> > > : have heard this is pretty good but no hands on experience yet
> > >
> > > Embedded Solutions' RC1000-PP board - suitable for Virtex:
> > >   http://www.embeddedsol.com/tech_info_3.htm
> > >
> > > Embedded Solutions' "Special Offer to universities":
> > >   http://www.embeddedsol.com/programs/academic/uni_offer.htm
> > >
> > > ``In partnership with the Xilinx University Program, Xilinx are
> > >   supplying a limited number of the Virtex XCV1000 parts free of
> > >   charge as a donation for suitable teaching/research projects.
> > >
> > >   ESL is mounting these devices on the RC1000-PP reconfigurable
> > >   computing PCI board enabling this top end version of the
> > >   RC1000-PP to be offered at a very substantial discount on the
> > >   standard university discounted price.''
> > > --
> > > __________
> > >  |im |yler  The Mandala Centre  http://www.mandala.co.uk/
> > > tt@cryogen.com
> > >
> > > It is a miracle whenever curiosity survives a formal education.
> > >
> >
> >
> 
> --
> -----------------------------
> Alpha Data Parallel Systems Ltd.
> http://www.alphadata.co.uk
> -----------------------------
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> 

Article: 19391
Subject: Dumb question springing from a discussion about chess on a chip...
From: "Dann Corbit" <dcorbit@solutionsiq.com>
Date: Fri, 17 Dec 1999 19:58:32 -0800
Links: << >>  << T >>  << A >>
There is a recent discussion on the computer chess club internet forum about
the feasibility of creating a chess chip using FPGA.  Now, a chess chip
*must* have very fast access to large amounts of shared memory, and also be
able to execute an instruction set (much like a general purpose CPU -- but
the instruction set is {of course} specialized for chess).

My question:
Is it a good idea to attempt this with an FPGA, or should a general purpose
CPU be fabricated or should it be done with something else entirely?
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
 "The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm

Article: 19392
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: Ray Andraka <randraka@ids.net>
Date: Sat, 18 Dec 1999 00:38:54 -0500
Links: << >>  << T >>  << A >>
The chess processor as you describe would be sensible in an FPGA.  Current
offerings have extraordinary logic densities, and some of the newer FPGAs have
over 500K of on-chip RAM which can be arranged as a very wide memory.  Some of
the newest parts have several million 'marketing' gates available too.  FPGAs
have long been used as prototyping platforms for custom silicon.

If I were doing such I design in an FPGA however, I would look deeper to see
what algorithmic changes could be done to take advantage of the parallelism
offered by the FPGA architecture.  Usually that means moving away from a
traditional GP CPU architecture which is limited by the inherently serial
instruction stream.  If you are trying to mimic the behavior of a CPU, you would
possibly do better with a fast CPU, as you will get be able to run those at a
higher clock rate.  The FPGA gains an advantage over CPUs when you can take
advantage of parallelism to get much more done in a clock cycle than you can
with a CPU.

That said, I wouldn't recommend that someone without a sound footing in
synchronous digital logic design take on such a project.  Ideally the designer
for something like this is very familiar with the FPGA architecture and tools
(knows what does and doesn't map efficiently in the FPGA architecture), and is
conversant in computer architecture and design and possibly has some pipelined
signal processing background (for exposure to hardware efficient algorithms,
which are usually different than ones optimized for software).

Dann Corbit wrote:

> There is a recent discussion on the computer chess club internet forum about
> the feasibility of creating a chess chip using FPGA.  Now, a chess chip
> *must* have very fast access to large amounts of shared memory, and also be
> able to execute an instruction set (much like a general purpose CPU -- but
> the instruction set is {of course} specialized for chess).
>
> My question:
> Is it a good idea to attempt this with an FPGA, or should a general purpose
> CPU be fabricated or should it be done with something else entirely?
> --
> C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>  "The C-FAQ Book" ISBN 0-201-84519-9
> C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p
> C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm



--
-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: 19393
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: "Dann Corbit" <dcorbit@solutionsiq.com>
Date: Fri, 17 Dec 1999 22:30:07 -0800
Links: << >>  << T >>  << A >>
"Ray Andraka" <randraka@ids.net> wrote in message
news:385B1DEE.7517AAC7@ids.net...
> The chess processor as you describe would be sensible in an FPGA.  Current
> offerings have extraordinary logic densities, and some of the newer FPGAs
have
> over 500K of on-chip RAM which can be arranged as a very wide memory.
Some of
> the newest parts have several million 'marketing' gates available too.
FPGAs
> have long been used as prototyping platforms for custom silicon.

I am curious about the memory.  Chess programs need to access at least tens
of megabytes of memory.  This is used for the hash tables, since the same
areas are repeatedly searched.  Without a hash table, the calculations must
be performed over and over.  Some programs can even access gigabytes of ram
when implemented on a mainframe architecture.  Is very fast external ram
access possible from FPGA's?

> If I were doing such I design in an FPGA however, I would look deeper to
see
> what algorithmic changes could be done to take advantage of the
parallelism
> offered by the FPGA architecture.  Usually that means moving away from a
> traditional GP CPU architecture which is limited by the inherently serial
> instruction stream.  If you are trying to mimic the behavior of a CPU, you
would
> possibly do better with a fast CPU, as you will get be able to run those
at a
> higher clock rate.  The FPGA gains an advantage over CPUs when you can
take
> advantage of parallelism to get much more done in a clock cycle than you
can
> with a CPU.

The ability to do many things at once may be a huge advantage.  I don't
really know anything about FPGA's, but I do know that in chess, there are a
large number of similar calcutions that take place at the same time.  The
more things that can be done in parallel, the better.

> That said, I wouldn't recommend that someone without a sound footing in
> synchronous digital logic design take on such a project.  Ideally the
designer
> for something like this is very familiar with the FPGA architecture and
tools
> (knows what does and doesn't map efficiently in the FPGA architecture),
and is
> conversant in computer architecture and design and possibly has some
pipelined
> signal processing background (for exposure to hardware efficient
algorithms,
> which are usually different than ones optimized for software).
I am just curious about feasibility, since someone raised the question.  I
would not try such a thing by myself.

Supposing that someone decided to do the project (however) what would a
rough ball-park guestimate be for design costs, the costs of creating the
actual masks, and production be for a part like that?
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
 "The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm


Article: 19394
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: "Simon Bacon" <simon@tile.demon.co.uk.notreally>
Date: Sat, 18 Dec 1999 01:24:39 -0700
Links: << >>  << T >>  << A >>
Dann

With today's technology an FPGA can easily evaluate,
for instance, the (one-level) threats to all pieces on the
board _in parallel_ at, say, 50MHz to 100MHz, depending on
the metric used to quantify 'threat'.  This is probably
equivalent to mucho conventional MIPs if FPGA-friendly
algorithms exist.

Driving a bunch of DIMMs from an FPGA is pretty straightforward.
However, the big win comes from using on-chip resources in as
parallel a mode as your imagination can conjure, as Ray noted.
Typically on-chip memory is a bunch of small blocks of a few
KBytes each, with memory widths from 8 bits to 200+ bits,
together with zillions of really small memories in the 16x1 range.

Logic densities can be huge - thousands of primitive operations in
parallel at the rated clock speed.  Using the available density is
one place where the designer's ingenuity comes in.

Could you post a few examples of the sort of primitives you
would like to see a Chess Machine execute.

As for the cost, much of the design work can be done with a student
edition of a manufacturer's toolset, at a cost of around $100.
Of course, building a real board would be $2000++, plus
whatever your time costs.  Professional help in this area is
expensive.  Depending on the design, it may be possible to use
a manufacturer's evaluation board.

There are no charges for mask sets; there are no masks.  An FPGA
is typically configured at power-on from a processor or from a
comms link of some sort.

Hope this helps...


Article: 19395
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: Ray Andraka <randraka@ids.net>
Date: Sat, 18 Dec 1999 12:50:33 -0500
Links: << >>  << T >>  << A >>


Dann Corbit wrote:

> "Ray Andraka" <randraka@ids.net> wrote in message
> news:385B1DEE.7517AAC7@ids.net...
> > The chess processor as you describe would be sensible in an FPGA.  Current
> > offerings have extraordinary logic densities, and some of the newer FPGAs
> have
> > over 500K of on-chip RAM which can be arranged as a very wide memory.
> Some of
> > the newest parts have several million 'marketing' gates available too.
> FPGAs
> > have long been used as prototyping platforms for custom silicon.
>
> I am curious about the memory.  Chess programs need to access at least tens
> of megabytes of memory.  This is used for the hash tables, since the same
> areas are repeatedly searched.  Without a hash table, the calculations must
> be performed over and over.  Some programs can even access gigabytes of ram
> when implemented on a mainframe architecture.  Is very fast external ram
> access possible from FPGA's?

This is conventional CPU thinking.  With the high degree of parallelism in the
FPGA and the large amount of resources in some of the more recent devices, it
may very well be that it is more advantageous to recompute the values rather
than fetching them.  There may even be a better approach to the algorithm that
just isn't practical on a conventional CPU.  Early computer chess did not use
the huge memories.  I suspect the large memory is more used to speed up the
processing rather than a necessity to solving the problem.

>
>
> > If I were doing such I design in an FPGA however, I would look deeper to
> see
> > what algorithmic changes could be done to take advantage of the
> parallelism
> > offered by the FPGA architecture.  Usually that means moving away from a
> > traditional GP CPU architecture which is limited by the inherently serial
> > instruction stream.  If you are trying to mimic the behavior of a CPU, you
> would
> > possibly do better with a fast CPU, as you will get be able to run those
> at a
> > higher clock rate.  The FPGA gains an advantage over CPUs when you can
> take
> > advantage of parallelism to get much more done in a clock cycle than you
> can
> > with a CPU.
>
> The ability to do many things at once may be a huge advantage.  I don't
> really know anything about FPGA's, but I do know that in chess, there are a
> large number of similar calcutions that take place at the same time.  The
> more things that can be done in parallel, the better.

Think of it as a medium for creating a custom logic circuit.  A conventional CPU
is specific hardware optimized to perform a wide variety of tasks, none
especially well.  Instead we can build a circuit the specifically addresses the
chess algorithms at hand.  Now, I don't really know much about the algorithms
used for chess.  I suspect one would look ahead at all the possibilities for at
least a few moves ahead and assign some metric to each to determine the one with
the best likely cost/benefit ratio.  The FPGA might be used to search all the
possible paths in parallel.

> > That said, I wouldn't recommend that someone without a sound footing in
> > synchronous digital logic design take on such a project.  Ideally the
> designer
> > for something like this is very familiar with the FPGA architecture and
> tools
> > (knows what does and doesn't map efficiently in the FPGA architecture),
> and is
> > conversant in computer architecture and design and possibly has some
> pipelined
> > signal processing background (for exposure to hardware efficient
> algorithms,
> > which are usually different than ones optimized for software).
> I am just curious about feasibility, since someone raised the question.  I
> would not try such a thing by myself.
>
> Supposing that someone decided to do the project (however) what would a
> rough ball-park guestimate be for design costs, the costs of creating the
> actual masks, and production be for a part like that?

The nice thing about FPGAs is that there is essentially no NRE or fabrication
costs.  The parts are pretty much commodity items, purchased as generic
components.  The user develops a program consisting of a compiled digital logic
design, which is then used to field customize the part.  Some FPGAs are
programmed once during the product manufacturer (one time programmables include
Actel and Quicklogic).  Others, including the Xilinx line, have thousands of
registers that are loaded up by a bitstream each time the device is powered up.
The bitstream is typically stored in an external EPROM memory, or in some cases
supplied by an attached CPU.  Part costs range from under $5 for small arrays to
well over $1000 for the newest largest fastest parts.

The design effort for the logic circuit you are looking at is not trivial.  For
the project you describe, the bottom end would probably be anywhere from 12
weeks to well over a year of effort depending on the actual complexity of the
design, the experience of the designer with the algorithms, FPGA devices and
tools.


> --
> C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>  "The C-FAQ Book" ISBN 0-201-84519-9
> C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p
> C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm



--
-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: 19396
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: mushh@slip.net (Dave Decker)
Date: Sat, 18 Dec 1999 17:51:27 GMT
Links: << >>  << T >>  << A >>
On Sat, 18 Dec 1999 01:24:39 -0700, "Simon Bacon"
<simon@tile.demon.co.uk.notreally> wrote:

>Dann
>
>snip


>Could you post a few examples of the sort of primitives you
>would like to see a Chess Machine execute.
>
>snip

The partition between the work done by the micro or DSP and the work
done by the FPGA, is usually best made giving the micro the more
complex algorithmic jobs and giving the FPGA the compute intensive,
but algorithmicly simple, repetitive, flow through tasks. 

Chess programs have to:
Generate a tree of all possible moves from the current position for a
depth of a few generations, the more the better.

Prune that tree so that stupid moves are not investigated, giving time
for more interesting moves to be probed to more generations.

As each new possible future board position is postulated it must be
evaluated.

It seems that one first task the FPGA could do is to evaluate a board
position and return its merit.

If that's not enough work, perhaps the FPGA could also generate a list
of every possible next half move and return that list.

The micro would be used for the more complex task of pruning the tree
and sending the next position to be evaluated to the FPGA(s). The
micro would need access to big memory. The FPGA would just run a
subroutine, without need to reference the history or progress of the
overall algorithm.

Why not ask around on some the chess news groups like: 
rec.games.chess.computer
to see what part of computer programs use the most time, and then see
if the FPGA's power could help speed up one of those bottlenecks.

Dave Decker
there is only one 'h' in my email adr

Article: 19397
Subject: Re: Dumb question springing from a discussion about chess on a chip...
From: geronimojones@my-deja.com
Date: Sun, 19 Dec 1999 10:28:19 GMT
Links: << >>  << T >>  << A >>
In article <385bc858.108486125@news.slip.net>,
  mushh@slip.net (Dave Decker) wrote:
> On Sat, 18 Dec 1999 01:24:39 -0700, "Simon Bacon"
> <simon@tile.demon.co.uk.notreally> wrote:

> Why not ask around on some the chess news groups like:
> rec.games.chess.computer
> to see what part of computer programs use the most time, and then see
> if the FPGA's power could help speed up one of those bottlenecks.

Actually this came from CCC which is like rec.games.chess.computer but
with a much better signal to noise ratio. (http://www.icdchess.com/ ,
and you have to join up but it's free.)

Over on CCC there are plently of people who understand chess programs
and their bottlenecks. But not many who know about FPGAs. And the ones
that do know a bit about FPGAs seem to be badly out of date. From the
answers here it seems FPGAs would do the job much better than some
people on CCC (including me) thought it could be done. Thanks for the
help.

There is also someone who knows someone who probably knows FPGAs and
doesn't know computer chess. We are trying to understand each other
enough to see if we can do a joint project :-)

Computer chess consists of a tree search which is easiest done serially.
But there are service subroutines you need to call at every node in the
tree that could have a lot of internal parallelism. Most notable are the
static evaluator for end-node positions, and the move generate and sort.
Both of those could eat huge numbers of gates to work faster and better,
especially the evaluator. The tree search engine though would probably
run on a simple general purpose CPU that you would build in the FPGA
somewhere so it would have very fast access to the special purpose
parts.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19398
Subject: Re: Speed grade
From: "Luigi Funes" <fuzzy8888@hotmail.com>
Date: Sun, 19 Dec 1999 18:23:27 +0100
Links: << >>  << T >>  << A >>

Peter Alfke ha scritto nel messaggio <385A7561.F990F364@xilinx.com>...
>To the buyer, this may look like a bargain, getting a Porsche for the
>price of a VW. But it can get the design in trouble if "dirty asynchronous
>tricks" were used.
>Always assume that the part you buy tomorrow may be faster than the one
>you bought yesterday.  That's why we are advocating synchronous design
>methods...
>
>Peter Alfke, Xilinx Applications
>

Peter,
can you explain what are the "dirty asynchronous tricks"  to avoid, please?
The manufacturers specify only the max. delays.  I have always to assume
that  the min. delay, theorically, could be zero?
If several signals follow similar paths, like in a bus, how have I to assume
the timing relationships between these signals at the end of path? Each
signal could have a different delay on the same device?
And generally, how much real is the timing analysis and simulation?
I belive these are important misunderstood questions. Thank you.

Luigi






Article: 19399
Subject: JamPlayer and 10K10
From: "Thomas Bornhaupt" <Thomas.Bornhaupt@t-online.de>
Date: Sun, 19 Dec 1999 22:53:04 +0100
Links: << >>  << T >>  << A >>
Hi,

i use MAX+plus II 9.3 7/23/1999 (1999.07). I can program the EPF10K10LC84-4
direcly out of Max+plus. And all works correct!

Then I try to program the EPF10K10LC84-4 with JAM.EXE (16Bit Dos) on the
same Hardware (Computer and Byteblaster). But it does not work!

The following lines are from the dosbox
-----------
Jam (Stapl) Player Version 2.12
Copywrite (C) 1997-1999 Altera Corporation
Device #1 IDCODE is 010100DD
DONE
Exit code = 0 ... Success
-----------

If i take off the cable from the ByteBlaster then i get the following lines:
-----------
Jam (Stapl) Player Version 2.12
Copywrite (C) 1997-1999 Altera Corporation
Device #1 IDCODE is FFFFFFFF
DONE
Exit code = 0 ... Success
----------

The ExitCode ist always 0. But the EPF10K10LC84-4 ist not working.

This Error is so clear, that i think that must be an User Error.

Which option is not correkt in MAX+plus or JAM.EXE?

thanks

--
Thomas Bornhaupt
Bernard Humblot Str 8a
67434 Neustadt adW
Tel: +49 (06321) 482260
eMail: Thomas@Bornhaupt.de







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