EDK : FSL macros defined by Xilinx are wrong

[Marco]

I live in Italy.
I've a Laurea degree (equivalent to a Master of Science degree) in
Electronic Engineering with specialization in analog and digital integrated
circuits.

I have worked for about 1 year to develop a microcontroller based on
microblaze. It is a part of a test bench for industrial electric motors,
pump and engines.

I have developed the electronic system. A mechanical engineer has developed
the mechanical parts.

I have experience in developing opb peripherals, interfacing them to a
complete system.

I hope that these informations are enough.

Marco

 

[Jim Granville]

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

 

[Martin Ellis]

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

 

[Jeremy Stringer]

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

 

[learnfpga]

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.

 

[Ray Andraka]

Robin Bruce wrote:

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.



What tools would those be? I've yet to see a tool that will take C

code that has not been so badly bastardized that it no longer looks
much like C code and turn out even half decent hardware. All of them
require proprietary extensions to the C language to sufficiently
describe hardware, as well as a very specific and stilted programming
style that is as foriegn to C programmers as VHDL or verilog is.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[seb_tech_fr]

Yes, it's a very good idea... if it works !! :lol:

dcm.pdfwrote:
If only the DFS outputs are used (CLKFX & CLKFX180), this status

bit will not go

high if CLKIN stops.

That means, I have to use the clock CLKFX or CLFX180 somewhere in my
design :?

I will try ..

Thanks everybody.

I will give results in a few days...

Ben Gwrote:
Hi,

there are a couple of general control signals for the DCM, i.e.
STATUS[7:0], one of which STATUS[1], indicates if CLKIN is stopped.

I've never used this myself and I'm not sure if it will be of help
to
you but there's more details in the V2Pro platform handbook should
you
need it.

Good luck,
Ben.

seb_tech_fr wrote:
Hi !
I need advice to build a very small firmware which will detect if a
clock signal is active or not.
Indeed, My FPGA (V2Pro) is connected to other devices/boards and
receives a clock signal. However, this clock signal is not active
at
the begining and I would like to inform other devices/boards if
clock
signal is ready or not.

My question is : How can I do to know if a signal clock is active?

I thought to implement a counter driven by this clock. But this
will
not ensure me that signal is a clock at X MHz.

May I use a DCM, and look at the LOCKED signal?

All ideas are welcomed.


Thank you.

 

[Peter Alfke]

Marco, do not automatically assume that we all live in the same global
village.
Salaries differ from country to country, often by a factor of 2 or
more.
American and Italian salaries are probably quite different. They even
differ within the US.
Ask some italian engineering friends or organizations. They may have a
more realistic opinion.
Peter Alfke

 

Ray Andraka wrote:

What tools would those be? I've yet to see a tool that will take C
code that has not been so badly bastardized that it no longer looks
much like C code and turn out even half decent hardware. All of them
require proprietary extensions to the C language to sufficiently
describe hardware, as well as a very specific and stilted programming
style that is as foriegn to C programmers as VHDL or verilog is.

Which is very true, Celoxica being a prime example as code written for
their target as an HDL would be very tough to get to run on a RISC/CISC
machine and do anything meaningful.

You have to move up the food chain to a C++ design with heavy operator
overloading before you can get close to having the same source target
both enviroments if you are going to introduce HDL features into C. Std
C
just lacks the native types that get introduced with HDL features in
Handel-C.

SO, that leaves two distinctly different camps each tring to use the
same or
similar tools for two opposite goals ... the HDL guys designing
hardware, and
the reconfigurable computing guys just trying to gain a faster
computing platform
with FPGAs.

