New BeagleV single board computer adopts Microchip's PolarFire SoC with FPGA | Hacker News Reader

New BeagleV single board computer adopts Microchip's PolarFire SoC with FPGA

linuxgizmos.com

84 pointsteleforce63 comments

Last I looked Microchip's Libero FPGA/FPGASoC development tools were paid, either on an expensive one-time fee for a specific version, or an expensive-compared-to-this-board annual subscription. It won't even show me current pricing without logging in, which is a bad sign, and none of the press has mentioned if these come with a comped board-locked license or something to make them tenable for hobbyists.

The big FPGA players have mostly quit that shit; AMD/Xilinx, Intel/Altera/Whatever dumb name its about to be spun back out as, and Lattice all have free versions of their dev tools for at least their parts small players can afford. They just want you to buy chips and IP.

I haven't heard of the Yosis folks making a PolarFire backend, so I don't think there's an open alternative.

Libero is even FlexLM based licensing like the bad old days of proprietary dev tools.

You can generate yourself a free Libero Silver license, which needs regenerating every year, but yes flexlm is annoying.

Seems the MPFS025T is not supported on the silver license unfortunately

The product table says that MPFS025 works with the free Silver license. Only the -S (security) versions require a paid license. Meaning, the MPFS025T has a free license, but the other MPFS025TS would not.

When searching for hardware part numbers, you should first omit the letters at the end, and then read carefully about what they mean.

Not only that, but you can flash an MPF*S with a non-S version. You only lose the "security" features (read: anti-tampering and debug prevention)

The product table I saw says "MPF100 (non 'S' devices)", and then I checked their MPF100 family comparison page and saw that no "MPFS*" devices were listed there. Is there a more informative product table on some page? Or how is one expected to know that MPFS025 is a "MPF100 non S" device? Genuine question, I am curious

https://www.microchip.com/en-us/products/fpgas-and-plds/fpga...

Then click on the link "Libero license selector guide" to download the Excel spreadsheet. Filter or search for MPFS025.

Microchip does Excel spreadsheet selector guides for everything. As a general guideline when dealing with hardware components, don't trust anything you read on a web page.

Ah, thank you!

They even switched to mandatory yearly renewals a while back when Libero SoC launched. Buy a copy of Libero Gold for $999? You lose access after 365 days unless you renew. Every license tier used to be perpetual upon purchase, but now a single node perpetual license is some ridiculous bullshit like $20,000 USD.

At least when you buy Vivado and Quartus you can actually keep using it...

Thought I might have accidentally navigated to Slacker News for a moment there. Logging in, I can see that there's a big blue button that says "Request Free License".

Not finding any documentation for this SoC on either the beagleboard or microchip websites. I'm still waiting for a RISC-V SoC that actually has reasonable documentation instead of a pile of random linux kernel and (maybe) bootloader patches. A list of base addresses for peripherals and a block diagram does not count.

If they did that, someone might actually develop an open source toolchain and software stack for these. However, considering they charge 200x more for the software than the hardware, I can't imagine that's in their financial interest :)

Oh I don't even mean the FPGA side (of course that'd be nice), just the SoC's CPU complex and its peripherals! The only "documentation" I've found is a high level block diagram.

So, AFAICT, pricing hasn't been officially released on this, but the original source (https://www.beagleboard.org/blog/2023-11-02-beaglev-fire-ann...), states around $150.

