Introducing fpgasm - a free, opensource "assembler" for FPGAs

Hello everyone. This is not an ad - I just want to let you know about a new language for low-level FPGA design. Hardly a language - there are fewer than 10 reserved words so it's pretty easy to grasp. It allows you (if you are up for it) to create 'bare metal' FPGA designs - without Verilog or VHDL. It's free and opensource and I hope it - and your participation - will benefit our community here on edaboard and everywhere.

If you have a free minute, look at a one-page wiki summary at github and my (hopefully amusing) blog entry introducing fpgasm.

While not for everyone, fpgasm lets me avoid the enormous tools and the associated headaches (minimal use of Xilinx tools is required to do final routing and bitstream generation). I really did not like the standard workflows; now I just use a makefile that does everything (assembling all code and configuring my XC3S200) in under 10 seconds.

I will be around to answer any questions. Please post them here so everyone can benefit.

Thank you for your support and participation.

Regards,
Victor

From https://github.com/stacksmith/fpgasm/wiki/What-is-this ...

FPGAsm is to HDLs (Verilog,VHDL) is what assembly language is to C++.

Do you have the equivalent of inline assembly? As in, suppose I have a design that really is too big to do asm all the way. So I do some abstraction using this strange and boring thing called verilog. Then I have a part of the design where I really want to do some low level placement of every single resource at the place I want. And not just that, I want to have 100% control over the routing. Now what would be handy is if I could use something like fpgasm to take care of the low level modules. Mostly the routing would interest me to be honest. Why? Because I have done a few designs where I had to control the routing to do some picosecond tweaking. And the xilinx tools are only soso, so it was perl scripts to the rescue to horribly hack me some constraints.

Soooooo, egotistically taking my own use cases to see how something like fpgasm would be a useful addition to the collection of tools...

1. can I mix and match it with verilog code in some clever way? You know, HDLish equivalent of C++ with inline asm.

2. how do you control routing? Placement I did see in some of your example code, but no routing. So how do you do that?

thanks!

Excellent questions.
1. mix/match or inline.
Having written fpgasm out of sheer frustration, I am stubborn enough to reinvent the wheel and go all-in, no verilog. But I've been thinking a lot about mixing/inlining. I see the need for it. I could use it myself, really.
Soooo, perhaps you can help me out:

I output xdl. Xilinx tools can output xdl. These can be merged, assuming that the circuits don't overlap. On my side that's easy - you manually place the circuit. On HDL side, it's a little bit more difficult, but can be done with constraints.

Now all we need is to merge the xdls. With some naming conventions that can be automated with a simple command-line tool that replaces some dummy object with the right input and output wires with the fpgasm object.

Or perhaps there is an easier way. Can we create a hard macro from our xdl file (or an ncd converted from xdl?) I've made a bunch of hard macros a year or so ago and now can't remember the details, orther than it made me want to write fpgasm.

2) Routing. Yes. I don't currently do much. My xdl files are placed but not routed; I run it through the xilinx par tool with placing disabled - it adds about 7 seconds to my 0.09. For now that's fine, although I think about a router a lot. V2 maybe. However, for now

• Xilinx routing tools are, well, reasonable (with a pained expression not available on emoticons menu)... I find that FPGA editor actually does a much better job.
• Initializing a LUT with expression (like A1*A2+A3) allows Xilinx tools to optimise the routing by switching the pins around, which is sometimes what you want (especially when you miss Verilog). Other times you may want to fix the pins - you can convert the expression to a 16-bit number and initialize the LUT with it. That actually prevents Xilinx from messing around with your pins.
  Routing is pretty important to me, and I've been doing a lot of research and testing. I felt that fpgasm is actually usable as is, and wanted to share it with you as soon as possible.

Where do you see this? At the small/tony design end of the market? or really just a hobbyist end?

Personally, I wouldnt want to go near the placement with some larger DSP type algorithm. Thats where HDL with higher abstraction (like using the fixed point packages) has real strength.

The 'inline' version (soon) will allow you to embed "IP" developed with fpgasm into an HDL design containing other things. Much like you would use an assembler in a C program. That's probably the most likely place in the food chain.

Exploration and education are another. There is nothing like laying out an adder by hand to be respectful of what a simple '+' generates (and realising that you can combine an incrementor with LUTRAMs, for instance). I hope that after playing around with fpgasm an HDL designer might be more thoughtful about their HDL code.

Finally, there are hackers like me who would love to never see Verilog again, even if it means starting from scratch.

A quick follow-up

A pre-compiled Windows version is here:

https://sourceforge.net/projects/fpgasm/files/latest/download?source=files

I suspect that a fair number of you guys use Winders.