The Amino Project has evolved over the last couple of years from a need for higher performance and modularity than I could find in the opensource hardware world. Turns out I was far from alone in my desires for such a solution. Although initially I worked on possible ARM based solutions when others expressed opinions that strategy changed and we adopted Xmos as a core part off the architecture. In between those periods I was hoping to use FPGA and MCU combinations but a conversation with Omerk back in November 2009 moved the conversation onto Xmos. But we would like to indicate that this isn’t the final chapter for Amino on the architecture front and in the background we are still exploring both FPGA, MCU and Asic approaches to solving the issues we face in modularity and performance at this level.
This brings me to the point of this post then which is the clarification of what Amino really is. It is all to easy to let Amino’s scope drift away from it’s initial goals and become either to specialist or all to encompassing. So we would like to make a clarification for Amino going forward. In addition I would also like to clarify Folknology Lab’s role in Amino.
Amino is primarily concerned with the definition of a hardware interface. This will allow modular hardware components to be mixed and matched in order to build hardware prototypes, applications or solutions. So Amino’s primary documentation and focus should be concerned with the interface specification which is something we are working on and hope to get something concrete out shortly. In order to reach a point where this makes sense Folknology Labs has been building experimental open implementations of the standard. In this regard Amino Beta is purely an experimental Implementation on the Amino interface specifications, it does not represent a shipping or commercial product. Indeed anyone can and should make Amino compliant products, be they blades or boards that house blades. we also need to state that Amino does not decide the exact form factor of a blade or a blade holder, rather it concentrates on the pinout function and spacing. Thus one can for example have horizontal blades, indeed Folknology Labs has several design of this type for housing single or double horizontal blade configurations. However if more than 2 blades are required to be attached to a single board then a vertical arrangement is clearly needed, hence the initial design of Amino Beta using vertical blades. This has been asked about quite a lot by the way..
Obviosuly Amino interfacing is primarily about the hardware interface specification, in order to make these blades work together with different Amino boards however, there needs to be some standardisation around software, as well as the electrical characteristics. Initially this will be based around Xmos toolchains as that is the initial architecture used for the implementations but it is clearly not confined to that, later we hope we can expand this across other architectures whilst maintaining the benefits of a common interface.
One of the things we need to do after testing Amino Beta is make an initial release of documentation and implementation examples in a common area for everyone to access and perhaps participate in if they feel passionately about the idea. My initial idea is to use Github to house the project and use opensource tools where possible to create implementation examples. Amino Beta by the way was created in Eagle and we will release those files as part of this process, however we are trying to move everything over to Kicad (including our libraries) which will better support version control process provided by git, this is due to Kicad’s use of open format and text files unlike Eagle’s more restrictive binaries. We Cannot guarantee That Amino Beta will be ported as it is just a first example (porting is a lot of work), but future implementation examples will most certainly be created in Kicad.
We also hope to finalise the electrical and physical Amino interface standard by the end of March so that we can focus on implementations and software ASAP, clearly if there are any changes you wish to put forward or include, now is the time to do so.
Where does Folknology Labs sit within this? Well Folknology Labs is likely to create its own implementations of Amino and see it as an important part of its hardware and software strategy moving forward, but that doesn’t represent a reference implementation, rather it would represent Folknology Labs implementation, in other words Folknology Labs != Amino or vice versa..
So please let us know your thoughts on moving Amino forward, should we use github or some other method? how would you like to see Amino move forward, what sort of license should we use etc..