EDK : FSL macros defined by Xilinx are wrong

[Tim Wescott]

Marko wrote:

Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?

Dunno if it's appropriate, but I see it called that in many places.
"FPGA configuration file" is probably best, but that makes managers'
eyes cross. Call it "firmware" and it sounds safely familiar.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

 

[Falk Brunner]

mk schrieb:

VHDL may "produce" hardware when doing ASIC design.

So what do you call a gate array or structured asic ? What does VHDL

This is an ASIC too, just with a reduced number of user defined
parameters (since most geometries are already fixed).

do when it generates files for one of these processes ? (for the
uninitiated gate-arrays or structured asics in general have all their
base layers produced already and several metals are used configure the
manufactured general purpose gates to what you want and provide the
connectivity).

Yep.

By the same token when you take a bit file generated for an FPGA and
use it to produce a hard-copy device (a structured asic specifically
generated for a certain FPGA family) does the VHDL suddenly realize
that it has produced hardware ? What does this say for laser trim or

There is always an exeption to every rule ;-)

metal only ECO ?
Also is an Intel or AMD processor really hardware as they have
micro-code which can be downloaded by BIOS which can be used to fix
quite a bit of "issues" with the processor.

SoC ;-)

In an FPGA not a single bit is "produced", all is fixed.


So the function of each LUT and how they are all connected are fixed
and the VHDL doesn't produce anything ? What does it do then ? If in

Neither did I not write this nor did I say this. Nevertheless,
incomplete quotes are quite popular.

my standard cell design, I have memory based FSMs the function of
which can be changed by updating the contents of such, does my asic
become software ? What about external pins which can change the

The chip will stay an ASIC. But you can (and will) download firmware.

behaviour of combinational FSMs ?

;-) C'mon.

I think the issue is a lot less clean-cut then is suggested here.

Maybe. Thats why we are here to discuss. Or to argue. Or to get into
philosopy. The last works a lot better with a nice bottle of red wine ;-)

Regards
Falk, taking this "issue" not too serious, since it is quite academic

 

[James Morrison]

On Mon, 2006-02-20 at 10:18 -0800, Marko wrote:

Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?

In a former position I pondered this very question.

What is firmer than firmware (the term they used to describe code
designs for micro-controllers) but softer than hardware (designs using
wires to connect together various components)?

The answer I came up with was "stiffware".

The problem is that there are elements of both in FPGA code, or at least
there can be. And depending on how you write your VHDL it may resemble
one more than the other.

James.

 

[Jan Panteltje]

On a sunny day (20 Feb 2006 11:55:08 -0800) it happened "Jordi"
<a80x86@hotmail.com> wrote in
<1140465308.468125.76070@z14g2000cwz.googlegroups.com>:

Hi,
thanks to all for the answers !!! (and sorry for my bad english
)

I think I'm begining to understand how it works.

If the monitor uses PLL then the HSync frecuency determines how fast
the monitor moves the beam.So if I increase the HSync frecuency the
active time is shorter(and the back and front porch) but I can draw
more lines per second so I can have better resolutions. I don't
understand how resolution control works. The monitor has a fixed number
of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images
and the monitor must draw 1024 pixels per line and 768 lines, then some
pixels will be repeated. Isn't it?

Yes in an analog monitor there will be an 'aliasing' effect.
Some LCD monitors and TVs will use digital processing to recalculate the picture
for the resolution these themselves have.
In such a case the timing requirements for the input format may be more strict,
like for example a specific TV standard.

In an analog monitor it is very possible to have 'half a pixel' on (if enough bandwidth):

-- -- -- -- -- -- -- -- -- shadow mask
--- --- --- --- --- --- --- video signal
This 'half on' gives a brightness change at that pixel location.

The intensity of the ascanning electron beam is just modulated by the video.

In a LCD this is not the case, but the pixel brigtness can be corrected accordingly by
processing.

 

Julian Kain wrote:

The difference is execution versus synthesis. Firmware is indeed
embedded and dedicated code, but the code is executed. FPGA code is
written in a _description_ language, is then interpreted, synthesized,
and ultimately produces hardware.

So, for Reconfigurable Computing, where we compile C directly to
netlists to execute certain algorithms with high degrees of
parallelism, use a sea of logic resources as a universal computer
architecture, .... it's hard to consider the resulting fpga "design"
(AKA program) either hardware or firmware.

