Amino and HW_Slices

[Interactive_Matter]

Thanks Dan,

due to your patience to explain any detail again and again for me I got a quite clear view of what the base board of the slice kit will look like.
When do you ship it? ;)

OK got one last question quite unrelated: what about structural (like in physics) stability of the slice kit. I think one of the success factors of Arduino is that it is relatively robust.
Is there any plan to increase the physical stability?

Thanks

Marcus

[dan]

Thanks Dan,

Is there any plan to increase the physical stability?

what would you suggest??

I'm going to ignore the other question for now...

[TonyD]

[moved from https://www.xcore.com/forum/viewtopic.p ... 4&start=20]

I'm struggling with the how much space is wasted with the plugin card concept. I've always found a stacked based arrangement similar to PC104 or even the Arduino Shield concept to be more efficient and easier to mount or house in an enclosure.

Have you an particular type of enclosure in mind for housing the Slices?

[Corin]

Hi Tony,

The reason for using the plugin card concept was that PCI-E connectors are used, which are in this orientation, because:
- they are cheap
- they require no connector on the daughter (slices) board
- they are good for high speed signals
- they are compact

Cheers,
Corin

[Interactive_Matter]

I have raised the same questions about physical stability.
I think it is an advantage of the arduino platform.

What are the costs to create a basic custom case?

For stability of the daughter cards it might be enough to have some kind of slotted plastic cubes which hold the daugther cards firmly (think of a cube of soft plastic with a slot in the middle - slighty to small for a PCB,at the end of each PCIe connector which grabs PCB edges of the daughter card).
But that would not realy solve the issue of stability of the overall construction - it still can fall over. If the case is laid out horizontally (So that the daughter cards are horizontal and the main PCB is vertical) it would solve this because the whole construction allready has fallen over ;) - I hope you know what I mean

Marcus

[dan]

Let me try and clarify what the modular hardware is about. We hadn't envisaged it to be an all things to all men kind of deal - that always ends in tears somewhere.

We see the following key objectives for it:

1) A general, flexible XS1-L development system with a range of networking connectivity options and plenty of IO resources.
2) A standard platform to enable the sharing of software components among the community. Abundant IO is important IMO to enable this.
3) reasonably low cost
4) easy to develop add ons for

It was not intended to be the cheapest entry point or to target minimal form factors. For this we have corin's DIP proposal, possibly with XTAG functionality integrated.

We should consider the best mix of features for the modular system, on the assumption that a separate low cost, small 48-pin option exists for those who are targeting more basic functionality or who want to make something compatible with a particular enclosure. The question is then, what is the gap left uncovered between these two systems and is it likely that many potential projects would fall into this gap?

[Interactive_Matter]

Sorry, I have to disagree in one point:

2) A standard platform to enable the sharing of software components among the community. Abundant IO is important IMO to enable this.

The XC langaugea is powerfull enough to write software modules which can be used on any platform (due to the injection of ports and channels in the main method. We should drop this completely from the lsit and just say that software modules are supposed to run on any hardware (if they are not too resource hungry). I think the XC compiler does a job good enough to enforce this

It was not intended to be the cheapest entry point or to target minimal form factors. For this we have corin's DIP proposal, possibly with XTAG functionality integrated.

We should consider the best mix of features for the modular system, on the assumption that a separate low cost, small 48-pin option exists for those who are targeting more basic functionality or who want to make something compatible with a particular enclosure. The question is then, what is the gap left uncovered between these two systems and is it likely that many potential projects would fall into this gap?

Let me go through some examples to verify if there is a gap:

- I want to create a small and cheap stepper motor control. For this I use the DIP module for protoyping and perhaps in some way later (e.g. just the schemtics, layout and BOM) for the production run - check.
- I want to create a real beefy project which includes a lot of resource. It can be cumbersom with the slice kit since I have to use 2 to 3 kits with interconnects - real big set up. I still can use the XC-2 (XC-1a has a little to few connectors) or several of them (I still like its form factor a bit more). An XC-0 kit would be cool, without USB and ethernet. Half check
- I want an experimentation hardware to mix modules for a given task - that is the slice kit. As said above it's scalability is given but can be a bit cumbersome with different kits connected over interconnect slices.
- I want to build a semi-final build of my project based on slices - works ok. The slice kit probably takes up a lot of cm3 due to it's vertical slices (and presumably some space between it. Would still be ok.

So my summary:

Cheap & small: DIP
Experimenter package: Slice & XC-*
Powerfull: XC-* though a XC-0 is missing (Still like the XC- form factor a bit more).

I do not see many gaps.

[Corin]

I've just added some diagrams of the L2 core board and the single and double width slices to the repo in the "Edge connector layout" section of connectors.rst

Cheers,
Corin

[kuba]

I'm somewhat worried about sending CLK signal around. It will utterly fail if the CLK is supposed to go to multiple daughter cards. You cannot connect it like a bus. It should be point-to-point connections, and there should be a dedicated driver per each load. You can use clock distribution chips that have multiple drivers in a single package. It can be something simple like 74xx04. For short runs (couple inches), it can be single-ended. If it's a longer run, it should be LVDS, but I don't see it a problem for daughter cards.

I don't see what the point is of distributing CLK anyway, since it's unlikely any daughter card will need exactly 15 or 20MHz, or whatever the clock speed is. It's much easier to generate a clock output at the right frequency using a port on XS1, right?

I'd think that using a multilane PCIe slot would save a little bit of room and allow having one slot per core.