CPLD HDL?

[Winston]

I want to put my latest idea in a PLD to save board space.
Years ago I was comfortable working in PALASM, CUPL and ABEL.
I also documented another guy's Verilog source.

I see that Xilinx offers their ISE WebPACK suite for free
but it is said to have 'limited' simulation ability.
There are addon$ available that have complete simulation
ability.

My Question Without Intending To Start A Religious War:

What modern HDL compiler and simulator package has:
The ability to run on Linux
A gentle learning curve
Good user support
Fast, easy use
Efficient use of PLD resources
Support for multiple part vendors
Reasonable purchase price
..and all other characteristics of a superior product. :)

Thanks!


--Winston

[lang...@fonz.dk]

On 9 Feb., 20:18, Winston <Wins...@Bigbrother.net> wrote:
> I want to put my latest idea in a PLD to save board space.
> Years ago I was comfortable working in PALASM, CUPL and ABEL.
> I also documented another guy's Verilog source.
>
> I see that Xilinx offers their ISE WebPACK suite for free
> but it is said to have 'limited' simulation ability.
> There are addon$ available that have complete simulation
> ability.

as far as I remember the limits is that with more than 1000 lines
of code simulation gets slowed down, and code for xilinx blocks
doesn't
count, Not a big problem with a cpld sized design

you could always use a free simulator like e.g Icarus and GTKWave

>
> My Question Without Intending To Start A Religious War:
>
> What modern HDL compiler and simulator package has:
>    The ability to run on Linux
>    A gentle learning curve
>    Good user support
>    Fast, easy use
>    Efficient use of PLD resources
>    Support for multiple part vendors
>    Reasonable purchase price
>    ..and all other characteristics of a superior product. :)
>
> Thanks!
>
> --Winston

don't know if multiple vendor is really available

-Lasse

[Winston]

OK. Thanks!

--Winston

[Jon Elson]

I run the free webpack version on some systems, the "limits" have never
bothered me, I use modest FPGAs and CPLDs. Runs well on Linux.
The only thing I know doesn't work is printing schematics, which
I don't use much, anyway. CPLDs will not have very big HDL
files, maybe 1-2 pages. I use VHDL, you can also use Verilog.
Hmmm, not so sure about user support. You get email support with
the free tools, and phone support with the paid tools, but their
phone support is pretty awful, or was the last few times I called.
I ended up diagnosing the problems myself and telling THEM how to fix it!
I think the efficiency is good but have nothing to compare it to.
But, expensive packages use Xilinx back-end tools to do place and route.
Obviously, Xilinx tools don't support other vendors.

Jon

[Winston]

Thanks, Jon.

Sounds like I ought to contemplate a microcontroller
implementation instead. Then I could use assembly,
which I find entertaining.

--Winston

[Tim Wescott]

Oh, don't give up now, I was hoping to harvest ideas from this thread for
a board that's already got four 74AHCxx parts on it, and seems to be
acquiring more!!!

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[Nico Coesel]

Winston <Win...@Bigbrother.net> wrote:

>I want to put my latest idea in a PLD to save board space.
>Years ago I was comfortable working in PALASM, CUPL and ABEL.
>I also documented another guy's Verilog source.
>
>I see that Xilinx offers their ISE WebPACK suite for free
>but it is said to have 'limited' simulation ability.
>There are addon$ available that have complete simulation
>ability.
>
>My Question Without Intending To Start A Religious War:
>
>What modern HDL compiler and simulator package has:
> The ability to run on Linux
> A gentle learning curve
> Good user support
> Fast, easy use
> Efficient use of PLD resources
> Support for multiple part vendors
> Reasonable purchase price

I use Xilinx' free webpack for their CPLDs. Their XC9500 series is
pretty cheap. As a language I use VHDL because... I know VHDL. For
simulation I use ghdl (ghdl.free.fr).

> ..and all other characteristics of a superior product. :)

Not on this world...

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

[Jon Elson]

Winston wrote:


>
> Sounds like I ought to contemplate a microcontroller
> implementation instead. Then I could use assembly,
> which I find entertaining.

Well, I do a lot of stuff where micros may be too slow,
or not parallel enough. VHDL is pretty easy to pick up.
And, you CAN enter a schematic, even in familiar 74xx
part numbers, wire it all up and have it turned into logic
on a CPLD or FPGA. Some interface glue projects I still
do it that way, although I am moving more and more to HDL.

Jon

[Jon Elson]

Tim Wescott wrote:


>
> Oh, don't give up now, I was hoping to harvest ideas from this thread for
> a board that's already got four 74AHCxx parts on it, and seems to be
> acquiring more!!!
>

CPLDs have really saved the day sometimes when working with the ASICs
we make, and we find some dumb error in the ASIC. Well, just throw some
more gates into the CPLD and fix the goof. The Xilinx 95xx series is still
available and runs off 5V, too! (Warning, the power consumption given
by their formula is WAY optimistic, it can be 3X higher than they claim.)
Xilinx admitted this in email, but refused to correct the docs.

