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

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

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

Custom Search

Messages from 91325

Article: 91325
Subject: Memec Insight Spartan-3 LC Development Kit USB drivers needed! Help!
From: "Robert" <robertsolanki@gmail.com>
Date: 3 Nov 2005 08:20:44 -0800
Links: << >>  << T >>  << A >>
Hi,
I am using the Spartan-3 development kit from Memec. I can't find my cd
and need to use the USB. Can anyone send me the drivers. The file is
supposed to be CP2101.exe or CP2101_Drivers.exe on the CD.

Thanks in advance,
Robert.


Article: 91326
Subject: Re: Xilinx trouble opening ml40x_emb_ref_xx
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 3 Nov 2005 08:29:00 -0800
Links: << >>  << T >>  << A >>
>> First of all I have tried to download the reference design for the ML403
>> twice today with no luck.  The download page is completely empty. Could
>> somebody at Xilinx please fix this?
>
> Were you at :
> http://www.xilinx.com/products/boards/ml403/powerpc_microblaze_demos_refsys.htm
>

No, from the home page I went to Silicon Devices, Virtex-4 MultiPlatform 
FPGA, Development Boards, Virtex-4 ML403 Embedded Platform, ML403 Demos and 
Reference Designs which is still a blank page. This is the dead end link:

http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=null&sSecondaryNavPick=null&category=&iLanguageID=1&key=HW-V4-ML403-USA

Your link works well thank you Newman.

And, in response to the Xilinx website flame by the Jim G  I find the Xilinx 
website very satisfying. The only reason I post my gripes to the group is 
that the I don't like the formalities of creating a Xilinx case.

Can anybody help me, or has anybody seen, the other issue about the opening 
the UART IP ?

Brad Smallridge at
aivision dot com



Article: 91327
Subject: Re: ChipScope on ML401 kit
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 3 Nov 2005 08:54:42 -0800
Links: << >>  << T >>  << A >>
I recently got some ChipScope stuff to work..and I am pretty sure there
are many people in this group who are using ChipScope. So anyways the
question is where exactly r u stuck. I dont use a ML 401 but I dont
think so that matters..If you can e-mail me the exact problem then
probably I can help you out..

--
Parag


Article: 91328
Subject: re:Newbie. Clocks.
From: miti0200@student.miun-dot-se.no-spam.invalid (mice)
Date: Thu, 03 Nov 2005 11:16:17 -0600
Links: << >>  << T >>  << A >>
You're all too kind!

The reason why I'm asking these starter-questions is that my read-only
SPI sometimes
misses a byte. And it's using both flanks of a clock.
It worked ok without so much other stuff in there, but after a while
it started to
act strange.
I've, almost, built a complete SoC (CPU,SPI,Mem-Manager and GPU) and
there is so much
going on in here that I really had no clue where to start looking for
the SPI problem.
As a test I now let the part that handled the SPI run on a 12.5Mhz
clock instead of a 25Mhz
and now it's stable again.

If I'd had a timing report generated that would have told me the
delays for the relevant
path's I might have discovered this sooner. Alas, I've started to read
how the
constraints works.
This probably isn't the "right" way to learn things, but I'd like to
see results fast
whenever I do something, which means missing basic "how it works"
stuff until problems
pops up. Good thing I'm not building houses...

My todo list:
- Learn Constraints
- Implement/learn DCM
- Taking a bl**dy electronics course

These new cheap "Fogs" are the coolest thing! Can't remember when I
had this much fun before...