They had announced this board sometime ago with totally different specs (https://old.beagleboard.org/static/beagleV/beagleV.html).

That being said, I'm actually looking forward to this board. I see this as kind of an alternative to the Xilinx Zynq boards.

Mouser.com has it listed at $149 in the USA, at least.

Pretty amazing price point considering a Polarfire board is normally like $1000 although those have a lot more features (socketed RAM, PCIe edge connector, SERDES breakout, etc). IGLOO is a little more affordable but Polarfire is nicer.

Microsemi (now Microchip) does not really cater to the low-price hobbyist market. A lot of their sales are high-reliability FPGAs and weird things like anti-fuse FPGAs (one-time programmable). I will say that they were very early adopters of RISC-V. We've been using their core in our product for something like 5 years now.

Is this the first Beagleboard that doesn’t use a TI chip?

That's what I was thinking! I always assumed TI spun off Beagle since I've never seen their chips anywhere else!

I suppose the bigger news is that this is a RISC-V device with some FPGA fun mixed in.

Someone in the previous thread mentioned programming fpga is very hard. Could anyone opine?

Yes, it’s a very different paradigm than typical programming. By default, everything in hardware happens at all at once, unless you add what’a called sequential logic, which is clocked and holds state.

FPGA programming is like another level below assembly programming.

In high-level languages you got functions, variables and scopes while in assembly you need to build them yourself using more primitive units, i.e. instructions and registers.

In assembly you got many helpful instructions and easy memory access while in FPGAs and ASICs you have... nothing. Only wires and boolean logic.

It allows you to build some things extremely efficiently, e.g.: Press button 1 and 2 to activate LED 1. No clocks, no memory accesses, no I/O polling or interrupts, just a direct connection from some inputs to others with some logic in between.

Although there are many modern tools, libraries and IP blocks to make FPGA programming easier or even possible with languages like Scala or C++, it usually takes way more time to build anything compared to doing it with the help of a CPU.

I've always been interested in coaxing extreme performance in a computational task by using FPGA or ASIC.

This seems like a mad science. Is there a recommended entry point like a book or learning resource?

The only exposure I have is from the FPGA stereo disparity module on the Mars Rover. And sadly I left before I could really pick any brains. Or ASIC Bitcoin mining.

Well first you need a problem where using a FPGA is a good fit.

FPGAs usually clock much lower than CPUs. If you want to beat a modern multicore CPU running at 5GHz with a 100MHz FPGA, you need to do a lot more per cycle to win. Your optimal problem is either highly parallel or solvable using a deep pipeline that gives you crazy throughput.

Since accessing external RAM is much more complicated on a FPGA and you don't have all the nice prefetching and caching levels of a CPU, you better make do with the limited on-board memory.

Usually this limits you to real-time stream processing like audio, video, packet filtering or I/O muxing.

But if you have an interesting problem in these spaces, FPGAs can be crazy power efficient and fun.

At my university, we used a ZynqBerry (Raspberry Pi format and only around $100) with the Vivado tools, so maybe that would be a good start for you as well.

This. It's quite hard to find a computational task than an FPGA is more suited for than a CPU or GPU. Probably the biggest one is ASIC simulation. The biggest use for them otherwise is either dedicated high-speed I/O in embedded applications or super-low latency/jitter applications.

Accessing RAM in itself isn't actually that bad, the real challenge is that writing an AXI Manager is too much trouble. The fixed costs are too high for a hobbyist that just wants to do a single project.

You might find "Digital Design and Computer Architecture" by Sarah Harris & David Harris helpful. (Note that it comes in ARM and RISC-V editions)

https://www.waterstones.com/book/digital-design-and-computer...

> This seems like a mad science. Is there a recommended entry point like a book or learning resource?

There is this new book: https://nostarch.com/gettingstartedwithfpgas

FPGAs are actually not that hard to program, in theory. If you understand basic logic gates (and/not/nor/etc) and other logic concepts (flip-flops, latches, clocks) you can understand vhdl or verilog. And then you can write your own vhdl/verilog code (really, is it code though?). The actual difficult part is using the tooling. Intel's and AMD's development environments are designed for professionals, so they're hard to work with if you're just starting out. Add to that a liberal sprinkling of annoying bugs and workarounds, and it's actually quite frustrating to do if you aren't getting paid for the effort.

It's not necessarily harder, it's very different from writing code for CPUs and it's used to accomplish different things. Though it's different, a usually what what you're writing is smaller in scope than something written for a CPU.

It's great for stuff like driving LED matrixes, offloading crypto operations, or signal processing. Anywhere you want low latency, but simple processing.

Software engineers can sometimes find it difficult as with a HDL you (should) describe hardware that exhibits the intended behaviour, rather than just directly describing the behaviour.

HDLs have familiar syntax that makes it seem like you can just program algorithms imperatively (for loops, if statements, functions etc) but it's all just a mean trick to catch software people out, and generally won't give the results you expect.

On top there's then the fact everything happens at the same time, the faff of making everything synchronised and making sure it meets timing and fighting the frankly awful tooling every step of the way.

Once you get it, it's fine, but you have to unlearn a lot of software muscle memory and keep the actual design work (boxes and lines) almost entirely separate from the implementation (typing your boxes and lines into a text editor).

I've written software for decades and didn't find it very difficult at all to pick up HDLs conceptually. The idea that you're writing a circuit that all executes in parallel is really not a difficult one.

The biggest issues are really:

1. The tooling is generally awful. Open source tooling is very primitive and not usable. Commercial tooling is unaffordable to hobbyists. There are a couple of exceptions:

a) Vivado which I haven't used extensively but seems fairly nice. Unfortunately the FPGAs it works with are not cheap.

