-
Notifications
You must be signed in to change notification settings - Fork 4
Home
- Support for arbitrary file properties (suggested by Walter F.J. Müller) - done!
- Support for testbenches (suggested by Walter F.J. Müller)
- If the EPRJ file continues to evolve, it may be necessary to add the format version description. (As the sources included from the "alien" repository may be described with earlier version)
- 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)
- The above point of course implies that the port for Altera/Quartus is finished. It is in very initial stage yet...
- Add the 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.
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).
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.
We have two git related commands:
- 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] )
- 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] )
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 )
In case of other VCS we can always implement a script for downloading the appropriate sources, and use the
exec line to execute it!
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...
The simulation of designs with OOC blocks does not work (due to problem with compilation order).
The behavioral simulation works, after all OOC blocks are "OOC unset". The post-synthesis and post-implementation functional simulations also work.
There are problems with post-synthesis timing and post-implementation timing simulations. After checking the https://forums.xilinx.com/t5/Simulation-and-Verification/ERROR-XSIM-43-3225-Cannot-find-design-unit-xil-defaultlib-glbl/m-p/703641 I have modified the project building script so, that:
- If the project default lib is "xil_defaultlib"
- If the library for the block is "work"
The library for the block is set to "xil_defaultlib". That solves the problem of post-synthesis and post-implementation timing simulations.
Below are a few references describing the problems with simulation in Vivado: