FPGA toolchain for Linux

[baremetal]

Hello everyone,

I would like to get recommendation on how to set up toolchain with Makefile on Linux distro for FPGA. I couldn't find any steps on how to set this up without some IDE.

Thanks,

[tsman]

You couldn't find any guides because you're asking an extremely vague question. What FPGA manufacturer? What model? The short answer is install the manufacturer provided software suite such as Xilinx Vivado and pay lots of money if your part isn't in the freely available version.

[rstofer]

Did you Google for 'xilinx makefile example' or something similar?  There are lots of examples for the older toolchain 'ISE'.  You might change the search to 'xilinx vivado makefile example'.  The Makefile approach was fairly common with ISE back about 10 years ago.

There is a Linux centric toolchain, search for: 'linux fpga tools'

So, yes, it can be done.

The generic tools under Linux often can't synthesize.  They can simulate standard logic but not vendor specific primitives.

IceStorm is open source, maybe it can be driven with a Makefile.

[FlyingDutch]

Hello,
 if you use Xilinx FPGA it might be interesting for you to take a look into "Petalinux":

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842250/PetaLinux

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841618/PetaLinux+Getting+Started

Kind regards

[james_s]

Why not just save a lot of time and trouble and use the vendor supplied IDE? I'm not aware of any viable alternative. ISE and Quartus are both available for Linux.

[nctnico]

Why not just save a lot of time and trouble and use the vendor supplied IDE? I'm not aware of any viable alternative. ISE and Quartus are both available for Linux.

The tools can be used from Makefiles. There is also hdlmake which can be used to automate building FPGA projects. It is not quite finished yet but it helps to share large projects which share common modules. With bigger projects the IDEs starts to suck especially when you want to share code between various projects.

[dgtl]

The vendor ides execute external binaries, these calls can be ported to makefile. Or alternatively, they support tcl scripts - ie Vivado can be run in batch mode given an tcl script. You can run that from your makefile. For our big projects, we generate tcl scripts from our build scripts and then run the tool in batch mode (no project files are stored in repositories, only system to resolve dependencies and generate tcl script to let Vivado generate its project depending on the configuration needed). This gives enough flexibility while being a single-step-make to reduce human errors to minimum.
There are some limitations, ie the components generated using their ip generation tools - afaik their configuration can not easily be modified with non-gui tools (parameters etc), so we need to store multiple variants and choose from them.

[NorthGuy]

Vivado is TCL based, so you can write your own scripts which can do practically anything - more than you could do in GUI. If you wish, you can use it as a TCL console, or you can invoke it to run a single TCL script - same as makefile. Of course, there's some learning curve involved.

[legacy]

I don't see points. What do you want to achieve?

[legacy]

With bigger projects the IDEs starts to suck especially when you want to share code between various projects.

I have never had problems with that. And I share a lot of VHDL code. What's wrong exactly?
Here, when I create a project, I manually import VHDL files from my library under versioning (git) into a local folder. And that's all I need to do. If I modify a local file, git and Beyond Compare (on Linux you use "Meld") report what has changed.

For simulating large project I am using ModelSim, which is the best ever for this.

[legacy]

we generate tcl scripts from our build scripts and then run the tool in batch mode

what have these tcl scripts have to do, exactly?

[filssavi]

Why not just save a lot of time and trouble and use the vendor supplied IDE? I'm not aware of any viable alternative. ISE and Quartus are both available for Linux.

There are various reasons:

1) FPGA IDE’s lag noticeably behind everything else on the planet (even VS code is significantly ahead of every fpga ide) in term of everything, especially dependency management
2) the integrated editor in fpga tools are almost at notepad level of sucking, using an external editor takes away the I in IDE and thus the things don’t make sense
3) altera hasn’t even managed to integrate a modelsim  front end and waveform viewer in the crappy mess they call An IDE
4) using VCS with gui projects is a nightmare, as the bloody things spread the settings and everything else among so many directories it isn’t even funny

And I could go on for hours

Thank god vivado has sane tcl scripting support from command line and I can create and delete projects on the fly as needed and check in only the tcl script

[legacy]

Thank god vivado has sane tcl scripting support from command line and I can create and delete projects on the fly as needed and check in only the tcl script

Why do you need a TCL script to create a project? Exactly what do you need to do?

[james_s]

I have not encountered these problems, ISE, Vivado and Quartus all have perfectly adequate text editors, it is a concept that has existed for decades, what more could one do to improve a text editor? Who cares if it's behind? With the current trend of software being constantly tinkered with, being in a constant state of flux like some perpetually half finished project car, chasing the latest UI fads which currently seems to involve hiding/removing frequently used features and inserting acres of useless white space to look "clean" or "uncluttered", being "behind" is something I've come to see as a benefit. I have 10+ year old software that is infinitely more usable than a lot of current stuff I encounter.

