A Physical-Constraints-Aware Programming Language
April 18, 2021

A distributed program should know where its computation lives. Brian Greenforest’s physical-constraints-aware language models FPGA regions, CPUs, GPUs, networks, ports, placement, and communication as parts of one reactive application.

The architecture puts FPGAs at the center as programmable cores that control the larger constellation rather than treating them as peripheral accelerators.

Make Physical Reality Part of the Language

Objects occupy regions, expose ports, and connect through routes with finite bandwidth and latency. The language can express placement, SerDes boundaries, clock relationships, and which resource owns each connection.

Harel statecharts organize reactive behavior, while object capabilities govern authority and sharing. Dynamic resource creation lets programs instantiate new types and structures as the machine changes.

Compile From Intent to a Distributed Machine

A MUX-centered primitive can encode useful local behavior compactly; one design step reduced a configuration from 25 bits to 8. The same discipline extends upward from a cell to meshes of FPGAs and the CPUs and GPUs they coordinate.

Programming-language researchers, FPGA engineers, and distributed-systems builders can bring a physical workload into this model and help make the entire machine programmable as one system.

Ground Programming Abstractions in FPGA Physics

The linked FPGA-abstraction essay connects language design to timing, area, routing, and the physical cost of computation.

https://www.cs.cornell.edu/~asampson/blog/fpgaabstraction.html?utm_content=buffer03216&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

Originally posted on LinkedIn

Brian Greenforest · (2021-04-18 06:09:00 UTC)

Open the original LinkedIn post · LinkedIn activity 6789429527421558784

LinkedIn status when archived: Edited · Visible to anyone on or off LinkedIn.

Wow, this type of abstraction this amazingly crystal clear minded author argues about is exactly what my research group at Solid State Pros working on for the past few years! Steve Haak Wyatt Flanders We ALMOST made it work! It's a dynamic distributed parallel reactive physical constraints aware programming language. It knows where you have all parts of your giant distributed program, including the constellation of GPUs and CPU over Ethernet and IP your mesh of FPGAs is connected to and controls. It's FPGA-first control architecture. FPGAs are not accelerators anymore, but main cores.

Comments added by Brian Greenforest on LinkedIn

These 11 comments were also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.

Comment 1 · (2021-04-18 07:45:25 UTC)

Siemens is a German company. In general, Verilog is used in North America, VHDL—in Europe.

View the LinkedIn post

Comment 2 · (2021-04-18 08:32:18 UTC)

The author has clearly stated that it's the problem of lacking of a programming language which is heterogeneous-first-class-citizen.

View the LinkedIn post

Comment 3 · (2021-04-18 08:37:22 UTC)

Thank you! I'm language agnostic in terms of low-level languages (Verilog, VHDL, C, Python, GLSL), but for high-level languages I prefer JavaScript instead of TypeScript for prototyping productivity, and C++ instead of Rust for scalable comprehensible systems. The language in question preserves the datapath bits flow of Verilog and VHDL, but tries to stay above C++ and JavaScript, enabling dynamic distributed heterogeneous nature out-of-the box, without hiring all kinds of domain experts. What ASIC community doesn't get, that WE WANT YOUR MODEL OF COMPUTATION, and after we take it, we want AIs to do P&R. We want to compute. We don't want to do EE. (I personally was doing EE for 30 years).

View the LinkedIn post

Comment 4 · (2021-04-18 17:40:21 UTC)

A Linux instance in a distributed system is a CGRA in a sense. A compute node in Frontier connected over Infiniband is a CGRA for sure.

View the LinkedIn post

Comment 5 · (2021-04-18 17:49:35 UTC)

I think you got it right. I see the community of VLSI designers, embedded programmers, even operating system kernel authors as Luddites of semiconductor and computation industry. It's offensive to say that, but it's the reality in which the entire industry will soon be completely reformatted. Stagnation never lasts, that's what history books taught me. Ride the wave. Take one more look at the article. Imagine, how a language can look like if it encapsulates the "feel" of Verilog/VHDL, C++, JavaScript, with dynamic types and tasks creation over distributed trees of compute nodes (over IP networks too), managed as first-class citizens within that hypothetical language, being aware about all hardware ports locations, using SerDes IP on the fly repurposing necessary areas of compute resources. Multi-tenant, virtualization compatible out-of-the-box, object capabilities (OCaps) alike right in the way how it connects, computes, distributes the workload and type information for massive distributed instantiation of the monolithic program structure.

View the LinkedIn post

Comment 6 · (2021-04-19 02:35:56 UTC)

Microsoft almost wrote the article. Then the government payed much more attention:

View the LinkedIn post

Comment 7 · (2021-04-19 02:36:54 UTC)

https://arxiv.org/pdf/2102.09713.pdf

View the LinkedIn post

Comment 8 · (2021-04-19 05:53:28 UTC)

Massimo Del Zotto dynamic distributed object-oriented reactive programming does not exist as a class. I invented it. It combines Harel statecharts for control; ordinary mathematical expressions which either parallel or in a softcore / hardware core machine instructions algorithm; distributed resource ownership with dynamic code upload, compilation, instantiation, change of resources, and the structure of application.

View the LinkedIn post

Comment 9 · (2021-04-19 15:55:42 UTC)

HSL and even OpenCL treats FPGAs as accelerators. In my opinion (not sure what the author of the article believes in), FPGA-first high-level execution reasoning programming platform is what's lacking. There's no reconfiguration wire abstraction in the syntactic primitives of SystemC. Shaders have no idea that FPGAs have an SPI interface to rewrite their bitstream.

View the LinkedIn post

Comment 10 · (2021-04-19 21:37:46 UTC)

Hardware is irreplaceable, just like life. Hard IP blocks using bleeding edge technology are the only ones which can provide specific functionality within some specific time and energy constraints, and cost efficiency. This will never change. We don't make hardware first class citizens in our programming language, being obsessed by the "portable nature" of C, C++, and everything else. Nobody ever questioned portability's premise to "just work everywhere". It caused us to throw away a lot hardware and "legacy source code" which all became obsolete/inefficient. But maybe we shouldn't? At least, for some applications. It feels like we have asteroids killing each generation of dinosaurs over and over with this silly introduction of "legacy code". I hate that concept. It's a pejorative term in software engineering community. We can do better. Nobody has to die again. Let everything stay alive _forever_. Be humane, human! Support all your legacy. Keep selling it.

View the LinkedIn post

Comment 11 · (2021-04-21 17:13:50 UTC)

Yes, it is. Efinix even states that openly in their XLR cell fabric which combines routing and compute. In my own research on alternative FPGA design, I came to realize that in complex systems, most of space is composition wires rather than logic gates. So I decided to make a multiplexer a basic building block instead of a LUT4, and reduced the overall configuration size from 25 to 8 bits!

View the LinkedIn post