FPGA toolchain for Linux

[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.