In power-sensitive applications, the Cool Runner II is a MUCH lower power
CPLD, but it is 3.3 V only.

Jon

[Jon Elson]

Nico Coesel wrote:


> I use Xilinx' free webpack for their CPLDs.

Oh, note that due to export restrictions, the free webpack
will not run on 64-bit OS's. Apparently you can alter some
links to 32-bit libraries and make it work.

Jon

[Phil Hobbs]

I haven't done a PLD in quite awhile--my current toolset is Orcad PLD
for DOS. ;) They're great for stuff where you need better timing
coherence than the processor can give you, e.g. sampling.

What's the easiest way to start with VHDL?

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

[Winston]

Tim > Oh, don't give up now, I was hoping to harvest ideas
Tim > from this thread for a board that's already got four
Tim > 74AHCxx parts on it, and seems to be acquiring more!!!

Jon, Tim and I would very much like to know what package
you use to capture a schematic and output (JEDEC?) for a
CPLD or FPGA. Is the ghdl package Nico mentioned involved?

Thanks

--Winston

[Nico Coesel]

Fortunately Linux doesn't need 64 bit to use >3GB of memory :-)

[Nico Coesel]

Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

>On 02/09/2012 06:23 PM, Jon Elson wrote:
>> Winston wrote:
>>
>>
>>>
>>> Sounds like I ought to contemplate a microcontroller
>>> implementation instead. Then I could use assembly,
>>> which I find entertaining.
>> Well, I do a lot of stuff where micros may be too slow,
>> or not parallel enough. VHDL is pretty easy to pick up.
>> And, you CAN enter a schematic, even in familiar 74xx
>> part numbers, wire it all up and have it turned into logic
>> on a CPLD or FPGA. Some interface glue projects I still
>> do it that way, although I am moving more and more to HDL.
>>
>> Jon
>
>I haven't done a PLD in quite awhile--my current toolset is Orcad PLD
>for DOS. ;) They're great for stuff where you need better timing
>coherence than the processor can give you, e.g. sampling.
>
>What's the easiest way to start with VHDL?

I guess a good book with actual examples, not just a language
specification :-) Just make sure it covers writing functions and so
on. There is a lot of power in VHDL. In the past I've often designed
pieces of logic which can be configured for different widths,
channels, etc. That took some studying to get it right but it has paid
off big time in several occasions. It helps if you have a programming
background.

There is also Verilog but I never understood Verilog. It makes me feel
like I'm looking at a netlist output from a schematic.

[Phil Hobbs]

Is there an equivalent to K&R for VHDL?

[Mr.CRC]

I use Xilinx Webpack on Linux, and the Icarus Verilog simulator.

Gentle learning curve just doesn't apply to Xilinx software.

I suppose support is good if you use Xilinx or Altera, between the
USENET and manufacturer forums. I rarely need support, and even when I
do it's just to save some time rather than figure it out myself.

I've never taxed any of my PLDs enough to care about very high efficiency.

Support for multiple vendors? Well, that will only happen if you aren't
using the software from one of the manufacturers. I don't go there, due
to too high prices, which I prefer free.


Good luck and have fun.



--
_____________________
Mr.CRC
crobc...@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

[Winston]

Mr.CRC wrote:

(...)

> I use Xilinx Webpack on Linux, and the Icarus Verilog simulator.
>
> Gentle learning curve just doesn't apply to Xilinx software.

I see what you mean. I downloaded and installed just now.
Holey Cannolli! In the Good Old Days, you just supplied a source
file and told the compiler to get started. The tutorial
has me doing all kinds of gyrations, referring to unlabeled
windows and sending me on a goose chase to locate buttons that
are not visible on the existing screen, all with no explanation
of *why* these things need to be done. Wow!

> I suppose support is good if you use Xilinx or Altera, between the
> USENET and manufacturer forums. I rarely need support, and even when I
> do it's just to save some time rather than figure it out myself.
>
> I've never taxed any of my PLDs enough to care about very high efficiency.
>
> Support for multiple vendors? Well, that will only happen if you aren't
> using the software from one of the manufacturers. I don't go there, due
> to too high prices, which I prefer free.
>
>
> Good luck and have fun.

Thanks, Mr. CRC

--Winston

[MK]

Hello - This thread is so Xilinx centric !

Have a look at Lattice - their free tool is based on Aldec HDl which is
nice (Schematic, VHDL and Verilog in one simulator -I have the paid for
version but the free one is OK for small stuff).

Lattice have a much better offering than Xilinx (IMHO) for small FPGA
and PLD/FPGA crossover parts.

Michael Kellett

[o pere o]

