mostly incompatible - part 2: Wrapping it up

The problem, stated in the last post, has an answer - an artificial layer above the status quo, where everything is just fine ;-)

What should be acomplished

• You start with a collection of SOPC components, normally described by a _hw.tcl file and VHDL files for their implementation
• You want to connect them in a useful manner, not worrying too much about the little details
• The component should work out the connection details on its own - if possible.
• HW dependencies / specifications should be implemented as transparent as possible.

Starting with the technique and hitting off from there ...

• Every component will get a Java-File that can be included like
  "import fpga_components.component2.*;"
• The Project itself gets another Java-File e.g. mySystem.java that is calling the components' functions in order to make the right connections (sometimes with arguments, referencing data files like the memoryInstance...xml files)
• The Projects can inherit from one another (Java is quite suitable for clean inheritance) and overwrite properties (e.g. bit_width) and methods (when some part is just handled in a completely other way).
• The output of that whole Java-Process would just be some small TCL-Files with the plain calls to the automated SOPC builder...
• In the long run the _hw.tcl files should also be generated by the Java-File (... but that might be a nice second step ...) so the correspondent things can be done for Vivado etc. - but for a first run, the SOPC integration could be done with the already existing _hw.tcl files.
• "service" components like a memory core with multiple ports collect all the requests from the connected components and configurate themselves afterwards accordingly (so - it is dynamically decided, whether a component gets port 3 or 4, whichever is the next unused one...).
• For the normal case, that the memory core isn't written by yourself, its configuration is done with a Java-File nevertheless - the instantiation calls just call something external that is included otherwise.

First traps - right means used?

• A first thought was to use precompiled .jar-Files - that way, you could have started out without knowing, which files are around...
• For a first implementation, the version with "hard linked" files will be more transparent and the upcoming errors easier to find... (You just have to call "javac .." and "java ..." after one another to get it started - so linkage problems will occur already at javac).
• Java is a "clean" language and on all platforms available.
• The alternative might have been C# where the plugins would have been .dll files - do-able but not really easy to read.

Above above

• The components should have a common core - so the base class(es) will also be a part of the fpga_components-directory and they will also be checked-out/copied-into/whatever.

=> Hot air without content

• The real problems and real answers will occur on the battlefield - when the first classes have been written and the smoke clears...
• A good way would be to port some existing code to the new manner and to try to implement a small project that just instantiates two or three of these components and glues them together ...