b) I discovered that Intel provides a free version of ModelSim. I've used Questa a lot (the "pro" version of ModelSim more or less; their branding is confusing) and it's great.

It also doesn't help that all the tools use TCL which is also awful.

2. SystemVerilog is just a really bad, ancient language. It wasn't even designed for synthesising ASICs, let alone FPGAs! You're writing a simulation of an ASIC, and then some other tool tries to infer how it should run that simulation on an FPGA. It's a completely bonkers system.

It's not just the system that is bonkers. The language is too. Implicit casts all over the place, undefined values as part of the language (though not in Verilator!), multiple assignment types, ridiculously flexible array indexing.

Maybe VHDL is better... but unfortunately SystemVerilog won the language war in the ASIC space so that's what I know.

It also doesn't seem like we'll get a replacement any time soon. You'd need buy-in from the big vendors otherwise debugging will always be a total nightmare.

Though it would be nice if there was something like Typescript for SystemVerilog - something that fixed all the very rough edges and footguns but didn't change the code so much that debugging is painful.

> Open source tooling is very primitive and not usable

Maybe you're working off old information, but the FOSS tooling (ghdl, yosys, nextpnr) is completely sufficient for hobbyists. If you're doing huge, high-speed designs on expensive FPGAs, sure, use the vendor tools, but for your average iCE40/ECP5-scale design, FOSS is the way to go.

Sufficient, sure. But in terms of usability it's like giving someone sed and grep and saying "this is sufficient for writing a novel".

Maybe in time they'll move on from the "here's a bunch of random poorly documented tools, you only have to do all of the integration work!" stage, but they aren't there yet.

The hard part is not the "programming" part; it's boolean logic, if you understand how your machine works at the gate level, it makes sense as a kind of pseudo-declarative model of the bits of the machine. I found Verilog / SystemVerilog very intuitive and fun to work in. Not that I ever did it for a living, but it was entirely comprehensible to me after some practice. I went from newbie to wiring up my own simple video chip & character generator to a RISC-V core in a month or two.

The hard parts are...

a) the "fuzzy" bits -- timing, propagation delays, etc. the tool will warn you about it but it's not always easy to understand. It's easy to end up with a mess that makes perfect sense "logically" and works in your sim, etc. but actually only sorta works in meatspace.

b) the tools. They all want to ram you into their shitty 1000lb IDEs which are forks of Eclipse from 15 years ago with a heaping dose of Tcl on the side and only work in some specific version of RedHat or whatever. Forget about using your preferred editor or IDE or build tool, they want to ram you through their GUI. You can sometimes route around it, by reverse engineering their Tcl and figuring out what command line invocations rae actually happening behind the heap of wizards they want to herd you through... but you'll always end up back in Quartus or whatever at some point. HW Engineers seem to be suckers for this kind of punishment.

