While messing around trying to figure out exactly how to use Libero, I noticed that one of the available IP components is an FFT core. It is called CoreFFT and it shows up with a green key which should indicate that it is available to use with Libero Silver. You can get the documentation for it either by right clicking on it in the Libero Catalog window or by doing a web search on “Libero CoreFFT”. I haven’t tried it, so I have no idea if it is what you are looking for, but just wanted to point it out.
I’d point out to others that there are a lot of interesting looking cores available. It is worth taking a look at the catalog in Libero.
Thanks for all the input in this topic.
I’m not sure if my original question is answered: do you think I would be able to (easily) use the same tools/workflow for both BeagleV-Fire and the Discovery kit (and reuse tools/examples oriented to BeagleV-Fire in the Discovery Kit)?
Unfortunately, I don’t have experience with the tools and I’m not much experienced in FPGAs.
For the one(s) that have ordered the Discovery Kit, has it been finally shipped? @keck9939
The Discovery kit started shipping yesterday. I expect to receive mine today.
All the same tools and workflow work for both boards. Most of the examples should be able to work with either board with possibly minor modifications. Note that regardless of board, if you are new to FPGAs there is a considerable learning curve.
Note that regardless of board, if you are new to FPGAs there is a considerable learning curve.
Definitely. I’ve heard the learning curve described as “climbing the cliffs of insanity” and that seems fair. FPGAs are awesome but not for the faint hearted.
I found that Verilog can feel like you’re writing C but then realizing that all the lines of your code may be running at the same time.
I have had mine for a week or so and it is a pretty annoying board
I have quite a bit of experience over the years with the Xilinx tools and I will never moan about them again, the Microsemi/microchip tools are laughable.
The documentation is bad and fractured, loads of dead links.
The supplied yocto linux image, is very basic (even the ethernet doesn’t work!) so you are going to have to build your own. I have also found that the images I have built (from the microchip repo) are unstable. You can sync then shutdown then power down then there is a good chance that it won’t boot again with what looks like kernel panics around the filesystem.
Flashpro jobs created in Libero will not load into Flashpro at all, flashing does not work here in Linux VMs and is 6 times slower on a windows vm rather than a real machine (where it is still really slow).
I have still failed after quite a bit of effort to create a basic system with just the processor, UART and some GPIO. This is something that takes about 5 minutes in Vivado which then enables you to immediately fire off the software IDE and in another 5 minutes have code running.
Libero doesn’t even allow you to just add or configure the processor block, you have to use another tool MSS to create or edit the block, then import it into Libero where you can’t even edit it, back to MSS, re-import it, re-add it to system, it’s madness!
So currently for bare metal I am stuck with editing their reference design, which does take a fair amount of time to synthesise and place while I watch the CPU usage on the machine trickle along at around 2%, the whole toolset seems pretty limited to one core (they say the tools support 4 cores but I have yet to see this much in practice).
What you are experiencing is “big tech culture” in action.
So much of the stuff is just an infomercial to bait users into purchasing. What happens next, a company buys the product. Then after their engineers beat their heads against the wall for weeks trying to make progress, nothing happens. C suite is frustrated, they assume the engineering team is a band of incompetent fools. So what is next, C suite contacts those upstream and requests a quote to get it up and running.
It is a cash cow for the vendor of the product. They have already characterized the product, performed rigorous testing so it can be validated… Guess what is next, its called cut and paste…the existing code base has been developed by them so it is a trivial task to get the customer up and running. Yet the customer is quoted 9 months and 6-7 digits in $USD for a solution…
It is also how big tech suppresses small companies and protects their biggest customers. A small agile company can respond too market changes in a fraction of time that is takes for larger companies. Many cases only 10% of their customers supply 90% of the revenue. Protecting those in the 10% group becomes a priority…yet, they still need to move product.
I’ve had mine for about 2 weeks now and have had a somewhat different experience, although my goals are different (more bare metal than Linux). I have found the documentation to be not bad although it is scattered, and there are a lot of bad links. I have had no problems with FlashPro. I agree Libero is painfully slow and I’ve never seen it come close to maxing out 4 cores, but it does get the job done. Note that I am using the native Windows versions of Libero and SoftConsole. VMs are often problematic when accessing USB peripherals like FlashPro. The MSS configuration is annoying, but on the other hand, it is not really something you need to change that often.
My initial goal was program the fabric so that an LSRAM block could be written by one of the U54’s and then access the data in the LSRAM from the fabric to drive WS2812 addressable LED’s without CPU intervention. I have succeeded in that.
I have found that it is useful to play around with the various demos, make incremental changes and see what happens before just diving in trying to do my own thing from scratch.
Having used various CPLD’s and FPGA’s in the past, I’d say my experience here is pretty much what I expected.
I have used the modified reference design. The reason for this is if you look at the reference design, there are multiple blocks that are likely required for the system to properly function that would likely be tricky to configure without really knowing what you are doing. In particular, the CLOCKS_AND_RESET block and the FIC_3_PERIPHERALS block. Some of the stuff in FIC_3_PERIPERALS may not be required, but if you are running Linux you do likely need the IHC_SUBSYSTEM. In addition, there are multiple constraint files in the reference design that are also important, notably the pin constraints, but there are others I haven’t investigated.
In short, I think even if you want to start “from scratch”, you are better off starting with the reference design and removing stuff and altering stuff to suit your needs rather than trying to start completely from the ground up. In essence, think of the reference design as being your “board support package”.
Thanks, from this link with the icicle board it seems that at least in this case most of the reference design, Fics, Clock and reset, interrupts etc are not needed :
So this has led me to think it is to do with something else internal to the mss, there are no board presets available from microchip apart from for the icicle (at least from what I can find), so I used the MSS (and constraints) from the discovery reference design and disabled everything as per that link, UART 0, 3 and 4 enabled, one fabric GPIO connected to one of the LEDs.
Libero generates everything perfectly, smmc and Fabric are programmed but the HART doesn’t seem to start correctly, the debugger cannot attach to it.
Interesting link. I will try following it sometime and see what happens.
One thing to note is that the Icicle board and Disco board are (obviously) not the same. In particular, on the Disco board, the reset switch (switch 2) goes through the CLOCKS_AND_RESET block, so it is possible that the way the two boards handle reset is different, leading to the situation you are seeing.
Since the Disco board is much cheaper than the Icicle, it is possible that certain things that were done in hardware on the Icicle board were done in the fabric on the Disco to save cost.
I did something like what you want, but going in reverse. I.e. I stripped the reference design down to just 3 UARTS, nothing else.
I get exactly what you are seeing. I think what is going on is the eNVM still has HSS in it. So it tries to boot that, but fails because it doesn’t have the required hardware. At this point, I suspect the system is in a state where it will not respond to debug break requests, so you are stuck.
The solution is to get the system into boot mode 0, so it halts on power up and basically waits for a debugger to kick it off. I’ve done this and it works.
There is a tool to do this in SoftConsole, but you need to change its configuration for the die to:
–die MPFS095T
You should probably also change the –package setting to the correct package, although I missed that and it seemed to work.
Note that the example I used (mpfs-gpio-interrupt) took a while after the initial break before it produced output, so you may need to be patient. This example started and produced the correct initial output, but did not completely work, probably because I blew away all the GPIO.
Thanks very much for looking into this for me and solving my problem, I had been concentrating on it being an issue in my Libero project/MSS when really it was that boot mode.
This is the address of FIC_3->IHC_SUBSYSTEM_0 which from my untrained eye looks like the core communication stuff. So I’m guessing the E51 is just having no luck finding the 54 cores.
So it looks like at a “minimum” we need that IHC_SUBSYTEM, I will look at getting a Libero setup with that in…
HSS has a lot of configurable options using Kconfig. I think there is an option that will turn off it needing IHC. If you are not planning on running Linux and depending on your baremetal needs for inter hart communication, you might be able to dispense with it.
Also, for baremetal, you don’t necessarily even need HSS at all, but then your code needs to configure the MSS. However, the baremetal examples show how to do this.
The number of options on this little beast is staggering.
I had tried disabling that, and the watchdog stuff and it kept resetting itself after a couple of seconds, the debugger could connect though but just as slowly.
I’d like to get it to a state where the HSS used for the default reference will work with a reduced reference design, but I have got to a point with Libero where I have had enough!
Maybe you can help:
I took the reference design and removed all the bits I was not interested in.
I reconfigured the FIC_3_PERIPERALS block which made Libero disconnect all outputs and remove the slices on MSS_INT_F2M, arghhh.
So I redid the slices and connected up the IRQs.
But I am getting an error that MSS_INT_F2M has an unconnected input pin.
As far as I can it is exactly the same as the original reference design, so I thought maybe the error is being suppressed, but I can’t do that, So back to banging my head against the wall.
p.s. I tried removing all the slices that are not used, same error, also double clicking on the warning and error does not take me to the correct location in the design!
After some back and forth we determined that the problem was that lines 58:0 were unconnected and it was not apparent how to connect them. The solution was to do a custom slice like:
