EDK : FSL macros defined by Xilinx are wrong

Rene Tschaggelar wrote:
Why are those guys so keen on C ? Suggesting compatibility with
something while having least readability ?
Click to expand...
air_bits@yahoo.com writes:
The description at the project page pretty much says it all:

"C provides an excellent alternative to VHDL/Verilog for algorithmic
expression of tasks targeting FPGAs for reconfigurable computing."
Click to expand...
That doesn't explain *why* it's an excellent alternative. I can just
as easily state that "C provides a terrible alternative to VHDL/Verilog
for algorithmic expression of tasks targetting FPGAs for reconfigurable
computing". So why is their statement any more accurate than mine?
 
air_bits@yahoo.com writes:
One of the interesting parts of FpgaC is that

int VeryWideInt:512;

will build a 512 bit plus sign integer ... which doesn't make a very
fast counter, as the carry tree is pretty slow, but you get the
precision asked for.
Click to expand...
Why is that any better than

VeryWideInt: unsigned (511 downto 0);

in VHDL? I expect that this can just as easily be expressed in Verilog,
too.
 
I'm interested on this point, too. If the core is provided as source, the
synthesis will probably handle the conversion well. If the core is an .ngo
file like the Xilinx alternative, the Xilinx mapper ends up making the
supstitution and the synthesis tool (SynplifyPro in my case) is stymied
because the black box for the core doesn't have the information to allow the
tristates in the core to be converted so the total conversion falls apart.


"Eric Smith" <eric@brouhaha.com> wrote in message
news:qhsluelmll.fsf@ruckus.brouhaha.com...
Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com> writes:
If the number we presented is not satisfactory, we have several
ideas to reducing the LUT count such as:

* Using multiplexer instead of internal tri-state buffers for
configuration register part of the PCI IP core

Will that help? Don't the synthesis tools translate use of tri-state
buffers into multiplexers on most of the newer Xilinx FPGAs anyhow,
since the parts don't have actual tri-state buffers?
Click to expand...
 
Eric Smith wrote:
air_bits@yahoo.com writes:
One of the interesting parts of FpgaC is that

int VeryWideInt:512;

will build a 512 bit plus sign integer ... which doesn't make a very
fast counter, as the carry tree is pretty slow, but you get the
precision asked for.

Why is that any better than

VeryWideInt: unsigned (511 downto 0);

in VHDL? I expect that this can just as easily be expressed in Verilog,
too.
Click to expand...
I can build them at a schematic level too, so why is any HDL better?

I can even wire them out of TTL so why is using an FPGA better?

Heck, I can even wire them out of diodes or vacumn tubes, ....

So why waste people time bitching about others preferences, and the
tools
they use to implement them. If you like VHDL, certainly use it.

have a nice day ;)
 
air_bits@yahoo.com writes:
I can build them at a schematic level too, so why is any HDL better?
I can even wire them out of TTL so why is using an FPGA better?
Heck, I can even wire them out of diodes or vacumn tubes, ....

So why waste people time bitching about others preferences, and the
tools
they use to implement them. If you like VHDL, certainly use it.
Click to expand...
I'm not the one claiming that any particular HDL is better than
another. But I'm trying to understand the hype about using C as
an HDL. Where is the actual benefit?
 
Eric Smith wrote:
Rene Tschaggelar wrote:
Why are those guys so keen on C ? Suggesting compatibility with
something while having least readability ?

air_bits@yahoo.com writes:
The description at the project page pretty much says it all:

"C provides an excellent alternative to VHDL/Verilog for algorithmic
expression of tasks targeting FPGAs for reconfigurable computing."

That doesn't explain *why* it's an excellent alternative. I can just
as easily state that "C provides a terrible alternative to VHDL/Verilog
for algorithmic expression of tasks targetting FPGAs for reconfigurable
computing". So why is their statement any more accurate than mine?
Click to expand...
There are a few hundred thousand engineers on the planet that can
express large complex algorithms in C, and a few tens of thousands of
engineers that can express large complex algorithms in VHDL/Verilog,
and probably a few thousand that can actually grasp the test vector
space and simulation effort necessary to actually get a large
VHDL/Verilog design working for large complex alogoritsms. So access to
design talent is one.

