EDK : FSL macros defined by Xilinx are wrong

[Steve Lass]

Hendra,

ISE Simulator Lite is included free with WebPACK and Foundation. It has
limit
of around 10,000 lines of code.

ISE Simulator is only available to Foundation customers and costs $995. It
has no line limit.

Steve

Hendra wrote:

What is the price for ISE Simulator? There is no mention of it in
Xilinx Online Store. How does it compare to ModelSim Xilinx Edition
III?

Hendra

 

[Mike Treseler]

Brannon wrote:

I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

I fifth the motion.
All in favor of gateware say aye.

-- Mike Treseler

 

[Tim Wescott]

Bob Perlman wrote:

On Tue, 21 Feb 2006 10:52:42 -0800, Mike Treseler
mike_treseler@comcast.net> wrote:


Brannon wrote:

I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

I fifth the motion.
All in favor of gateware say aye.

-- Mike Treseler


Sounds good to me. Anything that disabuses people of the notion that
FPGA design is the same as or similar to software design meets with my
approval.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Yea verily. I do a lot of embedded software development, and a bit of
FPGA design. While Verilog may bear a passing resemblance to C the
thought processes that go into FPGA design vs. software design are
considerably different.

--

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

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

 

[Tim Wescott]

Brannon wrote:

I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

I think I'll start using that -- at least where I think it has a chance

to stick.

--

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

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

 

[JJ]

Except there really aren't any useable gates in the FPGA, LUTs only
model them and other functions that might be built of gates in an ASIC.
We hardly think in terms of gates do we, usually equations, registers
and memory blocks otherwise we would still be using schematics.

I'd would offer bitware since we also use bitfiles, maybe boolware,
lutware, flexware, mixware, dunnoware, undewear.

Some other thoughts

Now to those who rail that xxxxware isn't software just because Verilog
also uses some C style syntax. What happens if say SystemVerilog is
used to describe a system with both hardware & software components,
half (mostly the parallel part) being synthesized and the rest being
executed by a cpu in the FPGA. Suppose that cpu is in control of
dynamic reconfiguration and allows hardware blocks to be loaded at
will. Right now we have no language to support this (do we?). What
about the far future when the onboard processor(s) might even run the
synthesis locally on demand. Maybe too much coolaid.

One should also note the industry shift by Intel, AMD, IBM to 2, 4 and
n way cores and multithreaded cpus. Eventually the software industry
will look over our shoulders and see that hardware guys have had
parallel figured out for 50+ years and don't fall over themselves with
it. They might even notice that SystemVerilog includes a good chunk of
C and that Verilog seems to describe concurrency pretty well too. For
the most part software guys even OS and language experts (not embedded)
have zero clue about our side of the language fence v the 1000s of
languages they reinvent all the time.

A lite version of Verilog combined with a subset of C++ that describes
processes as objects as well as Verilog describes modules using C
syntax all the way might be an attractive alternative to the rather
biggish SystemVerilog. It might allow all execution as code with a
provided runtime event wheel or might be synthesized to hardware or any
mix of the two, at least its one language. Not sure when that might
arrive but it would be alot better than most of these parallel C
dialects that haven't been thought out to well like Jave, C# which
completeley ignored CSP theory.



John Jakson
transputer guy

 

[JJ]

Except there really aren't any useable gates in the FPGA, LUTs only
model them and other functions that might be built of gates in an ASIC.
We hardly think in terms of gates do we, usually equations, registers
and memory blocks otherwise we would still be using schematics.

I'd would offer bitware since we also use bitfiles, maybe boolware,
lutware, flexware, mixware, dunnoware, undewear.

Some other thoughts

Now to those who rail that xxxxware isn't software just because Verilog
also uses some C style syntax. What happens if say SystemVerilog is
used to describe a system with both hardware & software components,
half (mostly the parallel part) being synthesized and the rest being
executed by a cpu in the FPGA. Suppose that cpu is in control of
dynamic reconfiguration and allows hardware blocks to be loaded at
will. Right now we have no language to support this (do we?). What
about the far future when the onboard processor(s) might even run the
synthesis locally on demand. Maybe too much coolaid.

