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 30800

Article: 30800
Subject: Re: Multiple state machines in altera AHDL
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Mon, 30 Apr 2001 11:09:45 +1000
Links: << >>  << T >>  << A >>


Russell Shaw wrote:
> 
> Hi all,
> 
> I'm using max-plus-ii, and just learnt AHDL.
> 
> I made this simple state machine that calls some functions, and these
> functions also have their own state machines...

i figured it out by passing flags. Got three different state machines
in a 128macro-cell epld now. AHDL is *much* better than VHDL.
Max-plus-ii is FREE:)

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\                                       /  /\/\
/__/   / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
\  \  /  Victoria, Australia, Down-Under      \  \/\/
 \__\/                                         \__\/

Article: 30801
Subject: Re: C++ To Gates
From: "Austin Franklin" <austin@darkroom98.com>
Date: Sun, 29 Apr 2001 23:00:39 -0400
Links: << >>  << T >>  << A >>
> Arguing that these C/C++-with-extensions or occam based languages are
> useful because they are parallel means that whoever's doing the arguing
> cannot possibly have really understood VHDL/Verilog.

hardware IS parallel...no matter what your design tool is...so why would one
argue that C is somehow providing some parallelism that VHDL etc. isn't?

> Further comments:
>
> o Arguing that these languages are in some sense better because they run
> at a higher level of abstraction also shows a lack of grasp of what HDLs
> are about. They should allow h/w designers the scope to specify logic
> over a range of abstraction from transitor level to full behavioural
> synthesis.

One could say that about schematics too.  You can draw a box to what ever
level of abstraction you want.

>  This is was an
> agrument used in the previous thread to justify the  idea of using s/w
> engineers to design h/w

Bad, bad idea.  Even calling most of them engineers is a stretch.  Most of
them are programmers, not engineers.  There is a significant difference.

> o The argument that there are a lot of cheap s/w engineers out there who
> could be turned to doing h/w

Bad, bad idea too.  You get what you pay for, usually....





Article: 30802
Subject: Need info : Training on ASIC/FPGA
From: "A. I. Khan" <aikhan@chat.carleton.ca>
Date: 30 Apr 2001 03:08:53 GMT
Links: << >>  << T >>  << A >>
Hi all !

It would be highly appreciated if anyone can let me know if there is any
good training course related to " ASIC/FPGA flow" (I know its huge;
still if there is any that covers important aspects) arranged by any
Institute around North America.

Thankx,

______Khan


Article: 30803
Subject: Re: C++ To Gates
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Mon, 30 Apr 2001 10:36:18 +0200
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

> Magnus Homann wrote:
> >
> > Kolja Sulimma <kolja@prowokulta.org> writes:
> >
> > > For example it would make sense to use a language that either
> > > - allows explizit parallelism, (like occam), or
> > > - does not make any assertions about the execution order to allow for a larger
> > > design space for the synthesis tools (like some functional languages)
> >
> > VHDL? Or am I missing the point?
> >
> > Homann
> > --
> > Magnus Homann, M.Sc. CS & E
> > d0asta@dtek.chalmers.se
>
> No Magnus you are not missing the point you are a smack on top of it.
>
> Arguing that these C/C++-with-extensions or occam based languages are
> useful because they are parallel means that whoever's doing the arguing
> cannot possibly have really understood VHDL/Verilog.

VHDL allows a high level of abstraction, but you still must model everything:
Your clocking scheme, your comunication model, a.s.o.
This of course gives the best results, but it involves some design decisions that need
a lot of know-how and design time.

The next higher level of abstraction would be to hide an implicit model of
communication within the language.
This dramatically reduces the design space. This a bad thing in some sense, as there
are some optimization that are not possible anymore.
But it is a good thing as there are a lot of thing that can not go wrong anymore
during the design. And it becomes possible to perform additional optimizations in the
EDA software.
One example for this is the Berkeley SCORE project, where the restriction on buffered
streams for communication allows to virtualize hardware and perform partitioning in
time automatically.

And please: You are not arguing that there will ever be a VHDL compiliert that
performs more than trivial architechture decisions or instruction scheduling?
But there are (academic) tools for this for C and other languages. I just believe that
C is a bad decision for this, because it is harder to discover parallelism in a
sequential language, than it is to simulate a partially parallel language
sequentially.

Kolja Sulimma







Article: 30804
Subject: Re: C++ To Gates
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Mon, 30 Apr 2001 10:47:00 +0200
Links: << >>  << T >>  << A >>
> > The formal meaning of language is so general that I doubt that you can
> > find any construct that is not a language.
> > To interpret schematics as a formal language for example should not be
> > too difficult.
>
> I do not believe schematics are a language, in the 'formal' sense.
> Schematics are far more symbolic, where languages are traditionally
> 'textual' where groups of symbols (letters) are required to make constructs.
> I do believe there is a distinct difference.

Schematics in itself are not a language as a word in a language is a list of
symbols.
But a schematic can be transformed to a list of symbols and vice versa. (Thats
what happens
if you select "Save" in your schematic editor)
This means that there is a language that is isomorph to schematics.



Article: 30805
Subject: Re: C++ To Gates
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Mon, 30 Apr 2001 19:33:36 +1000
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
[big snip] 
> And please: You are not arguing that there will ever be a VHDL compiliert that
> performs more than trivial architechture decisions or instruction scheduling?
> But there are (academic) tools for this for C and other languages. I just believe that
> C is a bad decision for this, because it is harder to discover parallelism in a
> sequential language, than it is to simulate a partially parallel language
> sequentially.

Have you seen behavioural VHDL tools such as Monet from Mentor?  It
reads behavioural VHDL, and outputs RTL VHDL.
I've seen a demo, but I haven't used it for a real design.

Regards,
Allan.

Article: 30806
Subject: Re: C++ To Gates
From: Richard Meester <rme@quest-innovations.com>
Date: Mon, 30 Apr 2001 12:23:34 +0200
Links: << >>  << T >>  << A >>

Magnus,
Magnus Homann wrote:

