Which CPLD vendor to choose today?

[janoc]

She's complaining that 240 logic cell devices are too large.  I think that Spartan is probably even bigger than what she wants.

I was only completing the info on FPGA boards that Mike wrote. As others said before, it is likely easier to learn programmable logic on an FPGA than fight with the tight constraints of a CPLD.

And when package size is concerned, you will be really hard pressed to find a CPLD under 32-48 pins. On a pre-populated devboard it is a moot issue anyway.

[nctnico]

It's true an FPGA won't easely get you in trouble with limited resources for a first project. OTOH it may cause people to get completely lost when they try to understand how their code translates into the programmable elements (primitives) of the device.

[mikeselectricstuff]

It's true an FPGA won't easely get you in trouble with limited resources for a first project. OTOH it may cause people to get completely lost when they try to understand how their code translates into the programmable elements (primitives) of the device.

That isn't something a beginner needs to go anywhere near though. You have to get fairly deep into things before you need to know about that stuff. If you're well away from fully utilising space or speed you may never need to, though it can be interesting to look at the place/route diagrams.

[janoc]

That isn't something a beginner needs to go anywhere near though. You have to get fairly deep into things before you need to know about that stuff. If you're well away from fully utilising space or speed you may never need to, though it can be interesting to look at the place/route diagrams.

Personally I found it fairly enlightening to look at the generated RTL. Xilinx ISE allows displaying the generated code as a schematics of flipflops and gates and it really drives the point home when you can actually see that e.g. your VHDL state machine translates into a counter + decoding logic or that there really isn't any "black magic" behind something like an SPI interface, just a long strings of flip-flops forming a few shift registers.

It is probably less useful for complex designs, but for simple things when learning the HDL it does help to understand what is actually going on. However, whether you are building for an FPGA or CPLD makes a little difference here, unless you are using some built-in features of the FPGA - those show only as opaque boxes.

[mikeselectricstuff]

That isn't something a beginner needs to go anywhere near though. You have to get fairly deep into things before you need to know about that stuff. If you're well away from fully utilising space or speed you may never need to, though it can be interesting to look at the place/route diagrams.

Personally I found it fairly enlightening to look at the generated RTL. Xilinx ISE allows displaying the generated code as a schematics of flipflops and gates and it really drives the point home when you can actually see that e.g. your VHDL state machine translates into a counter + decoding logic or that there really isn't any "black magic" behind something like an SPI interface, just a long strings of flip-flops forming a few shift registers.

It is probably less useful for complex designs, but for simple things when learning the HDL it does help to understand what is actually going on. However, whether you are building for an FPGA or CPLD makes a little difference here, unless you are using some built-in features of the FPGA - those show only as opaque boxes.

Abssolutely - it is interesting to look at, but you don't need to understand it to get the job done.
In exactly the same way that it's not necessary to know any assembler to effectively use a C compiler, but it can be very useful when optimising or debugging strange behaviour.

[Laura]

She's complaining that 240 logic cell devices are too large.  I think that Spartan is probably even bigger than what she wants.

At this point, there's several of us getting advice on this thread. FPGA suggestions might be correct for other readers.

For my project, an FPGA is overkill. A small CPLD in a 44 or 48 pin package is a better choice. I also want the result to fit in an overside cable plug or dongle. The resulting cable needs to quite literally go out into the field.

I don't fear running out of synthesis logic. I've hacked enough digital logic that I know what I want for the underlying implementation. In terms of not knowing what some "code" synthesizes to, I may have the opposite problem: I may have to hunt around for the magic Verilog spell to cast to get what I want.

And FYI, my project has changed a bit: Due to frustration with the FTDI chip, I'm going to use a different FTDI mode and a bigger (64 macrocell) CPLD that takes on more functionality.

[janoc]

Abssolutely - it is interesting to look at, but you don't need to understand it to get the job done.
In exactly the same way that it's not necessary to know any assembler to effectively use a C compiler, but it can be very useful when optimising or debugging strange behaviour.

Well, certainly not necessary if you know what you are doing already. However, for me, as someone who is originally a "software guy" and more familiar with basic discrete logic, seeing the results of the synthesis translated to actual flip-flops and gates really helped me to understand what I am doing and where did I screw up. I am speaking about the value of it for learning the HDL, not necessarily for writing production code.

And the analogy with the assembler vs C - it is not exactly the same thing. Yes, C is compiled to assembler and VHDL/Verilog to RTL, but that's where the similarity ends. With C I have a debugger or at least something like printf() that I can poke and prod the binary with when something isn't working right. I can't really see inside of that FPGA or CPLD, only observe what is going on from outside (yes, I am aware there are some debugging/probing tools, but I don't have access to those). So having a clue what could actually be going on inside is extremely helpful. I have also found it really indispensable when actually trying to fit a larger design I was working on into a CPLD, to see where I could fix some inefficiencies and save some flip-flops and thus CPLD cells.