One should also note the industry shift by Intel, AMD, IBM to 2, 4 and
n way cores and multithreaded cpus. Eventually the software industry
will look over our shoulders and see that hardware guys have had
parallel figured out for 50+ years and don't fall over themselves with
it. They might even notice that SystemVerilog includes a good chunk of
C and that Verilog seems to describe concurrency pretty well too. For
the most part software guys even OS and language experts (not embedded)
have zero clue about our side of the language fence v the 1000s of
languages they reinvent all the time.

A lite version of Verilog combined with a subset of C++ that describes
processes as objects as well as Verilog describes modules using C
syntax all the way might be an attractive alternative to the rather
biggish SystemVerilog. It might allow all execution as code with a
provided runtime event wheel or might be synthesized to hardware or any
mix of the two, at least its one language. Not sure when that might
arrive but it would be alot better than most of these parallel C
dialects that haven't been thought out to well like Jave, C# which
completeley ignored CSP theory.



John Jakson
transputer guy

 

Isaac Bosompem wrote:

For me the biggest hurlde of learning to utilize VHDL was programming
my brain to not think of it as a programming language. Then everything
began to fall into place.

Interesting discussion. In a prior discussion regarding "programming"
or "designing" with C syntax HLL or HDLs, it was interesting how many
people took up arms that they could do everything in VHDL or Verilog
that could be done with a C based fpga design language such as
Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement
was that VHDL/Verilog really isn't any different that C based HLL/HDL's
for FPGA design, and frequently with the assertion that VHDL/Verilog
was better.

Now, we have the looks like a duck, walks like a duck, quacks like a
duck, must be a duck argument that if in fact VHDL/Verilog is some
equivalent to C based HDL/HLL's, then it's probably has some
significant aspects of software development, rather than gate level
schematic based hardware design.

So is an fpga design in VHDL/Verilog hardware, and the same realized
equiv gates written in in Celoxica's Handel-C software just because of
the choice of language? Or is a VHDL/Verilog design that is the same
as a Handel-C design software?

 

[Gabor]

Just to throw in my 2 cents on the semantics of FPGA configuration
code/bitstream/whatever...

In the software realm, software vs. firmware is generally the
difference
between something easily changed (i.e. stored on your hard
disk) vs. something not as easily changed (i.e. stored in a ROM).

There is a bit of grey area here, like the BIOS in your PC which is
in a flash memory in most modern systems and can be upgraded
by running a program you download from the Internet. I would still
call it firmware, though.

At our company we call FPGA configuration code "software" if it
is stored on the hard drive and uploaded at run time by a user
application. When it is stored in a serial PROM or flash memory
on the board we call it firmware.

I don't think the terms "firmware" or "software" have as much to do
with the programming paradigm as with the delivery of the bits to
make the actual hardware run.

Interesting thread...
Gabor

fpga_toys@yahoo.com wrote:

Isaac Bosompem wrote:
For me the biggest hurlde of learning to utilize VHDL was programming
my brain to not think of it as a programming language. Then everything
began to fall into place.

Interesting discussion. In a prior discussion regarding "programming"
or "designing" with C syntax HLL or HDLs, it was interesting how many
people took up arms that they could do everything in VHDL or Verilog
that could be done with a C based fpga design language such as
Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement
was that VHDL/Verilog really isn't any different that C based HLL/HDL's
for FPGA design, and frequently with the assertion that VHDL/Verilog
was better.

Now, we have the looks like a duck, walks like a duck, quacks like a
duck, must be a duck argument that if in fact VHDL/Verilog is some
equivalent to C based HDL/HLL's, then it's probably has some
significant aspects of software development, rather than gate level
schematic based hardware design.

