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
SPLASH 1990: Smith-Waterman implementation that outperforms Cray-II by a factor of 300 and a CM-II with 16K Processors by a factor of 200 using 32 pieces of XC3090 (equivalent to about one XCV800) ""Building and Using a Highly Programmable Logic Array". Maya Gokhale et. al., IEEE Computer 24(1):81-89, Januar 1991 „Searching Genetic Databases on SPLASH-2“ (available online) Dzung T. Hozang, Proceedings of FPGAs for Custom Computing Machines (FCCM), 1993 Commercial Solutions: http://www.timelogic.com http://compugen.co.il/products/bioxl_tech.htm Other applications where CPUs are outperformed by FPGAs - Test Pattern Generation - Fault simulation It can be said in general that many dynamic programming algorithms that require at most linear memory can be very well ported to systolic structures. Kolja Sulimma Kevin Neilson wrote: > Do they really use FPGAs for DNA sequencing? Back when Celera was working > on the genome they were using these huge banks of computers to match shotgun > sequencing fragment overlaps which, like correlation, is a job poorly suited > to oldschool one-line-at-a-time processors. I had the great idea of using a > long radix-4 correlator to do this and told my boss to patent my idea, but > I'm sure it was thought of long ago, like the rest of my ideas. Just the > other day I came up with a novel technique for powering automobiles through > internal combustion, and then I find out it's been in use for a century! > Ha. > > > > > > > What else? > > > > DNA sequence matching. > >Article: 30776
Richard Meester wrote: > > 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: > > I'd like to re-make a comment I made in the previous thread on this topic. What I find interesting in this discussion is that the comparisons of coding simplicity always seems to set the C++ route against VHDL, never Verilog. Has anybody had any experience or comments on say Handel-C vs. Verilog esp V2K ? To put it in its strongest sense: If VHDL didn't exist & we only had Verilog-like HDLs would there be any point or need for C++ -> gates ? i.e. is Handel-C fixing a non-problem ?Article: 30777
Rick, Rick Filipkiewicz wrote: > Richard Meester wrote: > > > > 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: > > > > > > I'd like to re-make a comment I made in the previous thread on this > topic. What I find interesting in this discussion is that the > comparisons of coding simplicity always seems to set the C++ route > against VHDL, never Verilog. > > Has anybody had any experience or comments on say Handel-C vs. Verilog > esp V2K ? > > To put it in its strongest sense: If VHDL didn't exist & we only had > Verilog-like HDLs would there be any point or need for C++ -> gates ? > i.e. is Handel-C fixing a non-problem ? 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. Second the chipsize of FPGA's are growing so fast, that the gap between design software and hardware increases. 3th, 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. 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. 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). Other aspects like more people who can write hardware, easier to maintain etc are also very much applicable. Richard -- Quest Innovations tel: +31 (0) 227 604046 http://www.quest-innovations.comArticle: 30778
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: 30779
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. > 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. > 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. > 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...), > 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++? > 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. 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. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 30780
> 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.Article: 30781
Kevin Neilson wrote: > 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. Welcome to FPGA design. The only comments you missed was that synthesis and mapping are also an independant processes. Sooner or later you will get two flops that need to be in opposite corners mapped into the same CLB. Place and route then have no chance at all of making timing. And synthesis will build logic that just can't work, as the really long, slow net ends up going through the most LUTs. As another person replied, "physically knowledgable synthesis" is one solution that does work. Pricy, yes. Has some important limitations, yes. I've used Amplify by Synplicity, and it's a good tool. Another solution is putting placement information on key elements of the design using VHDL attributes or the .ucf file. -- Phil HaysArticle: 30782
Rick Filipkiewicz wrote: > I'd like to re-make a comment I made in the previous thread on this > topic. What I find interesting in this discussion is that the > comparisons of coding simplicity always seems to set the C++ route > against VHDL, never Verilog. > > Has anybody had any experience or comments on say Handel-C vs. Verilog > esp V2K ? > > To put it in its strongest sense: If VHDL didn't exist & we only had > Verilog-like HDLs would there be any point or need for C++ -> gates ? > i.e. is Handel-C fixing a non-problem ? I don't see many comparisons between Handel-C and schematics as well. Handel-C (or something similar) would be more needed if VHDL didn't exist. To me, as a VHDL user, Handel-C more unlike Verilog than like Verilog. If I was stuck using Verilog, I would be more tempted by Handel-C. An important advantage of Handel-C is that your system can be coded and simulated in a single language. This advantage would be present regardless of the existence or nonexistence of VHDL or Verilog. -- Phil HaysArticle: 30783
> > To put it in its strongest sense: If VHDL didn't exist & we only had > > Verilog-like HDLs would there be any point or need for C++ -> gates ? > > i.e. is Handel-C fixing a non-problem ? I think the main reason for Handle-C is that there are so many software engineers that are aquainted with C. Thats the same reason way Java was more successful than many other "Internet" languages. There were just a lot of peaople that were used to the syntax. There are good reasons to do hardware design in a higher level of abstraction than VHDL or schematic. But there are very few reasons to use C (besides the point stated above). 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) Also, variable bit width of operands would be useful. Kolja SulimmaArticle: 30784
"Aki M Suihkonen" <asuihkon@beta.hut.fi> wrote in message news:9cc7q9$j99$1@nntp.hut.fi... > Facts and fantasies: > > DSP on modern Pentium 4 at 1.7GHz has about 13.8 GOPS > computing power using MMX instructions - it's assumed > only one *arithmetic* (vectored 8x8bit) instruction can be executed > in a clock cycle. > > Similarly a modern FPGA, Altera's Mercury has 14400 Logic Elements, > of which about 900 8-bit "instructions" can be composed assuming > 50% utilizations. (Routing becomes perhaps too difficult). > With 300MHz clock, the equivalent number of Meaningless OPS is > about 270000, or 270GOPS. The ratio in benefit of FPGA is about 20:1. > > This is far from the 1000:1 claim in www.andraka.com/dsp.htm > > I'd still like to believe, this kind of acceleration can be achieved. > And if not literatively, perhaps having other metrics - > GOPS/buck, GOPS/power consumption etc. As Ray already commented, 1000:1 is at the extreme end of potential performance gain. Quoting a 10:1 through 1000:1 performance gain range though is a bit on the vague side, don't you think Ray ? [I like the web site though, I'll have to check it out when I get back in the office next week] I'd be careful about comparing GOPS, BOPS, and whatever other clock rate multiplied by the number of arithmetic units and the like with logic cells. It won't help. Besides, it's really just part of a very sophisticated marekting language that doesn't mean very much :^) What you really need to do is compare what people are achieving for specific algorithms. I'm not really familiar with Intel performance capabilities for DSP but Texas Instruments and Xilinx have lots of figures on their web sites, where you see what their respective approaches will allow for such things like Filters, FFTs, etc... You'll should find some good performance gains on anything FIR related, such as decimation, down conversion, etc... Rays web site is clearly biased towards the FPGA approach. I certainly go along with the FPGA offering some substantial gains over DSPs, but it really depends on the situation. In the situations where you can exploit parallelism at the logic level, the FPGAs will blow DSPs away. You'll probably find that this isn't always the case though, and there are many advantages for using a DSP also. I guess there is also the issue of which set of tools you'd prefer to fight with, or at least which ones are more likely to let you achieve what you need more quickly. We prefer to sit on the fence, and allow people to use either, or even combine the two if they want. We don't have any experience with Altera stuff, but we do work with Xilinx and TI. You can see details on it at: http://www.traquair.com/catalog/heron.proc.html Also, check out the Virtex II FPGAs on the Xilinx web site if you want to see some impressive capabilities. http://www.xilinx.com Regards, Steve Bradshaw, Traquair Data Systems, www.traquair.comArticle: 30785
Ich habe Fragen. Wo kann man in Berlin CPLD und FPGA ab Lager kaufen? Wer verkauft Bauelemente durch INTERNET Shop? Antworten Sie besser auf eMail. Vielen Dank. -- Andrew Buckin AndrewBuckin@aol.com ipm_grp@yahoo.com ipm_grp@mail.com http://www.geocities.com/ipm_grp/ http://members.aol.com/andrewbuckin http://hometown.aol.com/andrewbuckinArticle: 30786
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:
subdesign controller
(
clk,reset: input;
)
VARIABLE
ss : MACHINE WITH STATES (s0,s1,s2);
begin
ss.reset=reset;
ss.clk=global(clk);
case ss is
when s0=>
do_pixclk();
ss=s1;
when s1=>
do_wait();
ss=s2;
when s2=>
do_line_and_frame();
ss=s0;
end case;
end;
I'm not sure about the concurrency of all this stuff. I want the
state machines in these functions to be 'stopped' when another
function in the above state machine is 'active'.
How can you do that? How does a sub state-machine 'exit'?
The function do_wait() is:
subdesign do_wait
(
clkout: output;
)
VARIABLE
waitcnt[7..0] : DFF;
ssw : MACHINE WITH STATES (s0,s1,s2,s3);
begin
defaults
waitcnt.clrn=vcc;
clkout=gnd;
end defaults;
waitcnt[].d=waitcnt[].q+1;
case ssw is
when s0=>
waitcnt[].clk=vcc;
clkout=vcc;
ssw=s1;
when s1=>
waitcnt[].clk=gnd;
clkout=gnd;
ssw=s2;
when s2=>
if waitcnt[].q>=20 % wait time %
then
ssw=s3;
else
ssw=s0;
end if;
when s3=>
waitcnt[].clrn=gnd; % async. reset %
ssw=s0;
end case;
end;
Is this state machine running concurrently with everything else?
--
___ ___
/ /\ / /\
/ /__\ / /\/\
/__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
\ \ / Victoria, Australia, Down-Under \ \/\/
\__\/ \__\/
Article: 30787> ...software engineers Not all that write software are engineers...another topic though. > There are good reasons to do hardware design in a higher level of abstraction... Absolutely agree. > For example it would make sense to use a language... Why does that necessitate a language?Article: 30788
Do the following: 1. Use a clkdll on your input clock. (Actually this doesn't affect Tiockp, but it affects the output delay relative to the input clock.) 2. Use the register in the IOB (I guess you're already doing that). 3. Use the constraint editor to set the output speed to "Fast". (The default is slow.) 4. Get the latest "Speed File - Ver 1.78" from your FAE. This should result in Tiockp of 3.73nS and about 4.5nS relative to your input clock. On Thu, 26 Apr 2001 23:05:28 -0800, "Jinhua Li" <jhli@memec-asiapacific.com> wrote: >Hi All, > >Could you help me for this issue? > >Virtex-II Data sheet show the Tiockp=3.73ns max (Ver.1.5). But the Timing Analyzer show the Tiockp=8.003ns (Tool: F3.3i SP7). >Which is correct? > >Thanks > >Jinhua Li mchampion@Xbigfoot.com (remove the X to send me email)Article: 30789
During my study I am looking for descriptions of other HDLs than Verilog and VHDL, for example Schematic UDL/I Hardware-C (Stanford) Altera HDL LogIC ABEL-HDL where can I find tutorials where these HDLs are described shortly, only for an overview? They could also be written in German or French. Thx! -- T |-| ( ) |\/| /-\ S mailto:thomas@wambera.de http://www.madmusic.de http://www.kripps.deArticle: 30790
> > For example it would make sense to use a language... > > Why does that necessitate a language? 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. KoljaArticle: 30791
Thomas Wambera schrieb: > > During my study I am looking for descriptions of other HDLs than Verilog > and VHDL, for example > > Schematic > UDL/I > Hardware-C (Stanford) > Altera HDL > LogIC > ABEL-HDL have you tried Google ? -- Bertram Geiger, bgeiger@aon.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 30792
Kevin Neilson wrote: > > Do they really use FPGAs for DNA sequencing? Back when Celera was working > on the genome they were using these huge banks of computers to match shotgun > sequencing fragment overlaps which, like correlation, is a job poorly suited > to oldschool one-line-at-a-time processors. An inetresting point with the implemntation of DNA sequencing dynamic programming on modern CPU (like PII) is that you get relly poor perfomance (12 millions comparison/sec with a C code implementation vs approx 1 or 22 billion for an FPGA) This is probably due to the absence of MAX/MIN instruction in the x86 ISA, which is performed through conditional branches, inducing a lot of branching misprediction which impact very negatively performances. StevenArticle: 30793
"Austin Franklin" <austin@darkroom98.com> writes: > > 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? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 30794
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.seArticle: 30795
I found this cool program you can download it from: www.applicationwarp.comArticle: 30796
"Ray Andraka" <ray@andraka.com> wrote in message news:3AE84CA0.65A0107@andraka.com... > My info is dated but: > > Harris (now intersil), Graychip, LSI Logic, TRW (Raytheon), GEC Plessey all make > or made FIR chips. None are as flexible or powerful as what you can do in an > FPGA. > > Also, check out Logic Devices. They make clones of the TRW/Raytheon stuff, and also make their own, more hightly integrated, stuff.Article: 30797
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. 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. o Any language that is a candidate to succeed or replace VHDL/Verilog cannot be restricted to the programmable world alone. This is was an agrument used in the previous thread to justify the idea of using s/w engineers to design h/w ``getting it wrong doesn't risk a $250K respin since we'ere only talking about FPGAs''. With the advent of very large FPGAs modern practice seems to be tending towards the use of FPGAs as ASIC prototyping platforms and even, if you can buy them [sorry Peter!] cheap Spartan2 type FPGAs for small scale production. o The argument that there are a lot of cheap s/w engineers out there who could be turned to doing h/w is also largely a marketing invention. The bulk of these C/C++ programmers spend their time writing database query apps, complicated GUIs for doing simple tasks, and web programs that use all my 128K ISDN bandwidth to flash a red light on & off. The s/w engineers who *would* take naturally to this are those used to writing multi-threaded RTOS code or device drivers or interrupt handlers - in short kernel hackers. But these people are (a) at least as rare & expensive as h/w engineers and (b) are usually bright enough that they could pick up at least the basics of Verilog coding in a few days [VHDL might stop them for a little longer but not much] o There was another comment re Handel-C that gave me the shivers. It was that the clock doesn't explicitly appear. I don't know about you but if I've been sitting there coding a module & repeatedly typing always @(posedge cpuclk) ... for some time & then I find myself typing always @(posedge pciclk) ... the alarm bells go off in my head, the red light flashes, the siren howls & out of the corner of my eye I see the silicon crunching fangs of the metastab beast waiting to tear the guts out of my design.Article: 30798
"Kolja Sulimma" <kolja@prowokulta.org> wrote in message news:3AEBFDCA.A80EE504@prowokulta.org... > > > For example it would make sense to use a language... > > > > Why does that necessitate a language? > > 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. You can NOT look at VHDL and tell me what the function does without reading it. You CAN look at a schematic symbol and tell me immediately (if drawn correctly) what the function is.Article: 30799
> > > 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.
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