There is a reason I call FpgaC an HDL, and move it's syntax and use to
mainstream computing (rather than leave it in it's original HLL focus
when it was TMCC). But that really is true of other C compilers that
target some C subset/superset HLL/HDL's such as Handel-C (Celoxica) or
Streams-C (Impluse-C) as well. Some people use
FpgaC/Handel-C/Streams-C to design "hardware" some just use it to run
"software" on FPGA's.

For that mater, the same is true of VHDL, Verilog, JHDL, and some dozen
other FPGA centric HDL/HLL tools.

 

Falk Brunner wrote:

What code? The source code (VHDL/Verilog/whatever) or the final
bitstream? The same distinction applies to microprocessor "Firmware",
where you have the source code and the compiled binary.
Hmm, the more I write and think about it (where it should be better the
other way around ;-) FPGA and microprocessor bitstreams are becomming
more and more similar "Firmware".

Enter dynamic reconfigurability, and it's not even "firmware" any more
.... not hard locked in even a rom for many designs. More like a solid
state disk, IE compact flash card, used has the primary storage in many
portable computer devices, and a growing number of not so portable
devices, to avoid hard drives. Sometimes, with even network driving
dynamic loading, where all that is "rom'd" is a "boot loader", and the
rest of the design is fetched off the net at powerup.

 

soar2morrow@yahoo.com wrote:

FPGA code is logic, not programmable
instructions (spare me comments on the Micro-Blaze and its ilk).
Personally, I would like to see a different term beause non-FPGA people
will think that you are talking about a general purpose programmable
computer. How about "coreware"?. Don't like it? Then invent your own.

FPGA code USED TO BE (some ten or more years back) only a hardware
designer accessable logic resource, that you *MIGHT* class as "not
programmable instructions".

The reality is (for the last 10 years) C compilers have compiled to
netlists to execute HDL algorithms and programs directly on FPGA's.
When Reconfigurable Computing was proposed, and researched over a
decade ago, we also saw various HLL compilers targeting FPGA netlists
as execution resources. TMCC is just one of many, and reciently it
rebirthed at FpgaC. Handel-C, Streams-C, and nearly a dozen others,
have also since appeared. Several are here to stay, some are lost
research projects.

C language code, is a combination of "logic" and "data path"
representations. Actually, just about all programs are. Each LUT/FF
pair is a minimal one bit state machine building block which with
programable routing resources form wider and more complex state
machines and data paths, which are highly configurable **AND**
PARALLEL!!! An FPGA is the ultimate UNIVERSAL computing engine. Most
HLL's are simply description languages for data path and state machine
engines ... a perfect mariage with FPGAs that provide exactly those
resources in the most configurable way.

 

[Joseph Samson]

Marko wrote:

Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?
At my previous employer, a proposal was submitted and the Xilinx

configuration files were called firmware. Someone forgot to read the RFP
carefully, because we were specifically prohibited from developing
firmware. The proposal was changed, I believe to 'configuration file'.


---
Joe Samson
Pixel Velocity

 

[John_H]

Hal Murray wrote:

What's the spectrum of the output of a "two-modulus prescaler"?

What's the spectrum of a DDS?

How low do I have to make the PLL bandwidth if I want to filter
out the junk? (Assume I run the DDS output through a PLL
to filter out the steps.)

The output of a two-modulus prescaler (specifically "fractional-N
synthesis") and the MSbit of a DDS (as opposed to a phase-to-sine lookup
feeding a DAC) are the same thing - they produce the same spectra. The
largest spurs are related to the closest integer ratio approximations to
the output to reference clock ratio, many smaller spurs coming from
mixing of those components and other slightly nonlinear effects of the
ratios that produce these beat frequencies.

With no extra help, both approaches have phase steps in some situations
that are too low to be filtered out in an analog PLL filter. Imagine an
output frequency so close to a divide-by-12 that the divide-by-13
happens once a second. The result will be the same from the MSBit of
the DDS and the accumulator for the divide by 12/13 control - a phase
"slip" that has a ramp back to "steady state" controlled by the analog
PLL filter.

The phase steps in DDS or fractional-N synthesis can be reduced by using
the same techniques in sigma-delta converters but the control is a
little more than a dual modulus. If there is a phase offset from
"ideal" that is a ramp going from -0.5 Unit Intervals (UI) phase error
to +0.5 UI of error, adding compensation to the output divider to push
the phase error occasionally beyond the +/- 0.5 UI range at high enough
frequency will allow the PLL's loop filter to average the compensation
to directly match the offest from "ideal."

