Why you think an FPGA/CPLD is better from MCU for interface and protocol bridging applications?

[e-music]

Hello,

I've been doing many embedded designs based on MCUs for quite so long. I have never used an FPGA or CPLD in any of my designs. However, I have a classical protocol interfacing/bridging application where CPLD seems a great fit. I even found many open and free IPs for some of the intended application.

One of the reference designs I was studying implements a great deal of the protocol bridging application in a single CPLD device. The IP core implements the DMA, bridging interface, and the interface to the host processor. However, the host interface is a "Wishbone" interface. From the RD, it says the Wishbone interface is a 32-bit data in/out interface. As you might know, most MCUs in the market do not support data bus width over 16 bit for external memories.

I was told recently a CPLD/FPGA is better for bus interfacing and protocol bridging applications. From an experienced designer perspective, could you please explain in a few words why a CPLD/FPGA is better for this type of application?

Thanks

 

[KlausST]

Hi,

You say" where CPLD seems a great fit" ... why do you think so?

I was told recently a CPLD/FPGA is better for bus interfacing and protocol bridging applications.

Who told you this? And what did they tell are the benefits?

Such statements .. without the whole source, without context ... are almost useless for a forum discussion.
Is red better than violet? Both are just colors ... there is no general objective "better" of one above the other.
But if you talk about laser beam color for cutting 3mm thick PMMA ... there will be a "better".
****
From my perspective there is no general "better" for FPGA vs MCU.

CPLD/FPGA is hardware, has to be coded in hardware style, can process a lot in parallel
MCU operates with software. It processes data woth commands one after the other.
So they are different and each has it's benefits and drawbacks.


As so often: I think you have a clear requirement ... but ask very generalized questions.
Like: I want to go on vacation...should I use a plane or a train? There is no general answer. If the dustance us just 50 miles a plane may make not much sense ...but if there is an ocean inbetween, there may be no railway at all.
--> I recommend to ask very clear questions by giving exact informations about your requirement.
Tell us about both protocols, speed, complexity, bus width, data, block size, stream .... which exact MCU ... with which interface?

In many cases even a combination of CPLD/FPGA and MCU is the preferred solution.

Klaus

 

[barry]

An FPGA can perform multiple tasks simultaneously. An MCU generally performs tasks sequentially. This is not totally true, as MCUs can have built-in DMA controllers, etc. An FPGA is more flexible and faster than an MCU. Generally, you can get a higher data rate with an FPGA.

 

[e-music]

Hi,

You say" where CPLD seems a great fit" ... why do you think so?


Who told you this? And what did they tell are the benefits?

Such statements .. without the whole source, without context ... are almost useless for a forum discussion.
Is red better than violet? Both are just colors ... there is no general objective "better" of one above the other.
But if you talk about laser beam color for cutting 3mm thick PMMA ... there will be a "better".
****
From my perspective there is no general "better" for FPGA vs MCU.

CPLD/FPGA is hardware, has to be coded in hardware style, can process a lot in parallel
MCU operates with software. It processes data woth commands one after the other.
So they are different and each has it's benefits and drawbacks.


As so often: I think you have a clear requirement ... but ask very generalized questions.
Like: I want to go on vacation...should I use a plane or a train? There is no general answer. If the dustance us just 50 miles a plane may make not much sense ...but if there is an ocean inbetween, there may be no railway at all.
--> I recommend to ask very clear questions by giving exact informations about your requirement.
Tell us about both protocols, speed, complexity, bus width, data, block size, stream .... which exact MCU ... with which interface?

In many cases even a combination of CPLD/FPGA and MCU is the preferred solution.

Klaus

Hi Klaus,

Well, I know I didn't elaborate much about the specific application intended, but this is for a commercial product and I'm not sure if I can expose much about it here. I have read several ALTERA/INTEL and Xilinx literature on their devices and I read on many pages things that say FPGA or CPLDs are better when implementing interfaces or bridging applications between different protocols. Well, if you want to ask me why, I'm not sure why because I didn't use an FPGA before, and I wasn't the one who made these statements, neither do I want to make useless statements for a discussion. If I found reference for that statement, I will share the link here.

