Multiple CPLDs on a PCB.

Hi,

Apologies if this isn't the best group, but there doesn't appear to be a comp.arch.cpld group.

I'm going to start learning about CPLDs to use them in my projects, but the algorithm I've developed will require a few CPLDs working on different parts of the algorithm in sequence. So part A of the algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They are all complete guesses at the moment, as I know next to nothing about PLDs in general, but I know that for my algorithm to run as fast as required, I will require multiple PLDs. I'm choosing CPLDs as from what I've read FPGAs can be a bit overbearing for a beginner due to the amount of features/number of gates they have, also CPLDs have more predictable timing?

So, I'm wondering just how difficult using multiple CPLDs on a custom PCB actually is? I'm sure it's achievable, but I would like to know how difficult this could be. Also, could any simulators be used to simulate a complex design with multiple CPLDs on a PCB? Finally, could anybody recommend any books for getting started in the CPLD world - I'm unsure to use Verilog or VHDL at the moment?

Thanks for your time. Nick.

Reply to
NickNitro
Loading thread data ...

Probably not the best direction.

You do not have to use all features on the first pass :)

On simple designs, yes. As multiple CPLDs get into the frame, it gets harder.

The real fish-hook comes, when you find "Part B" really needed 9 devices!

Not easily. You _could_ have two designs, one that is partitioned into the smaller blocks, and another that is the whole system. The whole system one would simulate - but you may have spotted by now, that such a whole systemm design, is a FPGA design flow :)

Download the development tools, and try some code in each. Search for come examples close to what you want to do. The tools can target BOTH cpld, and FPGA (& both languages), so you can actually get quite advanced in the design, before you commit to a PCB design. (or even a final device)

There are also cross-over CPLDs like MAX II and MachXO, and also the FLASH FPGAs from Actel and Lattice to look into.

Give a short list if what your design needs to do, and someone here might suggest a device family, and an expected speed range.

-jg

Reply to
Jim Granville

As someone who started designing with TTL, then PALs and GALs, then CPLDs, then FPGAs, I would take issue with that reasoning. I find FPGA's much easier to use if the alternative means using multiple of any sort of part. Generally there is a big advantage to fitting a design in a single part. Partitioning the design was always the biggest part of the design process when I used the smaller parts. Fitting the design in a single part also frees you from reworking your PC board when you realize you needed another signal in one of the CPLD's, or you run out of macrocells or internal routing.

Once you have made the decision to use a high-level language to design your logic, using an FPGA becomes actually simpler than the multiple CPLD approach. Also while CPLD's may have predictable timing, modern FPGA's have such fast internal timing that you generally can meet timing easily for nearly any design that runs in a CPLD. Even pin-to-pin timing can be fast in FPGA's nowadays. And if you look at the timing of the signals you route from one CPLD to another, and think of using only internal FPGA timing on those, you may find the design running considerably faster. Depending on your algorithm CPLD's can be bad for timing. For example if your equations end up with too many product terms you suddenly double the delay. You didn't mention the clock speeds you're shooting for, but those superfast CPLD's aren't so hot if you need to go through 2 macrocells or more between registers.

Also think of all of the connections you don't need to make when your design fits in one part. O.K. you don't have all those extra points to scope on when you debug, but there are better tools for debugging in FPGA's that don't require physical access to the chip guts (see ChipScope on the Xilinx site or ispTracy from Lattice).

There are plenty of threads on the language selection. No need to start up another one here. Google for Verilog vs VHDL for some heated discussions. Also check out comp.lang.verilog and comp.lang.vhdl for lots of threads on books for newbies, etc.

Good Luck, Gabor

Reply to
Gabor

Hi Jim,

Thanks for taking the time out to reply.

May I ask why?

But if everything is solidly designed before code is started, then this shouldn't happen?

If done correctly though wouldn't multiple CPLDs working on different parts of the algorithm perform better overall than a single FPGA?

Appreciated, I'll have a look.

Thanks again, Nick.

Reply to
NickNitro

Hi Gabor,

The only thing is is that my algorithm has to work on 2^17 bits, all in one go, so it would have to work on one group then another group then another etc... until it has worked on all groups of bits. However, with the constant input output to the fpga I thought it would be a major delay, so I (naively) assumed using multiple CPLDs would be best because they would have the same wire delay as that as an fpga.

CPLD's aren't so hot if you need to go through 2 macrocells or more between registers. Well to be honest I don't have a clue. But I again naively assumed that having more than one pld working on the problem would be better than one pld working on the problem.

another one here. Apologies, I wasn't intending to create a flame war, but instead hoping for suggestions on a book or two that would give me the pros and cons of the languages to help me make a decision.

I'm needing a bit more than luck I think for something as ambitious this - thanks anyway.

Nick.

Reply to
NickNitro

My subsequent comments explained why.

Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes.

That would depend on the design details, which is why you should get the tools, and actually implement the design before starting the PCB.

Device retargeting is not difficult.

-jg

Reply to
Jim Granville

Don't you ever get a new idea after a design has been running for a while?

Why would you think that way? Getting on/off chip is usually slow.

If your FPGA is big enough to hold the whole design, I'd expect it to be faster.

CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that.

Another potential advantage of FPGAs is that you can get prototype boards that might be good enough for your problem.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

Nick, you are much better off doing this design inside one FPGA, even if you have to operate sequentially on 128000 bits (is that what you really meant with 2^17 bits?) I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk. I would focus on one of the Xilinx Spartan evaluation boards, and go to a Virtex-4 evaluation board only if the design really mushrooms (which I doubt)

I would first sketch out the basic design on paper, to easily see the speed bottlnecks, but that may just be my style... Peter Alfke, Xilinx ============================

Reply to
Peter Alfke

I'd recommend using an FPGA. The CPLD pins/interconnects can be deadly, not to mention slow. And as you mention, simulation of the entire design is a lot easier if it's all in one chip.

John

Reply to
John Larkin

Hi all,

good designer allows for late changes. Well I don't think I've mentioned just how far the algorithm is through development, although is it completely designed and has been finalised by many people and all have signed it off. It has been designed down to the bit level and has been tested in a software environment with no flaws (strong words, but every possible scenario has been tested through brute forcing, so nothing has been missed); so I can safely say the algorithm being altered at this stage won't happen.

I've done what you've suggested and had a look at the Xilinx web pack and if I've done it correctly, device retargeting seems to be just be selecting a different device from the list? Or am I greatly oversimplifying to what I imagine?

Very much, although as above, the algorithm is set in concrete.

Naivety. ;) I'm coming from a software background, so unfortunately I'm relying on software knowledge, where more cores==better performance.

some designs that will be faster on CPLDs because they take advantage of that. I'm afraid I don't have a clue what 'wide inputs' are, but I'll take your word at it. ;)

Yes, that's correct.

a lot of work, time, money, and risk. Thing is, once it's working fine in the FPGA/evaluation board environment, I'll still need to move the chip to a custom PCB so it has the correct peripherals?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - -

Speed is extremley important to this problem, I'm not too worried about the difficulty of this - just the final result; since ideally execution of the algorithm cannot take more than 15-20 milliseconds. I hope you don't think I'm being completely ignorant and rude asking this, nor do I want you to think that I don't appreciate your advice - although I can't help but think something like the following would be faster - I'm stuggling to shake off my software thinking:

formatting link

Where 32 bits would be passed from a 'CPLD Memory Manager' to a 'CPLD Parallel Algorithm', and while that was working, another 32 bits would be passed from the same 'CPLD Memory Manager' to the next 'CPLD Parallel Algorithm', etc... and each 'CPLD Parallel Algorithm' when complete would check that the other 'CPLD Memory Manager' was available to take data and if so pass it to the memory manager, and then asking the first memory manager for some more data.

Again, I apologise for sounding like a broken record. I'd appreciate your thoughts for the pros and cons for something like this.

Thanks, Nick.

Reply to
NickNitro

good designer allows for late changes.

probably some designs that will be faster on CPLDs because they take advantage of that.

eliminates a lot of work, time, money, and risk.

Nick, you can implement the same (or many other) structure(s) in an FPGA. You have many hundreds of I/O pins, wide adders and multipliers (if you need them) and tens of thousands of flip-flops (rather scare resources in CPLDs). You can have many (hundreds) of independent or dependent operations going on in the FPGA simultaneously. Don't forget pipelining to enhance throughput by using many of the "free" flip- flops...

But you have to make the decision that you are comfortable with. Regarding peripherals, you can get them "for free", i.e. without design effort, in the more sophisticated development boards, like the Xilinx ML405. That allows you to concentrate on the uniqueness of your design, and avoid pc-board lay-out, manufacturing and debugging headaches, for just a few hundred dollars or pounds in your case Peter Alfke (we are all just trying to preserve your good spirits and your sanity)

Reply to
Peter Alfke

Take a llok at: HDL Programming fundamentals, Nazih M. Botros, Da Vinci Enginnering press.

It is a simultaneous introduction to VHLD and Verilog, so you may compare pros and cons of both languages easily.

Try both in some FPGA design tool, and decide for yourself.

Best regards,

Zara

Reply to
Zara

More gates means you don't need to worry about squeezing your design to fit, so you can concentrate on getting it working. You can ignore peripherals etc. you don't need, and if you start with one of the many devboards, you don't need to worry about the more complex multiple power supplies or config devices.

Reply to
Mike Harrison

Ok, thanks everybody for the comments. It seems I've underrated FPGAs in comparison to CPLDS. :)

Thanks again, Nick.

Reply to
NickNitro

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.