I came across this yesterday. It seems to be a new HDL designed specifically for hand-layout of FPGA. The github hosts an overview

https://github.com/stacksmith/fpgasm/wi ... -to-fpgasm!

Normally I am sceptical of 'new' language, but I think it may be of some value in creating compact and fast hardware as the author demonstrates in an article creating VGA output with 5 and 1/2 slices:

http://www.fpgarelated.com/showarticle/42.php

What is cool is it is opensource.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It's a clever method, but the module only generates (approximate) VGA timing, not an actual VGA output. Now, he has to solve the problem of generating 640 pixels using a 24.75 usec horizontal timing pulse.

That's a good find: thanks enso, and welcome!

I'm not too worried about the specifics of a design example: the motivation to design a digital circuit and quickly and easily get it running in an FPGA is very recognisable. Not only are the HDLs verbose and peculiar, but the tools are more difficult to use than they should be. (It's easy for someone who's already become proficient to forget how frustrating the beginning is.)

So, a simple syntax for connecting elements together to run quick experiments in order to enjoy the learning process is welcome.

As to how well this offering works in practice, well I haven't had a go, obviously!

Cheers
Ed

I don't know. I am aware that progress depends on unreasonable men, but the syntax looks more complicated than Verilog, and that's just for hooking up a few LEDs to buttons.

Getlemen, I compiled it last night and messed around. My xilinx setup is not here so I can't configure a real fpga, but here is what I found compiling a simple test.

Synthesis time: 0.094 sec. This checks errors and creates an xdl file. fpgasm guy says 10 seconds to fully-configured fpga.

Arlet, the syntax is different and you are king of Verilog. I have some trouble, so different syntax is not a problem for me. It seems consistent. Compared to verilog, similar to module declarations, but wiring is all in one place, explicit instead of implied in verilog. And no assignment or registers.

There is hardly any syntax. Just "wire my ... to his ...". All the complexity is in the configuration strings, but that is hidden on bottom layer modules in the 'library', middle and top layers are real easy.

The example you are talking about with Leds and buttons acts as both verilog and ucf file together, so not unreasonable.

I like it. Quickly fixing errors is great - usually its a long time in verilog. I wll keep learning.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

This seems to be an interesting project, I'll read up on it. Thanks for posting!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Arlet, I looked a bit closer at the tutorial. Actually the code to instantiate 4 buttons and connect to 4 (out of 8 ) leds is this:


No worse than verilog really

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Not much worse, but not better either. In Verilog you'd write something like:

Seems clear enough.

To be fair, this example is confusing because in Verilog automatic IOBs at the top module are created from the ucf files. In fpgasm IOBs are instances like everything else. The example actually creates an instance of 8 leds and another instance of 4 buttons. So a more fair comparison would look like:



My verilog is rusty, sorry if any errors.
I do not mean to fight with the master. Verilog is obviously a more powerful language. I am amazed at the speed and simplicity of fpgasm. It also looks like you can do everything. The spartan libraries included are not complete but it looks like still work in progress.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Complete module, without the 4 ground pins for the LEDs (who would drive those from the FPGA?)

Of course, the pin assignment is in the UCF file, but it's actually an advantage not to have to change the design itself when moving the code from one FPGA/board to another. Also, the UCF file does not just contain the pin locations, but can also hold many other I/O constraints, like slew rate and drive strength, but also constraints for timing and other things. How does fpgasm support timing constraints ?

Arlet, your code is again not a valid comparison. Fpgasm example instantiates two modules, with 4 input IOBs and 8 output IOBs. The top module in fpgasm has no pins - all input and output are IOB instances inside. So when you say in fpgasm

it creates an instance of Buttons module, which is defined in another file in this case, called DigilentSpartan3. This is the equivalent of the ucf file. You don't need a ucf file in a different language, because fpgasm is powerful enough to describe all of FPGA parts itself. You don't need another language for constraints. You can swap in another include file for a different board with the same names like Buttons that address different IOBs.

Looking at the documentation I think you can modify IOB settings like this:


And no timing constraints - you don't need them because you are manually placing on X-Y grid . When you know your register file is always immediately to the left of your ALU, no need for timing constraint as it will always work.

Look at me - I am an expert after 3 days

I said before, Arlet, I don't want to fight with you, I have a lot of respect for all your work. Verilog is a much higher level lanugage and you can go on forever. Fpgasm does not have + or - or any logic operators - you have to make a lookup table. It does not have generate or concatenation or conditionals or case statement. Most important - verilog works, and I don't know if fpgasm does yet.

What I like is that it is really fast and simple and can do everything. It is getting me to think different about FPGA - the way I used to think about it from reading FPGA manual before learning Verilog. I think I understand it. And I keep thinking about how to make a CPU...

I feel very excited - they way I did when I got my first assembly code working on the Commodore!

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Good point, reflected in the name: it's an assembly language for FPGA. Not going to be an easy ride for complex designs but could be very rewarding for small efforts. Less power in the language, probably easier to make mistakes, but simple enough to get started quickly.

No, that depends on your routing delays, and your desired speed. Since the routing is still done by the Xilinx tools (correct me if I'm wrong), you don't know how much delay is incurred. Also, whether even a direct connection is fast enough depends on your speed target. What if you want to run at 200 MHz ?

And simple instantiations and wiring modules together can be done just as easily in Verilog/VHDL, with similar learning curve. So, the only disadvantage would be the execution time of the tools (but in return you get a guarantee you'll meet timing constraints). For simple designs, the tools don't take more than a minute, so it's still a small part of the overall time (assuming you spend a few minutes testing and redesigning). The execution time is even less of a concern if you do most of the design/test work using a simulator, which is recommended because that's the only good way to really see what's happening inside. I don't know how fast the Xilinx tools are for simulation, but you can get free Icarus Verilog simulation that will run simple designs almost instantly.

(Xilinx simulation is fast, convenient and very useful! This assembly-level approach lend itself more to experimention - again a point in favour of applying it only to simple designs.)

Arlet, you win, OK? You still have Verilog! Please do not take it as a challenge. Like I said, maybe this works, maybe not - I just like it.

In fpgasm, it is like designing a PC board. You pay a lot of attention to floorplanning and finding or creating components. Then you place the components close together, connect the wires and hope for the best! It worked for us in real world. Then you try it at 200MHz, I imagine. If it doesn't work, try 150MHz. In a minute you could try a few clock speeds. With timing constraints you can prefer some signals for speed at the expense of others. I don't see fpgasm doing it - I will email the creator about it - it is a good question.

BigEd, small projects is right. But what if someone made a 6502 module? Your small project could be a full retro computer, just wiring it in with other modules.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut