Date   

updated standard specification at github

Antti Lukats
 


website alive, standard specification 1.0.4 released

Antti Lukats
 

www.cruvi.com

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


Re: OLIMEX low speed interface standards

Antti Lukats
 

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


OLIMEX low speed interface standards

Mr. Edmund Humenberger
 

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/


Re: Klick Modules

Mr. Edmund Humenberger
 


Re: Klick Modules

Mr. Edmund Humenberger
 

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


Display interface for CRUVI boards

Mr. Edmund Humenberger
 

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

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

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


Re: Klick Modules

Mr. Edmund Humenberger
 

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.


Standard document from Antti here because I can not upload them to the shared folder

Mr. Edmund Humenberger
 

More infos about the proposed standard


System borders?

Mr. Edmund Humenberger
 

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.


Re: Use case

Antti Lukats
 

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.


creating ADAPTERS from-to

Antti Lukats
 

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 :)


Re: some infos from Antti about ID system

 

I can imagine a computer BIOS-like management tool for reading/writing the ID-s as well as for performing some rudimentary testing should the meta-data contain a HW description.


Re: First motherboard?

Antti Lukats
 

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


Re: Obvious modules

Antti Lukats
 

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.


Use case

Mr. Edmund Humenberger
 

I need a solution with several interfaces.

I buy a carrier board with enough cruvi slots and I buy all the different cruvi modules I need.

I plug in all cruvi modules into the carrier board and switch on the power.

The carrier board generates a device tree file which gets stored (where?).

I upload the device tree file to a web site. I configure othe website what kind of SoC I want (32bir Risc-V with Rust environment for all HW devices)

I download my system file, put it into my system(how?) Start the system and connect to it from my Rust development environment. 

I start writing my solution in Rust.

Edmund


Modules

Mr. Edmund Humenberger
 

Cruvi Verlängerungskabel between carrier and module (Up to how long?)

Cruvi connector cable between two carrier boards to connect two FPGA boards.


Re: cruvi2PMOD

Antti Lukats
 

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


Obvious modules

Mr. Edmund Humenberger
 

HDMI out

HDMI in


Re: PCIe M.2 ?

Antti Lukats
 

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 !

1 - 20 of 41