> Richard Meester <rme@quest-innovations.com> writes:
>
> > I have no experience using Verilog, but answering your question the
> > Handel-C or our Java compiler doesn't solve a non-problem. The
> > problem is that 1, there is a high need of hardware engineers, and
> > there are not enough, or the costs are to high for a company.
>
> There is no tool that can make you do good design. Good design comes
> from good designers. To design good hardware, you need to be a good
> hardware engineer. Of course, you can implement a CPU in and FPGA, and
> let the programmer use that. But that's no need for a new language.
>
> Anyway, I'm convinved that the company will be better off teaching HW
> design to the programmer. If he's a good programmer, that wont be a
> big problem.

I agree that if you can teach the software engineer to design good
hardware, and i agree on the fact that there is no tool that can make the
engineer do a good design, but there is a difference in designing an
architecture in VHDL, or an algorithm in Java/C. You can create a CPU in
Java, you can also do it in VHDL. If it is time critical, VHDL probably
does a better job at it (for now). It is just a different point of view.
I.e. sometimes i really don't care how the design is done in hw, i just
wan't my algorithm designed in Java to be performed in an FPGA. If it
meets timing then there is no problem. The advantage of using Java is (for
me) that it is quite faster in designing the hardware that i need than
when i do it in VHDL.

>
>
> > Second
> > the chipsize of FPGA's are growing so fast, that the gap between
> > design software and hardware increases.
>
> I'm not sure what you mean. the FPGA's are bigger, so you can fit more
> "lines of code" in them. It's like having a bigger memory (and faster
> CPU) on a computer. Doesn't have to change to way you program, just
> how much you can fit.
>
> Of course, bigger problems tend to be more complex, and that's where
> good tools are useful.

Indeed the lines you can program increases, and so is the risc to get lost
in your design. If you have an application of 40.000 lines of code, it is
more difficult to understand the program, also it is more difficult to
maintain. It is however indeed not impossible.

>
>
> > 3 th, because of the increase
> > of the FPGA's and the level of abstraction of HDL design languages
> > is so low, it is difficult to not get lost in your design.
>
> No, no, no. The level of abstraction i VHDL can be what you want. High
> or low. Frankly, it's a better programming language than C, and as I'm
> not into OOP I can't tell about C++. It's ADA with extensions,
> goddamit! :-) Java is good though, I give you that. Better than C++.
>
> HW designers tend to want low abstraction because that's where the
> problem domain tend to be.

I agree that the level of abstraction can be what you whan;t but for me
the level of abstraction in Java is better understood. The main thing is
that in Java i write the algorithm itself, not the infrastructure
executing the algorithm. Second i agree that Java is better than C/C++.

>
>
> > Overal i
> > like to compare it with the time when we changed from assembly to
> > C. At first people where sceptical, at the end it was accepted. The
> > same things for this change (like assembly programming results in
> > faster execution times etc) also apply from the change of HDL to
> > C/Java.
>
> No, no, no. Why does it have to be analogous? Anyway, assembly is more
> like schematics. VHDL is a high level language like C, C++, ADA, Java,
> Basic(well...),

It doesn't have to be analogous, but from my point of view it is. From
your point of view it may be not. I agree with you that VHDL is a higher
level language, and from your point of view it may be as high as C/Java,
but i don't see it that way. Personally i beleive that Java is a higher
level language than C/C++. Mostly because of the restrictions it puts on
designs in software. (i.e. no pointer usage, no access to hardware
directly etc).

>
>
> > If you don't need the fast execution time, you program in C,
> > if you need the fast execution time you program in assembly.  The
> > same goes here, if you don;t need the fast execution time, jo design
> > in Java/C, if you do need the fast timing, you program in VHDL. (you
> > can add VHDL cores in the Java program with special constructs).
>
> We don't need a new language. We need better tools. Are you trying to
> comapre the speed of programming languages? That's rediculous. Which
> language is faster, Java or C++?

I am not trying to compare the speed of the programming language, indeed
that is rediculous, i am trying to compare the speed of the final design,
the design written in VHDL perhaps can run at a higher clock frequency
than the design created in Java. Keep in mind that you don;t execute or
interpret the java Design, jou create a hardware architecture with it. (
indeed on a PC C++ creates code that runs faster than Java, but a design
created in C probably runs as fast as the design done in Java).

>
>
> > Other aspects like more people who can write hardware, easier to
> > maintain etc are also very much applicable.
>
> The language doesn't make people able to design hardware. The people
> can learn.

From their point of view they don't design hardware, they design an
algorithm that can be run in hardware instead of a CPU.

>
>
> A good _toolset_ can simlpify Hardware design, so that designers get
> more efficient.
>
> What we need is "behavioural synthesis". It doen't matter if it synths
> from VHDL, Verilog or "parallel extensions to C"
>
> Programmers should be able to pick up a new language in weeks. The
> language is _not_ the problem, it's the tools.

I agree that you can pick up VHDL in a couple of weeks, I am a software
engineer with C/C++ experience, and i learned VHDL in a couple of weeks.
The only difference in design is that you describe the architecture that
solves your problem, and not the algorithm. I.e. you create an
infrastructure where the designer desides how to do it. In software you
code the algorithm, and you let the tool deside how the architecture
should be. For me this is much simpler and faster, resulting in less time
spent per design, which in our case improves productivity. And as said,
for now it is only applicible for designs that are not that time critical,
second our designs use more gates than when designed with VHDL. But this
is not allways a problem. If it is a problem don't use it, if it is not a
problem, and you can cut down on development time and cost why shouldn't
you use it?

Richard

>
>
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> d0asta@dtek.chalmers.se

--
Quest Innovations
tel: +31 (0) 227 604046
http://www.quest-innovations.com



Article: 30807
Subject: FPGA-CPLD
From: "jawahar ali" <jawaharali_us@yahoomail.com>
Date: Mon, 30 Apr 2001 03:13:19 -0800
Links: << >>  << T >>  << A >>
Hi,
  can anyone say me whats the FPGA series equvalent for CPLD series XC9572XL (100 pin TQFP), also kindly help me how to relate the FPGA and CPLD series.

with thanks and regards,
jawahar ali.

Article: 30808
Subject: Re: FPGA-CPLD
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 30 Apr 2001 13:21:57 +0200
Links: << >>  << T >>  << A >>
jawahar ali schrieb:
> 
> Hi,
>   can anyone say me whats the FPGA series equvalent for CPLD series XC9572XL (100 pin TQFP),
>   also kindly help me how to relate the FPGA and CPLD series.

FPGs and CPLDs are different althrough you can do similar things with
them. A FPGA 2replacement" for the XC9572XL would be a Spartan XCS05XL,
which has comparable logic and flipflop ressources.