Personally, I'm comfortable with using VHDL/Verilog for HDL and a
fairly generic
C to netlist tool (FpgaC) for general reconfigurable computing, and a
mix of tools for gluing
projects togather (SoC's).

The which HDL is better debate is pretty much preference and
requirements based,
and impossible to win as a general case.

I do think we will see HLLs that target particular techologies that are
well defined and
difficult to easily code ... the whole pipelined data path problem for
distributed arithmetic
and filters is already shaping up that way with core generators (which
are in fact simple
forms based HLLs).

 

[Benjamin Ylvisaker]

On 3 Nov 2005 12:15:30 -0800
air_bits@yahoo.com wrote:

Martin Ellis wrote:
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.

If by ASH you mean the application specific hardware project run by
Seth Goldstein and Mihai Budiu (until he graduated) at CMU, then you
have gotten the wrong impression. I spent a semester in that research
group, and they most certainly do not intend to replace HDLs with C.
They have developed some very interesting compiler technologies that
can generate surprisingly efficient circuits from nearly arbitrary C
code, but even they wouldn't claim that C is an appropriate
replacement for HDLs in all cases. They are spinning their compiler
as a tool that can be used by many more people than traditional HDL
synthesis tools, but the quality of the circuits they produce is still
far from optimized HDL-based designs.

Benjamin

 

[Marco]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...

Marco, do not automatically assume that we all live in the same global
village.
Salaries differ from country to country, often by a factor of 2 or
more.
American and Italian salaries are probably quite different. They even
differ within the US.
Ask some italian engineering friends or organizations. They may have a
more realistic opinion.
Peter Alfke

I'll do it.

Many Thanks to everyone has replied.
Marco

 

[Ben G]

Hi Sebastien,

If only the DFS outputs are used (CLKFX & CLKFX180), this status
bit will not go high if CLKIN stops.

My reading of that would be that as long as you are not using CLKFX or
CLKFX180 then it should work, i.e. use any of the DLL outputs such as CLKO.

That means, I have to use the clock CLKFX or CLFX180 somewhere in my
design :?

You can check this but as above I would say it's the opposite to this.


Good luck,
Ben.

 

[Luis Vaccaro]

I'm Italian and here salaries are very low, I think that 3000 ? /month will
be very hard to get, may be 2000 ? will be very good in Italy....


in bocca al lupo!

--
Luis Vaccaro


"Marco" <marcotoschi@nospam.it> wrote in message
news:dkf5p6$j2p$1@nnrp.ngi.it...

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...
Marco, do not automatically assume that we all live in the same global
village.
Salaries differ from country to country, often by a factor of 2 or
more.
American and Italian salaries are probably quite different. They even
differ within the US.
Ask some italian engineering friends or organizations. They may have a
more realistic opinion.
Peter Alfke


I'll do it.

Many Thanks to everyone has replied.
Marco

 

[Luis Vaccaro]

? = euro, problems with unicode...

--
Luis Vaccaro


"Luis Vaccaro" <lvaccaro@hotmail.com> wrote in message
news:436b2e93$0$6018$4fafbaef@reader4.news.tin.it...

I'm Italian and here salaries are very low, I think that 3000 ? /month
will
be very hard to get, may be 2000 ? will be very good in Italy....


in bocca al lupo!

--
Luis Vaccaro


"Marco" <marcotoschi@nospam.it> wrote in message
news:dkf5p6$j2p$1@nnrp.ngi.it...

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...
Marco, do not automatically assume that we all live in the same global
village.
Salaries differ from country to country, often by a factor of 2 or
more.
American and Italian salaries are probably quite different. They even
differ within the US.
Ask some italian engineering friends or organizations. They may have a
more realistic opinion.
Peter Alfke


I'll do it.

Many Thanks to everyone has replied.
Marco

 

[Robin Bruce]

Ray,

OK, maybe I should rephrase what I said, reading it again myself I
don't quite agree with it . What I meant was that there are tools out
there that can map HLL well to hardware. I didn't mean to suggest that
they are ANSI C. I realise it's a bit of an abuse of the language to
describe these things as C, but I tend to describe the C-inspired
languages of these tools as C, and talk about ANSI C when I want to
make it clear I'm talking about canonical C.

It does seem that most of the tools out there are extensions to C. I
should say at this point that I've never used any of the tools that
have been discussed so far on this board, so I'll leave it to someone
else to talk about how close they are to C. I'm a research engineer
based in Nallatech, and I've been working with a tool being developed
there, DIME-C. I can safely say that DIME-C is to all intents and
purposes a subset of C, so everything you do in it can be compiled with
a gcc compiler. You can't have pointers, and you have to go round the
houses sometimes to avoid breaking your pipelines, but it's definitely
recognisable as C. If anyone is particularly interested, I could send
them some examples of the code. I don't want to bring DIME-C into the
debate though, I'm interested in finding out more about what's out
there, rather than in doing marketing

Cheers,

Robin

 

[Robin Bruce]

Jim,

I agree with you about the value of mixing and matching HLL and HDL
solutions in your system. You might want to design the core of your
algorithm using an HLL tool, then link it up to control and memory
systems that you've designed using HDL.

I also can see the constant changing of the underlying hardware as
being a challenge to those who are developing C-to-hardware tools. I
think perhaps it favours those who target their systems at a single
architecture, like SRC with their Carte programming environment.
HandelC has seen a lot of real success, the most notable in my mind is
it being used in an effort by Lockheed Martin to create a space system
to dock with Hubble
(http://klabs.org/mapld05/presento/220_feifarek_p.ppt). My
understanding of HandelC is that the basic package contains generic HDL
routines for the common operations (data array storage and retrieval,
fixed-point multiplication etc.) bu the user is given the option to
supplement this with implementation specific routines. So in Xilinx
V-II this would be BRAMs for data array storage and use of the 18x18
multipliers for the fixed-point stuff.

With each new generation of FPGA, you'll need to update your underlying
library routines. As I recall Peter Alfke saying at this year's FPL, to
get the best out of FPGAs, you need to target your architectures,
generic just won't cut it (apologies to Peter if that's not what he was
getting at).

So I guess I agree with you Jim, in that C -> registers is not the best
approach.

Apologies for my ignorance, but can I ask you to expand on "alternative
of HLL -> FPGA Running HLL amd the best tool set". I wasn't sure what
you meant.

Cheers,

Robin

 

[Falk Brunner]

Antti Lukats schrieb:

Why Spartan-3e is the best
==================
Antti Lukats
4.Nov 2005

[snipped Lord's prayer]

Amen, Reverend Atti.
Is it possible that you are obsessed by S3E??
C'mon, life goes on with and without S3E!!
There other things that are important. Even in an engineers life, right?

Just my two(euro)cents
Falk

 

[Antti Lukats]

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb im Newsbeitrag
news:3t3o7bFr3hddU1@individual.net...

Antti Lukats schrieb:

Why Spartan-3e is the best
==================
Antti Lukats
4.Nov 2005

[snipped Lord's prayer]

Amen, Reverend Atti.
Is it possible that you are obsessed by S3E??
C'mon, life goes on with and without S3E!!
There other things that are important. Even in an engineers life, right?

Just my two(euro)cents
Falk

Hi Falk,

sure! Like going to movies with the family.
"Little Ice-bear II" is on our family menu this afternoon,
when Anna (2 years) wakes up from beaty sleep we go.

Antti

 

Kolja Sulimma wrote:

But apparently all those highly trained clever software engineers can
not be bothered to learn another language. At least this argument
allways comes up at that point. (Maybe I can find an engineer in india
that is still capable of learning?)
So if your really need C-syntax as many believe - I don't - at least use
a modern C derived language that is easier to compile.
With java essentially only the "new" operated is a problem. With C, well
look at the System-C restrictions.

Open source know no boarders, no race, no religion, no ethnic, no
political, no barriers to who can contribute to the world.

Since you KNOW the answer, share it. We will be looking for your
work on sourceforge, and your announcement here. Good ideas which
are never realized, always ways worthless failures.

On the other hand: What's so hard about dynamic allocation? Tell the
designer that it will be slow, and if he uses it simply synthesize to a
microblaze implementation. You will not meet the timing constraint, but
it can be synthesized.

Good designs have excellent space time tradeoffs. CPU cores are large,
and take you right back to serial execution with poor parallelism, that
in
many cases would have been done better with a VLSI cpu, either as a
hard core, or external device. Likewise, pointer based memory takes
you right back to serial access of that memory as a critical path
resource. Dynamic allocation is implicitly serial by design.

Or even use profiling to find a typicall number of allocated objects and
create them in hardware. If more are used halt execution. That is
exeactly what a sequential processor would. You can't call malloc a
billion times in C and maybe you can not call it 16 times in hardware C.
It is the same type of constraint that is not imposed by the language
but by the implementation fabric and the designer needs to know the
capabilities of his system before implementing.

A language designed around dynamic allocation of objects and classes
is implicitly unusable if limited to 16 such allocations, if only
trivial
code body invocations can be realized.

The multiplexors to emulate a memory pool of statically allocated
objects
are both huge and implicitly serial once hazzard free for conncurrent
access.
This takes us right back to poor space time tradeoffs and a lack of
implict
parallism that static objects offer.

Obviously you see right past these problems, and we are waiting for
your
magic to be realized as a much better language offering on
sourceforge.net.

Since the programmers in India are by your assertion superior, please
show
us by results, and time may prove you right.

 

[John_H]

"The RPM cannot have shift registers or distributed CLB SelectRAM
(single port or dual port) in both odd AND even RLOC columns. The
SLICEL has a lookup table that's logic only while the SLICEM has LUTs
that can be loaded and read as a single port memory, a dual-port memory,
or a shift register."

So 1) find all your memory elements, and 2) move them around so they're
either all in even RLOC columns or they're all in odd RLOC columns.

This will allow all you memory elements to be RLOCed into SLICEM slices.

- John_H


Andrew Lohbihler wrote:

Thanks John,

The code did work for a Virtex-II and the details of the packing don't
indicate which column constraint was used. Any idea what constraint should
be changed to make it work in a Virtex-4? There must be a way to tweak the
design for the V4 to make it pack similarily as a V2. Any help will do.

Thanks,
Andrew

"John_H" <johnhandwork@mail.com> wrote in message
news:YMQaf.57$Ge6.296@news-west.eli.net...

Unlike earlier Virtex family devices, the Virtex-4 has half the slices
allowed as memory-capable. The RPM cannot have shift registers or
distributed CLB SelectRAM (single port or dual port) in both odd AND even
RLOC columns. The SLICEL has a lookup table that's logic only while the
SLICEM has LUTs that can be loaded and read as a single port memory, a
dual-port memory, or a shift register.

If the RPM was done for a project in a Virtex-IIPro or older device,
you'll need to tweak it for the "odd or even column only" constraint of
the Virtex-4. If your RPM is fresh for this design, simply reconfigure it
for the constraint you now know is getting in your way.

- John_H