There are clear advantages to being able write, test, and debug large
complex algorithms on a traditional processor with a source code
debugger and moving the nearly finished product to FPGAs for deployment
and performance. So access to advanced software development tools is
two.

The embedded logic analyzer cores are a very poor subsitute when
debugging complex algorithms with lots of state and data.
 
Eric Smith wrote:
That doesn't explain *why* it's an excellent alternative. I can just
as easily state that "C provides a terrible alternative to VHDL/Verilog
for algorithmic expression of tasks targetting FPGAs for reconfigurable
computing". So why is their statement any more accurate than mine?
Click to expand...
There are probably a few hundred billion statements of C/C++ IP for
designs which
contain easily reusable code segments (IE cores) in nearly every
application
area. Probably a few trillion, when you include privately held IP in
addition
to what is on SourceForge and other open source depositories.

I suspect, the total IP coded in VHDL/Verilog is three to four orders
of magnitude less.

So that is three reasons why C can be an excellent althernative for
reconfigurable computing projects, and for the home hobbyist that
already knows C and would like to use an FPGA for a reconfigurable
platform for their robotic or other project.
 
air_bits@yahoo.com wrote:
Eric Smith wrote:

That doesn't explain *why* it's an excellent alternative. I can just
as easily state that "C provides a terrible alternative to VHDL/Verilog
for algorithmic expression of tasks targetting FPGAs for reconfigurable
computing". So why is their statement any more accurate than mine?


There are probably a few hundred billion statements of C/C++ IP for
designs which
contain easily reusable code segments (IE cores) in nearly every
application
area. Probably a few trillion, when you include privately held IP in
addition
to what is on SourceForge and other open source depositories.

I suspect, the total IP coded in VHDL/Verilog is three to four orders
of magnitude less.

So that is three reasons why C can be an excellent althernative for
reconfigurable computing projects, and for the home hobbyist that
already knows C and would like to use an FPGA for a reconfigurable
platform for their robotic or other project.
Click to expand...
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 ?

I presume a mixed-language design is possible ? - an example of that
as well, would assist understanding.

Otherwise, it's all arm-waving.....

-jg
 
Eric Smith wrote:
I'm not the one claiming that any particular HDL is better than
another. But I'm trying to understand the hype about using C as
an HDL. Where is the actual benefit?
Click to expand...
You have it backwards. The intent is not to use C for hardware design,
but to use FPGA's for computing. There is a grey area in between, but
the view point is from completely different ends of the problem design
space.
 
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 ?

I presume a mixed-language design is possible ? - an example of that
as well, would assist understanding.

Otherwise, it's all arm-waving.....
Click to expand...
Most applications of reconfigurable computing are not hardware design
applications, so any pure HDL may be the wrong tool, as it's design
focus
is at the gate/register level.

Reconfigurable computing is about taking tranditional C/C++
applications and pushing the resource intensive parts into net lists
for a performance gain ... frequenly as much as 200 times the fastest
RISC/CISC processors by removing memory latency and ALU pipelines (both
of which are serial resources) from the critical path.

Moving the front end of web servers, router/classifier logic and TCP/IP
stacks into several large FPGA's ... VertexII-Pro's with rocket IO's
and PPC backend engines is one example. These applications are already
written in C, and get married to the external hardware with logic
typically written in VHD/Verilog.

Likewise, most protocol converters which interface different fibre
connections are freqently being pushed into fpga's to maintain wire
speed operation.

Mixed C, VHDL, Verilog, and schematic are all very likely. C is just
one
more implementation tool.
 
air_bits@yahoo.com writes:
There are a few hundred thousand engineers on the planet that can
express large complex algorithms in C, and a few tens of thousands of
engineers that can express large complex algorithms in VHDL/Verilog,
Click to expand...
Of those few hundred thousand that know C, very few have any clue how
to design hardware. If you turn them loose with C as an HDL, you're
going to end up with really crappy hardware, just like when programmers
are thrust into Verilog or VHDL.

It's not knowledge of the syntax of a particular language that's the
problem. The semantics of hardware design are fundamentally different
from the semantics of sequential software design.

and probably a few thousand that can actually grasp the test vector
space and simulation effort necessary to actually get a large
VHDL/Verilog design working for large complex alogoritsms.
Click to expand...
Are you claiming that test vectors and simulation aren't needeed when
using C as an HDL? I'd be very skeptical of any such assertion.

