Amino and HW_Slices

[Folknology]

I (and others) have been working on a opensource modular Xmos based hardware design for quite a long time (summer 2009). Please take a look at folknologylabs it is very relevant given the HW_Slices discussion

Thoughts

regards
Al

[jonathan]

Yeah - I have to say that it's great to see XMOS backing modular, open hardware based on the technology. I think Amino represents the best instantiation of this concept at present, though discussions are always good and its great to see XMOS' angle...

Does anyone at XMOS have any views on Amino?

[dan]

Thats great - let me go and get up to speed with amino then I'll be back.

[Folknology]

Cool, looking froward to your feedback Dan, although beware some of the posts there go back to 2009 ;-)
regards
Al

[dan]

Ok I've had a look at the two most recent posts on amino. I guess my feedback at this point is mainly a re-iteration of the stuff in the hw slices README. We liked the idea of using an L2 as the starting point because its got lots and lots of GPIO. It also has a good deal more resources than an L1 which makes for easier prototyping.

The kind of things we'd like to be able to construct using this system are detailed in the README - for example, the SD filesystem browser system requires an LCD connector on one daughtercard (along with a resistive of capacitive touch controller) and on the other daughtercard at least an SD card connector and ideally an SDRAM as well for use as a frame buffer.

It seems to me that the minimal form factor of the amino would likely preclude this particular app from an IO perspective and may or may not exclude it due to lack of threads and MIPs. Just to connect an external SDRAM for example you need a lot of IO.

We also considered vertical connected daughtercards like on the amino. We have not reached a fixed opinion WRT to what would work best, but in many cases we anticpate daughtercards having buttons, other connectors (for ethernet, CAN or something) and would worry that these little vertical blades/slices would not be mechanically sound for such uses.

What I couldn't see on the amino outline was any kind of outline of requirements - e.g. what are the design goals and target applications? Why did you go for a 64 pin rather than a 128 pin for example?

[dan]

One more thing - where are the amino design files - the schematics mainly, to be found?

[Folknology]

Hi Dan

Here is an ugly (we are working on a proper version thats more useable) version of the schematic keep in mind the caveats about changes etc

Excuse the issue with source files as we are looking at porting it all to Kicad to be more community friendly

I will respond to your other points a little later when my internet connection is more reliable.

regards
Al

[Folknology]

Thanks for your feedback Dan much appreciated, especially your clarification around HW_Slices in this regard.

Here are some responses to your feedback, hope it helps explain a bit more about Amino and its history.

Ok I've had a look at the two most recent posts on amino. I guess my feedback at this point is mainly a re-iteration of the stuff in the hw slices README. We liked the idea of using an L2 as the starting point because its got lots and lots of GPIO. It also has a good deal more resources than an L1 which makes for easier prototyping.

Originally we started of with dual core designs but after requests and suggestions form others looking to use it in more constrained applications we lowered the bar and simplified the basic project goals. It also has the advantage of lowering the entry to barrier always a good idea with opensource projects. We envisage support for all of the Xmos L family of XS1 chips with a range of appropriate boards (we already have L1 64/128 and L2 variants in design progress). This also enables Amino boards to be designed in 2 layers in addition to 4 making it more accessible as we didn't want to confine opensource construction to just the peripherals, we are trying to be as inclusive as possible in this regard really.

The kind of things we'd like to be able to construct using this system are detailed in the README - for example, the SD filesystem browser system requires an LCD connector on one daughtercard (along with a resistive of capacitive touch controller) and on the other daughtercard at least an SD card connector and ideally an SDRAM as well for use as a frame buffer.

We have no such limitations and requirements, that would be to specific for the Amino project. These features are considered add ons or options.

It seems to me that the minimal form factor of the amino would likely preclude this particular app from an IO perspective and may or may not exclude it due to lack of threads and MIPs. Just to connect an external SDRAM for example you need a lot of IO.

Sure, Amino isn't about specific add ons like LCD displays, SD cards or external SDRAM, The Amino project focuses more on the interface (slots/blades). Some Amino compatible boards will likely have the peripherals you allude to however. Also even the basic Amino boards can have cores added if more threads are required, that's a key part of its modularity concept.

We also considered vertical connected daughtercards like on the amino. We have not reached a fixed opinion WRT to what would work best, but in many cases we anticpate daughtercards having buttons, other connectors (for ethernet, CAN or something) and would worry that these little vertical blades/slices would not be mechanically sound for such uses.

We have designed the blades to be able to cope with Ethernet, usb and all manner of different right angled connectors. Top and front panels physically reinforce the blades depending on the deployment/prototyping and environment choices.

