Scineric Workspace has been in development for more than 3 years. Looking back at where it started, you would hardly notice any relationship between what it was back then and the product we have today. This post is about how Scineric Workspace came to be.
(If you are not familiar with the tools in the sections to follow, they are all firmware development and vendor tools.)
To be honest, it actually began by accident – as a simple utility to convert Xilinx .prj files into ISE .tcl scripts. In our team at the CSIR, we were in a situation where we needed to do some floorplanning on our Xilinx devices in order to meet timing requirements. We do our development in Mentor Graphics’s HDL Author and we have always just created a netlist using the available built in tasks which we would then use to create NGC based top level ISE projects. To have more control over the floorplanning and the complete implementation process we decided to move away from these netlist-based top level projects.
To do that, someone in the team created a simple command line based converter. However I’ve been very interested in the Qt framework at the time and decided to rewrite it in Qt. Allowing the converter to be launched from within HDL Author. The result was a simple utility called “HDL Author ISE Export Plugin”, shown below:
We started to use the plugin on a daily basis and it made our lives much easier. Having this control over the way we do the exporting, soon lead to numerous ideas on small improvements that can be made to it, however since I wrote it quite quickly it was a bit of a mess and not really easy to maintain. As a result, we used it as is for a few months without maintaining it at all.
During that time we finished off a big project in our team, where I had the responsibility to book most of the firmware into our configuration management system. Since we didn’t have a standard way to do that, it took more than a month to put around 15 firmware packages together. I learned an awful lot during this exercise and although I did not have the answers back then, I knew that there had to be an easier way to package firmware designs. I looked around for solutions, but found none.
A few months after the configuration package exercise, at the end of 2010, I found time to do some work on the script converter and decided to rewrite it from scratch. My main goal back then was to store the structure of the design internally in the tool, to allow us to eventually use it to create our own firmware configuration packages. The architecture was simple, allow parsing designs from (initially just .prj files) and to (initially just .tcl scripts and zipped configuration packages) different sources. To facilitate this functionality, different parsers were grouped into different plugins allowing easy extension of the tool. The result was a new application called “Firmware Management Tool”, show below:
Using this new tool on a daily basis soon lead to many small changes and improvements to it. The name changed to the easier to use “Firmware Manager” and because its architecture was properly thought through this time, extending it was pretty easy. For example, we added a documentation mode where you can open someone else’s configuration package and just click “Generate” and you have their code documented using a Doxygen backend. Another example is the ability to track changes to the structure of a design over time. Perhaps the biggest change during this period was introducing the ability to define where files must be hooked to the design tree. For example, .vhd files ends up under “Design Files” and .ucf files under “Constraint Files”. The “File Associations” settings page for that is shown below:
In the middle of 2011 it got to a point where we decided to present the tool to other firmware teams within the CSIR with the expectation that the tool can be useful to them as well. The initial reaction was positive, but it was clear that the tool must be more customizable and generic in order to fit into the workflow of other teams. We also learned that the problems solved by the tool are not necessarily unique to the processes involved in firmware designs. I decided that the solution was to change the core of the application to work on a concept called “File Association Databases”. A seperate blog post will dig into the details, but in short a file association database defines a set of rules of how a design must be managed.
The file associations idea from previous versions thus evolved into a database which stores much more than just the file associations. At the time I stumbled upon a company called Boldport and it presented some well thought out ideas on how firmware designs must be managed. After a lot of research, discussions and polishing the ideas in my head, I started to work on what would eventually become v1.0 of the application released on the 14th of March 2012. A product which allows you to manage any arbitrary set of files using a set of customizable rules. The name changed to Scineric Workspace, which represents a Scientific and Generic Workspace in which you can manage your files and the processes around them.
Presenting Scineric Workspace v1.0 at numerous places soon indicated that people got excited about it and that it might be useful to a wider audience outside of the CSIR. Today we are getting ready to exhibit Scineirc at the International Conference on Field Programmable Logic and Applications (FPL2012) and we are looking forward to see how people will react to it.
Naturally, many things have changed from the initial screenshots shown in this blog post (they are all about 2 years old by now) as well as the functionality described above. Today Scineric Workspace is a full blown product which has been polished over a long time and boasts a long list of features.
Last but not least, here is Scineric Workspace as it looks today:
If you found this post interesting, you will find Scineric Workspace very interesting. Get in touch, we would love to hear from you.
No comments yet.