-
Notifications
You must be signed in to change notification settings - Fork 7
/
Makefile_rules.mw
56 lines (48 loc) · 4.12 KB
/
Makefile_rules.mw
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
{{Obsolete|This page is obsolete as new ORPSoC isn't based on makefiles}}
Standardized makefiles will help porting ORPSoC to new boards and toolchains. This proposal aims to find a set of rules for the various tasks involved in making a ORPSoC build
== Rationale ==
* The user should be able to build a load module for any supported board from the root directory of ORPSoC
* Users who want to make builds for several boards should not be hindered by the build environment
* The ORPSoC environment should be able to download, synthesize and create a load module for a given FPGA board with a command or two
* When a new board port is created, only the properties directly affecting the new board should be updated in the new build environment
* Synthesis and simulation tools shall be replacable
* Changing build options should only affect one file
== Design ==
* The ORPSoC root should contain a makefile that contains all targets needed to choose the preferred board and performing syntesis, simulation and P&R for it
* Each board should have a separate Makefile that handles the synthesis and P&R options
* Makefile snippets with predefined target for the supported tools shall be placed in a common directory and will be included by the board makefiles that need them.
* A board configuration file should contain all options needed for building and simulating a design for a specified board
== Board-specific ==
* config
** Download and patch all cores needed for the board (and other things necessary to perform synthesis)
* list-rtl-files
** Return a list of the board-specific ORPSoC RTL files needed for the top-level as well as all submodules' RTL files
* list-include-dirs
** Return a list of all directories for the board and it's submodules containing include files needed for synthesis
* netlist
** Create a synthesis netlist
* loadmodule
** Create a load module that can be directly programmed to the FPGA
== Synthesis ==
* netlist
** Create all netlists that are required for the backend tools
== Backend ==
* loadmodule
** Create a load module from the netlists and constraint files that can be downloaded to an FPGA or a Flash memory
== Implementation ==
So far, only support for Xilinx ISE with XST and CoreGen as synthesis tools have been implemented. The following rules in their respective Makefile snippets are used.
* Makefile-syn-xst
** orpsoc.xst (Generate a settings file with all synthesis options, include dirs (generated by list-include-dirs) and path to the project file
** orpsoc.prj (List of all RTL files. Generated by list-rtl-files
** xst (Perform synthesis)
* Makefile-syn-coregen
** coregen (Build coregen netlists from xco and cgp descriptions)
* Makefile-par-ise
** orpsoc.ngd (Run ngdbuild on a netlist from synthesis
** orpsoc_mapped.ncd (Run map on a ngd file
** orpsoc.ncd (Run par on a mapped ncd file)
** orpsoc.bit (Run bitgen on a p&r'd ncd file)
= Whiteboard =
I would like to have a standardized set of makefiles for every ORPSoC build, and include a Makefile.inc that contains all user parameters. I've been discussing with Saar Drimer at [https://www.boldport.com/docs/fpgaproj boldport] about integrating his work with our efforts [[User:Olof|Olof]] 09:48, 19 August 2011 (CEST)
I took a quick look at boldport. It isn't rocketscience they are doing; anyone working with multiple tools uses the same approach. What I don't like about it, is that it is not generic enough. It is too FPGA centric.--[[User:Rherveille|Rherveille]] 18:29, 24 August 2011 (CEST)
I totally agree on standardizing the Makefiles. I have a hard time following the current global Makefile of OrpSoCv2. MinSoC has been using Makefiles only for Synthesis. We created two different "standard" Makefiles, one for Altera and one for Xilinx. Both have mostly the same targets but run the specific commands for their respective tool. The Makefiles are found in a subdirectory of syn. A configuration script patches them to add the FPGA family name and to include a constraint file. After that, the patched file is copied to syn, where the user can type make to synthesize the design for a specific board. I think if we can agree on standard targets (Makefile targets), this is a feasible approach.