The embedded logic analyzer cores are a very poor subsitute when
debugging complex algorithms with lots of state and data.
Click to expand...
What's that got to do with your choice of HDL? If you want to know
what's going on inside your FPGA, that's not fundamentally any easier
with C as your HDL than it is with Verilog or VHDL.

Eric
 
air_bits@yahoo.com writes:
You have it backwards. The intent is not to use C for hardware design,
but to use FPGA's for computing. There is a grey area in between, but
the view point is from completely different ends of the problem design
space.
Click to expand...
You're right, I wasn't aware of that distinction.

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.

Eric
 
Xilinx has IP that you could evaluate (yes, it costs $, but I believe there
is a free evaluation license which should be available.)

We have used it in the past. (Both evaluation and $ license.)

JTW
<atarynka@gazeta.pl> wrote in message
news:1130533636.244872.199890@g43g2000cwa.googlegroups.com...
I am looking for a program / a website / or anything that would allow
me to verify Reed Solomon code that my FPGA generates. Any help will be
greatly appreciated.

Regards,
Wojciech Toczynski
Click to expand...
 
air_bits@yahoo.com wrote:

Rene Tschaggelar wrote:

Why are those guys so keen on C ? Suggesting
compatibility with something while having least
readability ?

Rene


The description at the project page pretty much says it all:

"C provides an excellent alternative to VHDL/Verilog for algorithmic
expression of tasks targeting FPGAs for reconfigurable computing."

Project page at http://sourceforge.net/projects/fpga

The object is to use FPGAs as computing engines, and less concerned
about how to describe circuits in an HDL for synthesis, as most
hardware designers would with VHDL or Verilog. VHDL and Verilog are the
rough equivalent of programming in assemenbly language, as the
implementation languages are directly expressing clocks, registers and
wires which adds a tremendous design state factor and skill level in
their use.

Simplifed C to netlist compilers, such as FpgaC are attempting to hide
most of synthesis details, to ease the design burden for hardware
implementations of applications which have rich algorithmic complexity.
These applications range from doing network stacks in FPGAs for wire
speed performance at gigabit rates, to richly parallel algorithms such
as searching which are performance limited by the serial nature of
traditional CPU/Memory architectures.

FPGAs in this decade are simply building blocks for high performance
computing,
not just a dense PLD to express hardware funtions for the logic
designer.
Click to expand...
Thanks. It is a pitty that C was chosen. The choice
of C means some guys want to adhere to a standard,
instead of flexibly adapt to the problems ahead.
There should be a way to tell the compiler how
quick I want to have an operation. Do I want a one
cycle result with an enormous loockup table, do I
want an N-digit multiply accumulate loop, do I
want an NlogN solution or is it even less important.
Is this being solved by a bunch of #pragma ?

I'd be interested in the first floating point unit
coming out of such a compiler.

Rene
 
Much as Peter has said..

Two methods..

one is to run a second timer and compare results... you can get to ppm
accuracy then provided you reference is accurate enough. We do this to
check serial clocks against a 25 ppm reference.

Another is to use a simple RC filter on a couple of pins from the FPGA...
note that it is important that the centre tap is connected by a C to the
FPGA... so that if the FPGA remains inactive either high or low it will have
no effect. I've also done this for a rough is the clock 16 MHz or not .. 8
Mhz turn on/off or there abouts .. not very accurate but it wasn't
necessary.

Simon

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1130967597.327071.315120@g47g2000cwa.googlegroups.com...
This is easy if you have a continuously-running clock somewhere.
If you don't, you can easily detect when the clock starts for the first
time after power-on ( have the clock advance a 2-bit counter that you
had reset during power-on.)
But if you also want to detect if the clock has diappeared later on,
you need some timing element somewhere.
There is no mystery, it's all very logical, and your sharp Gallic
analytical mind will understand that...
Cheers
Peter Alfke, Xilinx
Click to expand...
 
HDL has a benefit that you can include abstract ideas in your FPGA. That's
why HDL is better.

I can also see the point of using C as a base language... But I can just
imagine the latest windows.. instead of crashing once a week..it now crashes
every mili second :).. Poor software is still poor software... C isn't
typed strong enough to use with out adding other tools, so it would be at
the bottom of my list of recommended software. Also anything you create in
C you will need to be able to verify. Failing to do so will only lead to
hours and hair loss.

Pascal would have been a better choice IMO.

Simon


"Eric Smith" <eric@brouhaha.com> wrote in message
news:qhfyqelkvf.fsf@ruckus.brouhaha.com...
air_bits@yahoo.com writes:
I can build them at a schematic level too, so why is any HDL better?
I can even wire them out of TTL so why is using an FPGA better?
Heck, I can even wire them out of diodes or vacumn tubes, ....

So why waste people time bitching about others preferences, and the
tools
they use to implement them. If you like VHDL, certainly use it.

I'm not the one claiming that any particular HDL is better than
another. But I'm trying to understand the hype about using C as
an HDL. Where is the actual benefit?
Click to expand...
 
Simon Peacock wrote:
HDL has a benefit that you can include abstract ideas in your FPGA. That's
why HDL is better.

I can also see the point of using C as a base language... But I can just
imagine the latest windows.. instead of crashing once a week..it now crashes
every mili second :).. Poor software is still poor software... C isn't
typed strong enough to use with out adding other tools, so it would be at
the bottom of my list of recommended software. Also anything you create in
C you will need to be able to verify. Failing to do so will only lead to
hours and hair loss.

Pascal would have been a better choice IMO.
Click to expand...
Or Modula-2, or IEC 61131, ... or even better, something like :


http://research.microsoft.com/fse/asml/
"AsmL is the Abstract State Machine Language. It is an executable
specification language based on the theory of Abstract State Machines."

-jg
 
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 ?
Click to expand...
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'.

They point to one of their own references that describes the
implementation, but I guess you'd probably need to ask them for the
resulting source.

I guess Celoxica can probably give you some references to C-based examples
too.

Note that this sort of example is a more likely application in the HPC
community rather than the hardware design community per se.

Martin
 
Thomas Reinemann wrote:

FPGAs offer massive parallelism, therefore only
application/problems which utilize this parallelism should be
implemented in FPGAs. They are all a kind of communication system or
signal processing system.
Click to expand...
All? Perhaps you should read these for other high-performance computing
applications that can be accelerated using FPGAs:

@MISC{compton00reconfigurable,
author = {K. Compton and S. Hauck},
title = {Reconfigurable Computing: A Survey of Systems and Software},
year = {2000},
text = {K. Compton, S. Hauck, Reconfigurable Computing: A Survey
of Systems and Software, submitted to ACM Computing Surveys, 2000.},
url = {http://citeseer.nj.nec.com/compton00reconfigurable.html},
}

@ARTICLE{hauck98roles,
author = {Scott Hauck},
title = {{The Roles of FPGAs in Reprogrammable Systems}},
journal = {Proceedings of the IEEE},
year = {1998},
volume = {86},
number = {4},
pages = {615--638},
month = {Apr},
url = {http://citeseer.nj.nec.com/hauck98roles.html},
}

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
Click to expand...
Isn't that what people said about assembly language? And GOTO statements?

So that is three reasons why C can be an excellent althernative for
reconfigurable computing projects, and for the home hobbyist that
already knows C and would like to use an FPGA for a reconfigurable
platform for their robotic or other project.

Never, since most of them think in sequential algorithms and don't
understand the advantages of hardware.
Click to expand...
Yawn. I wonder when people from traditional hardware design backgrounds
will get over this kind of attitude.

So what if some hobbyists don't 'get' it at first? People aren't born
hardware designers, nor software programmers. Are you really saying you've
never made any mistakes while you were learning?

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

Martin
 
You have not given anywhere near enough info to even hazard a guess.

Where you live, where the jobs is, your education, experience, .... are all
HUGE factors in this.


"Marco" <marcotoschi@nospam.it> wrote in message
news:dkcud4$r16$1@nnrp.ngi.it...
Hallo,
I would have a suggestion about.

The job consist in: developing a microprocessor based system for data
acquisition.

I have begun working with fpga about 1 year ago. I have developed some opb
peripherals and a microcontroller based on microblaze.

How much could I ask as monthly wage?

Many Thanks
Marco
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top