[NorthGuy]

I have not encountered these problems, ISE, Vivado and Quartus all have perfectly adequate text editors

Certainly not Vivado. Say, when you paste something, it automatically "improves" indentation, and then you need to fix it. I wish they had a simpler editor.

[nctnico]

I have not encountered these problems, ISE, Vivado and Quartus all have perfectly adequate text editors, it is a concept that has existed for decades, what more could one do to improve a text editor?

OMG! Those text editors suck badly. Try Eclipse + veditor for starters or Sigasi if you want to get luxureous. Being able to search through your project, having realtime syntax checking, browsing through the project, etc. Seeing which signals and components are used in a file. The list goes on and on. If you have a reasonably big project then having a real code development tool instead of notepad saves you a ton of time because the development environment helps you to navigate through the project.

[nctnico]

With bigger projects the IDEs starts to suck especially when you want to share code between various projects.

I have never had problems with that. And I share a lot of VHDL code. What's wrong exactly?
Here, when I create a project, I manually import VHDL files from my library under versioning (git) into a local folder. And that's all I need to do. If I modify a local file, git and Beyond Compare (on Linux you use "Meld") report what has changed.

Now try to share the same project using different IDEs from different vendors. The hdlmake I mentioned earlier can create project files for ISE, Vivado and Quartus from the same project for a specific build target. Also needing to import files manually into the IDE sucks especially if there are about 100 to 200 files and some conflict with eachother.

[legacy]

Now try to share the same project using different IDEs from different vendors.

I do without any problem, and I do it for a living.

Also needing to import files manually into the IDE sucks especially if there are about 100 to 200 files and some conflict with eachother.

100 files? here my projects (and I am talking about the largest one) have a max of 50 files. Importing them is no problem, neither with git nor for libraries. Files are hierarchically handled.

Which conflicts are you talking about?


Besides, I still have to understand WTF Makefile should have to do.

[legacy]

Sigasi if you want to get luxureous.

is it luxury or ... just envy? 

[filssavi]

The script creates the project, imports all the required dependencies, create and adds the block design etc.

This workflow has many advantages:
-Moving between machines is trivial as it only takes just 2 commands (git clone source make.tcl)
-everything is versioned through git, even the project settings, and my repository is not a mess of auto generated files Peppered across a massive directory structure
-code reuse and sharing between different modules is much easier, especially if interfaces between modules are not completely set in stone

[nctnico]

Sigasi if you want to get luxureous.

is it luxury or ... just envy? 

If you want to pay for it (which I don't because I need software to have perpetual licenses) then Sigasi is a tool which helps a lot during Verilog and VHDL development. I tried the Sigasi Eclipse plugin for a while and it works great. Veditor is a good alternative but not as extensive.

[james_s]

Certainly not Vivado. Say, when you paste something, it automatically "improves" indentation, and then you need to fix it. I wish they had a simpler editor.

I've only played with Vivado briefly, decided it was dog slow and that I'd rather spend my time making something than learning a different tool. I spend most of my time in Quartus and at least with that you can turn off the auto-formatting features. You can also edit the files in whatever editor you like and the IDE will offer to reload the modified file.

[rstofer]

Besides, I still have to understand WTF Makefile should have to do.

Among other things, it could call up the C compiler to create a .hex file to be included in the image to initialize the contents of BRAM.  This occurs somewhere during synthesis.

There is another way to patch the image with new memory contents using Data2Mem and this is a LOT faster than rebuilding the project.  But, still, a Makefile could drive the C compiler and Data2Mem.

[Macbeth]

I heard Altium is the one-stop-shop you are asking for regarding FPGA? Indeed, PCB layout should be a mere add-on afterthought optional extra.

Oh wait - I think that was when Dave worked there... 

[nctnico]

Also needing to import files manually into the IDE sucks especially if there are about 100 to 200 files and some conflict with eachother.

100 files? here my projects (and I am talking about the largest one) have a max of 50 files. Importing them is no problem, neither with git nor for libraries. Files are hierarchically handled.

Which conflicts are you talking about?

Actually the project I'm working on every now and then has over 500 VHDL files and some provide the same functionality for a different platform / build target.

[legacy]

Among other things, it could call up the C compiler to create a .hex file to be included in the image to initialize the contents of BRAM.  This occurs somewhere during synthesis.

One thing is compiling the firmware, one thing is injecting the hex/srec content of the binary file into the ROM of the softcore project.

They are two separates phases, and I appreciate Makefile only for the C/Ada/Assembly step.

There is another way to patch the image with new memory contents using Data2Mem and this is a LOT faster than rebuilding the project.  But, still, a Makefile could drive the C compiler and Data2Mem.

This is a good point.  Here I use two approaches

1) an external tool (made by myself); it reads the VHDL file that describes the ROM without data initialized (it's sort of ... "empty structure") and the output of the C toolchain (hex/srec file), and it produces a VHDL file with the BRAM instantiated. This way I have the possibility to describe the BRAM as I wish (usually b16 model) without any troubles. So the Makefile only needs to "copy" a file to a specific path in the project's source. This is OK for ModelSim with no bad side effect, but ISE usually tends to re-synthesize other stuff, which takes more time unless you try to force "differential synthesis".

2) Data2Mem is the tool I usually go to save time. But I invoke it manually.