Different systems have different requirements for what is "good" quality
results. Using the dithering just mentioned, there are often still
noticeable spurs in the output spectrom though they won't look like much
from the time domain. Many systems - such as analog - can't deal with
the associated background tones and would gladly trade off a higher
noise floor for lower spurs. In most of the stuff I want to deal with,
I'm concerned about the time domain.

 

[ernie]

I played around in Quartus and I think I've discovered the answer to my
own question.

If you assign to a pin location "null", that removes the assignment
apparently. ie. cmp add_asssignment top_name "" pin_name LOCATION null


Cheers,
Ernie

 

[Michael Schöberl]

When I capture some data I have unexpected activity on my signals,
including the 3 bits that are tied to 0 in the VHDL!!!

Anyone else experienced this?

a collegue had this problem last week (but I'm not sure about the
version) ... (I hope I remember correctly)

If you change the port connections with the core inserter tool, then the
analyzer sometimes fails to update the names and port numbers ...
you end up with some signals toggling that should not and your trigger
beeing constant ... AFAIR a new analyzer project could help ...


bye,
Michael

 

[simon.stockton@baesystems]

Thanks for the reply,

I am not actually using the Core Inserter Tool.

I create the ICON core and the ILA core using the Core Generator, then
manually instanciate them into my design and wire them up.

At this point I then use the Core Analyzer to set up the trigger and
capture the data.

Simon

 

[Hal Murray]

Yes, that too; the other trick shown in the example is how to keep
the two IOB DDR clock nets identically loaded by splitting the internal
logic clock loads out onto another BUFG net.

Does this run into skew problems between the main clock and the IOB clock?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Falk Brunner]

fpga_toys@yahoo.com schrieb:

Enter dynamic reconfigurability, and it's not even "firmware" any more
.... not hard locked in even a rom for many designs. More like a solid

I would'nt connect the term "Firmware" to ROMs. For my understandig so
far, Firmware is data in any storage medium (ROM/RAM/FLASH/Network) that
is loaded into a "Execution memory", for a processor it will be RAM, for
a FPGA it will be Config-RAM, or if yo like RAM for FSMs.
How about this "definition"?

Regards
Falk

 

Firmware is instruction-stream-based - more precisely:
micro-instructions for programming the inner machine in a nested
machine, where an instruction of the outer machine is executed by a
sequence of micro-instruations by the inner machine.

Programming FPGAs etc., however is NOT instruction-stream-based (i. e.
NOT a procedural issue), and it should not be called "software" how
some people do, because a software compiler generates an instruction
schedule. Configuration code, however, is NOT an instruction schedule.
It is a structural issue (but NOT procedural).

The sources for compilation into configuration code should be called
CONFIGWARE, and not software, nor firmware. A typical configware
compilation process uses placement and routing, however, NOT
instruction scheduling.

FPGA code I call configware code - the output of configware compilation
of design flow

Best regards,
Reiner
http://fpl.org/RCeducation/

 

[Aurelian Lazarut]

google for "microblaze uClinux" you'll se a good colection of demos for
uClinux - all of them are copying the linux image into external SDRAM
(or DDR sdram) and run from there.

Aurash


me_2003@walla.co.il wrote:

Hi all,
Does anyone knows of a complete reference design (preferably xilinx's)
describing a MB system that is running from external memory.
I'm trying to setup such a design and have some questions, I'll be
happy to get a well documented reference design to get me started..
Thanks in advance , Mordehay.

 

[Kolja Sulimma]

reiner@hartenstein.de schrieb:

Configuration code, however, is NOT an instruction schedule.
It is a structural issue (but NOT procedural).

[...] A typical configware
compilation process uses placement and routing, however, NOT
instruction scheduling.

Now, this discussion is going to become really interesting with multi
context FPGAs. In that case there is a stream of very few very large
instructions.

Configware is ok, but I like stiffware better because it fits nicely
between software, firmware and hardware.

Kolja Sulimma

 

[Joseph Samson]

Marko wrote:

Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?

James Morrison wrote:

The answer I came up with was "stiffware".

reiner wrote:

FPGA code I call configware code - the output of configware compilation
of design flow

At Pixel Velocity, we call it 'gateware'.


---
Joe Samson
Pixel Velocity

 

[Brannon]

call it 'gateware'

same at Starbridge Sys.

 

[Ray Andraka]

I've called it "gateware" for the last 15 years.