A generic tool that allows simulating VHDL is GHDL. I use it on linux,
don't know if there is a windows port. HOWEVER, you have to be careful,
as GHDL is a pure simulator and simulates exactly what you write (which
is sometimes not what you want): if you forget to add a signal to the
sensitivity list of a process, it will not react to changes in that
signal. Altera's Quartus , for instance, defaults to implicitly add
every signal you read inside a process to the sensitivity list (which is
usually what makes sense for synthesis), giving you a warning. There are
also constructs that are not synthesizable.

For instance, process(A,B) and process(A) are not the same if inside you
want to achieve C <= A and B.

User support and documentation is sufficient but very limited.

It is not a compiler and, as a consequence, does not support any
specific parts. You have to build a block from your VHDL code and insert
it into Quartus or ISE (yuck). This usually works ok.

Pere

[Jan Panteltje]

On a sunny day (Fri, 10 Feb 2012 01:19:52 GMT) it happened ni...@puntnl.niks
(Nico Coesel) wrote in <4f346dc9....@news.kpn.nl>:

>There is also Verilog but I never understood Verilog. It makes me feel
>like I'm looking at a netlist output from a schematic.

Verilog looks more sane to C programmers.
It usually is less typing (I mean like hitting keys) work than VHDL, VHDL reminds me of ADA,
and I threw away that book.
So maybe if you come from a C background Verilog is easier to get used to.
Somebody did a VHDL version of a camera software I did in C, and I could not read it...
I found Verilog easy to learn.
You were talking about crypto, I did a nice decoder for some well known TV crypto system
in FPGA, to do it all with logic gates (one clock decoding), so they could brute force faster.
That system is now longer in use for obvious reasons,
Those were the times when hackers were still heros..
These days it would get you arrested,
Actually published that code on the internet, may be it is still somewhere.

[o pere o]

On 02/10/2012 12:29 AM, Phil Hobbs wrote:
> On 02/09/2012 06:23 PM, Jon Elson wrote:
>> Winston wrote:
>>
>>
>>>
>>> Sounds like I ought to contemplate a microcontroller
>>> implementation instead. Then I could use assembly,
>>> which I find entertaining.
>> Well, I do a lot of stuff where micros may be too slow,
>> or not parallel enough. VHDL is pretty easy to pick up.
>> And, you CAN enter a schematic, even in familiar 74xx
>> part numbers, wire it all up and have it turned into logic
>> on a CPLD or FPGA. Some interface glue projects I still
>> do it that way, although I am moving more and more to HDL.
>>
>> Jon
>
> I haven't done a PLD in quite awhile--my current toolset is Orcad PLD
> for DOS. ;) They're great for stuff where you need better timing
> coherence than the processor can give you, e.g. sampling.
>
> What's the easiest way to start with VHDL?
>
> Cheers
>
> Phil Hobbs
>

IMO, the easiest way is to have a look at a book that teaches digital
design presenting simultaneously the conventional and the VHDL approach.
For instance, the first half of P. J. Ashenden's "Digital Design, an
Embedded Systems Approach Using VHDL". It seems there is the same book
with Verilog.

The most common error when learning VHDL is to start thinking of it in
software terms: since VHDL is a programming language, with constructs
which are very similar to conventional languages, it is easy to forget
that you are actually using it for a very specific subset of its
abilities: to describe hardware. As you already know digital design,
this will not be a problem for you, but it IS a problem with students.

Pere

[Jeroen Belleman]

o pere o wrote:
> On 02/10/2012 12:29 AM, Phil Hobbs wrote:
>> On 02/09/2012 06:23 PM, Jon Elson wrote:

>>> [...] VHDL is pretty easy to pick up.

>>
>> What's the easiest way to start with VHDL?
>>
>> Cheers
>>
>> Phil Hobbs
>>
> IMO, the easiest way is to have a look at a book that teaches digital
> design presenting simultaneously the conventional and the VHDL approach.
> For instance, the first half of P. J. Ashenden's "Digital Design, an
> Embedded Systems Approach Using VHDL". It seems there is the same book
> with Verilog.
>
> The most common error when learning VHDL is to start thinking of it in
> software terms: since VHDL is a programming language, with constructs
> which are very similar to conventional languages, it is easy to forget
> that you are actually using it for a very specific subset of its
> abilities: to describe hardware. As you already know digital design,
> this will not be a problem for you, but it IS a problem with students.
>
> Pere

I have little trouble translating VHDL code in mind-images of logic
circuitry, but I find its syntax clumsy and baroque. I can't
seem to get used to "if signal = '1' then" as opposed to
"if signal then", or "<=" rather than just "=", not to mention
that "<=" means different things inside or outside of processes.
And the inconsistency of "elsif" vs. "end if", or the difference
between "if" and "when" statements, etc, etc.

Also, I see many people, even those fluent in VHDL, draw little
circuit diagrams before translating them into VHDL.

I think VHDL is a crutch, just like the 1984 rectangular logic
gate symbols were a crutch for immature plotting software.

Jeroen Belleman

[Nico Coesel]

Actually you should treat it like a programming language and a design
as a software problem. If you keep thinking in logic then you end up
inputting a netlist with VHDL. VHDL gets very clumsy that way (lots of
typing).

For fun: use google to find a VHDL implementation of a priority
encoder. 9 out of 10 people write an if statement for each output
(which gets large quickly). Only one writes a clever three line
function which works regardless the number of input bits.

The problem students have is not with logic design but with the fact
that VHDL describes a parallel process and that every line of code is
executed simultaneously.

[o pere o]

If you go this way, it can quickly become very fun indeed, especially
when you end up using a huge number of resources. Yes, optimizers do
work (more or less), but you should only trust them when you already
have an approximate idea of what the outcome should be (and this is not
only true speaking about VHDL).

> The problem students have is not with logic design but with the fact
> that VHDL describes a parallel process and that every line of code is
> executed simultaneously.

Because they loose the connection of the language with the underlying
hardware!

Pere

[Nico Coesel]

Thats part of getting experienced. Programmable logic manufacturers
often have documents describing what is efficient for their devices
and what is not.

>> The problem students have is not with logic design but with the fact
>> that VHDL describes a parallel process and that every line of code is
>> executed simultaneously.
>
>Because they loose the connection of the language with the underlying
>hardware!

That is the purpose of a high level language. When I program in C I
don't care how many instructions it uses. As long as the program works
fast enough and fits in the flash it is OK.

[Winston]

MK wrote:

(...)

> Hello - This thread is so Xilinx centric !
>
> Have a look at Lattice - their free tool is based on Aldec HDl which is nice (Schematic, VHDL and Verilog in one
> simulator -I have the paid for version but the free one is OK for small stuff).
>
> Lattice have a much better offering than Xilinx (IMHO) for small FPGA and PLD/FPGA crossover parts.

OK, thanks Michael. Now downloading Lattice's entry (*also* called 'diamond'!)

--Winston

[Phil Hobbs]

Thanks, I'll have a look at it. Every project needs somebody who knows
enough about everyone's job to be at least a nuisance, and preferably a
help. I'm never comfortable with a job unless I have my arms around all
facets of it.

One time about a dozen years ago, I was leading a team--an unusually big
one for me, about 5 people--building a sensor system for use inside
retail stores. We had a customer pilot installation set up for the
Monday before Thanksgiving in a 50000 square foot box store in New
Jersey, when my firmware guy crapped out on me a month ahead of time,
leaving a complete mess. (I wrote the whole amusing story up for Optics
& Photonics News--see
http://electrooptical.net/www/footprints/fpwaropn.pdf if you're
interested.) We couldn't push the date back, because we had a lift and
a crew lined up, and more importantly, retailers won't let you fiddle
with their ceilings between Thanksgiving and New Year's.

So I spent three weeks re-doing all the firmware myself, on top of all
the other stuff. I'd never done any firmware before, and I'd have been
dead if I hadn't been spending time coming up to speed before that. As
it was, we had working sensors with a few days to spare--and then the
retailer cancelled, the day before the scheduled install. Ah,
technology. I eventually produced the production firmware, which worked
fine--no errors or crashes in over six months' continuous operation.

I have to take personal credit for the project management screwup (I
should never have let the f/w get to that stage without regular code
walk-throughs), but otherwise I don't think that sort of tale is that
unusual.

So as I say, I care about having my arms around the project.

[Phil Hobbs]

Nico Coesel wrote:
>
> o pere o <m...@somewhere.net> wrote:
>
> >On 02/10/2012 01:05 PM, Nico Coesel wrote:

<snip>

> >>
> >> For fun: use google to find a VHDL implementation of a priority
> >> encoder. 9 out of 10 people write an if statement for each output
> >> (which gets large quickly). Only one writes a clever three line
> >> function which works regardless the number of input bits.
> >
> >If you go this way, it can quickly become very fun indeed, especially
> >when you end up using a huge number of resources. Yes, optimizers do
> >work (more or less), but you should only trust them when you already
> >have an approximate idea of what the outcome should be (and this is not
> >only true speaking about VHDL).
>
> Thats part of getting experienced. Programmable logic manufacturers
> often have documents describing what is efficient for their devices
> and what is not.
>
> >> The problem students have is not with logic design but with the fact
> >> that VHDL describes a parallel process and that every line of code is
> >> executed simultaneously.
> >
> >Because they loose the connection of the language with the underlying
> >hardware!
>
> That is the purpose of a high level language. When I program in C I
> don't care how many instructions it uses. As long as the program works
> fast enough and fits in the flash it is OK.

That's an overstatement, I think. Since MCU cost depends strongly on
the flash size, knowing how to make the code smaller is economically
important. (It's especially important whey you're already using the
biggest version of your processor, of course.)

[John Devereux]

Hi Phil,

On microcontrollers what you often find is that a large chunk of the
program size turns out to be consumed by a few large library
functions. Sometimes ones you did not even realise you referenced.

And the reason say the ARM compiler might beat gcc on size is that their
libraries are better optimised, not because its detailed code generation
is significantly improved.

For smaller projects I find I am better off not using the traditional C
library at all. It is more trouble than it is worth. An innocent
"#assert" brings in a full floating point printf and all of stdio, and
suddenly your 64k flash is full.

Over time I have built up a library containing replacements for the very
few C library functions that are any actual use (in a small embedded
system context).

--

John Devereux

[Nico Coesel]

True, but ask yourself: are you going to tinker with assembler or make
the algorithm more clever so it is faster or smaller?

Sometimes there is a third option. With the ARM7TDMI controllers (the
non-Cortex ones) you have a choice to use the thumb instruction set or
the bigger ARM instruction set. For one project I had to cram a TCP/IP
stack, DNS, DHCP, webserver and some other stuff into 32kB flash. I
opted to use the thumb instruction set. That saved lots of memory at
the expense of having to write some assembly to handle interrupts.

And is the price of the MCU really the only driving parameter? Leaner
programming often means spending more time (and the amount of time
goes up exponentially). In my experience people often look too much to
the price of the parts and forget about the time required to make the
firmware. Once a product sells by thousands you can still do a
redesign to cut the costs.

[Phil Hobbs]

I can well believe that. Pulling in all of scanf() to parse keystrokes
is not going to be very space-efficient. That's another reason for
caring what's going on under the covers.

[Phil Hobbs]

I don't disagree in general--I program MCUs only in C for that
reason--but earlier you seemed to be defending a purist HLL ethos that I
run into a lot, and that (when held in its full rigour) has some fairly
bad consequences.

[lang...@fonz.dk]

On 10 Feb., 07:47, Winston <Wins...@Bigbrother.net> wrote:
> Mr.CRC wrote:
>
> (...)
>
> > I use Xilinx Webpack on Linux, and the Icarus Verilog simulator.
>
> > Gentle learning curve just doesn't apply to Xilinx software.
>
> I see what you mean.  I downloaded and installed just now.
> Holey Cannolli! In the Good Old Days, you just supplied a source
> file and told the compiler to get started. The tutorial
> has me doing all kinds of gyrations, referring to unlabeled
> windows and sending me on a goose chase to locate buttons that
> are not visible on the existing screen, all with no explanation
> of *why* these things need to be done. Wow!
>

maybe I'm strange or have used xilinx too long, but I find rather
straight forward;

open new project, choose name, location, part, etc.
add new source file, verilog module, add some ports if you like,
or do it later in the text editor

code code code ....

and new source, verilog test fixture,

code testbench...

run simulator, fix bugs

user constraints, assign what pins to what ports

implement design

configure device, done ...


-Lasse

[Nico Coesel]

John Devereux <jo...@devereux.me.uk> wrote:

>Phil Hobbs <pcdhSpamM...@electrooptical.net> writes:
>
>> Nico Coesel wrote:
>>>
>>> o pere o <m...@somewhere.net> wrote:
>>>
>>> >On 02/10/2012 01:05 PM, Nico Coesel wrote:
>> <snip>
>>> >>
>>> >> For fun: use google to find a VHDL implementation of a priority
>>> >> encoder. 9 out of 10 people write an if statement for each output
>>> >> (which gets large quickly). Only one writes a clever three line
>>> >> function which works regardless the number of input bits.
>>> >
>>>

>>> That is the purpose of a high level language. When I program in C I
>>> don't care how many instructions it uses. As long as the program works
>>> fast enough and fits in the flash it is OK.
>>
>> That's an overstatement, I think. Since MCU cost depends strongly on
>> the flash size, knowing how to make the code smaller is economically
>> important. (It's especially important whey you're already using the
>> biggest version of your processor, of course.)
>
>Hi Phil,
>
>On microcontrollers what you often find is that a large chunk of the
>program size turns out to be consumed by a few large library
>functions. Sometimes ones you did not even realise you referenced.
>
>And the reason say the ARM compiler might beat gcc on size is that their
>libraries are better optimised, not because its detailed code generation
>is significantly improved.
>
>For smaller projects I find I am better off not using the traditional C
>library at all. It is more trouble than it is worth. An innocent
>"#assert" brings in a full floating point printf and all of stdio, and
>suddenly your 64k flash is full.

I like to stay Posix compliant so existing pieces of code can be used
directly and other people can get up to speed quickly. The C library
which comes with mspgcc is pretty compact and its easy to get it
compiled for ARM. I have been using that library ever since I moved
from MSP430 to ARM.

