Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
> 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
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, ______KhanArticle: 30803
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 SulimmaArticle: 30804
> > 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
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
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.comArticle: 30807
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
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 FalkArticle: 30809
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: 30810I 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!@`````` ` endArticle: 30811
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/ xhgbkewezofektwqvvnckubqwfnkiyzurmelnwjxkttbbsArticle: 30812
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. KoljaArticle: 30813
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
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. - BrianArticle: 30815
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
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: 30817There 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
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
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: 30820Brian 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.seArticle: 30821
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: 30822Kolja 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.seArticle: 30823
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? > > -KevinArticle: 30824
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:
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