[rstofer]

With ISE, I could specify memory contents in the VHDL code that instantiated the memory or I could write it into the constraints file (*.ucf).  Putting it in the contraints removed the requirement to resynthesize the project, only place/route plus bit file generation was required.

I wrote a bunch of programs in Basic that would take conversion tables, like ASCII -> Hollerith, and magically patch the .ucf file.  I have forgotten why I used Basic but it seemed right at the time.  Probably for the string handling.

Data2Mem requires that I know a lot more about the placement of memory.  It's a nice way to patch a complete bitstream but it does take a little more effort.  Then there could be a problem if the place/route phase moved the memory block to some other location.

[nctnico]

With ISE, I could specify memory contents in the VHDL code that instantiated the memory or I could write it into the constraints file (*.ucf).  Putting it in the contraints removed the requirement to resynthesize the project, only place/route plus bit file generation was required.

Unfortunately synthesis is usually the quickest part of the whole 'compilation' process. I have not used data2mem but usually I have a way to load the memory through some kind of interface.

[legacy]

I have a way to load the memory through some kind of interface.

This is the job done by Otaku. Our debug-engine.

[Bassman59]

Why not just save a lot of time and trouble and use the vendor supplied IDE? I'm not aware of any viable alternative. ISE and Quartus are both available for Linux.

There are various reasons:

1) FPGA IDE’s lag noticeably behind everything else on the planet (even VS code is significantly ahead of every fpga ide) in term of everything, especially dependency management

That's because nobody actually uses the IDE for code development, only for synthesis and place-and-route.

2) the integrated editor in fpga tools are almost at notepad level of sucking, using an external editor takes away the I in IDE and thus the things don’t make sense

You are correct -- they do suck. Which is why those of us who do this for a living choose another editor (I prefer emacs, see that long thread about it) but everyone has their own preference. There is absolutely no reason to use the Xilinx/Altera/Microsemi/Lattice tools' built-in editor.

Code entry is a separate process from simulation and from the back end synthesis and place-and-route.

3) altera hasn’t even managed to integrate a modelsim  front end and waveform viewer in the crappy mess they call An IDE

And so what? I use ModelSim standalone. That's a lot more flexible and actually straightforward than pushing a button in the fitter project manager. My ModelSim projects have more than one top-level and simulation configuration.

And not having the simulator integrated into the IDE means you can choose any simulator you like. I've been using GHDL and it's fine and a lot more lightweight than ModelSim.

4) using VCS with gui projects is a nightmare, as the bloody things spread the settings and everything else among so many directories it isn’t even funny

I've been using a version-control system with FPGAs for 20 years. All you need to put into your repo are the sources, the synthesis constraint files and the simulation project file (for ModelSim that's the .mpf). Keep your sources separate from the other two things. You can re-create the entire GUI project for Vivado if you use their script.

Microsemi's Libero is annoying as hell and I stopped using it. Once I realized that you can run the designer place-and-route standalone, I just did that. Synplify runs standalone, too.

I mean, I agree that FPGA tool usability sucks in general. Xilinx finally got religion late in the ISE cycle and got rid of the binary project file format and replaced it with VCS-friendly XML. Then they went backwards for Vivado. And it's not like they actually listen to their users.

[filssavi]

 no one uses the IDE for code development because it sucks, if it was actually good people would use it

Again code entry is done outside the ide because the ide sucks at it, if was actually decent surely people would use that as opposed to a separate text editor (also note that decent text editors have emacs/vim plugins for people that are used to those)



In the end people don’t use IDE’s because they suck:
they are extremely limiting, especially once you start wanting to split designs into separate modules for reuse, I have used both vivado IP system and qsys and they suck equally as much at it

If you look at the software development workflow it is largely the same, but there IDE’s are used it is because they do actually solve problems, instead of just getting in your way.

This is not a problem with IDE’s in themselves It is just the FPGA implementation of IDE’s that suck

[dgtl]

we generate tcl scripts from our build scripts and then run the tool in batch mode