If the printf from the mspgcc libc gets too big I rather create a
minimal version of printf than writing my own non-standard printing
routines.

Here is an example of a minimal printf:
http://users.powernet.co.uk/eton/kandr2/krx703.html

In some space constrained projects of mine it just supports decimal
and hex without any formatting.

[Winston]

lang...@fonz.dk wrote:
> On 10 Feb., 07:47, Winston<Wins...@Bigbrother.net> wrote:
>> Mr.CRC wrote:

(...)

>>> Gentle learning curve just doesn't apply to Xilinx software.
>>
>> I see what you mean. I downloaded and installed just now.
>> Holey Cannolli! In the Good Old Days, you just supplied a source
>> file and told the compiler to get started. The tutorial
>> has me doing all kinds of gyrations, referring to unlabeled
>> windows and sending me on a goose chase to locate buttons that
>> are not visible on the existing screen, all with no explanation
>> of *why* these things need to be done. Wow!
>>
>
> maybe I'm strange or have used xilinx too long, but I find rather
> straight forward;
>
> open new project, choose name, location, part, etc.
> add new source file, verilog module, add some ports if you like,
> or do it later in the text editor
>
> code code code ....
>
> and new source, verilog test fixture,
>
> code testbench...
>
> run simulator, fix bugs
>
> user constraints, assign what pins to what ports
>
> implement design
>
> configure device, done ...

It's easy after the first 25!

:)

--Winston

[John Devereux]

Uh - that one seems to call printf so does not seem a great amount of
use on it's own?! :)

But yes I started out with a public-domain printf and added a few things
to it (like support for "fixed-point" format specifiers).

> In some space constrained projects of mine it just supports decimal
> and hex without any formatting.

--

John Devereux

[Nico Coesel]

Ofcourse you substitute those with functions that dump the contents to
the console as chars :-). There is a much better 'skeleton' but I
can't find the link.

[Jon Elson]

Phil Hobbs wrote:


>
> What's the easiest way to start with VHDL?

You can download Xilinx webpack for you favorite OS.
You can get their parallel cable III or make one from the
schematic available online. It connects to the parallel port
and has one 74HC125 (I think) IC inside, and a few diodes and
resistors. Or, you can get their USB JTAG device for a bit
more $.

The XC9500 chips are available in a wide range of packages, the
XC2R (cool runner 2) are available in some quite small packages,
and are amazingly cheap. Put a JTAG header on the board for programming.
I use a 2x4 2mm header and made my own adapter from the Parallel Cable
III unit. You can wire the JTAG in series so all your devices can
be programmed from one JTAG tap.

But, that's just what I use. I have used quite a few hundreds of
the XC9500 series, and some hundreds of their Spartan line of FPGAs.
I've done several dozen designs using Xilinx parts.

Jon

[Jon Elson]

Winston wrote:


>
> Jon, Tim and I would very much like to know what package
> you use to capture a schematic and output (JEDEC?) for a
> CPLD or FPGA. Is the ghdl package Nico mentioned involved?

No JEDEC format for FPGAs. At least up to a point, the
Xilinx web pack had schematic entry and libraries for their
various chips. They MAY have dropped schematic at some point
fairly recently. Schematic still works on 10.1, which we still use
because it has support for 5V XC9500 and Spartan 2E.

You need to know that while you may enter a schematic, it
will be broken down into equations and resynthesized into
very different logic to best fit the CPLD or FPGA architecture.
The FPGAs get a "bit" file, which can be converted to a
memory image to be put into an EPROM. The Spartan 3AN
and CPLDs have flash memory on-chip to hold the configuration
info. I program the CPLDs using a Xilinx parallel port JTAG
pod, there is newer and better USB stuff now, but this still works.
I have not used ghdl, I just use the Xilinx tools on Linux.
They have an integrated environment that works, but may not be the
most wonderful. So,you get schematic entry, VHDL and Verilog
synthesis, simulation from the HDL, simulation from the
synthesized logic, and a bunch of other tools to examine
the timing results, edit pin lists and timing constraints
and a bunch of other stuff. You can actually track your signals
through the logic fabric, which can sometimes be instructive when
things are not communicating properly on-chip.

On FPGAs you can synthesize a mini-logic analyzer on chip
(Chip Scope) and read it out via JTAG to track problems that
can't be solved with simulation.

Jon

[Jon Elson]

Winston wrote:

> Mr.CRC wrote:

>>
>> Gentle learning curve just doesn't apply to Xilinx software.
>
> I see what you mean. I downloaded and installed just now.
> Holey Cannolli! In the Good Old Days, you just supplied a source
> file and told the compiler to get started. The tutorial
> has me doing all kinds of gyrations, referring to unlabeled
> windows and sending me on a goose chase to locate buttons that
> are not visible on the existing screen, all with no explanation
> of *why* these things need to be done. Wow!

