Control multiple MicroBlaze cores with a custom Verilog Module

[BTaylor]

Hello!

I'm using a CMOD S7 FPGA module to collect data and want to do several things in parallel. I need a main Verilog module to generate input data for the system being tested and measure the output data. At the same time, I want to measure the temperature and save the data to an SD card without interrupting this process. My solution is to have a Verilog module that generates/measures data and 2 MicroBlaze cores that poll signals from the Verilog module to do their respective operations in parallel. 

Is it possible connect 2 MicroBlaze cores to a single Verilog module, with separate applications on each MicroBlaze core to poll the module and write to SD card/read temperature sensor respectively? Note: In order to use a PMOD with CMOD S7, I have to use Vivado 2019.1 with Xilinx SDK.

Thanks!

[zygot]

2 hours ago, BTaylor said:

I'm using a CMOD S7 FPGA module to collect data and want to do several things in parallel.

Great! That's exactly what programmable logic does very well.

Why no just ditch MicroBlaze and the SDK and implement the whole thing in Verilog?

[D@n]

If I recall correctly, MicroBlaze does not work well with other MicroBlazes.  The specification only warrants one in a system.  This was at least the answer given to me when I pointed out that Xilinx's MIG controller couldn't handle exclusive access.

Backing up a bit.  To do multiple CPUs in a design (properly), you need some form of communicating between them.  This is typically done via atomic accesses over the bus.  AXI calls this capability "Exclusive access", and there's quite the protocol behind it to do it.  When I was studying how to implement exclusive access on my own, I discovered the MIG did not support it.  I think Microblaze had instruction support for it, but the MIG did not.  When digging I seem to recall someone saying that the documentation specifically disallowed Microblaze from ever working in a multi-CPU system, so this would never be an issue.

In other words--you are doing something new, and untested.

Dan

[zygot]

2 hours ago, D@n said:

If I recall correctly, MicroBlaze does not work well with other MicroBlazes.

No doubt true. MicroBlaze isn't the only soft-processor that can be implemented in an AMD/Xilinx FPGA. I'm not referring to resource hungry programmable controllers like RISC-V either. You can find much simpler soft cores with HDL sources to play with.

The big question is whether or not any soft-processor is required or even appropriate. I wouldn't get out the back-hoe to weed my garden when a simple hand-held tool would do a better job and be a lot quicker. If you can design and debug a Verilog module, then do you really need 1 or more processors to get your project completed? Do you really want to spend your time on multiple software development projects using proprietary tools, plus complicated Verilog design only to find that your system concept is too hard to understand and get working?

[D@n]

53 minutes ago, zygot said:

I'm not referring to resource hungry programmable controllers like RISC-V either.

RISC-V cores aren't necessarily resource hungry.  I've seen quite a few that've given me a run for my money when trying to generate low-resource IP.  These can actually get really small--once you throw away all of the expensive features.  In fact, I know of one that will work using only 125 LUTs.  All that's to say, it's not necessarily the RV IP that is the resource consumer.

Quote

I wouldn't get out the back-hoe to weed my garden when a simple hand-held tool would do a better job and be a lot quicker. If you can design and debug a Verilog module, then do you really need 1 or more processors to get your project completed? Do you really want to spend your time on multiple software development projects using proprietary tools, plus complicated Verilog design only to find that your system concept is too hard to understand and get working?

Yes/no.  While I understand the sentiment, a lot of software engineers trying to access hardware will initially view this to be the "easiest" approach.  A CPU can (presumably) convert a hardware design problem to a software problem, and hence it is often estimated to be a simpler task than properly learning how to engineer hardware designs in the first place.  That said, a CPU needs 1) a ROM to get its first instructions from (typically provided by flash), 2) some RAM for its stack, 3) the special purpose verilog module this engineer wants, 4) a serial port for debugging purposes, 5) an interconnect to connect all three together, 6) a linker script, 7) software to load the program first into ROM, and then 8) software to load the program from ROM to RAM, and ... @zygot has a point here.  All of that put together constitutes both 1) a lot of complexity that will need to be debugged when things aren't working (and no, nothing works the first time), and 2) it also represents a significant logic cost which will pull you away from your ability to use the full resources of the part you've purchased.

Dan

[BTaylor]

On 6/30/2023 at 4:24 PM, zygot said:

Great! That's exactly what programmable logic does very well.

Why no just ditch MicroBlaze and the SDK and implement the whole thing in Verilog?

Thanks for the responses! It seems both you and @D@n are in agreement that using MicroBlaze might be overkill. I completely agree. As a Verilog fan, my original hope was to do everything completely in hardware. However, I found that the CMOD S7 module had a PMOD for a micro SD, and it seemed easier for starting the project to do a SDK application instead of writing a custom SPI module and coming up with the correct sequence of serial commands to write data to the SD card. But if you have some references toward the Verilog-only route, I'd actually prefer it that way.

My current plan for the time being is to write a Verilog module that communicates with separate MicroBlaze cores through GPIO and orchestrates the whole process so that the cores don't have to interact and can each run a separate application reading and writing to the GPIO communicating with the Verilog module. But, like you've pointed out, this might be too much and would only be used for initial prototyping.

[zygot]

54 minutes ago, BTaylor said:

But, like you've pointed out, this might be too much and would only be used for initial prototyping.

Even I can be tempted into using the IPI design flow.. if I can prototype an idea in an hour or so and test it on running hardware. When it comes to programmable controllers that require a closed system, then I lose interest. I'm not you of course, and Dan is correct that for some people, converting a logic design problem into a software problem might seem like an easy short-circuit of an arduous development effort. Personally, I prefer doing everything in Vivado where I can simulate the whole system ( or at least the part that I'm designing ). Sometimes, there are complications like DDR or an SD card interface, or other external hardware that complicates the simulation effort, but I've never found that effort to be wasted.

My general rule is that combining blocks are are simple to understand can sometimes lead to very complicated system issues that are hard to figure out and resolve. Combining blocks that are complicated only tend to increase the system complexity exponentially. Using blocks that I don't understand and are controlled by a third party rarely works out in the end.

My purpose for addressing your question is to simply expand the question into manageable parts. You job is to decide which approach gets you to a completed project. For me, when i learn something useful that can be applied to future projects, the extra effort is a bonus not an expense.

[asmi]

On 7/3/2023 at 7:10 AM, D@n said:

Backing up a bit.  To do multiple CPUs in a design (properly), you need some form of communicating between them.  This is typically done via atomic accesses over the bus.  AXI calls this capability "Exclusive access", and there's quite the protocol behind it to do it.  When I was studying how to implement exclusive access on my own, I discovered the MIG did not support it.  I think Microblaze had instruction support for it, but the MIG did not.  When digging I seem to recall someone saying that the documentation specifically disallowed Microblaze from ever working in a multi-CPU system, so this would never be an issue.

This is nonsense. I've even seen Linux support for multi-core Microblaze designs (though admittedly it's been very much WIP at that time). The only problem is that currently there is no local interrupts support, so all cores' interrupt controllers need to be wired to exactly same interrupt lines, or you will need to ensure your software is aware of the way interrupts are routed. I highly recommend adding an L2 cache using System Cache IP, it also supports AXI ACE bus which handles cache coherency. 

Edited July 4, 2023 by asmi