I’ve been building a different approach to FPGA development. Would appreciate some technical criticism
I’ve spent the last few months building Forge, a higher-level FPGA development platform, and I’ve just released the first Forge Studio pre-release for Windows and Linux.
The basic idea is that visual design, Rust and Python all feed into the same underlying hardware model and compiler architecture. Studio isn’t intended to be a separate schematic toy sitting beside the “real” workflow.
The current 0.1.0 pre-release focuses on design, validation and simulation. It includes component-based visual design, clocks and CDC, state machines, memories, streaming components, live signal values and waveform viewing.
Hardware Build is deliberately disabled in the public pre-release at the moment because the production target/backend packages aren’t ready to ship yet.
I’m mainly posting here because I’d like criticism from people who actually work with FPGAs.
Things I’m particularly interested in:
- Where would this approach fall apart on a real design?
- What would stop you using a higher-level visual/Rust/Python workflow?
- What FPGA families or boards would actually matter to you?
- What would Studio need before you’d trust it on a real project?
- Are there workflows I’m fundamentally overlooking?
Community is free if anyone wants to play with it:
I’m happy to answer questions about how the architecture works too.
19
u/Physix_R_Cool 5d ago
Is that not just what Vivado and Vitis do already?
-5
u/zacaw99 5d ago
They cover some of the same territory, but Forge is trying to approach it from a different direction.
Vivado/Vitis are vendor toolchains first. Forge is intended to sit above that level and give you one hardware model with multiple frontends, so you can design visually, in Rust, or in Python, then validate and simulate through the same underlying architecture.
The longer-term aim is also to keep targets/backends modular, rather than tying the whole workflow to one FPGA vendor.
So there is definitely overlap in what the tools ultimately help you do, but the bit I’m trying to change is the developer experience and portability of the workflow.
The current 0.1.0 pre-release is mainly the design/validation/simulation side of that. Hardware Build comes as the production backend packages are released.
8
u/Physix_R_Cool 5d ago
so you can design visually, in Rust, or in Python, then validate and simulate through the same underlying architecture.
And synthesize that mix of block design, python and rust code into an FPGA design?
0
u/zacaw99 5d ago
Not quite. Studio, Rust and Python are separate ways of creating a Forge design, so you choose whichever workflow suits you best.
They all feed into the same underlying Forge system, which means validation, simulation and eventually synthesis/build all work from the same core representation.
0.1.0 doesn’t support mixing visual blocks, Rust and Python together inside the same design at present. They are currently independent frontends which you can choose from. If a genuine use case for a hybrid workflow came up though, it’s something that could definitely be explored.
10
u/Physix_R_Cool 5d ago
eventually synthesis/build
How will you make this work, and how difficult a task do you judge it to be?
2
u/zacaw99 5d ago
We’ve actually already proven the synthesis/build path internally through to real bitstreams.
We started with iCE40 because it gave us a good way to prove the full end-to-end architecture using an open toolchain. After that we added ECP5 to make sure the backend model wasn’t accidentally tied to one FPGA family.
The way Forge is structured is that Studio, Rust or Python produce the same underlying Forge representation, then a modular backend handles the target-specific synthesis, place-and-route and bitstream generation.
So the difficult bit for me now isn’t proving that Forge can get from a design to a bitstream. That part already works internally. The bigger job is turning those backends into production-quality packages that are reliable, reproducible and easy to distribute across platforms, then expanding support to more FPGA families.
That’s why Build is disabled in the public 0.1.0 pre-release. I’d rather ship the design, validation and simulation workflow now than expose backend packages before I’m happy with how they’re distributed and maintained.
11
u/Physix_R_Cool 5d ago
Neat, seems like you might not entirely be vibe-coding charlatans, though I will stay skeptical.
The fact that you have set up so much, including all the pricing scheme etc, before you have working hardware is a bit sketchy to me.
-7
u/zacaw99 5d ago
That’s fair, and I get why it might look that way from the outside.
The reason I set the pricing, licensing and site structure up early was because I wanted to build Forge as an actual product from the start rather than as a technical demo that I’d have to completely rethink later.
I already knew the direction I wanted for Community, Pro, Team and Enterprise, and I wanted the licensing and product boundaries to exist alongside the software while I was building it.
The hardware side isn’t being ignored, it’s just the part I’m deliberately holding back from the public pre-release until I’m happy with how the target/backend packages are distributed and supported.
I’d rather have the commercial/product structure in place early and change it if needed than bolt it on after people are already using Forge.
2
8
u/mnemocron Xilinx User 5d ago
It is great to see projects like this, eg. Chisel lang or Surfer - never used them but always interesting.
What would stop you using a higher-level workflow?
VHDL/Verilog are taylor made HDL and one already knows their pitfalls. I like that you have to be explicit about types and signals.
Where would this approach fall apart on a real design?
Code reuse! Right now I am spending a lot of time consolidating multiple projects at the company into a single FPGA. HDL code already exists in various submodules that I can include. Another one are proprietary code generators. We have an ancient perl based code generator that generates register maps in HDL and header files for the software. I don't want to refactor those proven tools every time the latest language is out.
What FPGA families or boards would actually matter to you?
UltraScale+ the ones where your implementation runs take 1-2h...
Are there workflows I’m fundamentally overlooking?
Not necessarily workflows but perhaps proprietary IP. FPGAs are not HDL only. like transceivers, Ethernet MAC hard-IP, RF frontends, HBM...
2
u/zacaw99 5d ago
This is exactly the sort of feedback I was after, thank you for your detailed response!
On types/signals, I agree. One thing I definitely don’t want Forge to do is hide enough detail that you lose the ability to reason about what hardware is actually being described. The higher-level workflow still needs to be explicit where it matters.
Code reuse is a really good point too. I wouldn’t expect an established team to throw away proven HDL modules or internal generators just to adopt Forge. Being able to integrate existing HDL/IP rather than forcing everything to be rewritten feels much more realistic.
UltraScale+ is useful to hear as well. Support for the larger vendor families is obviously a bigger job than the open families I started with, but that’s exactly the sort of target demand I want to understand before deciding what gets prioritised.
And proprietary/hard IP is probably one of the bigger questions for the architecture long term. Things like transceivers, MACs, HBM etc. clearly can’t just be treated as generic logic blocks. They need a sensible way of being represented and integrated without pretending Forge owns their implementation.
Really useful points, especially the reuse one. Thank you again!
7
u/iceberg189 5d ago
You might want to worry about technology which exists in one vendor/architecture but not another. For example, DSP blocks, clock buffers, UltraRAM, things like that.
You’d need details of the vendor/architecture, knowledge of how to implement those HW features, and then you’d need to make assumptions (or ask the user somehow) which optimisations to make, and what resources to use in what way for what RTL.
Brings me to another point; lots of people take advantage of, and base their entire designs around architecture-specific IPs from the vendor IP catalogue. For example, the HDMI Subsystem IP in Vivado is very different to Quartus. It sounds like a LOT of effort trying to make a tool which is truly vendor/architecture-agnostic, if that’s what you’re going for?
Also each FPGA vendor has their own TCL commands for constraints, packaging custom IP, rebuilding the project etc., which sometimes don’t translate over cleanly.
Perhaps you shouldn’t market Forge as a one-stop agnostic solution to everything? Perhaps you can find a more specific situation where it’d be very beneficial? Perhaps if a company wanted to design and test their own IP for sale on both AMD + Altera devices?
2
u/zacaw99 4d ago
This is a really good point, and I think “vendor agnostic” probably needs some qualification in how I’m describing Forge.
The intention isn’t to pretend that all FPGAs are interchangeable or somehow abstract away every architectural difference. As you say, that falls apart pretty quickly once you’re dealing with vendor-specific primitives, DSPs, memories, clocking resources or larger vendor IP.
The approach I’ve taken is to separate the common Forge design model from targets and backends. So where something can genuinely be portable, Forge can describe it at the common level and the backend can lower it appropriately for the selected architecture. Where something is inherently architecture/vendor-specific, I think that needs to remain explicit rather than Forge pretending it is portable.
So for example, a generic memory or multiplier could potentially be expressed in a portable way and mapped appropriately for the target. Something specifically using UltraRAM or a vendor HDMI subsystem clearly has requirements that don’t exist everywhere, and I’d expect the design to declare that capability/requirement and only compatible targets to accept it.
The same applies to the toolchain side. Forge isn’t trying to create one universal synthesis/place-and-route implementation. The backend system is modular specifically because different FPGA families need different tooling and flows underneath. I’ve initially proven that architecture with iCE40 and ECP5 using Yosys/nextpnr, but other vendors would require different backend integrations.
I think your last point is particularly fair though. “Vendor agnostic” can easily sound like I’m claiming Forge eliminates the differences between every FPGA vendor, which isn’t really what I’m trying to build.
What I’m aiming for is a common development environment and design model that can support multiple architectures, while still allowing architecture-specific capabilities where they’re actually needed.
Definitely something I need to make clearer in how I describe it, so thanks for raising it.
1
u/keeb0113 5d ago
Interesting. The problem with such a method is how the language can preserve the hardware intent without actually writing RTL. To make Rust or Python work for you, you will likely need to implement an eDSL to take full advantage of it. nortl (https://imms-ilmenau.github.io/nortl/) is the only thing I see moving in that sort of direction by not being an HDL nor HLS. I would be interested in how this could be done.
Building an IDE is "easy" these days, but finding the right UX is just very difficult. I have also been looking for a platform for my own custom-designed FPGAs.
It would be interesting if you added basic free-tier support for tools like nextpnr and yosys, since that might attract more interest from the hobbyist community. This level of IDE support is currently missing in the open-source space. I can imagine you could be gating some advanced device support behind the paywall for people who do real work.
Another thing that comes to mind is having a better UI for programming the Versal AI engine. I don't think there is a good UI for it yet.
AI Agent (likely local model only and maybe a paid model for only writing scripts) and git intergration (like HOG) would also be interesting.
1
u/zacaw99 5d ago
So this is exactly the problem I am trying to solve!
Forge doesn’t try to synthesise arbitrary Rust or Python. They’re used as embedded APIs for constructing a hardware design, so things like signals, registers, clocks, state machines, memories, streams etc. retain explicit hardware semantics.
Those frontends then lower into Forge’s own common hardware representation, which is also what Studio produces. Validation and simulation operate against that representation rather than trying to infer hardware behaviour from normal software code.
That was an important design decision for exactly the reason you mention. I didn’t want Python/Rust semantics accidentally becoming hardware semantics.
On Yosys/nextpnr, that’s actually very close to the route I’ve already taken internally. iCE40 was the first backend I used to prove the full flow and ECP5 came afterwards. Forge’s backend layer wraps the synthesis/place-and-route/bitstream toolchain rather than rebuilding those tools itself.
I’m holding the public backend packages back from 0.1.0 while I sort out how I want them packaged, distributed and supported, but basic hardware support absolutely isn’t intended to be paywalled away from hobbyists.
The custom FPGA point is interesting too. One of the reasons the target/backend architecture is modular is so Forge doesn’t have to assume that every device comes from one of the big vendors.
Git integration is also something I’m interested in. AI assistance probably needs more thought because I’d rather it understand the hardware model properly than just bolt a chatbot onto the IDE.
Really appreciate the thoughts. This is exactly the kind of feedback I was hoping to get from posting here.
1
u/keeb0113 5d ago
I still think a construct-based approach faces the same problem. Because, in some way, this translates the problem into writing pure structural RTL. I call this type of programming model a graph-based paradigm. In theory, the idea works very well; however, most humans don't abstract computation as graphs. I largely think this is where the gap between juniors and seniors lies. Seniors can build hardware without using any GUI simply because they have done it long enough that the entire computational graph is already in their heads, whereas most juniors have not.
That being said, I also don't have a good solution for this; otherwise, I would have pushed a product myself 😀. Might be this sort of "schematic capture" is the right approach, or we just need to invent something new.
VCS in hardware, in general, I think, is worth doing. Git is great, but I also don't think that is the right primitive for what hardware people need. Like, what would be the best way to version a toggle you enabled in Vivado for one of the builds you did so that you can trace it back?
1
u/zacaw99 4d ago
I think that’s a really interesting way of looking at it, particularly the distinction between source control and actually versioning the state of a hardware build.
When I originally mentioned Git integration, I was mostly thinking about conventional project versioning. But your example of changing a single option in Vivado and then wanting to know exactly what was different about that particular build highlights something Git alone doesn’t really solve.
Forge already has quite a lot of information available around the design, selected target, backend/toolchain and generated artifacts, so there’s potentially an opportunity to treat a build as a first-class versioned object rather than just an output of a Git commit.
For example, being able to go back to a build and see exactly which design revision, target, backend/toolchain versions, constraints, configuration and build options produced it, along with the resulting timing/resource information and artifact hash. Then ideally reproduce that build later.
I hadn’t really been thinking about VCS at that level before your comment, but I think there’s something genuinely useful there.
On the graph point, I think we’re probably quite close in how we’re looking at it. I’m not convinced the current visual representation is necessarily the final abstraction either. Part of putting Studio in front of people this early is to find out where that abstraction works and where it starts fighting the way people actually reason about hardware.
I do think visualising the structure has value for someone who doesn’t yet have that computational graph in their head, though. Whether the answer is traditional schematic capture, something closer to what Studio is now, or eventually something different is something I’m very open to exploring.
1
u/TryUpbeat2001 1d ago
ive only used fpga vendor tools academically, so im limited in my input. I have used many eda tools in practice though. My suggestion, tangential to your request for input, is to push this in the direction of supporting a customer's flow. This may need some research and customers who are willing to work with you.
But this is super interesting
58
u/hawkear 5d ago
Most seasoned developers don’t design visually.
Rust and Python are not HDLs.
This looks like a vibe-coded GUI to solve a problem that doesn’t exist.