Thanks to you all!
((mice


Article: 91329
Subject: Re: Memec Insight Spartan-3 LC Development Kit USB drivers needed! Help!
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 3 Nov 2005 18:47:37 +0100
Links: << >>  << T >>  << A >>
"Robert" <robertsolanki@gmail.com> schrieb im Newsbeitrag 
news:1131034844.173053.146390@f14g2000cwb.googlegroups.com...
> Hi,
> I am using the Spartan-3 development kit from Memec. I can't find my cd
> and need to use the USB. Can anyone send me the drivers. The file is
> supposed to be CP2101.exe or CP2101_Drivers.exe on the CD.
>
> Thanks in advance,
> Robert.
>

when you buy memec kits you also have kit serial number that can be used 
access memec rdc site there is the driver available

antti 



Article: 91330
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 3 Nov 2005 10:16:10 -0800
Links: << >>  << T >>  << A >>

Martin Ellis wrote:
> Thomas Reinemann wrote:
> >> I suspect, the total IP coded in VHDL/Verilog is three to four orders
> >> of magnitude less.
>
> > May be, but it uses the hardware very efficiently
>
> Isn't that what people said about assembly language?  And GOTO statements?

Isn't that what people said about Schematic based designs when HDLs
popped up?

The reality is the HLLs targeting reconfigurable computing on FPGAs get
very good
fits already, just as HDLs do simply because the back end optimizers in
the tool
chains for space/time traceoffs, partitioning, mapping, and routing
yield the same
benefits for HLLs.  The biggest differences is that most HLLs hide
implementation
details that create design risks, which are considered expert tools for
HDL users, thus
allowing coders with less hardware experience the ability to realize
functional designs
with a small performace penalty. Given that the speed ups from a
RISC/CISC architecture
CPU to FPGAs that can be obtained where there is parallism, are often
one to three
orders of magnitude, this small efficiency loss is completely mouse
nuts. To gain that
extra effieciency would require an experienced HDL coder and sigificant
delays in the
development schedule, each of which have marginal cost benefit gains in
comparison
to the huge gains made by using reconfigurable computing with FPGAs.

Heck, Impulse C is said to use VHDL as the netlist technology to
optimize the fit.
FpgaC even has some experimental code that uses Verilog as the netlist
technology
instead of XNF. Even the XNF outputs allow for respresenting the output
design as
basic gates or packed LUTs with equations allowing the user to decide
which will
do the best technology mapping. Each of these choices gives the backend
tool chain
considerable room to optimize the HLL produced netlist for the target
technology, just
as VHDL and Verilog designs expect.

> It's not like using a HLL for FPGA design is only useful for hobbyists
> anyway.

Celoxica C and Impluse C are becoming thriving products with expensive
high
value tool chains. Others are likely to become successful as well, and
it's very
likely that Xilinx or Altera or other FPGA company will offer a C
HLL/HDL as their
flagship tool chain as reconfigurable computing takes off and drives
the high end
FPGA revenues.  Some expect that may be in the form of System C if that
techology
really takes off as a system level design specification tool.

Doesn't matter. There are few low cost C HLL/HDL tools available for
students,
hobbyists, and low budget design shops. The total cost of the Celoxica
tool chain
for a modest sized development team can easily run the cost of several
engineers
for the multiple licenses needed. Small 1-10 man shops like mine simply
can not
afford Celoxica licenses, so I've used a mix of TMCC and Verilog for
several
projects to meet my budget.

There are several interesting specialty C HLL/HDL research tools that
knock your socks
off. Several data flow C compilers have been presented at conferences
that would be
awesome for some projects if they ever became a real product that was
affordable or released GPL (search for ROCCC and PiCoGA projects, and
work by Oskar Mencer). Sarah's
partial evaluation C compiler called HARPE generates some awesome logic
optimizations
which coupled with her Async work would make a killer tool to add to
ones tool chain for
certain types of projects (see
http://findatlantis.com/syncpe_paper.pdf). And Mihai Budiu's
research at CMU which produced the ASH tool chain (see
http://www.cs.cmu.edu/~mihaib/research/research.html ) Other projects
like SA-C at ColoState.edu (see http://www.cs.colostate.edu/cameron/)
and Spark at UCSD (see
http://mesl.ucsd.edu/spark/) and a few dozen others are all exploring
and showing good solid gains in how to map HLLs to FPGA and win big.

C as an HLL to netlist toolchain is here to stay, and probably only get
better with time.
C as an HDL (in the form of Handel-C by Celoxica) is clearly here.


Article: 91331
Subject: Re: Spartan-3E starter kit
From: "Peter Alfke" <peter@xilinx.com>
Date: 3 Nov 2005 10:16:46 -0800
Links: << >>  << T >>  << A >>
Brian, your older comments must have fallen on good ears.
The S3e500-based evaluation board uses a two-row 100-pin connector with
(almost) one whole row dedicated to Ground.  Plus two legacy connectors
that are much smaller.
2 x 16 character LCD display, rotary shaft encoder input, USB
connector, plus other goodies...
The manual is still being written, and I offered some help.
December is the month...
Peter Alfke, Xilinx


Article: 91332
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 3 Nov 2005 10:46:12 -0800
Links: << >>  << T >>  << A >>
Robin Bruce wrote:
> >Never, since most of them think in sequential algorithms and don't
> >understand the advantages of hardware.
>
> What are you saying? That people who don't understand hardware don't
> make good hardware designs?

That's essentially it.  Let's define "good" hardware designs: best use
of hardware resources with highest performance (clock speed).

> Why would that make VHDL better than a HLL-to-VHDL tool?

Because VHDL and Verilog are designed from the ground up to take
advantage of the parallelism inherent in hardware designs.  Sequential
programming languages such as C are not, and much hackery has to happen
for C to map well to hardware.

As an example, think about how you could implement a FIR filter in C
for a DSP, and then think about how you could implement the same filter
on an FPGA.  I suppose one could write a tool that's smart enough to
translate the C description of a FIR filter into efficient hardware but
one presumes that sufficient restraints would need to be put into the
"hardware C" for the tools to work well.  But if the intent is to take
high-level C developed by a software guy and have it map to hardware as
well as it runs on a DSP, well, I just think you'll leave a lot of FPGA
peformance on the table.

> I could just as easily say that people who've never heard of algorithms
> don't understand the advantages of a microprocessor, therefore
> assembler is better than C. It's a non sequitur...

You could, but the statement is irrelevant.

-a


Article: 91333
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 04 Nov 2005 07:51:59 +1300
Links: << >>  << T >>  << A >>
Martin Ellis wrote:
> Jim Granville wrote:
> 
>>  How about some examples, of some real applications, that can be coded
>>in either, and the resulting source examples, and the FPGA resource
>>mapping that results ?
> 
> 
> Here's a reference that was posted here a while ago and I'm just following
> up just now:
> 
> "Survey of C-based Application Mapping Tools for Reconfigurable Computing"
> http://klabs.org/mapld05/program_sessions/session_c.html
> 
> On p14, the C-based implementation performs faster than the VHDL
> implementation, despite the VHDL being developed after 'semester-long
> endeavor into algorithm?s parallelism'.
<snip>

Thanks, very interesting link.

I like this oxymoron, on p5 :
" * Companies create proprietary ANSI C-based language
   * Languages do not have all ANSI C features
and this very important point
   * Must adhere to specific programming “style” for maximum optimization
"

  The benchmarks are usefull - and show the choice is very much a lottery.
  One benchmark they did not give, was just what results were if Generic 
C, from a generic graduate, was thrown at these tools.

  Source snippets are important, because these solutions are not C, but 
C-based.  The devil is in the details....

-jg




Article: 91334
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 3 Nov 2005 11:01:21 -0800
Links: << >>  << T >>  << A >>
I'm afraid if you throw generic C at these tools, it won't compile...


Article: 91335
Subject: Re: Memec Insight Spartan-3 LC Development Kit USB drivers needed! Help!
From: "Robert" <robertsolanki@gmail.com>
Date: 3 Nov 2005 11:02:37 -0800
Links: << >>  << T >>  << A >>
Hi checked their design center, I found the documentation on the JTAG
cable (last in the list) but not the USB drivers I am looking for.

Can you send me a link to that?

Thanks,
Robert.


Article: 91336
Subject: Actel SoftARM IP core generator tools finally available !!!
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 3 Nov 2005 20:08:40 +0100
Links: << >>  << T >>  << A >>
After loooong waiting the CoreConsole tool can now be downloaded from Actgel 
website.
It allows to create ARM based SoCs for the PA3/E Flash FPGA's.

Current version doesnt yet allow creation of custom peripherals what is 
promised in next releas(es).
Also the distributors (at least in Gemany) do not have and ARM7 ready 
silicon to ship from stock.
On my email inquiry I was asked to call back. I called and asked my question 
again
"do have some silicon to ship" what as usual ended up in long discusssion 
what is what I need
why I need it, do I want support. My question about availability remained 
unanswered still.

Anyway its some progress... Actel has been trying to push their ARM7 for 
some time
without the actual support for it in the tools available, now the software 
supports at
least seems to be avaialble.

Antti
DIY - FPGA Logic Analyzer:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=5826253867 



Article: 91337
Subject: Re: Memec Insight Spartan-3 LC Development Kit USB drivers needed! Help!
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 3 Nov 2005 20:11:30 +0100
Links: << >>  << T >>  << A >>

"Robert" <robertsolanki@gmail.com> schrieb im Newsbeitrag 
news:1131041752.243659.217280@g47g2000cwa.googlegroups.com...
> Hi checked their design center, I found the documentation on the JTAG
> cable (last in the list) but not the USB drivers I am looking for.
>
> Can you send me a link to that?
>
> Thanks,
> Robert.
>
sure, here it is:

http://legacy.memec.com/solutions/reference/xilinx/downloads/cp2101.zip

Antti
DIY - FPGA Logic Analyzer:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=5826253867






Article: 91338
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 3 Nov 2005 11:23:04 -0800
Links: << >>  << T >>  << A >>
Andy,

firstly, you've misunderstood my post. The previous poster seemed to
suggest that there was some kind of link between people not
understanding hardware and HLLs being inferior to VHDL. I didn't see
what the level of experience of people who use HLLs has to do with
whether or not HLLs are superior to HDLs. This was what led to my
intentionally fatuous comment:
> I could just as easily say that people who've never heard of algorithms
> don't understand the advantages of a microprocessor, therefore
> assembler is better than C. It's a non sequitur...

OK, as for your other comments:
>> much hackery has to happen for C to map well to hardware.

well, much 'hackery' obviously has happened, as there are tools that
map C well to hardware. We're not talking about what might happen,
we're talking about what is happening.

>I suppose one could write a tool that's smart enough to
>translate the C description of a FIR filter into efficient hardware but
>one presumes that sufficient restraints would need to be put into the
>"hardware C" for the tools to work well.

Check slide 13 of Brian Hollands presentation from MAPLD, you'll find
all 3 HLL tools tested beat the VHDL for FIR implementation:

>But if the intent is to take
>high-level C developed by a software guy and have it map to hardware as
>well as it runs on a DSP, well, I just think you'll leave a lot of FPGA
>peformance on the table.

Who said that's what we're trying to do? We're talking about high-level
languages not so we can compile legacy code. We're doing it so we can
rapidly infer reliable hardware using a more concise expression than
that achieved using HDLs while paying a minimal price in lost potential
performance.


Article: 91339
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Martin Ellis <me_ncl@hotmail.com>
Date: Thu, 03 Nov 2005 19:32:04 +0000
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> I like this oxymoron, on p5 :
> " * Companies create proprietary ANSI C-based language
>    * Languages do not have all ANSI C features

I don't think that's an oxymoron.  Just because a language is proprietary,
it does not mean it can't be based on ANSI C.

Sure it might read a bit funny - but we've all tried to cram too much onto
slides before.

> and this very important point
>    * Must adhere to specific programming ?style? for maximum optimization

Yes.  That's a very important point.

>   The benchmarks are usefull - and show the choice is very much a lottery.
>   One benchmark they did not give, was just what results were if Generic
> C, from a generic graduate, was thrown at these tools.

I think you've got the wrong end of the stick there.

This isn't about taking arbitrary C code and compiling it to an FPGA.
You simply can't do that.  

Reason:  It's possible to write architecture specific code (that is, code
specific to a particular ISA) in C.  Self-modifying code and dynamic code
generation are examples of this.

For example, linkers and JIT compilers modify code which is then executed. 
You couldn't compile that efficiently to an FPGA - it would need the
re-synthesis every time code was modified..

Another reason is that a compiler can't guess which inner loops are program
'hot-spots', and thus good candidates for synthesis.  Such information is
application-domain specific.

Concisely:  the aim isn't to be able to take a program written by someone
who knows nothing about hardware (at least, not yet).  The aim is to be
able to develop hardware acceleration for a given algorithm.  

One advantage of C-based languages is that when trying to accelerate an
algorithm, it might not be clear which parts to synthesise - this requiring
some trial-and-error for difficult problems, and also being dependent on
some rather arbitrary parameters.  It's easier to move a computation unit
from software to hardware, or vice-versa, if the languages are similar.
There's also a whole raft of software based optimisations that can be
applied before the hardware optimisations even get a look in.

Another, is that for some projects, a C simulation is developed to check the
algorithms anyway.  For example, Timothy Miller did a software model for
the OpenGraphics project.  The practise isn't uncommon.

>   Source snippets are important, because these solutions are not C, but
> C-based.  The devil is in the details....

For the reasons above, it is - in general - necessary to provide a compiler
with some pragmas or other hints that describe what code would be a good
candidate for synthesis.

However, the solutions are often close enough to C that it's possible to
execute the program entirely in software, as well as compile to a
object code/bitstream target.  That's useful for the intended applications.

Nobody's pretending C-based synthesis is a complete replacement for HDL,
only that for some applications/projects it's a very compelling
alternative.

Martin


Article: 91340
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 3 Nov 2005 11:51:50 -0800
Links: << >>  << T >>  << A >>

Eric Smith wrote:
> Still, if you're going to use reconfigurable computing, surely each
> configuration is a hardware design, and much better expressed in a
> language optimized for hardware design, rather than a language optimized
> for strictly sequential operation.

Actually, Handel-C (Celoxica), Impulse-C (derivative of StreamsC), ASH,
SA-C, HarPE, Spark, and even FpgaC all take a subset of the language
and to various degrees present extensions to the language to be a
language optimized for hardware design, some much more rigorous than
others.

Celoxica's long term goal is to compete 1 on 1 with VHDL/Verilog and
they are doing pretty well at it so far.

Impules-C with it's VHDL backend is ment to take communication based
designs (AKA RPC or MPI or other cluster based communication library)
and use FPGA's as computing nodes with clearly defined streams to build
pipelined system designs. The use of the VHDL backend leaves lots of
room to optimized the resulting design at a low level.

SA-C and ASH are clearly targeting high performance designs, actually
large high performance designs, with the intent to get as good a
hardware fit as VHDL/Verilog or better by picking a specification
language higher than VHDL/Verilog and lower than a full C/C++ which is
highly optimizable to give a better design yield than mid-level
experienced coders would get with VHDL/Verilog. Actually all the C HLL
offerings pretty much share this goal of trying to do better than the
average VHDL/Verilog coder.

ASH and HarPE go after optimizations that even a skilled VHDL/Verilog
coder are likely to miss, or even decide to avoid in the effort to
leave the VHDL/Verilog code readable and maintainable.


Article: 91341
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 3 Nov 2005 12:15:30 -0800
Links: << >>  << T >>  << A >>

Martin Ellis wrote:
> This isn't about taking arbitrary C code and compiling it to an FPGA.
> You simply can't do that.

Actually you could, and in the future when a few million luts are
cheaper
than a fairly fast CPU, some people probably will by using mixed
technologies
inside the FPGA ... a combination of application specific cpu cores and
generic netlists. Already Xilinx is targeting that market with PPC
cores and
micro blaze cores as an addition to the FPGA logic synthesis.

> Another reason is that a compiler can't guess which inner loops are program
> 'hot-spots', and thus good candidates for synthesis.  Such information is
> application-domain specific.

Actually, that is only partially true. It's been common for some time
to use
profiler input from actual runs to guide the compiler optimations for
later builds.
This happens to be one sweet spot that lcc exploits to beat gcc and pcc
executables. See
http://www.cs.princeton.edu/software/lcc/doc/linux.html

> However, the solutions are often close enough to C that it's possible to
> execute the program entirely in software, as well as compile to a
> object code/bitstream target.  That's useful for the intended applications.

Actually, it's very easy to write C to the subset implemented by a
particular
C to netlist HDL, that with a few #ifdef's is usable in either
environment, and
can accellerate development testing and debugging by doing most, if not
all,
the high level debugging in a well structured source code debugging
environment.

Others take it a step farther, and use rigourous type checking combined
with
super "lint" tools that provide verifiable correct construction
checking. In a
lot of ways, the original C++ development was exactly that, and was
implemented
as a front end preprocessor for standard C which was specifically ment
to be
only lightly typed so that it was a productive low level systems
programming
language only marginally higher level than PDP-11 assembly language.

It's actually fairly easy to code in C++ with abstract types that
directly implement
(IE emulate) the abstract hardware types that would result after
synthesis to
yield a strict HLL development environment with strict typing and
verifiable
designs and still translate to a subset dialect of C (or Verilog) for
synthesis.

> Nobody's pretending C-based synthesis is a complete replacement for HDL,
> only that for some applications/projects it's a very compelling
> alternative.

Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
really have
that goal. Celoxica has very clear guidelines, just as VHDL and Verilog
have, to
allow the coder to understand just what registers and logic will be
instantiated.

When you stop and think about it ... there is very little difference
between the
coding syntax of Handel-C and a subset of Verilog.


Article: 91342
Subject: Re: Spartan-3E starter kit
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 3 Nov 2005 20:25:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:
...
> December is the month...

Which year ;-)

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 91343
Subject: Re: Spartan-3E starter kit
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 3 Nov 2005 21:30:46 +0100
Links: << >>  << T >>  << A >>
"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> schrieb im Newsbeitrag 
news:dkdroi$si4$1@lnx107.hrz.tu-darmstadt.de...
> Peter Alfke <peter@xilinx.com> wrote:
> ...
>> December is the month...
>
> Which year ;-)
>
> -- 
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Uwe,

December is the month every year, but its 2005 to get real
Christmas presents from Xilinx.

S3e is WAY best FPGA around, so if we have to wait a little
more lets try todo wait in piece, this goes more tomyself and
my kinda angry comments about s3e availability, I am sometimes
like a boy who wants its presents too early.

Antti 



Article: 91344
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Martin Ellis <me_ncl@hotmail.com>
Date: Thu, 03 Nov 2005 20:36:22 +0000
Links: << >>  << T >>  << A >>
air_bits@yahoo.com wrote:
> Martin Ellis wrote:
>> This isn't about taking arbitrary C code and compiling it to an FPGA.
>> You simply can't do that.
> 
> Actually you could, and in the future when a few million luts are
> cheaper than a fairly fast CPU, some people probably will by using mixed
> technologies inside the FPGA ... a combination of application specific cpu
> cores and generic netlists. Already Xilinx is targeting that market with
> PPC cores and micro blaze cores as an addition to the FPGA logic 
> synthesis. 

Um.  Go back to the self-modifying code example and you'll see that it can't
always work.  To some extent, I agree with you, but the programs *have* to
be sensible and well behaved (type safe to some extent).

And that excludes *arbitrary* C.

>> Another reason is that a compiler can't guess which inner loops are
>> program 'hot-spots', and thus good candidates for synthesis.  Such 
>> information is application-domain specific.

> It's been common for some time to use profiler input from actual runs to
> guide the compiler optimations for later builds.

Yes, I know about this technique, and I thought about mentioning it here,
but didn't for brevity.  I don't call that fully automatic though.  You
need to seed it with some appropriate test data.

>> However, the solutions are often close enough to C that it's possible to
>> execute the program entirely in software, as well as compile to a
>> object code/bitstream target.  That's useful for the intended
>> applications.
> 
> Actually, it's very easy to write C to the subset implemented by a
> particular C to netlist HDL, that with a few #ifdef's is usable in either
> environment, and can accellerate development testing and debugging by
> doing most, if not all, the high level debugging in a well structured
> source code debugging environment.

That's exactly what I'm arguing.  Why are you arguing with me?

<!-- Snip further stuff about type-safety and C++ -->

>> Nobody's pretending C-based synthesis is a complete replacement for HDL,
>> only that for some applications/projects it's a very compelling
>> alternative.

> Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
> really have that goal. Celoxica has very clear guidelines, just as VHDL 
> and Verilog have, to allow the coder to understand just what registers and 
> logic will be instantiated.

As far as I know, Celoxica's products and similar offerings only target
digital designs for FPGAs.  

I'm not aware of any C-based language that was intended to cover ASIC
manufacture, or that would cover, say the 'Standard VHDL Analog and
Mixed-Signal Extensions' for example.

I could be very wrong there, and I'd be interested to know if they do intend
to target those aspects of HDLs though, if you can point me at any
references.

> When you stop and think about it ... there is very little difference
> between the coding syntax of Handel-C and a subset of Verilog.

Sure.  The syntax is very similar, but syntax is normally the least
interesting part of a language.


Martin



Article: 91345
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 04 Nov 2005 09:42:51 +1300
Links: << >>  << T >>  << A >>
Robin Bruce wrote:

<snip>
> 
>>But if the intent is to take
>>high-level C developed by a software guy and have it map to hardware as
>>well as it runs on a DSP, well, I just think you'll leave a lot of FPGA
>>peformance on the table.
> 
> 
> Who said that's what we're trying to do? We're talking about high-level
> languages not so we can compile legacy code. We're doing it so we can
> rapidly infer reliable hardware using a more concise expression than
> that achieved using HDLs while paying a minimal price in lost potential
> performance.

Which has a lot in common with the ASM-HLL debates on microcontrollers.

The best solutions will come from a mix of tools
- but the sad reality is marketing dept drive is to push the hot new 
thing, as a silver bullet, and any suggestions or examples of mixing 
HLL/HDL, might be seen as admitting that their hot-new-thing is not 
actually the universal new tool....

There is another, more recent shift in FPGA's, which means
a 'Sea of DSP' deployed in the FPGA, and that is missing from
this link:
"Survey of C-based Application Mapping Tools for Reconfigurable Computing"
http://klabs.org/mapld05/program_sessions/session_c.html

  The HLL -> HDL path, misses the alternative of HLL -> FPGA Running HLL
amd the best tool set, will be one that allows a softer migration
between Opcodes and Registers.

  The next generation FPGA will be interesting to watch, as we are
steadily getting more coarse & complex blocks, in BlockRAM and
DSP-able blocks, with each release.
  This may outflank the efforts to create C -> registers ?

-jg


Article: 91346
Subject: use ppc405 on virtex-II pro
From: "Eric" <dasani8888@hotmail.com>
Date: 3 Nov 2005 12:49:13 -0800
Links: << >>  << T >>  << A >>
Does anyone have reference on how to use the second ppc405 in virtex-II
pro?
I'm trying to write an application on each ppc, and see how two
processors work together.
xilinx reference manual didn't talk about how to use the second ppc,
from what i read.
any pointer is appreciated. Thanks.

-Eric


Article: 91347
Subject: Re: Spartan-3E starter kit
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 04 Nov 2005 09:56:04 +1300
Links: << >>  << T >>  << A >>
Summary of this thread :

Peter Alfke wrote:

> I promised an answer. The digging took a bit longer...
> 
> The good news is that Xilinx has many thousands of S3e100 in TQ144, and
> hundreds in vq100 packages, as well as many S3500 in several packages.
> The bad new is that -today- these parts are still ES ("early silicon")
> which distribution hates to touch, because  the parts will become
> obsolete very soon, once the production version becomes available.
> 
> If you need them immediately, order them through your distributor or
> your Xilinx sales folks. And realize that "6 to 8 weeks" is often
> exaggerated.

Or the Xilinx web store ? - All that infrastructure, going to waste....

> 
> Production S3e100 and 500s are expected this month, and 1600 soon
> after. And the distis will love to sell them (which they consider their
> job, even in Europe !).

And they WILL be on the fast track to the Web-Store (surely?) ?

> 
> I have held the almost final version of the S3e500-based evaluation
> board in my hand. It is dynamite, loaded with features and peripherl
> circuits, compatible with a slew of inexpensive Digilent add-on boards.
> Availability starts in December. Well before that, there will be a
> business-card-size eval board, packaged in a DVD-case, meant as a
> super-low-cost S3e100 demonstrator.

"Well before" December is March, so I guess now we are in November,
i.e. "really close' to December, the info on that nice sounding
super-low-cost S3e100 demonstrator, is being posted on the web
as I write ?  - Photos, users manuals, actual Prices, usual stuff....

-jg


Article: 91348
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Fri, 04 Nov 2005 11:13:19 +1300
Links: << >>  << T >>  << A >>
Robin Bruce wrote:
> I think we have to accept that high-level languages are going to be the
> future for FPGAs. Not to say that HDLs will be replaced entirely, but
> they'll be largely supplanted by the HLLs. Algorithms are easier to

<snip>

> First generation tools are far from perfect, but they will see use
> because they significantly decrease development time. Your HLL-designed
> system may not be as efficient as the best possible VHDL design, but if
> it's good enough and you get to market months before the competition,
> you'll come out on top.

Or cynically speaking, we may just get bigger, faster and cheaper FPGAs, 
so that it doesn't really *matter* how efficient you are, merely that 
you're in the ballpark.  I think this has happened to a certain extent 
in the software world anyway...

Jeremy

Article: 91349
Subject: Re: I have received a job offer
From: "learnfpga" <learnfpga@gmail.com>
Date: 3 Nov 2005 14:22:21 -0800
Links: << >>  << T >>  << A >>
Hey Marco,
I dont even know the conversion rates in Italy. But in US with your
profile one can command anywhere from 60K-75K depending on location,
type of company, your ranking of school etc. This in Dollors so in
Euros it would be 50000Euros to 62000 Euro. Ofcourse a lot of other
factors come into picture but this is just a ball park figure I am
quoting. Good luck with the job.




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

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

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

Custom Search