https://github.com/micro-FPGA/CRUVI/blob/master/docs/CRUVI_Specification.pdf

updated spec available!

www.cruvi.com

website is alive, currently mostly only to forward to github for file access, including the specification document.

adapters to-from UEXT are planned, they are "wires only" eco system adapters to-from CRUVI LS connector

Olimex does not have that many modules, but some very intereting ones.

I2c SPI and Serial

Cruvi interface board to UEXT

 

https://www.olimex.com/Products/Modules/UEXT/

As the  Klickboards are too wide to be put directly on a CRUVI board,

A cruvi board should be made which allows to connect KlickBoards via the adapter which is made available anyway

So we only would need a smaller CRUVI board which provides the connector to the cable.

https://www.mikroe.com/mikrobus-shuttle

I think this displays are a good option for the start.

https://riverdi.com/technologies/ribus/

https://www.mikroe.com/ribus-click

Klick modules are 25.4 mm wide

http://blog.ljcv.net/2018/08/mikroelektronika-mikrobus-and-click.html

Cruvi boards are only 22mm wide.

So Klick boards would not fit on cruvi boards.

This is a problem.

More infos about the proposed standard

When system-designers design a solution, they care about the complete solution.

In automation, that would be the whole machine.
The design tool would hold the model of the whole machine, and all its modules.
The design tool would need to model the interfaces to other external systems.

Only then you can do simulation of the system and verify its functionality.

If we consider the carrier board the "system", then only systems  small enough to be driven by all interfaces fitting on one
carrier board would be designed and programmed. this is near to useless.,

Design software like https://www.br-automation.com/en/products/software/automation-studio/  models the whole machine.

I think so must we.


This means that we can have several carrier boards carrying interface boards, and those carrier boards need to communicate to each other.

Those communication channels between two carrier board will very likely be attached to a Cruvi connector on each carrier board. Those 
carrier2carrier connections might vary in speed and latency, as the media used might vary. But we should think about this usecase. Especially about time and clock syncing.

One main point of Cruvi should be "easy of use" for building systems.

If we want to build big systems, then multiclocking becomes an issue.

nice, that could be set as long term goal, but full 100% plug and play is not set as ultimate target, so it may take a while..

Some comments: when the carrier wakes up, then either SoC (if hard CPU part of main IC), or FPGA cold-boot image or baseboard controller would try to enumerate all detected modules. For some subset of modules this information maybe sufficient to generate the device tree, for all I2C, SPI like stuff and some more generic interfaces. For complex interfaces it gets more complicated as the FPGA "SoC" builder may have to pull in IP cores support different interfaces. Things that maybe possible are like generating the constraint files for the FPGA I/O connections and validating that the I/O banking and standard rules are OK, etc.

https://github.com/micro-FPGA/CRUVI/tree/master/ecosystem

partial list of some planned adapters updated in github, there are several more planned but please also add your wishlist :)

yees ->

kind of idea is/was a EUROCARD template:

3 + 3 cruvi slots (back + front)
SPACE for "brain" in the middle
fits some existing enclosure for eurocards
"some" connector front - RJ45 gBe ?
power connector back

the brain could be 4x5 module or soldered down ECP5 also or some other FPGA

https://docs.google.com/spreadsheets/d/1dKAiwvI3NWGZzw_dij6I-t_KGuxpKrdJGuAo-tG4v04/edit?usp=sharing

adding modules there

there are some "compromises" and caveats that well, we should document somewhere better (better place than my brain)

one of them is "low profile" option - if the FRONT Panel IO has to fit PCIe or FMC bezel the connector must be max 5 mm above PCB on the CRUVI module..

normal HDMI does not fit, but mid-mount types
https://www.wieson.com/userfiles/files/G3168-7300XXXX-00%20Model.pdf

would fit also micro any mini versions.

"low profile" is not hard constraint, the connector can be on the other side of CRUVI module also, then choice of possible connectors is much larger.

This is something I did look into for long time, we use the "solder down" spacers in some stuff, and press-fit could also be an option, but

There are some constraints why I pretty much excluded those:

1) press fit really requires the PCB to be perfect for the press fit and should it "fall out" once the PCB is damaged and can not be used any more
2) both full SMD and hole-and SMD solderable spacers - the look NICE but if you compare the PCB area they need it is almost the same for M2 solder down thing as M3 would require

from seveal vendors 0D is 6.2 for M2, M2,5 and M3 !!!!

only würth has this
https://katalog.we-online.de/em/datasheet/9774050243.pdf

land pattern 5.3 mm copper

those things are actually cool, I did rule them out as of "space" constraints..

if we add support for "solderable SMD spacer" - ok for 5.3mm footprint there is needed to change:

1) module PCB size about 1mm larger
2) move mounting holes and connectors about 0.5mm

adding 1 mm would not change module spacing, and the modules would still fit into inside FMC  card (there was a bout 3mm space left..)

so the only drawback is that "useable free PCB space" between the connector on the same layer as the connectors will be maybe 0.5mm to 1mm smaller, the max PCB area for single large component (on the other side) would not decrease.

in ANY case the "soldered" spaced can only be on the BASE board, this must be forced that way.

antti

yes, in the HS connector there is one dedicated TRANSCEIVER lane, and USB has also dedicated pins (reserved)
and -  M2 connector fits onto single wide CRUVI module !
so at least theoretically it should be possible !