Home

TODO

1. Support for git repositories. For IP blocks handled by "include" it should be possible to define, that the sources should be checked out (using git archive?) as specific version from specific repository starting from specific directory. If the particular IP block is developped, then it should be included directly from the local clone of the repository [1]. That solution allows also having different versions of IP subblocks used in different bocks of the design as long as those blocks are marked OOC. Different versions are exported into different directories and then included into appropriate OOC blocksets.
2. Support for conditional commands in EPRJ files (e.g. depending on the platform - different lowest level blocks should be included for Xilinx and for Altera - idea suggested by Marek Gumiński)
3. The above point of course implies that the port for Altera/Quartus is finished. It is in very initial stage yet...
4. Added protection against selection for OOC synthesis of blocks located in modules already selected for OOC synthesis. In case of XCI or XCIX files, there should be also added automatic handling of their OOC flag. Generally that should be handled by the "in_OOC" or similar flag in the "block" object, which should be inherited from the parent, and possibly set when the new object is created by the OOC line. This flag will inform, that the currently processed block is a part of a bigger module chosen for OOC synthesis.

Implementation of VCS interfaces

In case of independently developed cores, we may need to copy the sources from remote repositories. Sometimes our cores may be compatible with the particular version (revision) of the external IP core. Therefore methods allowing to import the particular revision of sources should be provided. Additionally it may be necessary to slightly modify the imported sources. For that purpose we can either use the patch line (defined later) or use exec line to run the arbitrary script.

The imported sources probably will not contain the EPRJ files. We can describe the with a single EPRJ file (as the source related lines may use paths of arbitary complexity) or we may overlay the EPRJ files by overlaying them on the external sources (eg. unpacking the archive, but this is not VCS friendly, so copying of directory structure may be a better solution).

Implementation of GIT interface

Typical command used to download the sources (the particular version)

git archive --format tar --remote [email protected]:my_user_name/my_project.git tag-name directory/to/be/exported | tar -xf - --strip-components=2

The above works only with tags or branches. If we want to use the particular commit, then we must have a local clone of the repository, and then we can checkout the particular commit: ( cd /path/to/local/clone ; git archive --format tar tag_or_commit_id directory/to/be/exported ) | tar -xf - --strip-components=1

This should be conveniently wrapped in the EPRJ line. One of possible solutions may be:

git repository_url tag_name directory stripped_comp_num

There is however one important requirement. Assuming that our extended project structure is under VCS, we don't want the imported repository content to spoil our repository. So it must be either imported somewhere outside the tree:

git repository_url tag_name target_directory directory stripped_comp_num

or we can tell git to ignore the imported content.

We can simply assume, that the imported content should be always put into the "ext_src" subdirectory, and put the .gitignore file with single line ext_src/ into our directory...

In fact that solution seems to be better...

When the project is rebuilt, the ext_src directory should be removed, recreated and populated with the repository content.

Final decision:

We have two git related commands:

1. The first form: git_remote repository_url tag_name [exported_directory [stripped_comp_num]]

It will be transformed into:

rm -rf ext_src

mkdir ext_src

git archive --format tar --remote $repository_url $tag-name [$exported_directory] | ( cd ext_src ; tar -xf - [--strip-components=$stripped_comp_num] )

1. The second form: git_local clone_directory commit_or_tag_name [exported_directory [stripped_comp_num]]

It will be transformed into:

rm -rf ext_src

mkdir ext_src

( cd $clone_directory ; git archive --format tar $commit_or_tag_name [$exported_directory] ) | ( cd ext_src ; tar -xf - [--strip-components=$stripped_comp_num] )

Implementation of the SVN interfaces

In case of SVN repository, we can use a simple export command. The EPRJ line: svn repository_url_with_exported_path [revision]

Should be translated into following operations:

rm -rf ext_src

mkdir ext_src

( cd ext_src ; svn export [-r $revision] $repository_url_with_exported_path )

Using other repositories

In case of other VCS we can always implement a script for downloading the appropriate sources, and use the exec line to execute it!

Patching the content received from the remote directory

If we use the particular tag (release, version) from the external directory, we may need to patch it for our project. Therefore we need yer another EPRJ line patch...