Let me try to be more specific, perhaps this should make things much easier for an answer. Although I didn't expose pretty much every nitty gritty of the intended application, I guess I made it half way. In other words, if you refer to the first post, I did mention that I found an off-the-shelf IP core for a Lattice CPLD for the interface bridging application sought, however, the host interface for the CPLD is a Wishbone interface. And if that helps, the MCU I want to interface with is STM32. Regardless of series/package/HCLK, because I might switch to a different one later if that proves necessary. Of course, it has to provide full FMC (not FSMC) with 144+ pin package, 120 Mhz+ core, and at least 256 KB of SRAM.

By the way, I understand where you're coming from. I myself hate to deal with ambiguities, but really sorry, it was intended!

Zaher

--- Updated Aug 2, 2022 ---

An FPGA can perform multiple tasks simultaneously. An MCU generally performs tasks sequentially. This is not totally true, as MCUs can have built-in DMA controllers, etc. An FPGA is more flexible and faster than an MCU. Generally, you can get a higher data rate with an FPGA.

Guys, thank you for all of your answers. But I really didn't ask or start a discussion on whether MCU is better from FPGA/CPLD, or what is the difference between them, not at all. Yes, I didn't use one yet, but I read a lot about them, how they function, and how designs are implemented using one. I just asked whether an FPGA/CPLD is better for the application aforementioned earlier. I've seen many designs where higher data rates, a lot of IOs, interfaces, etc, all implemented with FPGAs, yes you're right. For example, most logic analyzers in the market are designed around FPGAs.

I was trying to implement a parallel 16-bit interfacing to an ASIC controller, but things got very complicated as I had to deal with multiple timers, one activating the other, and DMA to generate the tight timings requirements for the interface. Then I came across the reference design based on a CPLD. Anyways, I would be better off if I can get the job done without FPGA/CPLD. Not sure how steep is their learning curve for those coming from MCUs only.

 

[danadakk]

PSOC has a MCU + Fabric architecture, might possibly be a solution.

This is the onchip resources/components, many instances multiple copies, and its routable. Each
resource in PSOC language is a onchip component.

The community has also done custom components that can be used in chip, including
CPLD. This is done by schematic capture and/OR Verilog.

Validated Components

Validated Community Components The components listed on this page correctly follow the Development and Submission Guidelines for Community Components. Any questions regarding the validation process or results should be directed to psoc_creator_feedback@cypress.com

cypresscomstg.prod.acquia-sites.com

IDE (PSOC Creator or MODBUS) and compiler free. Low cost low pin count board (CY8CKIT-059,
$15) excellent start, or higher cost boards with larger pin count avaialble.

Regards, Dana.


Regards, Dana.

 

[e-music]

Thank you Dana. These might be great for many designs. I've seen them on Cypress' a couple of years ago, but totally forgot about them. As far as I remember, I made support request asking whether a DMA with full DREQ/DACK handshake mechanism can be implemented using these devices. They must have more advanced devices now with higher LEs count. Will definitely consider them at some point.

Regards,


Zaher

 

[KlausST]

Hi,

As already said, the main difference is: HW vs SW

Many interface bridges don't necessarily need a software / microcontroller. But for some interface bridges it would be a huge effort to build all in HW.
We can not say whether you need a microcontroller at all (how you further will process any data). We can not say whether it is an important data stream where you must never miss data, what error detections are involved, if erroneous data (packets) are requested again... or dismissed ... or interpolated...how big of a buffer you need.. synchronous, isochronous, unidirectional, bidirectional.....

"Better" has no meaning if it's not clear "on what item". Smaller, cheaper, part count, development time, debugging (time), peak or average data throughput, power consumption, PCB routing, and many more.

They are so different that one simply can not compare them. Is "fuel" (HW) better than an "engine" (SW)?
To run an engine, you need fuel, but to burn fuel you don't need an engine.
To run software you need some hardware, but to run hardware you don't necessarily need software.

Without application details (interfsce types, protocols, data throughput, and so on) the discussion will be almost useless. A lot of effort, text, guessing, assuptions, time ... at our side .... for only a small percentage of useful informations for your side.

Klaus

 

[danadakk]

Thank you Dana. These might be great for many designs. I've seen them on Cypress' a couple of years ago, but totally forgot about them. As far as I remember, I made support request asking whether a DMA with full DREQ/DACK handshake mechanism can be implemented using these devices. They must have more advanced devices now with higher LEs count. Will definitely consider them at some point.

Regards,


Zaher

The DMA controller is not a GP DMA engine in the sense of complete HW control
of the state machine that governs the transfers. That is done by the transaction descriptors
and set into motion by a TD request. So no on the general purpose DMA we all think of
from the 80's, 90's and now controller types we are used to. Does that mean your application
cannot be managed by that architecture, I do not know.

As far as LEs its still limited to their UDB blocks, 16 max. More recent focus is on dual core,
PSOC 6, for crypto and IOT/BLE, shared and isolated busses.

https://www.infineon.com/dgdl/Infineon-Universal_Digital_Block_(UDB)_Editor_Guide-Software+Module+Datasheets-v01_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0eb07eca2a90

Regards, Dana.

 

[e-music]

So no on the general purpose DMA we all think of
from the 80's, 90's and now controller types we are used to. Does that mean your application
cannot be managed by that architecture, I do not know.

Yep, I totally agree. That's actually what I'm trying to achieve. By the way, you seem familiar with Cyperss/Infineon ecosystem. I went to their website yesterday and spent some time reading many datasheets and reference designs for products similar to what I'm trying to achieve. It seems I've missed on a lot of opportunities to save time and reach my goal trying to re-invent the wheel with another architecture.

Anyways, if you're familiar with the General Programmable Interface (GPIF) available on some of their devices, I was reading their AN87216, and found the following:

If you see the DACK and DRQ, I don't know if these emulate the classic general purpose DMA. Anyways, the good news is, even if this didn't work for something, it would absolutely help on other. Like I said earlier on my original post, I have a reference design for the intended application on a CPLD, but the interface requires 32-bit data bus. As you can see in the following figure:

This would probably solve the problem. Not only this, but also generating timings for any interface seem much easier when compared to other MCUs.

--- Updated Aug 5, 2022 ---

Hi,

As already said, the main difference is: HW vs SW

Many interface bridges don't necessarily need a software / microcontroller. But for some interface bridges it would be a huge effort to build all in HW.
We can not say whether you need a microcontroller at all (how you further will process any data). We can not say whether it is an important data stream where you must never miss data, what error detections are involved, if erroneous data (packets) are requested again... or dismissed ... or interpolated...how big of a buffer you need.. synchronous, isochronous, unidirectional, bidirectional.....

"Better" has no meaning if it's not clear "on what item". Smaller, cheaper, part count, development time, debugging (time), peak or average data throughput, power consumption, PCB routing, and many more.

They are so different that one simply can not compare them. Is "fuel" (HW) better than an "engine" (SW)?
To run an engine, you need fuel, but to burn fuel you don't need an engine.
To run software you need some hardware, but to run hardware you don't necessarily need software.

Without application details (interfsce types, protocols, data throughput, and so on) the discussion will be almost useless. A lot of effort, text, guessing, assuptions, time ... at our side .... for only a small percentage of useful informations for your side.

Klaus

Hi Klaus,

Thank you again for your excellent follow up. However, I'm so sorry if I do not agree with most of your assertions. If you refer to the original post, you will realize that I provided a different path/requirement to the solution sought. Did you notice that you kept replying on a portion of the question, ignoring the other, which was the core of the problem/solution?

Now, I'm so sorry about my first "useless" and stupid question. Now, could you please tell me how to connect a CPLD to a STM32 MCU over Wishbone interface?

