CPLD: glue only or functional blocks too? [message #7419] |
Fri, 03 April 2020 14:52  |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
For a design I'm working, I'll need a CPLD (probably a MAX V) for glue logic and a DRAM controller.
The board also needs all of those other desirably I/O devices like UARTs, SPI, etc. I could put discrete ICs on the board for each function or I could implement them in the CPLD as programmable logic. [I know the latter is a slippery slope that leads to doing everything, including the processor, in the CPLD/FPGA.]
As I see it:
The advantages to putting "everything" in the CPLD:
- reduced board space due to fewer chips
- lower cost due to smaller board and fewer BOM items
- design flexibility
The disadvantages seem to be:
- increased complexity of the CPLD logic due to the additional functionality
- less "Retro" aesthetics
What is your opinion on the pros vs cons of a "do all" CPLD?
Mike
[Updated on: Fri, 03 April 2020 15:03] Report message to a moderator
|
|
|
|
|
Re: CPLD: glue only or functional blocks too? [message #7451 is a reply to message #7441] |
Tue, 07 April 2020 09:10   |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
Good point about the "standardized software interfaces". It's fairly easy to throw in a fixed baud rate UART into the CPLD but implementing one that is 100% compatible with the Linux 16550 driver is a whole different ballgame.
The local FPGA expert once told me one should aim to keep under about 40% usage of the logic gates. Above that and things get increasingly difficult. Sort of like routing PCB, as long as you have lots of spare area and layers, routing isn't too difficult. [Usually!]
A DRAM controller will definitely be in the CPLD as I know of no other "practical" solution. Yes, I've seen it done in a couple of GALs [KISS030 if I remember correctly]. I think I've seen it done in discrete 7400 series chips. But the ease of fixing most of my mistakes makes the CPLD the clear winner for this functionality.
Mike
|
|
|
Re: CPLD: glue only or functional blocks too? [message #7474 is a reply to message #7451] |
Thu, 09 April 2020 09:03  |
wsm
Messages: 232 Registered: February 2017 Location: AB, Canada
|
Senior Member |
|
|
I've primarily been using the Xilinx CPLDs. Although I've used 100% of the macrocells in a few designs, I've generally found that 90+% useage on the first pass still allows for expansions and changes without causing significant problems. The bigger restriction I've often encountered is with complex equations and the number of function block inputs.
The Xilinx software allows you to limit the function block inputs and I generally limit it to N-1 or N-2 on the first pass which allows me to add new inputs to the function blocks on a revision. Of course this depends on the complexity of the equations ... it's not an issue if most of them are quite simple with few inputs but large fan-ins for complex equations can restrict the number of useable macrocells and can cause logic splitting, extra timing delays and increased macrocell useage. Without splits, complex equations with large fan-ins can have a speed advantage in CPLDs versus FPGAs.
There's a bit of chicken and egg scenario with the PCB layout, pin assignments and the CPLD fitter. I tend to create dense PCB designs which leads to assigning pins based on ease of PCB routing. However, the fitter is oriented to speed and minimizing logic splits. Sometimes swapping two adjacent pins in different function blocks can make a very significant difference for the fitter in the logic / timing.
CPLDs can be used to build some pretty powerful functions similar to a dedicated I/O processor and having built a working DRAM controller in 7400 logic, I agree that it would be a practical example. However, just like FPGAs you have to be very careful about metastability, especially if there are multiple clock domains. I've learned the hard way that I tend to think in terms of asynchronous logic whereas the electrons in CPLDs and FPGAs are best kept in their expected places with synchronous logic.
|
|
|