anyone tried the Discovery Kit from Microchip?

Hi all,

I have decided liike to buy one of these PolarFiire based boards. An alternative to the BeagleV Fire is the PolarFire discovery kit:
https://www.microchip.com/en-us/development-tool/mpfs-disco-kit

Has anyone tried it? Should I be able to easily use Libero designs for the BeagleV Fire in that board?

I’m not an FPGA expert and I’ve never used Microsemi/Microchip FPGAs.
It seems to have similar SoC with ‘bigger’ FPGA but less RAM and no eMMC. The idea is to learn about the SoC and RISC-V with Linux and co-design with its FPGA (hopefully with Mi-V soft cores)

Thanks!

Juan

It looks like an interesting board - especially as it includes onboard JTAG - but I don’t think it’s available just yet.

It is nominally available from Microchip who claims to have 909 units available, but for some reason they are not actually shipping. I ordered one a week ago and as yet there is no estimated shipping date (they indicated it would ship immediately when I placed the order). If you are interested in learning about bare-metal or RTOS development, this could be a better choice than the Fire since it is slightly cheaper and includes the JTAG interface particularly given the cost of purchasing a JTAG interface for the Fire. For Linux, the Fire is probably the better choice given the larger memory.

[edit April 13] I have received a communication from Microchip that they expect to actually start shipping this coming week.

BeagleV Fire + FlashPro 5 = US$250.

PolarFire Discovery Kit (on board programmer) = US$150.

I choose the later.

In a way the programmer is also built into the BeagleV Fire. It is the application processor. You only need a FlashPro5 if you are an avid SmartDebug or Identify user or for bare metal software debug. And if you are into bare metal debug an FTDI based JTAG debug probe is the best option.

1 Like

How to take advantage of Microchip FPGA Suite with an on-board MCU?

Taking advantage of the Microchip FPGA Suite does not directly translate into having to use the device’s JTAG interface with FlashPro5. That’s why directly jumping to the conclusion that one needs a JTAG probe because there is an FPGA on the board is the natural reaction we have after using FPGAs for a few years but may not apply to the way everybody intend to use BeagleV-Fire.

The Microchip FPGA Suite is used as part of the BeagleV-Fire gateware build system. It may not be immediately obvious if using the CI system but it is the tools suite currently used by the openbeagle CI system. The exact same build scripts can be used locally on your development machine if you have the Microchip FPGA Suite installed on it. The BeagleV-Fire gateware build systems generates programming files that can then be copied to the board’s file system and programmed using the “change-gateware.sh” script. This sounds terribly convoluted when coming from a pure FPGA background. However, using this flow locally on my development machine comes down to 3 Linux commands (first 2 on my host machine, last one on the board):

  • python3 ./build-bitstream.py SOME-FPGA-DESIGN-BUILD-OPTION.yaml
  • scp -r ./bitstream beagle@192.168.X.Y:/home/beagle
  • sudo /usr/share/beagle/gateware/change-gateware.sh bitstream

This is the device programming part.

The other parts of the Microchip FPGA Suite that require a FlashPro5 are SmartDebug and Identify. What follows is my personal approach based on years of debug with the various Microchip FPGAs.

  • SmartDebug is a great tool. It is extremely useful for board bring-up.
  • Identify is another great tool for digital logic debug. However you should avoid debugging FPGA logic on the board. It is more efficient to do FPGA logic debug in simulation (no frustration with capture buffers that never seem deep enough).

Both tools are excellent, when you need them. Will you be doing board bring-up? Do you use simulation test-benches for your digital logic?

The last use case for the JTAG interface is bare metal software. In that case I would recommend using an Olimex ARM-USB-TINY-H instead of FlashPro5. Also if your focus is bare metal/microcontroller, this type of board/device might be a better fit for your requirements: https://shop.trenz-electronic.de/de/TEM0001-01A-ABC-2-SMF2000-FPGA-Modul-mit-Microchip-SmartFusion-2-8-MByte-SDRAM

I went on a little rant on this and slightly off-topic but my main point is that the BeagleV-Fire and its gateware build system is intended to simplify development for MCU+FPGA devices and that it is not blindly repeating the classic development flow for SoC-FPGA. It is different, hopefully for the best, so that means that our assumptions based on the classic SoC-FPGA flow may not always apply.