So is an fpga design in VHDL/Verilog hardware, and the same realized
equiv gates written in in Celoxica's Handel-C software just because of
the choice of language? Or is a VHDL/Verilog design that is the same
as a Handel-C design software?

 

Gabor wrote:

At our company we call FPGA configuration code "software" if it
is stored on the hard drive and uploaded at run time by a user
application. When it is stored in a serial PROM or flash memory
on the board we call it firmware."

Interesting. So the devices which have flash/eeprom based "solid state
disks" (SSD) such as your typical hand held IPOD, Windows CE based
PDA's, are not "software" based systems?

heck even phones these days are becoming PDA's and MP3 players with
very large SSD's in flash. Even most new "platform flash" FPGA's load
off the same SSD's in the form of compact flash cards.

So if SSD's are the factor for software vs. hardware, then it seems
that any FPGA that loads and runs off SSD related storage technology,
is probably software by the looks like a duck, quacks like a duck, must
be a duck test. No? Why not?

Why is an FSM and data paths controlled by it when written in a C based
HDL/HLL software, and the same FSM and data paths written in
VHDL/Verilog hardware?

It wasn't that many years ago I wrote software/firmware/microcode for
bit sliced "processors" implementing 'smart' high speed data
controllers, but we called it hardware. Now I write
software/firmware/microcode AND instantiate it as hard LUT/FFs in
FPGA's and it just doesn't seem like hardware any more ... when the
same "code" can be moved to a $0.99 microprocessor with a PLD wrapped
around it as a cost reduction.

 

[Jim Granville]

Gabor wrote:

Just to throw in my 2 cents on the semantics of FPGA configuration
code/bitstream/whatever...

In the software realm, software vs. firmware is generally the
difference
between something easily changed (i.e. stored on your hard
disk) vs. something not as easily changed (i.e. stored in a ROM).

There is a bit of grey area here, like the BIOS in your PC which is
in a flash memory in most modern systems and can be upgraded
by running a program you download from the Internet. I would still
call it firmware, though.

At our company we call FPGA configuration code "software" if it
is stored on the hard drive and uploaded at run time by a user
application. When it is stored in a serial PROM or flash memory
on the board we call it firmware.

I don't think the terms "firmware" or "software" have as much to do
with the programming paradigm as with the delivery of the bits to
make the actual hardware run.

Interesting thread...

There is another thread, where this actually matters from a medical
systems /regulatory basis.

Since you must have SOFTWARE to create the bitstream, then the
admin has to include software-handling discipline.

Many FPGA systems now include SoftCPUs, and that puts some portion
of the design clearly into the software box.

-jg

 

[johnp]

Another user emailed me saying he also saw this problem. His
solution (which I tried successfully) was to re-create the project
from scratch.

So, if you upgrade from 8.1.01 to 8.1.02 you may see Map fail.

I've opened a Webcase with Xilinx.

John Providenza

 

Jim Granville wrote:

Many FPGA systems now include SoftCPUs, and that puts some portion
of the design clearly into the software box.

In a prior thread about HDL's the VHDL camp was VERY VERY proud to
state they didn't need sequential programming languages like C based
HDL/HLL's, since VHDL already had nearly functionally idential
sequential statements and expressions, including extended data types
like floating point.

*IF* software is defined as sequential programming in a high level (or
any level) language, then sequential VHDL (and verilog) clearly passes
the walks like a duck, quacks like a duck, looks like a duck test for
being software.

I'm sure any lawyer would have little trouble showing C source and VHDL
source for sequential floating point data manipulation as functionally
identical, and a jury probably would completely ignore any hardware
designer claiming that it was hardware because his degree was in
electrical engineering and not computer science. Ditto for control and
data paths with integer data representations. Ditto for control and
data paths with bit level representations. Bit level "var1 AND var2"
is the same if written var1*var2 or var1&var2, syntax doesn't matter.

