Good Morning.
On 06/26/2018 07:56 AM, Luke Kenneth Casson Leighton wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jun 26, 2018 at 5:15 AM, David Lanzendörfer david.lanzendoerfer@o2s.ch wrote:
if you're not familiar with what a pinmux is, here are some resources:
http://bugs.libre-riscv.org/show_bug.cgi?id=8 hands.com/~lkcl/pinmux_chennai_2018.pdf https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf http://libre-riscv.org/shakti/m_class/pinmux/ http://git.libre-riscv.org/?p=pinmux.git;a=summary
I'm familiar with pinmuxing :-)
Thanks for the Ressources, I will look at this soon to understand, what your intention and fear is.
please note: a *commercially viable* 100% completed libre pinmux does NOT EXIST. SiFive's IOF is *NOT* suitable for general-purpose use (it does not do priority in-muxing).
Mohammed from eFabless promised me to put Tim (also on this list) and the others at the problem as soon as we get there. eFabless will design us a LibreSilicon muxing pad cell, which will essentially be a big analog switch with multiple contacts wired to of which only one is analog switched out at a single time.
it's a lot more complex than it seems: designing a pinmux is deceptive. a bit like how designing a DRAM cell is real easy so surely doing a DDR3/4 chip should be easy too, right?
the case that most people forget about is the one-pin to many-inputs case, which is absolutely essentlal to cover for a commercially successful chip (and with SiFive avoided dealing with by only ever having one-to-one on the inputs).
see slides 23 to 25 for why a priority-input mux is needed: http://hands.com/~lkcl/pinmux_chennai_2018.pdf
the pad characteristics *do not* need to be multiplexed. however the in, out and direction control *do* need to be multiplexed. (see slide page 14).
also it is *not* necessary to design an analog switch (and it is actually severely problematic for the rest of the design, to do so, as the entire chip must now be treated 100% as an analog design): a digital-only design can be done (and will cause a hell of a lot less problems). also as shown in the ericsson slides, it isn't necessary to do tri-stating either (except obviously as part of the IOpad control and characteristics, which themselves are *not* multiplexed).
basically a standard single-input single-output flexibly-configurable IO cell is sufficient for the job: one where it can be switched from Open-Drain to CMOS Push-Push, its pull-up and pull-down resistors can be enabled/disabled, hysteresis can be controlled, its current can be controlled, and so on. see STM32 Technical Reference Manuals (any one will do) and libopencm3 for details on what the pad characteristics look like.
based on that single-input single-output flexibly-configureable IO cell a COMPLETELY INDEPDENDENT external (*entirely digital design*) pinmux that HAS NOTHING TO DO WITH IO cells can be dropped on top of it, with no difficulty, and get the job done with no loss of functionality or compromises. see slides 14-17 for details.
Well, it is my part to design the Standard Cell Library for our LibreSilicon technology, as soon as I get the test wafer structures in Silicon. I already designed cells years ago.
Luke, please provide me the cells you would like to get - I'll do what is possible.
BTW, we already talked same years back in Brussels at FOSDEM about your great EOMA86 idea. I really like it :-) Keep going!
So, do you like to provide us (or me?) a list of requirements / features your embedded SoC really needs, which are nice to have and which are to avoid? Please dream, speculate, write down the list for the free and open silicon variant of your modules. And yes, I like to put in this card into my next "Brotkasten"-Style [0] laptop and developing the next generation even on this laptop.
I think, with getting this numbered list, we can great cooperating, even for dedicated IO Cells, RAMs and so on. do not hesitate.
Best Regards, Hagen Sankowski