-- 
MFG
Falk



Article: 30809
Subject: Re: Multiple state machines in altera AHDL
From: Greg Deuerling <egads@fnal.gov>
Date: Mon, 30 Apr 2001 07:52:14 -0500
Links: << >>  << T >>  << A >>
In article <3AECBB59.2C68BF6D@iprimus.com.au>, rjshaw@iprimus.com.au says...
> AHDL is *much* better than VHDL.
> Max-plus-ii is FREE:)

Yeh brother, I second that.  VHDL is way to wordy and hard to follow.

-- 
                                                                     gad
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=          Greg Deuerling, Fermi National Accelerator Laboratory          =
= P.O.Box 500 MS368  Batavia, IL 60510  (630)840-4629, FAX  (630)840-5406 =
=                  Electronic Systems Engineering Group                   =
=            Work: egads@fnal.gov       Personal: gad@elnet.com           =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Article: 30810
Subject: problems with rc1000pp and xhwif
From: "Vivian" <vivian.bessler@ucd.ie>
Date: Mon, 30 Apr 2001 14:11:41 +0100
Links: << >>  << T >>  << A >>
I am having problems accessing the rc1000pp memory from both the fpga and
accross the pci bus.  The Xhwif api does not include explicit memory
arbitration methods (such as PP1000RequestMemoryBank()).  The implicit
memory arbitration methods which occur when ever any memory related methods
are called do not seem to be working correctly.  I have attached a verilog
(ucf also included) file and a java file which demonstrate the problem I'm
having.  I have also included a handelc file that is equivalent to the
verilog file.

The hardware generated repeatedly requests and releases memory ownership.
The java program attempts to read from the board memory.  However for
reasons unknown to me the java program never gains memory ownership and will
hang waiting for it.  My computer crashes several minutes after running the
java program.

I am unsure whether this is an issue for xilinx, celoxica or whether it is
incompetence on my part.  What ever the case I was wondering whether anyone
in the user group has had similar problems and if so how did they resolve
them.

Thanks,

Viv