There is a lot of chest beating about being a hardware designer, and
having been formally trained in the lost art of schematic logic level
design. Every year, as hardware design is dominated by large HDL
systems designs, using algorithmic based FSMs and data paths in
languages which are functionally identical to HLL programming
languages, the difference and importanance of obsolete logic level
design training vanishes. If anything, programmers which have been
trained to design, implement, and manage the life cycles of huge zero
defect software projects are much better prepared to manage large
HDL/HLL hardware development projects as automated synthesis completely
replaces gate level design as an acceptable design practice.

Language features which impair the ability of synthesis tools to always
generate formally verifiable and provably correct constructions will
slowly fall by the way side,
and with it the ability to use arcane language hints to save a single
gate in a few hundred instances of a large 20M gate design. Saving a
few hundred (or thousand) gates in a $100 20M gate device if it risks
design errors that would cause a field problem or development delay are
a liability, not a necessary feature. HLL/HDL language features which
are simply there to ensure job security for a certain class of
programmers, will fade away, in favor of expanding the labor pool and
the ability to reused engineering talent in multiple disciplines.

Even in the software world, there are MANY zero defect design
environments ... from space craft mission systems to financial
banking/transactions systems where bugs are simply not an option and
rigorous testing is done before taking any line of code production. And
there are many hardware designs shipped just as buggy as your favorite
Microsoft product, where 99.9% functionality with a one year
operational life is good enough to ship, especially if there is a watch
dog reset to clear latchups caused by known race conditions or
power/ground rail instabilities at marginal operating conditions.

 

[Brian Davis]

Andy wrote:

Do you recommend separate ibufds primitives, or a single
ibufds_diff_out primitive?

The only reason I started using two IBUFDS's instead of one
IBUFDS_DIFF_OUT was to avoid various tool bugs that dropped
placement, I/O standard, and termination attributes when applied
to the IBUFDS_DIFF_OUT components.

The IBUFDS_DIFF_OUT is really just two IBUFDS's in disguise
for V2/S3, but I haven't looked at the V4 implementation.

Brian

 

[Isaac Bosompem]

Sorry I have a bad habit of not reading through my replies. I am using
Google so please spare me

I meant "Perhaps programs like FPGAC are the new progression"

 

[mk]

On Wed, 22 Feb 2006 11:47:56 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

....

There is another thread, where this actually matters from a medical
systems /regulatory basis.

Since you must have SOFTWARE to create the bitstream, then the
admin has to include software-handling discipline.

Does this include almost all ASIC design where synthesis SOFTWARE is
still used to generate gates from RTL, SOFTWARE is used to place those
gates and SOFTWARE is used to route the connections (not to mention
sw to run lvs/drc etc.) ?

It must also include then even any schematic entry based ASICs because
SOFTWARE is used to enter/netlist all the schematics.

Forcing software handling discipline if software is in the path is not
an easy requirement in my opinion. Unless you want to go back to paper
napkin diagrams and tape over transparencies.

 

mk wrote:

Forcing software handling discipline if software is in the path is not
an easy requirement in my opinion. Unless you want to go back to paper
napkin diagrams and tape over transparencies.

Forcing software handling discipline on software teams isn't easy
either.

 

[Jim Granville]

mk wrote:

On Wed, 22 Feb 2006 11:47:56 +1300, Jim Granville
no.spam@designtools.co.nz> wrote:

...

There is another thread, where this actually matters from a medical
systems /regulatory basis.

Since you must have SOFTWARE to create the bitstream, then the
admin has to include software-handling discipline.


Does this include almost all ASIC design where synthesis SOFTWARE is
still used to generate gates from RTL, SOFTWARE is used to place those
gates and SOFTWARE is used to route the connections (not to mention
sw to run lvs/drc etc.) ?

It must also include then even any schematic entry based ASICs because
SOFTWARE is used to enter/netlist all the schematics.