what have these tcl scripts have to do, exactly?

Generate project, add all required files into the project (there are a lot of alternative components depending on the configuration chosen etc), set up all synthesis options etc. In short, Vivado starts with empty project and gets set up to synthesize the specified configuration of the project, all without touching anything in the gui. Of course, some components are auto-generated too (ie bus matrixes etc).

In addition we have some scripts that post-process some of the intermediate results (where Vivado "optimizes" some constructs so bad that we're unable to reach timings) etc. It is possible to alter connections post-optimize to rewire some things that are mis-optimized (ie to low area, but that would never perform at timings we need) or to undo optimizer errors (glad that they are much more rare than years ago). Sometimes you just got to do crazy things to be able to ship project on deadline...

Then we can run the synthesis either interactive or not. Vivado's schematic viewer is very good and the ila gets used a lot too, so for dev, it is usually open in vivado gui. As of ide, we are not using Vivado. Vivado detects external file writes quite well and knows whats been updated (there are some exceptions, ie when pulling xci updates from source code repository...)

[legacy]

@dgtl
Thank you for your neat explanation 

[legacy]

I have a way to load the memory through some kind of interface.

This is the job done by Otaku. Our debug-engine.

Code: [Select]

# help
exit................ - byebye
?................... - cmd list
help................ - show specific cmd help
ver................. - version
devload............. - load into dev memory
devswho............. - device info
devslist............ - list devices
md.................. - memory display

# md 0x00100000
showing memory @ 0x00100000
00100000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]

# devload 0x00100000
0x00100000..001fffff 1048576 byte mem:1 rom0 data_ram0.bin
loading data_ram0.bin ... done, 512 Kbyte

# md 0x00100000
showing memory @ 0x00100000
00100000: 68 41 6c 6c 6f 0a 57 6f 72 6c 64 0a 74 68 69 73 [hAllo.World.this]
00100010: 27 0a 73 20 6d 65 21 0a 00 00 00 00 00 00 00 00 ['.s me!.........]
00100020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
00100090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
001000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]

#

This runs on a Linux host; it connects to the FPGA through a fast serial line @ 1Mbps, and it's able to upload a file into the "BRAM"- modeled ROM/RAM. The VHDL code for this inside the FPGA is very small.

It's used to upload a binary (hex) to a softcore's ROM.

[rstofer]

I haven't tried it but I understand I can include a memory initialization file in the platform flash residing beyond the FPGA image.  I am supposed to be able to read this file via SPI somehow.  I never pursued it.

At some point, it is just as easy to have some kind of 'cold start' process read the initial contents from something like an SDC or Compact Flash.

On the real IBM 1130, there was a Cold Start card that contained a startup image which the hardware forced into memory at 0x0000.  The cold start loader then loaded the operating system from the disk drive.  This loading of a card image directly after a reset was hardwired into the CPU and this allowed for other card images - notably diagnostics.

On my version, I hold the CPU in reset while I copy the cold start image from a small chunk of BRAM into main memory.

If I continue playing with the LC3 project, I'll probably do a similar kind of thing.  Have code in the FPGA image to read the boot code from some external storage device.  That would work well because the Digilent Nexys 4 DDR board has an microSD socket.  With a little imagination, I can put most or all of the system IO drivers in some high memory location ala CP/M.

Interesting project:  Recreate the functionality of CP/M on the LC3.

[nctnico]

I haven't tried it but I understand I can include a memory initialization file in the platform flash residing beyond the FPGA image.  I am supposed to be able to read this file via SPI somehow.  I never pursued it.

At some point, it is just as easy to have some kind of 'cold start' process read the initial contents from something like an SDC or Compact Flash.

Some Xilinx FPGAs can do that. I have used that in a project a while ago to have the FPGA update itself (through a softcore) and store parameters. IIRC the SPI pins become regular I/O pins after initialisation so if you have an SPI master in the FPGA you can access the external SPI flash.

[james_s]

no one uses the IDE for code development because it sucks, if it was actually good people would use it

Again code entry is done outside the ide because the ide sucks at it, if was actually decent surely people would use that as opposed to a separate text editor (also note that decent text editors have emacs/vim plugins for people that are used to those)

Loads of people use the IDE for code development, I've used the ISE and Quartus IDEs almost exclusively for as long as I've been doing FPGA development. I really don't see the issues people are complaining about, they work just fine. I type code and it appears on the screen and can be saved in a file. They're not the absolute best text editors I've ever used but they do the job and are far from the worst.

[asmi]

IIRC the SPI pins become regular I/O pins after initialisation so if you have an SPI master in the FPGA you can access the external SPI flash.

All except clock pin. To gain access to this pin you will need to use STARTUPE2 primitive.