CPLD HDL?

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 "

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.

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

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).

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

Pere

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

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.

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

(...)

(Schematic, VHDL and Verilog in one

PLD/FPGA crossover parts.

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

--Winston

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

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.

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

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.)

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

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

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.

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

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.

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

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.

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

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:

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

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

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).

--

John Devereux

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.

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

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

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

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

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

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

--Winston