Ummm, you should have seen it BEFORE! It used to be REALLY
ghastly. The Aldec schematic entry nearly drove me nuts!
I hacked up my own libraries so I could use Protel schematic
entry instead, but there were compatibility problems I ran
into there. And, the synopsys simulator was the absolutely LEAST
intuitive GUI I have ever seen, it was insanely hard to do
anything. (sysnopsys, is that the right name for the ise
simulator back around 5.2?) Xilinx's own simulator is still
a little difficult to use, but much easier. I don't do
HDL work all the time, so I never get fully comfortable with
it, then it lapses when I don't use it for a while.

When you get error messages in the synthesis, that's where it gets
REALLY messy. The messages may be totally obscure and make it
very hard to find what is really causing the problem. You'd
think bi-directional busses are pretty common, and although the
intrinsic logic doesn't support them (they use muxes instead)
the LANGUAGE supports the concept, so they should be handled
better. You get tons of "net has no source" or "net has multiple
sources" when in fact the description is correct the way the
language is written. This always gives me fits as to whether these
warnings are real errors or just synthesis warnings with no
real impact.

Jon

[Jon Elson]

lang...@fonz.dk wrote:


>
> maybe I'm strange or have used xilinx too long, but I find rather
> straight forward;
>

Well, the more you use it, the easier it gets. If you use it a
LOT, then you don't forget where all the menus are hidden, what the
cryptic error messages actually mean in your code, etc.

Jon

[Winston]

Thanks a lot for this info
and that in your other post, Jon.
I find it extremely valuable.

--Winston

[k...@att.bizzzzzzzzzzzz]

On Thu, 09 Feb 2012 20:22:13 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 02/09/2012 08:19 PM, Nico Coesel wrote:
>> Phil Hobbs<pcdhSpamM...@electrooptical.net> wrote:
>>

>>> On 02/09/2012 06:23 PM, Jon Elson wrote:
>>>> Winston wrote:
>>>>
>>>>
>>>>>

>>>>> Sounds like I ought to contemplate a microcontroller
>>>>> implementation instead. Then I could use assembly,
>>>>> which I find entertaining.
>>>> Well, I do a lot of stuff where micros may be too slow,
>>>> or not parallel enough. VHDL is pretty easy to pick up.
>>>> And, you CAN enter a schematic, even in familiar 74xx
>>>> part numbers, wire it all up and have it turned into logic
>>>> on a CPLD or FPGA. Some interface glue projects I still
>>>> do it that way, although I am moving more and more to HDL.
>>>>
>>>> Jon
>>>
>>> I haven't done a PLD in quite awhile--my current toolset is Orcad PLD
>>> for DOS. ;) They're great for stuff where you need better timing
>>> coherence than the processor can give you, e.g. sampling.
>>>

>>> What's the easiest way to start with VHDL?
>>

>> I guess a good book with actual examples, not just a language
>> specification :-) Just make sure it covers writing functions and so
>> on. There is a lot of power in VHDL. In the past I've often designed
>> pieces of logic which can be configured for different widths,
>> channels, etc. That took some studying to get it right but it has paid
>> off big time in several occasions. It helps if you have a programming
>> background.

>>
>> There is also Verilog but I never understood Verilog. It makes me feel
>> like I'm looking at a netlist output from a schematic.
>>
>

>Is there an equivalent to K&R for VHDL?