I don't think it is quite fair to say that HW Engineers are suckers for that kind of punishment. They don't enjoy it either but their options are pretty limited. The Yosys suite of tools is proof they are trying to fight back but it is an uphill battle as they try to decipher the encrypted bitstreams each vendor uses to hide what goes on between the curtain of their proprietary tools. With few exceptions (some Lattice chips), the various architectures are only semi-reverse engineered at best. The "suckers" can't leave that capability on the table in the meantime.

https://github.com/YosysHQ

FPGAs are "programmed", or perhaps more accurately, "Synthesized" with hardware description languages like Verilog or VHDL.

With typical programming, you're describing software. With VHDL / Verilog, you're describing hardware. When Verilog/VHDL "runs", its just the hardware existing, ready to react to whatever happens later. There's no code that "steps" through if-statements or loops... there's instead state-machines that get stored into memory... with their outputs being directed upon physical wires you name.

As far as a "language" goes, I'd say its close to C++ Template Metaprogramming, though the syntax is very different. But the concepts are surprisingly close. C++ Templates do not compile into code, they compile into concepts and layouts... so to speak.

Well, of course C++ Templates eventually turn into C++ code. But imagine if the end result were flipflops, wires, and 1-bit memory instead. Maybe I'm describing it wrong... or maybe the only way to really know is to try it yourself.

I always get excited by these kind of devices… until I realize I honestly can’t think of what I would use it for.

Anyone have plans for something like this that they would like to share? I’d love some project ideas.

Best application I can think of is a mid-level robot prototype. Small enough that you don't need a lot of computing horsepower, but also need lots of high speed I/O for cameras, LiDAR, etc. This is a small niche since most robots that need that kind of I/O also need much more computational horsepower.

I'm doing some 900Mhz ISM band SDR stuff. I'm mildly afraid, the polarfire toolchain is pretty wonky. F4PGA is wonky in a different way, but at least it's open and I know a few people using it. It would be cool if I could use F4PGA with PolarFire FPGAs.

You need a paid version of Libero to use this. A hobbyist FPGA board that isn't supported by the opensource toolchain Yosys is DOA.

https://github.com/YosysHQ

If you want to play with FPGA, get instead a Lattice ice40 board:

https://www.sparkfun.com/products/16526

> The BeagleV-Fire includes MMC 5.1 SD/SDIO, a Quad SPI flash controller, 128 KB eNVM, and 56 KB sNVM for storage, paired with a 36-bit memory controller supporting various memory types with error correction

I'm a noob here. Does it means it has ECC or does it support ECC?

Just curious: This is a computer, so why say it has USB "OTG" (a dumb term anyway)? I would expect any computer with USB to act as a USB host.

OTG means the BeagleBoard can act as a device (like a keyboard, pendrive, etc) when connected to something else which is the host.

Hm, I usually see this called out as being able to act as an HID.

"OTG" is such a gallingly stupid, uninformative term.

It's because it was originally developed for smartphones: originally normally trieted as devices, then adding the ability to act as hosts, therefore you have a USB host "on the go". The more modern version and terminology is USB-C dual-role support, which is the same basic thing but using the USB-PD protocol to negotiate instead of a special marker cable (which the product page does also use).

No it means it can act as a host, when it would normally be a device.

Probably a case of infectious terminology. Microchip has sold microcontrollers that could act as both a USB device or a USB host, and lacking a better term they used (misappropriated?) the term "USB OTG". Probably this FPGA is reusing the silicon block from those microcontrollers, so the term was copy-pasted also.

Someone mentioned this already but it means the beaglebone can act as a peripheral. Only RPi 4 and above has this feature so its not necessarily mainstream until maybe the past 5 years.