[nctnico]

It is always a good idea to have some debug pins on an FPGA/CPLD design. Usually you don't care much about timing on a debug port so they don't eat any of the 'valuable resources'.

[janoc]

It is always a good idea to have some debug pins on an FPGA/CPLD design. Usually you don't care much about timing on a debug port so they don't eat any of the 'valuable resources'.

Of course, that is what I usually do.

However, what I had in mind was something akin to a source code debugger that would allow you to step through the code and check variables. I don't think that such thing even exists for the FPGAs. The concept of "stepping through" doesn't even make much sense, because of the highly parallel nature of the thing. I know that there are some things available from Xilinx that allow you to virtually probe the content of registers and other things in your design through a debug port, but I don't have that. One can always synthesize a virtual logic analyzer on the chip to make the internal state accessible from outside, but that it not really an option on the small CPLDs. And even if you do that, you still don't really get to see the connection between your VHDL/Verilog lines and the data coming from the chip.

[nctnico]

The proper way of debugging an FPGA design is simulating it. This allows to probe any signal in a design from a waveform viewer. This works very well once you have programmed a proper test bench.

[JohnnyP]

I did my first and so far only CPLD design back in '07, reading online tutorials, etc.

I used the 44 pin EPM7064STC44-10N

I layed out the pcb as I was designing the logic in the Altera.  The Altera software said 94% (eek) utilization.  It's a good thing it worked because there wasn't room for the next larger device.

I use the Quartus 4.2 Web edition, which has schematic entry.

I didn't know the parts were obsolete when I designed it, but they are still available from Mouser and Digikey at less than $9.

[mikeselectricstuff]

The proper way of debugging an FPGA design is simulating it. This allows to probe any signal in a design from a waveform viewer. This works very well once you have programmed a proper test bench.

There is no such thing as "proper", only more or less appropriate for a given set of circumstances.
Simulation is often difficult or impossible when interacting with  with complex, unpredictable or non-synchronised signals - it will often be way quicker to test hardware than set up everything for simulation.

[nctnico]

That is only true for poorly specified hardware. Once you have the signals inside an FPGA or CPLD simulation is much quicker than going through synthesis & route to just try something. One of the projects I'm currently working on involves an FPGA design which takes about 30 minutes to get through the synthesis stage and another 15 minues for place & route. If I need to make a major addition or change I simulate that part first otherwise it just takes too long to try & test something let alone getting different debug signals out.

[mikeselectricstuff]

That is only true for poorly specified hardware. Once you have the signals inside an FPGA or CPLD simulation is much quicker than going through synthesis & route to just try something. One of the projects I'm currently working on involves an FPGA design which takes about 30 minutes to get through the synthesis stage and another 15 minues for place & route. If I need to make a major addition or change I simulate that part first otherwise it just takes too long to try & test something let alone getting different debug signals out.

True for complex stuff, but where compiles are seconds rather than minutes, it's often quicker to just program it.
Hence "most appropriate" not "proper"

[Muxr]

So I have to say I am quite pleased with the MachX02. Thanks Mike!

Over the weekend I implemented a simple SPI LED driver. It's basically ESP8266 -> MachX02 -> LED Matrix, ESP8266 is just sending some binary counter data (slowed down quite a bit), and the CPLD is driving the LED matrix with the data in the frame buffer.

[ale500]

Those MachXO2 are great !. The software works quite well and is fast at compiling/routing and so on. But I saw that once you get over like 70 % it may fail to route... What I like the most is that you can get purely 3.3 V parts, no need for multiple power rails, and an internal oscillator... I use them for various CPU developments... if they only were 5 V tolerant

[Muxr]

Those MachXO2 are great !. The software works quite well and is fast at compiling/routing and so on. But I saw that once you get over like 70 % it may fail to route... What I like the most is that you can get purely 3.3 V parts, no need for multiple power rails, and an internal oscillator... I use them for various CPU developments... if they only were 5 V tolerant

Yes! I really haven't run into many issues getting this going, and I am fairly new to FPGAs, did a bit of learning of Verilog, I got a decent handle on the principle now. The hardest part was deciding between Verilog and VHDL, I picked Verilog since it's more common here in the US. Also TQFP package instead of BGA is nice as well. I do get worried they might discontinue them with the release of MachXO3 but probably not for awhile.

Ice40 series looks interesting too, for low power applications. I might give those a try at some point as well. Lattice seems to have the low end small FPGA market on the lockdown.

[ale500]

Those MachXO3 seem to come only on BGA packages  boomer
I do not think that they will phase-out the MaxchXO2 that soon, I mean they are still offering the MachXO line...
I also picked up Verilog instead of VHDL... here in Germany is the latter more widespread, I am not german so it is ok ... Once you understand how to build a circuit and solve problems with programmable logic, the language shouldn't pose a problem anymore....