Forcing software handling discipline if software is in the path is not
an easy requirement in my opinion. Unless you want to go back to paper
napkin diagrams and tape over transparencies.

"software-handling discipline" relates to the tools, as much as your own
code.
It is fairly common practice to archive the tools, when a design is
passed to production, and then ALL MAINT changes are done with those tools.
So just because what you ship the customer might look like HW, you
still have to do risk-reduction in house.

For a live, and classic, example look at the ISE v8 release.
Some of the flaws that shipped in this, are frankly amazing,
and one wonders just what regression testing was done....


-jg

 

Isaac Bosompem wrote:

We have always progressed towards abstraction in the software
world,similar pushes have also been made in the hardware world with
EDA's and CAD software packages like MATLAB, which automate most of the
grunt work. Perhaps program like HDL's are the new progression.

Actually VHDL stuck it's toes into this some 20 years back. By 1993
1076.2 Standard Mathematical Package was part of the standards proces,
then 1076.3 Numeric Standards, not long later IEEE 1076.3/floating
point, and then discussions for supporting sparse arrays and other very
high level concepts for pure mathmatical processing rather than
hardware logic from a traditional view point. Interest in C based
HDL/HLL's for hardware design predate even Dave's TMCC work which is
also over a decode old.

So, I don't think it's all that new. Rather it started with sequential
high level syntax and automatic arithmetic/boolean expression
processing was added to VHDL. When computers were expensive in the
1960's and 1970's we traded design labor for microcode and assembly
language designs (frequently done by EE's). As computers dropped
drastically in price, that practice became rapidly not cost effective,
and was almost completely replaced with higher, and higher levels of
abstract language compilers to improve design productivity traded off
against inexpensive computer cycles. We see the same process logic
"hardware logic simulators" .... AKA FPGA's where they have dropped
rapidly in price, allowing huge designs to be implemented on them that
is no long cost effective in schematic form. And, we are seeing even
larger designs implemented that are not even cost effective to design
at the gate level using first generation HDL's that allow the designer
to waste design labor on detailed gate level design. Hardware
development with 2nd and third generation description languages is
likely to follow the software model of using higher degrees of
abstraction specifically to prevent designers from obsessing over a few
gates, and in the process creating non-verifably correct designs which
may break when ported to the next generation FGPA or logic platform.

All I can say though, is only time will tell. It depends on how well
compilers like FpgaC will be able to convert a program to hardware
description. Also how well it be able to extract and fine opportunities
for concurrency.

FpgaC/TMCC has a number of things that are less than optimal, but it
rests on a process of expressing all aspects of the circuit on boolean
expressions, then agressively optimizing that netlist. The results are
suprising to some, but hey, it's really not new, as VHDL has covered
nearly the same high level language syntax to synthesis too. I think
what is suprising to some, is that low level software design is long
gone, and low level hardware design is soon to be long gone for all the
same reasons of labor cost vs. hardware cost.

 

[Eric Smith]

Steve Lass wrote:

ISE Simulator Lite is included free with WebPACK and Foundation. It
has limit of around 10,000 lines of code.

ISE Simulator is only available to Foundation customers and costs $995. It
has no line limit.

Does the Lite version have any other limitations relative to the full
version? For instance, is there any artificial slowdown?

Eric

 

Jim Granville wrote:

For a live, and classic, example look at the ISE v8 release.
Some of the flaws that shipped in this, are frankly amazing,
and one wonders just what regression testing was done....

Or more importantly, why the select beta list developers designs didn't
stumble into the same problems. In large software land, alpha and beta
pre-release cycles are the critical part of not slamming your complete
customer base with critical bugs. The alpha and beta testers willing to
do early adoption testing is probably one of the most prized vendor
assets, and carefully controlled access resources, that any software
vendor can develop. And for that priv, and to build that relationship,
it's frequently necessary to give your product away to those early
adopters long term .... both the beta's and the clean releases that
follow.