Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 30775

Article: 30775
Subject: Re: Comparison of FPGA and DSP
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Sat, 28 Apr 2001 13:03:32 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: C++ To Gates
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 28 Apr 2001 12:47:08 +0100
Links: << >>  << T >>  << A >>


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
Subject: Re: C++ To Gates
From: Richard Meester <rme@quest-innovations.com>
Date: Sat, 28 Apr 2001 14:52:35 +0200
Links: << >>  << T >>  << A >>
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.com



Article: 30778
Subject: Re: BlockRAM outputs and the Placer
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Sat, 28 Apr 2001 23:34:30 +1000
Links: << >>  << T >>  << A >>
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
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 28 Apr 2001 15:53:14 +0200
Links: << >>  << T >>  << A >>
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.se

Article: 30780
Subject: Re: C++ To Gates
From: "Austin Franklin" <austin@darkroom98.com>
Date: Sat, 28 Apr 2001 10:09:30 -0400
Links: << >>  << T >>  << A >>
> 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
Subject: Re: BlockRAM outputs and the Placer
From: Phil Hays <spampostmaster@home.com>
Date: Sat, 28 Apr 2001 14:20:53 GMT
Links: << >>  << T >>  << A >>
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 Hays

Article: 30782
Subject: Re: C++ To Gates
From: Phil Hays <spampostmaster@home.com>
Date: Sat, 28 Apr 2001 14:21:30 GMT
Links: << >>  << T >>  << A >>
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 Hays

Article: 30783
Subject: Re: C++ To Gates
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Sat, 28 Apr 2001 20:17:59 +0200
Links: << >>  << T >>  << A >>
> > 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 Sulimma


Article: 30784
Subject: Re: Comparison of FPGA and DSP
From: "Steve Bradshaw" <sjb@traquair.com>
Date: Sat, 28 Apr 2001 19:11:04 GMT
Links: << >>  << T >>  << A >>

"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.com





Article: 30785
Subject: CPLD
From: "Buckin" <ipm_grp@freenet.de>
Date: Sat, 28 Apr 2001 23:02:32 +0200
Links: << >>  << T >>  << A >>
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/andrewbuckin



Article: 30786
Subject: Multiple state machines in altera AHDL
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sun, 29 Apr 2001 11:36:13 +1000
Links: << >>  << T >>  << A >>
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
Subject: Re: C++ To Gates
From: "Austin Franklin" <austin@darkroom98.com>
Date: Sat, 28 Apr 2001 21:50:53 -0400
Links: << >>  << T >>  << A >>
> ...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
Subject: Re: Virtex-II: Clock-to-PAD Issue
From: cantsay@here.com (Marko)
Date: Sun, 29 Apr 2001 07:41:23 GMT
Links: << >>  << T >>  << A >>
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
Subject: Verilog + VHDL - and the other?
From: Thomas Wambera <thomas@wambera.de>
Date: Sun, 29 Apr 2001 12:23:35 +0200
Links: << >>  << T >>  << A >>
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.de



Article: 30790
Subject: Re: C++ To Gates
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Sun, 29 Apr 2001 13:40:58 +0200
Links: << >>  << T >>  << A >>
> > 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.


Kolja


Article: 30791
Subject: Re: Verilog + VHDL - and the other?
From: Bertram Geiger <bgeiger@aon.at>
Date: Sun, 29 Apr 2001 14:11:22 +0200
Links: << >>  << T >>  << A >>
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 - AUSTRIA

Article: 30792
Subject: Re: Comparison of FPGA and DSP
From: Steven Derrien <sderrien@irisa.fr>
Date: Sun, 29 Apr 2001 15:21:04 +0200
Links: << >>  << T >>  << A >>


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.

Steven

Article: 30793
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 29 Apr 2001 18:55:00 +0200
Links: << >>  << T >>  << A >>
"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.se

Article: 30794
Subject: Re: C++ To Gates
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 29 Apr 2001 18:57:40 +0200
Links: << >>  << T >>  << A >>
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

Article: 30795
Subject: Speedup games, programs and get more FREE RAM
From: Jhon12@hotmail.com
Date: Sun, 29 Apr 2001 17:46:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
I found this cool program you can download it from: www.applicationwarp.com

Article: 30796
Subject: Re: manufacturer's of FIR chips
From: "Pete Fraser" <pfraser@dnai.com>
Date: Sun, 29 Apr 2001 12:03:35 -0700
Links: << >>  << T >>  << A >>

"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
Subject: Re: C++ To Gates
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 30 Apr 2001 00:44:13 +0100
Links: << >>  << T >>  << A >>


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
Subject: Re: C++ To Gates
From: "Austin Franklin" <austin@darkroom98.com>
Date: Sun, 29 Apr 2001 20:03:39 -0400
Links: << >>  << T >>  << A >>

"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
Subject: Re: C++ To Gates
From: "Austin Franklin" <austin@darkroom98.com>
Date: Sun, 29 Apr 2001 20:04:43 -0400
Links: << >>  << T >>  << A >>
> > > 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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search