What I couldn't see on the amino outline was any kind of outline of requirements - e.g. what are the design goals and target applications? Why did you go for a 64 pin rather than a 128 pin for example?

Well like many Opensource projects it isn't the result of a specification, rather it is the evolution of some key basic ideas by several folks over the last 18 months. We also have the luxury of not having to focus on a target market or specific applications which provides us with greater flexibility, all blades.will work with all boards However that isn't to say there won't be commercial applications for Amino boards. Even though I can't speak on behalf of the others, I can indicate that Folknology Labs isn't the only entity exploring commercial opportunities around the Amino project.

regards
Al

[dan]

Hi Al,

Thanks for the detail above. Before continuing to your responses, I wanted to outline my more general thinking around open xmos hardware. From our perspective, both as xmos.com and as xcore community members, the open hardware thing is as much about SW components as anything else. We see open hardware as a critical part of us all being able to develop and share sw components in a practical sense.

So we don't see a need for a single unified platform, but its nice to imagine a scenario where we have a bunch of components, some of which have 'works with Basekit/slices' badges, some of which have 'works with amino' badges and some of which have both, for example.

So the vision is more of open specs for practical development platforms that component developers can take account of when they look at portmaps and so on, than it is a vision for this or that specific HW platform.

But that said, I'm still interested to know a bit more about aminio. So:

Originally we started of with dual core designs but after requests and suggestions form others looking to use it in more constrained applications we lowered the bar and simplified the basic project goals.

It would be useful to understand more about what the specific issues were that steered you away from an inital L2 platform.

Is it your view that 4-layer boards are problematic for open source?

Sure, Amino isn't about specific add ons like LCD displays, SD cards or external SDRAM, The Amino project focuses more on the interface (slots/blades). Some Amino compatible boards will likely have the peripherals you allude to however. Also even the basic Amino boards can have cores added if more threads are required, that's a key part of its modularity concept.

I'm not sure how you could ever support an SDRAM blade for example with those small connectors, or am I missing something?

Top and front panels physically reinforce the blades depending on the deployment/prototyping and environment choices.

Any more details you can point to on that?

[Folknology]

OK here is some more answers hopefully, I'll try my best. A lot of this wiill be easier once the Documentation is done as the old stuff is outdated.

Thanks for the detail above. Before continuing to your responses, I wanted to outline my more general thinking around open xmos hardware. From our perspective, both as xmos.com and as xcore community members, the open hardware thing is as much about SW components as anything else. We see open hardware as a critical part of us all being able to develop and share sw components in a practical sense.

So we don't see a need for a single unified platform, but its nice to imagine a scenario where we have a bunch of components, some of which have 'works with Basekit/slices' badges, some of which have 'works with amino' badges and some of which have both, for example.

That's cool, I also don't see a"Platform" let alone a unified one. Also Amino Beta is about finalising the slot/blade interfaces so we can move forward with building plugin hardware. There is however an entire software side to Amino which will support the blades, this is still very much in progress..

It would be useful to understand more about what the specific issues were that steered you away from an inital L2 platform.

We haven't steered away from the L2 we fully support it we certainly don't see it as a platform. We have lowered the barrier by building around L1 as in many cases this is enough (possibly more cases than the L2 in fact). L1 is more than adequate for a great deal of different applications. Not only that but but we also wanted the lowest common denominator, this isn't just about cost, but rather about how we combine smaller pieces in order to solve larger more distributed problems. We can't say for sure what's required to solve a given application, but modularity of smaller common nodes provides an economical and less complex (less specialised) approach.

Is it your view that 4-layer boards are problematic for open source?

No not opensource in particular rather it adds significant cost barriers and we feel that lowering barriers improves access, to us opensource is all about access so this is a priority and provides choice.

I'm not sure how you could ever support an SDRAM blade for example with those small connectors, or am I missing something?

Well that's not strictly true, blades support Xmos links, so placing an L1-128 on a blade with SDRAM is fairly simple. Also the slot blade design is itself expandable, whether or not that would support SDRAM only boards is another question and undecided at this point. Also you are just viewing Amino beta which is L1-64 based, Folknology Labs also has an Amino L2 design which includes SDRAM as standard option so Amino isn't confined in that matter.

Top and front panels physically reinforce the blades depending on the deployment/prototyping and environment choices.

One of the reasons for Amino Beta is to explore some of these physical choices and options, I will post about those developments and experiments when time allows, I am sure others will be exploring similar ideas moving forward.

Hope this helps.

regards
Al