1 Like

Thanks for your useful comments. The alternate board you suggest is intriguing, although I suspect many of the people interested in the Fire or Disco are interested in learning about RISC-V, not ARM.

You recommend the Olimex debugger. If that works for debugging, the question is will any OpenOCD compatible JTAG debugger work for debugging? If not, what determines which debuggers will and will not work? Also, are there any example OpenOCD config files, that show the setup for OpenOCD debugging with other than FlashPro?

Finally, if Olimex and others can be used for debugging, can they also, in particular program the eNVM?

Great point @keck9939. If you have a JTAG probe supported by a recent build of openOCD then you should be able to do bare metal debug with it on BeagleV-Fire.

I am pretty sure there is an openOCD script for using the Olimex probe for PolarFire SoC included in SoftConsole. Will have to dig for it.

Regarding eNVM programming from openOCD… this could be possible soon.

Edit: This link should be useful for example openOCD scripts: Debugging — SoftConsole v2022.2-747-RISC-V documentation

sounds complicated. :thinking:

Not that much compared with trying to keep a microprocessor subsystem configuration, an FPGA design and a set of device tree overlays in synch.

The website is not very clear as to exactly what math modules are activated in the silver libero license package. Do you know how severely they downgraded it relative to the paid versions.

Looking over some of the stuff it mentions we need to buy a $5500 license to use FFT on the chip. Please clarify exactly what can and cannot be used on the Beagle polarfire board.

You are confusing what the build tools will do, vs what IP you can additionally purchase.

Libero Silver will allow you to fully utilize the PolarFire SOC on the Fire. If you want to implement your own or an open source Verilog or VHDL FFT routine in the FPGA, it will allow you to do so. In short, all you need to fully utilize the Fire or Disco board is Libero Silver and SoftConsole, both of which will cost you nothing.

The FPGA does not include some sort of FFT module that is unlocked by purchasing a license. However, any FPGA of sufficient size can be used to construct a hardware FFT by programing it with an HDL. The $5000 FFT license you refer to is for purchase a presumably highly optimized FFT routine IP that you can use as a black box to implement a FFT on the FPGA. It is likely to be much more compact and efficient than anything you could come with on your own. Implementing complex designs like FFT’s is not easy, and if you really need an optimal implementation, then it may be worth the price to purchase IP. If you are just getting started, you should not even be thinking about purchasing IP.

2 Likes

The silver license itself does not prevent to use anything on the chip used on BeagleV-Fire. The paid license allows using larger devices and additional soft-IP. I’m not sure which soft-IP requires a paid license. My recollection is that most of the soft-IP is still available with the silver license but most of the complex ones are distributed as obsfucated RTL.
From the point of view of FPGA math-blocks they are available with the silver license.

1 Like

Need to move raw data into the frequency domain and then frame it up. That is what revived our interest in the AI64 and its DSP. Their website mentions some blocks of code that are already validated and it was assumed those are in the software package. Too much vague sales non-sense and it becomes confusing. Was curious if this was going to work before trying to light up the dsp on the AI64. Zero experience here with FPGA so this might be a more of a time sponge than we need to get into.

FPGA is for parallel processing.
If you are satisfied with your sequential processor`s performance, there is no need to learn something new.

For instance, if you are on a Type 45 Destroyer and use her Sampson Defence System to track 1,000 incoming objects in real time, then FPGA is for your design.

1 Like

You do realize that this discussion is about the BeagleV-Fire and Microchip PolarFire Discovery? It sounds like you are considering the Beagle-AI which is a totally different beast. Libero would not even apply to the Beagle-AI. Indeed, the AI uses a SOC from Texas Instruments and the PolarFire is Microchip.

As @HKPhysicist points out, if a DSP will do the job for you and you have no FPGA experience, you are almost certainly better off sticking with the DSP.

If you are unclear about what IP is available for the AI, you might try asking on the General Discussion with tag bbai64 section of the forum.

2 Likes

Yes, agree with you on that. Some times the simple solution is the best.

We have one deployed with a full stack and it is sitting on top of big box machine and has not needed any attention. It is a work horse when configured for the application. It was only referenced because it has a DSP plus the fact it is a strong compared to other boards.

Thanks for sharing these insights mate.