begin 666 memArbitration.zip
M4$L#!!0````(`)9HGBI!58@;'@$``, !```0````;65M07)B:71R871I;VXN
M8V607VO",!3%GQ?(=[AT+[;@K)O;2]F#UBE%9:&.XIN$]78-2],NJ?\8^^Y+
M:X4-0QYRS_EQ<A)*!AXEX$&DWN4N18C#H>_[?<; [*JJU#7DR%/4D F)#3F@
MY#;%3"@$QAIV^W _B=ZV\7BUOK*F41)-7X97>KA\#1>7(0F7"TN(KH'#JD:^
MRQU*Z*7>&FNH<X09FX^AXK96?:H0N$HA*[B0IZZ:L5QK/X.3-#&3^>.3WQ\Y
MP=G+>&%AZVZ$%.HXLL0F"0`&'H3E'K6!1.@:CVV(`6[@@%*VT7_:K+A04.GR
M0_.BNWA?BA1L$]5K3BXEW]:PZY#;?^L-W?-DQ1OHWAWCUPY-O<*BU*<)5Y\]
M_SAS@W^$1&[PFFBB?BBQ^Q=02P,$% ````@`\6N>*K$S^*F:`0``4@,``!,`
M``!-96U!<F)I=')A=&EO;BYJ879A?9)-;]LP#(;O_A6$3\I0""[06[!#6M3M
M!A0;DJ =,.P@RVQ,U)9<B6X=%/GODS_B+!Y0GV3Q)1_J):FJK6,`;2O94DFF
ME;_NG[ZE\LLRHO]CWZ^)O7PDQ]C*&VN>:=<XQ63-;:NQ[@[+**J;K"0-NE3>
MPP-6*Y<1#S+ EM'D'K:%0Y7#1Q0!C'K/0:+AS5(.E2(C-NS(['[_`>5V?A&T
M$+Y9O>K\]RL8?)]IQ&+99YY+9< Y'F*'?[KH\:X)62.P]R.\U:#N$7K"S")'
M3G_]1%S<OJ%A#VWQ3L]#B-U^K-K9:J0>DK?VVBJ7B]CIRR1)ZCH>2\&0''B=
M>H<\JRW.==(CWY16OZ0.7QLT>B\NDTFRV7O&2MJ&91V,Y=*(^#C#X#.D/^]6
M)W '+*W*P\13*E'$,_O"*;Y(9GS=P7^84UM<D)>^1*Q%][+I/MLSAL%FG_6V
M#@O2];56U:FM+'@QL((;Z]6#2"ZNSGK.R8^NILY6@Z^?6I"2(5]@?F0<0"O6
M!8AII0$7T]1P2-RPTB];IS0>B_<[=(@.?P%02P,$% ````@`Q&:>*O3@HTBD
M`@``(PD``! ```!M96UA<F)I=')A=&EO;BYVC59=;]HP%'U.I/R'NZ<%";78
M>2NJM!9M"'5:)Z#3I&E"!@Q$A9@YCE@E?OS\$8?$<59X2'R.<Z_OQ\D-![8N
M]A0.]/# EZG@1*0L@WBR&'U]ZD=A$ 23Q93F5%@PYB03@P9"#80;*.F#AL_2
MRY^"YM:TPLC!V,%);ZB)*(S"-#L6`@(=' QKV 358E"+P2TFD0PKA*8N0?I(
MY".QCU0^HY#3K>.RR: 6@UN,\60B+ANAF5/**6@(]_"AOC.;/TSG+]\7/R;3
M^>>?D O"17&$^&8\FT*LG^OUX68\GT&,/BX'"LARFG7OXCR0I$:/+U_&,-JS
MU>MCL=E0+EU-C#Z4Z7.L%KU+PJ85HZ=A'2,'8P<G(W,6V9_(6PZ?XB/+Z7I+
M03F/0M _ZUEF7.OX-4:H;H2N-,)U(]49LW>-:5(WK<009/2O6+B"<%CD9;&7
M59X#6_A?Z&[P&T8%YS-!!%W,)*G?-8!OTJI&ZGB.A),#%;*=>@?)>!.I`&VA
M&5PRJ&(2PZ"!/=86HI05,.Z>KZBJ;2H6BU5'[!K7UK)RLI1+NDTS^7BZL8J5
MP)*!DXZ,RJ2@PG)K+#=]/.K@<0>?6)YF:W7=Y[0>T>TMB!V%-=V08B^ K-00
MS?VQ.A7J"-K'HPX>=_!)Q:](3B%V3N[IL6I*=Z?753XZ(VZ\J$\#XV^P)-EK
M;C8[&H#U666)2L_8YUFV=<>DYQW)@9TRRO-=>@2VL4?)F?4&::;N@@(V=DH+
ME93.%Q6=+R(ZUS44O!^IBH7)QO%3*NNS92"8.3,QVV6;_^,H\:2<^(NYIZH)
M5Q<3E2%VZ;E;T=V:[E1UE8&\*:U$I=#UI?Z>-R>>3=%]Z>\]$Z=T];ZS1J[M
MB1DT,F[/SJ"1=WN*!HWLV_.TC%/>#N:?413^`U!+`P04````" `C9)XJ])C7
M,WH```"$`0``$@```&UE;6%R8FET<F%T:6]N+G5C9O-S#5%0\HQW]O%64O#Q
M=U:P55!R-#17LN;E\H/(!*46IY8@Y'Q,D.3<BQ+S2@P0DKY&ENBRA@A9+W-T
M22.XI).Q`;JD,5S2!6&J/] ]A:6IQ2BV(NF%RR/9ZVN"*8VPV=D(B^D(NYTM
ML-KMYA@<@LU.K.)&.,2-H>(`4$L!`A0`% ````@`EFB>*D%5B!L>`0``P $`
M`! ``````````0`@`+:!`````&UE;4%R8FET<F%T:6]N+F-02P$"% `4````
M" #Q:YXJL3/XJ9H!``!2`P``$P`````````!`" `MH%,`0``365M07)B:71R
M871I;VXN:F%V85!+`0(4`!0````(`,1FGBKTX*-(I (``",)```0````````
M``$`( "V@1<#``!M96UA<F)I=')A=&EO;BYV4$L!`A0`% ````@`(V2>*O28
MUS-Z````A $``!(``````````0`@`+:!Z04``&UE;6%R8FET<F%T:6]N+G5C
79E!+!08`````! `$`/T```"3!@``````
`
end


Article: 30811
Subject: New sites 8994
From: aa@mail.pt
Date: Mon, 30 Apr 2001 13:19:37 GMT
Links: << >>  << T >>  << A >>
Visit this brand new sites all contents are free
Name: MP3LEECHPT          url: http://mp3leechpt.cjb.net
Name: THE ART OF SEX    url: http://www7.smutserver.com/hardcore/vareda/
xhgbkewezofektwqvvnckubqwfnkiyzurmelnwjxkttbbs


Article: 30812
Subject: Re: FPGA-CPLD
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Mon, 30 Apr 2001 16:26:01 +0200
Links: << >>  << T >>  << A >>
jawahar ali wrote:

> Hi,
>   can anyone say me whats the FPGA series equvalent for CPLD series XC9572XL (100 pin TQFP), also kindly help me how to relate the FPGA and CPLD series.

First, the XC9572XL costs $2.
You have 72 flip-flops. There is quite a lot of logic per bit. I never had to use more then one level of product terms per flip-flop.
So as a rough estimate one could say, that you can implement most circuits with less than 72 state bits in this part.

In small quantities you will not get an FPGA including configuration memory below $10.
For this money you might soon get a XC2S30 with almost 1000 flip-flops, but not so much logic per
flip-flop. (one 4-input function LUTs, plus some goodies)
In general you will be able to build much more complex designs in that FPGA.  But one can construct pathological cases where you need 70 FPGA-LUTs to
represent the logic of one CPLD-Macrocell. This means that in theory there could be designs that fit into a XC9572XL but do not fit into a XC2S15.
But I doubt that this has any relevance in practice.

Bottom line: If a cheap CPLD is sufficient, use it. It is easier . (No config memory for example)

Switch to FPGAs when necessary. They are much more flexible.

Kolja


Article: 30813
Subject: Re: Multiple state machines in altera AHDL
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 01 May 2001 00:47:50 +1000
Links: << >>  << T >>  << A >>


Greg Deuerling wrote:
> 
> In article <3AECBB59.2C68BF6D@iprimus.com.au>, rjshaw@iprimus.com.au says...
> > AHDL is *much* better than VHDL.
> > Max-plus-ii is FREE:)
> 
> Yeh brother, I second that.  VHDL is way to wordy and hard to follow.

plus i only put the max-plus CD in my PC on saturday, learnt the lingo,
and had the not-trivial design worked out and simulated by sunday
night:) Now to make a byte-blaster cable...

http://www.altera.com/products/software/free/fre-emax_baseline.html

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\                                       /  /\/\
/__/   / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
\  \  /  Victoria, Australia, Down-Under      \  \/\/
 \__\/                                         \__\/

Article: 30814
Subject: Re: C++ To Gates
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Mon, 30 Apr 2001 15:56:37 +0100
Links: << >>  << T >>  << A >>
On Mon, 30 Apr 2001 12:23:34 +0200, Richard Meester
<rme@quest-innovations.com> wrote:

>
>Magnus,
>Magnus Homann wrote:
>
>> Richard Meester <rme@quest-innovations.com> writes:
>>
>> > I have no experience using Verilog, but answering your question the
>> > Handel-C or our Java compiler doesn't solve a non-problem. The
>> > problem is that 1, there is a high need of hardware engineers, and
>> > there are not enough, or the costs are to high for a company.
>>
>> There is no tool that can make you do good design. Good design comes
>> from good designers. To design good hardware, you need to be a good
>> hardware engineer. Of course, you can implement a CPU in and FPGA, and
>> let the programmer use that. But that's no need for a new language.
[...]
>>  VHDL is a high level language like C, C++, ADA, Java,
>> Basic(well...),
>
> I agree with you that VHDL is a higher
>level language, and from your point of view it may be as high as C/Java,
>but i don't see it that way. 

Neither do I - I see it as MUCH higher level than C/C++/Java. As high as
Ada and arguably Modula-2/3. (And not as high as Lisp, SmallTalk etc)

>Personally i beleive that Java is a higher
>level language than C/C++. Mostly because of the restrictions it puts on
>designs in software. (i.e. no pointer usage, no access to hardware
>directly etc).

This indicates some confusion about the goals of language design - a
language isn't high-level because it's restricted, it's high-level
because it allows you to express complex things cleanly and simply.

Pointers shouldn't disappear because they are prohibited; if they
disappear it should be because they are an unnecessary low-level detail
with all-round unpleasant ramifications. For a simple example, consider
how a 3-D array is expressed using either array constructs or pointer
arithmetic. It should be cleaner, simpler, more intuitive, more reliable
in array form.

Unfortunately high-level languages don't achieve this particularly well
across the whole problem space. So they must provide clean ways of
extending themselves. Interfaces by whatever name. Again, compare the
robustness of VHDL's entity/architecture mechanism with C's header files
and the resulting namespace nightmare. (Though I find Modula-n's import
lists much cleaner still)

To see how well it works, consider that there is *absolutely nothing* in
VHDL to express a logic system with more than two states (1/0). And yet
std_logic_1164 (with its 9 states) is added so seamlessly that you might
think it is part of the native language. But it isn't - it's just a
library, added purely through the standard entity/architecture
interfaces.

(Though IMO some of the other libraries, for string handling etc, are
poorly thought out in comparison - but that's a function of their design
not the language itself.)

How would you accomplish the same in C/C++? 

I'm not sure that C has the expressive power to do it at all. In C++ it
might be possible, but you would have to struggle with layer upon layer
of virtual base classes, derived classes, templates, virtual functions,
overloading operators, constructors and destructors and so on. And
pointers of course! So many unnecessary low-level details that I doubt
it would be worthwhile, let alone reliable.

It's the expressive power, not the restrictions, that makes a language
high level. VHDL doesn't get everything right, but in basic things like
its interfaces and its process mechanism (to express concurrency simply
and naturally, compared with C/C++/J) IMO it does a pretty good job.

But sometimes restrictions are necessary to get the expressive power. 
If there is such a thing as software engineering, it is in the art of
making design decisions such as those which maximise the expressive
power while minimising both the restrictions and the complexity.

>> > If you don't need the fast execution time, you program in C,
>> > if you need the fast execution time you program in assembly.  The
>> > same goes here, if you don;t need the fast execution time, jo design
>> > in Java/C, if you do need the fast timing, you program in VHDL. (you
>> > can add VHDL cores in the Java program with special constructs).
>>
>> We don't need a new language. We need better tools. Are you trying to
>> comapre the speed of programming languages? That's rediculous. Which
>> language is faster, Java or C++?
>

>> What we need is "behavioural synthesis". It doen't matter if it synths
>> from VHDL, Verilog or "parallel extensions to C"
>>
>> Programmers should be able to pick up a new language in weeks. The
>> language is _not_ the problem, it's the tools.
>
>I agree that you can pick up VHDL in a couple of weeks, I am a software
>engineer with C/C++ experience, and i learned VHDL in a couple of weeks.
>The only difference in design is that you describe the architecture that
>solves your problem, and not the algorithm. I.e. you create an
>infrastructure where the designer desides how to do it. 

There is *nothing* about VHDL that makes this so - it might be a result
of the different coding styles you adopt in the two languages.

>In software you
>code the algorithm, and you let the tool deside how the architecture
>should be. For me this is much simpler and faster, resulting in less time
>spent per design, which in our case improves productivity.

In VHDL - which is, after all, only software - you can equally well code
the algorithm. The tool will (for simulation) execute it directly. Or,
(for synthesis), it will decide how the architecture should be. VHDL
synthesis tools are making progress in that direction, though they have
a long way to go yet.

(Unless I am WAY off beam, this is EXACTLY what Magnus meant by
"behavioural synthesis" above.)

Anything the C/C++/Java synthesis tools can do, VHDL's tools should be
able to do equally well, or probably better, given VHDL's expressive
power for hardware constructs.

- Brian

Article: 30815
Subject: Re: BlockRAM outputs and the Placer
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Mon, 30 Apr 2001 16:22:33 GMT
Links: << >>  << T >>  << A >>
Thanks for the pointers.  Some of the stuff I did try, like MPRR (which
would place some of the previously poorly-placed stuff well while replacing
the well-placed stuff poorly), although I didn't try the Perl script!  In
this case I eventually made source code changes to duplicate logic and make
the critical paths into multicycle paths.

And yes, I did notice the change in TBCKO for the -8 part.  I noticed that I
couldn't even come close to meeting timing with the -7 part, but could
easily with the -8 part, and I noticed it was because the TBCKO value for
the -8 was about 1/3 that of the -7.  I thought this was just a typo in the
speed files, because I couldn't see that there could be a threefold
difference in one speed grade.  However, since I was using service pack 7, I
couldn't see how such a bug could have persisted for so long.  Apparently it
wasn't a bug, because Xilinx announced they were "revising" the number.  It
was quite a revision (something like 1.095ns to 2.8ns).

-Kevin

"Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in message
news:3AEAC6E5.3924F651@agilent.com...
> Kevin Neilson wrote:
> >
> > I had a problem with the BRAM on my last project.  The Xilinx BRAM
> > clock->out time is about 3ns.  This is fine.  The problem I had was that
the
> > nets connecting the BRAM data outputs to other logic seemed to have
> > excessively long delays, many over 3ns.  Even when I handplaced flops
right
> > next to the BRAMs the net delays still seemed excessive.  This was in a
part
> > that was only 30% utilized, so there were no real routing issues.
> >
> > Have others had this problem?  I registered the BRAM outputs, but in
many
> > cases it was still over 7ns to get the data out, across the net, and
meet
> > the flop setup time.
> >
> > This raises an additional question about the placer.  The placer seems
to
> > make some really poor decisions.  All of my critical nets had huge
delays
> > because parts that should have been placed together were inexplicably
placed
> > on opposite sides of the part.  Place and route seem to be completely
> > independent processes.  Isn't there a way to place, route, and then
place
> > again based on the route information, and then route again?  This seems
like
> > a good idea, because on the second placement round, the placer could
look at
> > the critical nets from the previous route and say, "Whoa, it take 4ns to
get
> > from flop A to flop B; maybe I should place those closer together and
try
> > routing again."  But from what I can tell, placement is done first, and
then
> > locked down, with no regard to the post-route net delays.
>
> Hi Kevin,
>
> I've had the same problem.  Even with a mostly empty chip, it's still
> possible to have route congestion around the block rams.
>
> My fix was to hand place the flip flops close to the block rams.
> (Actually, I wrote a Perl script to generate the UCF.)
> This helped a lot, but I was still getting congestion.  The block ram
> signals were so congested, PAR was using route-throughs.  (A
> route-through is when PAR passes the signal through a CLB to get around
> the lack of routing resources.)
> You can check your timing report (or FPGA editor) to find
> route-throughs.
> Unfortunately, there is no way to tell PAR to not use route-throughs on
> some nets.
> Xilinx Support suggested setting the timespec priority, but that seems
> to only be used to resolve which timespec gets used when there are
> multiple timespecs covering the same path.
> It's also possible to set the priority in the PCF, but that made the
> tools crash, so I wasn't able to find out whether it would have helped.
>
> In the end, I made it work by
>
> 1.  Using a timespec that was faster than it needed to be on the paths
> that were giving problems.  Try a few different values.
>
> 2.  Hand placing everything.  (That Perl script again...)
> Automatic blockram placement is poor.  Don't rely on it.  You may be
> able to get away with automatic placement (perhaps aided by area
> constraints) for the flip flops.
>
> 3.  MPPR.  Occasionally, I would get a cost table that caused the tools
> to actually give acceptable results.  The best cost table would change
> every time the design changed.
>
> 4.  Making the other parts of the design easier to route, mostly through
> source code changes (pipelining, etc.).  It seems that PAR only expends
> so much effort before it gives up, so don't waste any of that effort on
> something that isn't so important.
> Similarly, don't overconstrain parts of the design that don't need it.
>
> 5.  (The most powerful technique of them all :) Make small changes to
> unrelated parts of the design, then run it through the tools again.
> This may perturb the placement enough to make a big difference to the
> critical path.
>
> 6.  Move other, unrelated parts of the design further away, so that they
> don't interfere with the critical stuff.
> Similarly, move the related parts of the design closer, so they don't
> "pull" on your critical paths as much.
>
> 7.  Don't trust Map.  It will sometimes put resources that really should
> be on opposite sides of the chip into the same CLB.  There is nothing
> PAR can do about this, and there is no feedback from placement to Map,
> so Map doesn't know it's not doing the right thing.  Work around this by
> using placement constraints on one or more of the problem resources, so
> that Map won't group them.
> This effect is really easy to see in the floorplanner.
>
> While I'm here...
> Did anyone else notice how the block ram timing tBCKO *more than
> doubled* with the 1.56 speed files (Virtex-E -8 speed grade)?  That was
> after the parts had been available for almost a year.  Was this change
> yield related?
>
> Good luck,
> Allan.
>



Article: 30816
Subject: Re: Multiple state machines in altera AHDL
From: Nial Stewart <nials@sqf.hp.com>
Date: Mon, 30 Apr 2001 17:31:45 +0100
Links: << >>  << T >>  << A >>
Russell Shaw wrote:
> 
> Greg Deuerling wrote:
> >
> > In article <3AECBB59.2C68BF6D@iprimus.com.au>, rjshaw@iprimus.com.au says...
> > > AHDL is *much* better than VHDL.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> > > Max-plus-ii is FREE:)
> >
> > Yeh brother, I second that.  VHDL is way to wordy and hard to follow.
> 
> plus i only put the max-plus CD in my PC on saturday, learnt the lingo,
> and had the not-trivial design worked out and simulated by sunday
> night:) Now to make a byte-blaster cable...


But what happens if you decide to target a Xilinx device?
(SpartanII devices are cheap, provide a lot of resource
and the web pack software's free too).


Nial.

Article: 30817
Subject: Re: C++ To Gates
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Mon, 30 Apr 2001 16:42:49 GMT
Links: << >>  << T >>  << A >>
There are some good points in this thread.  It would be shortsighted of me
to say that software guys will never be able to do hardcore FPGA design,
because just a few short years ago the chip designers all well-versed in
semiconductor physics and doping technology probably never foresaw being
usurped by the likes of me.  So perhaps, unlikely as it seems, more layers
of abstraction will be added such that knowledge of the chip architecture
won't be necessary at all, just like software guys now really don't care how
many registers the processor has or how many pipeline stages it has.

I am just wondering how close we are now.  I checked the example on your
website, and it seemed to be just two counters, so it was a very simple
example.  In addition, it was very verbose, and seemed to take three times
the number of lines of code that Verilog would.  I think there are two
issues here that are being confused.

RTL Design with C-like Syntax:  There is the issue of doing chip design with
a more C-like syntax.  This is definitely doable, though there seems to be
no advantage to it.  Verilog is close enough to a C-like syntax as it is.
Then there is the next issue:

Converting sequential C to chips:  This is what I don't think is possible
right now.  I think the people that are designing the C-like syntaxes know
that they are really just RTL languages, but are intentionally trying to
create confusion by pretending that code written for a processor can be
converted to an FPGA.  There is a huge difference between writing code
specifically for a chip in a C-like syntax and writing "normal" C and then
converting it to a chip.  But the confusion is created to make managers (who
aren't all technically the brightest) believe that they can leverage their
software people for chip design.

-Kevin

"Richard Meester" <rme@quest-innovations.com> wrote in message
news:3AEA8CE5.5FAE7672@quest-innovations.com...
> Kevin,
>
> I am a software engineer, with VHDL and hardware skills. I will not say
that i
> can write superior VHDL, but am doing quite a good job at it. As a
software
> engineer i wrote a Java to Hardware compiler. It is the same as the C/C++
> compiler, obly targeting Java.
>
> As these tools are in their child stages, they will not be replacing
hardware
> engineers for designs that will stretch the limit of the FPGA. So designs
that
> are very time critical will be difficult to create. But this is not really
a
> problem for designs that don't need to run at the limit of the FPGA. We
needed a
> design that run at 50 Mhz, i coded it in Java, and it run at 66MHz. So for
this
> application it was sufficient, and a lot faster to implement. I am not
saying
> that it is as efficient as when it is done inVHDL, but it is not worse
than
> that.
>
> We indeed use special java classes to create different adders, parallel
> performing tasks etc. We fully implemented these objects that they can
also run
> on a PC, so it is not just a keyword class. For the things you mention
about
> instantiating different kind of pipelines, instead of combinatorial
designs etc.
> For this special classes need to be build, but that is not different that
in
> VHDL, in VHDL you also instantiate different kind of objects.
>
> A second important aspect is that since FPGA's are growing rapidly in size
and
> speed, there is a problem with the software keeping up. These tools can
close
> the gap a little.
>
> Take a look at our website, we have a flyer called JavaToHardware, where
you can
> see some sample code, and the simulation of how it runs.
>
> Regards Richard.
>
> Kevin Neilson wrote:
>
> > OK, what's the latest on the C++ -> gates story?  I'm always hearing
about
> > how I should be using Celoxica or some such other tool, because it can
> > synthesize C++.  The implication is also made that such tools can take
code
> > written by software guys for regular processors and somehow efficiently
cram
> > it into an FPGA.  The implication is also made that I will be obsolete
soon
> > because I will be replaced by guys who are writing PC software.  I am
almost
> > certain that these tools don't work that way and are a waste of time,
and
> > that my job is not in immediate danger, but has anybody else found that
they
> > can write sequential C code and have it turned into wonderful parallel
> > synthesizable code by these tools?
> >
> > I don't even understand how these things are supposed to work.  Say I
write
> > some for-next loop in C describing a FIR filter.  Does this C->gates
tool
> > instantiate a MAC and a loop counter, or does it know that I really
didn't
> > want a temporal loop but wanted a separate multiplier for each tap and I
> > wanted an adder tree?  Furthermore, does it know that since I'm only
> > multiplying by one of a few values, that I really want the multipliers
> > replaced by lookup tables?  And does it automatically pipeline the adder
> > tree for me?  I don't get it.
>
> --
> Quest Innovations
> tel: +31 (0) 227 604046
> http://www.quest-innovations.com
>
>
>



Article: 30818
Subject: Re: C++ To Gates
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Mon, 30 Apr 2001 16:45:38 GMT
Links: << >>  << T >>  << A >>
There is a certain "mindset".  It is obvious that when Moore's Law breaks
down, advances are going to have to be made by parallel processing.  Such
methods have been in place for a long time, but I think there is a problem
in that the programmers don't seem to take advantage of them.  For example,
multiprocessor computers haven't taken off too well because software isn't
written to take advantage of that architecture.  Instead, they try to make
compilers that will take sequential code and split it up, but it doesn't
work all that well.  Another examlple is the VLIW DSPs that have multiple
MACs and ALUs and can do five or six things in one cycle.  The harware works
fine, but there are few software people that have the mindset to construct
the code properly, and the result is the the extra MACs sit around idling.
Again, they try to push the task of optimizing to the assemblers,  but
really, you just have to write the code in the first place to optimize that
architecture.  And if the assemblers can't handle the task of converting
sequential code to run parallel on two ALUs, how can we expect synthesizers
to create fully parallel code out of sequentially written C?  Someday, but
not likely soon.

-Kevin

"Austin Franklin" <austin@darkroom98.com> wrote in message
news:9cia6v$tce$1@nntp9.atl.mindspring.net...
> > > > Anyway, I'm convinved that the company will be better off teaching
HW
> > > > design to the programmer. If he's a good programmer, that wont be a
> > > > big problem.
> > >
> > > I have learned programmers do not necessarily make good hardware
> engineers.
> > > It is a different mind set and discipline.  There is much background
> that is
> > > not required for programming that is required for digital design.
> >
> > Depends on how you define a good programmer... :-)
> >
> > I'm curious what you mean when you say "make". Does that mean before
> > or after appropriate training?
>
> I do not believe most are trainable ;-)
>
> Digital engineering requires a certain mind-set.  There are obviously,
some
> very good programmers out in the world.  For the most part, it is not near
> as skilled a task as hardware engineering, IMO.  Programming languages are
> but a tool.  You can be a pretty lousy programmer, and still create a
> program that, well, 'works'.  That is not necessarily true with hardware
> engineering.  This is why I question generally calling programmers,
> engineers.  I do not see the engineering in most cases.  That is not to
say
> some aren't great engineers, but in general, most are not.
>
>
>
>



Article: 30819
Subject: Shannon Capacity
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Mon, 30 Apr 2001 17:03:09 GMT
Links: << >>  << T >>  << A >>
There's something I've never quite understood about Shannon's Law.  It
states something like this:

C = W*logbase2(1 + S/N)

where C is channel capacity, bits/s
    W = bandwidth, Hz
    S/N = signal-to-noise ratio

Theoretically, if using enough error-correction, you can transmit C bits/s
on a channel error-free.

Say you determine that the channel capacity for a particular channel is
1Mbit/s.  Does that include the error correction bits or not?  What if you
have a 1/2 rate code, where half of the bits are parity bits.  Does that
mean you transmit 2Mbit on that channel (with 1Mbit capacity) for a net data
throughput of 1Mbit error-free?  Or does the 1Mbit include the partiy bits?

-Kevin



Article: 30820
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 30 Apr 2001 19:26:04 +0200
Links: << >>  << T >>  << A >>
Brian Drummond <brian@shapes.demon.co.uk> writes:

> In VHDL - which is, after all, only software - you can equally well code
> the algorithm. The tool will (for simulation) execute it directly. Or,
> (for synthesis), it will decide how the architecture should be. VHDL
> synthesis tools are making progress in that direction, though they have
> a long way to go yet.
> 
> (Unless I am WAY off beam, this is EXACTLY what Magnus meant by
> "behavioural synthesis" above.)
> 
> Anything the C/C++/Java synthesis tools can do, VHDL's tools should be
> able to do equally well, or probably better, given VHDL's expressive
> power for hardware constructs.

Thank you Brian, I coulnd't have said it nearly as well!

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 30821
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 30 Apr 2001 19:45:14 +0200
Links: << >>  << T >>  << A >>

Richard, I cut most of your posting, because I think it all comes down to your
part below.

Richard Meester <rme@quest-innovations.com> writes:

> I agree that you can pick up VHDL in a couple of weeks, I am a software
> engineer with C/C++ experience, and i learned VHDL in a couple of weeks.
> The only difference in design is that you describe the architecture that
> solves your problem, and not the algorithm. I.e. you create an
> infrastructure where the designer desides how to do it. In software you
> code the algorithm, and you let the tool deside how the architecture
> should be.

Judging by what you write above, I'm not sure you grasp VHDL. Did you
know that VHDL has filesystem? Abstract data types? VHDL is Ada with
some extensions (not quite, but close enough). Anyone familiar with
Ada could write software in VHDL in a week, no problem.

I said write software and I mean it. This software could then be
compiled and run, just like your Ada/Java/C++ program

Now, _with the tools we have today_ that program would probably not by
possible to synth to an FPGA (at least not the file system).

You seem to think that the only VHDL you can write is low RTL-level
VHDL, probably because that's what almost everybody uses it for. This
is not due to any limitation in language, it's just that ther are no
tools to convert any VHDL-program to HW. However, writing such a tol
would be _much easier_ than to write an equally good tool for Java or
any other programming language that doesn't support parallelism.

So why is a lot of people looking into Java or C to HW, and not VHDL to HW?

* The VHDL crowd want control over what they do. Most of them (us) are
  used to specifing each and every register.

* It is easier to "sell" C-to-HW (_everyone_ knows C, right?) than
  VHDL-to-HW("VHDL is low-level, C is high-level"

> For me this is much simpler and faster, resulting in less time
> spent per design, which in our case improves productivity. And as said,
> for now it is only applicible for designs that are not that time critical,
> second our designs use more gates than when designed with VHDL. But this
> is not allways a problem. If it is a problem don't use it, if it is not a
> problem, and you can cut down on development time and cost why shouldn't
> you use it?

You are obviously trying to sell a tool that converts Java to HW. Now
tell me, hadn't it been better if that tool converted the same
expressions taken in VHDL and convert it to HW? If so, I could write
software for the "slow" part, and embed RTL for the fast part. Doing
it ioe languagfe instead of two, would make it _so_ much easier. Both
for me, that knows VHDL, and any programmer that could pick up VHDL
programming in a week.

My answer? Java is Internet. Java is sexy. Java is money. All valid
reasons for you, _but don't blame the language_.

Thanks,
Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 30822
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 30 Apr 2001 19:57:08 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma <kolja@prowokulta.org> writes:

> VHDL allows a high level of abstraction, but you still must model
> everything: 

No, no, no. Who says you must? Not the language, that's for sure. Your
toolset, perhaps, because that's what we expect it too. Please
don't make the mistake of equating the two.

> And please: You are not arguing that there will ever be a VHDL
> compiliert that performs more than trivial architechture decisions
> or instruction scheduling?

Study the baove and below for a while, and then read my comments.

> But there are (academic) tools for this for C and other languages. I
> just believe that C is a bad decision for this, because it is harder
> to discover parallelism in a sequential language, than it is to
> simulate a partially parallel language sequentially.

Kolja, why do you think that it would be easier to create a tool to
take C to HW, than VHDL to HW? It isn't, it's the other way around. It
is however not as "cool" to do, and not as much easy money. Easy money
that comes from the people who think that VHDL equates low-level, and
C high-level, when in fact we all know it's the other way around.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 30823
Subject: Re: Shannon Capacity
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 30 Apr 2001 11:43:36 -0700
Links: << >>  << T >>  << A >>
Kevin,

That is the rub.  Ever since the first paper was published, students have either
tried to prove Shannon wrong, or find the holy grail FEC method.

Since they now don't bother with trying to prove him wrong anymore (except in
advertising by companies), the best coding method is still an intractable
problem.

All bits must be included in the channel.  How else do you get them at the other
end?  They too, may be in error.  A rate 1/2 code means that twice as many bits
are in the channel, so that is a horrendously inefficient code (it cuts in half
your through put).

Modern BCH codes have as little as 4% "extra bits" to provide correction of 1, 2
bits of errors in block of 511 bits, as an example.  At the expense of
complexity, one can do even better, and correct many bytes in error over large
blocks (digital satellite TV uses these codes).  Longer codes (more bits covered
by the check and correct bits) are more powerful, but take more gates to encode
and decode.

Tricks such as turbo codes (codes with a code), adaptive coding (pick the best
correction scheme based on the kind of errors you are seeing), and soft decision
inputs (modem tells you, "maybe that was a 1, but I'm not sure") are all valid
techniques to approach the Shannon limit.

Even Bell Labs (where Shannon worked!) stated in a press release on exceeding
the Shannon limit with spatial diversity antenna systems a number of years ago.
OOPS!  Each antenna adds another Shannon channel to the picture, so in effect,
his limit wasn't exceeded at all.

Turbo codes initially made all kinds of strange claims.  Funny they made the
same mistake you almost did:  they forgot to count the check and correct bits!
Wow!  Look how good this code is!  Oops....again.

Pioneer 10 just went beyond the capacity of its ever changing and adapting
channel.  For years now, scientists and mathemeticians have uploaded new error
correction encoding schemes to Pioneer 10 while it flew out of our Solar
System.  Who is to say that with a little more work, they couldn't talk to it a
little longer?

My three favorite examples of superior channel coding are in the order of best
match to the application: Pioneer 10, music CD's, and digital satellite TV.

Oh, and go read Shannon's original paper.  I have never heard a single person
ever do a better job of explaining his theories than Shannon already did so many
years ago in his origianl paper.

Austin



Kevin Neilson wrote:

> There's something I've never quite understood about Shannon's Law.  It
> states something like this:
>
> C = W*logbase2(1 + S/N)
>
> where C is channel capacity, bits/s
>     W = bandwidth, Hz
>     S/N = signal-to-noise ratio
>
> Theoretically, if using enough error-correction, you can transmit C bits/s
> on a channel error-free.
>
> Say you determine that the channel capacity for a particular channel is
> 1Mbit/s.  Does that include the error correction bits or not?  What if you
> have a 1/2 rate code, where half of the bits are parity bits.  Does that
> mean you transmit 2Mbit on that channel (with 1Mbit capacity) for a net data
> throughput of 1Mbit error-free?  Or does the 1Mbit include the partiy bits?
>
> -Kevin


Article: 30824
Subject: FPGA : JTAG emulation in FPGA
From: "Stan Ramsden" <stan.ramsden@avnet.com>
Date: Mon, 30 Apr 2001 10:57:15 -0800
Links: << >>  << T >>  << A >>
Has anyone done a JTAG TAP controller within a FPGA? I am looking to borrow the design.

Regards,
Stan Ramsden
Field Apps Engineer
Avnet
631-434-7467



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