** Update **
Ah,, sorry, STM32[FMC] <> [Wishbone IF]CPLD

 

[KlausST]

Hi,

sorry, I don't understand what information you are looking for.
I see a lot of phrases and ideas, but I don't see how you want to put them together.
Some may be optional, some mandatory ... but I don't see which is which.

Some sort of detailed sketch certainly would be helpful.

Klaus

 

[FvM]

As for interface data rates, example FX3 has maximal throughput of 100 MHz * 32 bit (3 GBPS). This data amount can be handled e.g. by an ARM processor with 32 bit bus interface. No need to use a FPGA.

The other point is continuous ("maintained") data rate. An embedded processor will probably not be able to process the data at 3 GBPS. Connecting a FPGA between interface device and FPGA won't increase the troughput as such. You might however intend some kind of data decimation preprocessing in the FPGA, aspects that are yet missing in your posts.

 

[dick_freebird]

My take is, a uC has flexibility but needs "stuff" and tends
to be I/O poor, and executes code at clock rate, often low-ish,
often multiple cycles per instruction, and sequentially. Errors
in execution need to be caught and trapped out.

A CPLD tends to be I/O rich, higher clock rate, can be made
to to "parallel stuff" and its behavior can be constrained by
design to handle error inputs (this is probably an iterative
chore in either SW or HW implementation). Many CPLDs
have adequate internal memory to make a simple system
without adding a lot of "stuff".

I'd think about some of the small FPGA dev boards as a
trial.

Some FPGAs even have uC IP available to blast into the
config as part of the logic load. And I believe I may have
seen ones with a dedicated microwhatever core as part
of the fabric, but I don't pay much attention as this all
slides by, unless somebody's talking about powering it.
So maybe you don't even have to choose.

 

[e-music]

Hi,

sorry, I don't understand what information you are looking for.
I see a lot of phrases and ideas, but I don't see how you want to put them together.
Some may be optional, some mandatory ... but I don't see which is which.

Some sort of detailed sketch certainly would be helpful.

Klaus

Thank you again for the input. I almost found the solution based on certain devices from Cypress/Infineon. One of the solutions is to use an off-the-shelf Cypress/Infineon device that can provide the bridge application I'm looking for. Another solution would be interfacing to the CPLD I mentioned earlier. Cypress FX3 has GPIF that can be configured for 32-bit data bus. Not only this, but also it can be configured to interface with any ASIC.

--- Updated Aug 6, 2022 ---

My take is, a uC has flexibility but needs "stuff" and tends
to be I/O poor, and executes code at clock rate, often low-ish,
often multiple cycles per instruction, and sequentially. Errors
in execution need to be caught and trapped out.

A CPLD tends to be I/O rich, higher clock rate, can be made
to to "parallel stuff" and its behavior can be constrained by
design to handle error inputs (this is probably an iterative
chore in either SW or HW implementation). Many CPLDs
have adequate internal memory to make a simple system
without adding a lot of "stuff".

I'd think about some of the small FPGA dev boards as a
trial.

Some FPGAs even have uC IP available to blast into the
config as part of the logic load. And I believe I may have
seen ones with a dedicated microwhatever core as part
of the fabric, but I don't pay much attention as this all
slides by, unless somebody's talking about powering it.
So maybe you don't even have to choose.

Hi,

I've done many of those parallel interfacing stuff for variety of projects and, like you said, it wasn't a breeze implementing every kind of parallel-like interface with DREQ/DACK DMA mechanism, very tight timing requirements in the range of nano-seconds, hardware timers, interrupts, etc. I don't know, but FPGAs/CPLDs seem intimidating for me. That doesn't mean I didn't read much about them. I even remember that I played with the Quartus, Altera/Intel FPGA designer IDE a while back, but not to the extent that allow me to implement one in a design.

--- Updated Aug 6, 2022 ---

Oh before I forgot to mention, can you suggest a low-cost FPGA/CPLD board that can run embedded Linux and has a PCI interface?