No, the Raspberry Pi models A and Zero can also do USB OTG because they do not have a USB hub chip in the way like the models B.

Beagle can use USB OTG for cheap networking over RNDIS/CDC-ECM, or mount the device as a simulated thumb drive.

> I would expect any computer with USB to act as a USB host.

Do you expect your Keyboard to act as a USB Host?

If your Keyboard were USB OTG, then it would be a keyboard when plugged into a computer, but a mouse could plug into the keyboard and then the keyboard would be the USB Host. This bi-directional feature would be useful for maybe a modern Commodore 64 like device or something (I dunno, just making stuff up).

Traditionally, USB OTG was for phones. They want to be a device when plugged into a computer, but the phones also want to accept a mouse/keyboard/USB Mass Storage.

That question is nonsensical. A keyboard is not a computer; it's CONNECTED to a computer. This device IS a computer, and you would typically connect a keyboard to IT.

"OTG" is inherently meaningless. Kind of like a "red flag warning" (for any CA readers).

"Inherently meaningless" is fine for a name. Anyway this one has an externally-applied meaning in the form of an actual specification, which defines OTG explicitly:

   On-The-Go: An OTG product is a portable device that uses a single Micro-AB receptacle (and no other USB receptacles) to operate at times as a USB Targeted Host and at times as a USB peripheral. OTG devices shall always operate as a standard peripheral when connected to a standard USB host.

You can get the rest of the details from the specification itself: https://www.usb.org/document-library/go-and-embedded-host-su...

Thanks for the reference.

As to "meaningless is fine..." no. And doubly no to the abbreviation of a meaningless name.

"Dual-mode" or "dual-role" USB would make at least some sense and convey some information.

Nope!

a) A keyboard has a little computer in it too. Fundamentally they're both computers. It's not the "computerness" that matters, it's "is this normally a peripheral?"

b) This is normally a peripheral - you connect it to a host computer to program it.

Nope! We all know what the implication of the original statement was.

> A keyboard is not a computer

You underestimate the complexity of modern protocols and the amount of computational power in everyday devices.

All USB devices have more compute power than the entirety of the Apollo Moon Lander program. And we use that compute power to format USB checksums, USB packets, and other such protocol details.

In practice, a keyboard today has the compute potential exceeding that of supercomputers of decades past. We just don't think about it very much.

---------

A modern mouse is more obvious, in that it uses convolution kernels over the scanned 2d infrared picture to figure out if the image moved right, left, up or down about 100x per second and reports the results to the host.

That's how optical mouse works. Lots and lots of matrix multiplications and 2d digital signal processing...

Aaand this is the pedantry I expected. Didn't even bother trying to head it off. Why deny this stack of commenters their jollies?

This device can also act as a device when you connect it to another computer. Maybe "OTG" is not the best name, but rightly or wrongly, that is the accepted name for this feature.

Smartphones have the capability that:

1. You can plug them into your PC and they act as a device (e.g. mass storage device for downloading your photos, drawing power to charge)

2. You can plug devices into them, and they'll act as a host (e.g. you can plug in a mouse if your touchscreen is broken, download the photos from your non-smartphone camera onto your smartphone, supply power to charge something else)

3. They'll do all this through a single port.

Hardly any normal people use these capabilities, as the cables are somewhat rare and the software support is somewhat patchy. But if you're buying a development board ready to make your own product, you can read this as "can be a usb host or device, whichever your product needs"

It's a lot more common with USB-C, since you don't need special cables

This is actually a killer feature of beagleboards. You can use usb to connect it to a PC to flash the eMMC easily, or (at least on some of them) use usb to provide power and also provide a network connection from your PC to the beagleboard. So with one cable you get power, can ssh in, and have network connectivity to install python packages etc.

Are these the ones with the SiFive U54 riscv cpus?

Reply on news.ycombinator.com