I had a pretty good one but someone swiped it (and I don't remember the name).
:-(

The subset of VHDL used for synthesis is pretty easy to pick up. The entire
language, not so much. Learn it as you need it.

[k...@att.bizzzzzzzzzzzz]

On Fri, 10 Feb 2012 12:04:16 +0100, Jeroen Belleman <jer...@nospam.please>
wrote:

If you're having these troubles you don't "get" the language yet. It took a
while for it to "click" with me, too. The syntax is clumsy but hardly
baroque. It's designed to keep the designer for shooting himself in the foot
(see: C ;-).

>Also, I see many people, even those fluent in VHDL, draw little
>circuit diagrams before translating them into VHDL.

Your friends don't "get" it either. Yes, I'll sometimes draw a little circuit
but not usually because I can't visualize the VHDL, rather I really don't
understand the problem yet. VHDL is great for control logic (state machines).

>I think VHDL is a crutch, just like the 1984 rectangular logic
>gate symbols were a crutch for immature plotting software.

Utter nonsense. VHDL isn't perfect for every job but it certainly isn't a
"crutch". I can't imagine doing VLSI design without it (or similar).

[Jeroen]

VHDL is the wrong approach to the problem at hand. Of course it's
possible to describe structure using a one-dimensional language
like VHDL, but it's twisted. Just like it is twisted to use
schematic diagrams to describe a sequential process (like
LabView). Both work, but use the wrong abstraction. Both have
their partisans, despite the clumsiness. I like neither VHDL
nor LabView, for those reasons. I love C though. That just
'clicks' with me. Always did.

Jeroen Belleman

[k...@att.bizzzzzzzzzzzz]

Not at all. I felt much like you do, thirty years ago. It's a phobia, best
cured by doing. Once I actually used it, I found I actually like the
language. I'd never go back for a project of any size.

>Both work, but use the wrong abstraction. Both have
>their partisans, despite the clumsiness. I like neither VHDL
>nor LabView, for those reasons. I love C though. That just
>'clicks' with me. Always did.

Never used LabView. C absolutely sucks as a language.

[josephkk]

Hmm. Maybe not quite always, perhaps a lot like relay ladder logic?

?-)

[josephkk]

On Fri, 10 Feb 2012 10:02:51 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>
>One time about a dozen years ago, I was leading a team--an unusually big
>one for me, about 5 people--building a sensor system for use inside
>retail stores. We had a customer pilot installation set up for the
>Monday before Thanksgiving in a 50000 square foot box store in New
>Jersey, when my firmware guy crapped out on me a month ahead of time,
>leaving a complete mess. (I wrote the whole amusing story up for Optics
>& Photonics News--see
>http://electrooptical.net/www/footprints/fpwaropn.pdf if you're
>interested.) We couldn't push the date back, because we had a lift and
>a crew lined up, and more importantly, retailers won't let you fiddle
>with their ceilings between Thanksgiving and New Year's.

Fix your website. Requiring scripts for that size site is flat
irresponsible.

?-(

[Phil Hobbs]

That's a pretty random thing to say--my site is all classical
hand-tooled artisanal HTML: no scripts, no frames, no flash, no CSS
even.

And I don't take orders from you. What's got into you lately?

[John Devereux]

Phil Hobbs <pcdhSpamM...@electrooptical.net> writes:

> josephkk wrote:
>>
>> On Fri, 10 Feb 2012 10:02:51 -0500, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>> >
>> >One time about a dozen years ago, I was leading a team--an unusually big
>> >one for me, about 5 people--building a sensor system for use inside
>> >retail stores. We had a customer pilot installation set up for the
>> >Monday before Thanksgiving in a 50000 square foot box store in New
>> >Jersey, when my firmware guy crapped out on me a month ahead of time,
>> >leaving a complete mess. (I wrote the whole amusing story up for Optics
>> >& Photonics News--see
>> >http://electrooptical.net/www/footprints/fpwaropn.pdf if you're
>> >interested.) We couldn't push the date back, because we had a lift and
>> >a crew lined up, and more importantly, retailers won't let you fiddle
>> >with their ceilings between Thanksgiving and New Year's.
>>
>> Fix your website. Requiring scripts for that size site is flat
>> irresponsible.
>>
>> ?-(
>
> That's a pretty random thing to say--my site is all classical
> hand-tooled artisanal HTML: no scripts, no frames, no flash, no CSS
> even.
>
> And I don't take orders from you. What's got into you lately?

A virus? :)

--

John Devereux

[k...@att.bizzzzzzzzzzzz]

On Wed, 15 Feb 2012 22:54:14 -0800, josephkk <joseph_...@sbcglobal.net>
wrote:

Processes are sequential, but your analogy is a very good one. It is a lot
like ladder logic, in that way (with a process being one rung in the ladder).

[josephkk]

On Thu, 16 Feb 2012 09:07:27 -0500, Phil Hobbs

<pcdhSpamM...@electrooptical.net> wrote:

>josephkk wrote:
>>
>> On Fri, 10 Feb 2012 10:02:51 -0500, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>> >
>> >One time about a dozen years ago, I was leading a team--an unusually big
>> >one for me, about 5 people--building a sensor system for use inside
>> >retail stores. We had a customer pilot installation set up for the
>> >Monday before Thanksgiving in a 50000 square foot box store in New
>> >Jersey, when my firmware guy crapped out on me a month ahead of time,
>> >leaving a complete mess. (I wrote the whole amusing story up for Optics
>> >& Photonics News--see
>> >http://electrooptical.net/www/footprints/fpwaropn.pdf if you're
>> >interested.) We couldn't push the date back, because we had a lift and
>> >a crew lined up, and more importantly, retailers won't let you fiddle
>> >with their ceilings between Thanksgiving and New Year's.
>>
>> Fix your website. Requiring scripts for that size site is flat
>> irresponsible.
>>
>> ?-(
>
>That's a pretty random thing to say--my site is all classical
>hand-tooled artisanal HTML: no scripts, no frames, no flash, no CSS
>even.
>
>And I don't take orders from you. What's got into you lately?
>
>Cheers
>
>Phil Hobbs

Too itchy on the trigger finger. I saw the banner from NoScript and
closed the browser in disgust. It was rather premature. I do get a pip
form script kiddie crapware web sites where just a touch of clean HTML
would have done the job better. I am rather sensitive about them.

??-/