zjason has quit [Read error: Connection reset by peer]
zjason has joined #litex
shorne has joined #litex
wirthlin has joined #litex
<wirthlin>
We are new to Litex and are working on fault tolerant systems that tolerate radiation induced upsets. In particular, we are developing a variety of approaches for improving the reliability of liteDRAM using ECC and other methods. We created a simple SoC system that includes the BIST module and the ECC module that we plan on using at a radiation
<wirthlin>
test facility in December. Our system is available at a public repository that is forked from the main Litex repository (https://github.com/TommyCox/litex).
<wirthlin>
One of the issues we are struggling with is how to manage changes in the soc systems we make. We have had to make some changes in the soc.py and a number of bios functions to support our system. It seems that users of Litex may need to make small changes to files within the Litex repository that are specific to their project and it is not clear how
<wirthlin>
to manage such changes.We have identified a few possible ways to do this and are looking for feedback from the Litex community on best practices for managing local/project specific changes to Litex files for our work.
<wirthlin>
Method 1. Fork our project and track changes to main
<wirthlin>
This is what we are doing now. We made changes to soc.py and other files on our fork so we can customize our project and also track changes in the main repository. We will update our fork to track changes in the main branch occasionally. This is working for us so far but it seems like a lot of work for making relatively small changes to files in
<wirthlin>
the main branch.
<wirthlin>
Method 2. Create “patch” files for changes we make
<wirthlin>
Another idea is to create “patch” files for the various changes we make to the main branch and archive these patch files in our own local repository. This significantly cuts down on what we store locally but seems like a hack.
<wirthlin>
Method 3. Copy local files and diverge
<wirthlin>
Perhaps our changes to soc.py (and others we are working on) are such that we should just archive these files in our repository and diverge from the main branch. The advantage here is that we only have to archive the files we change. The disadvantage is that we will diverge from the main branch.
<wirthlin>
Method 4. Submit pull request to integrate changes into main
<wirthlin>
Some of our changes may be generic enough to be included back in the main branch. I suppose this is the preferred way if the changes we make are general. Of course we will do this wherever possible but some of our changes will be specific to our project and not relevant to the community.
<wirthlin>
Method 5. “Back door” changes of the Hardware
<wirthlin>
I have seen some Migen code in which changes are made to hardware that is already created. One approach we have considered is using the main branch sources to build a system and then provide code to go back and modify the hardware that was created. This allows us to archive only our “post process” code and rely on the main branch code. However,
<wirthlin>
this seems like a hack and is difficult to follow for other users.
<wirthlin>
Any suggestions or documents that discuss best practices would be appreciated.