[Arm-netbook] MIPI DSI instead of RGB/TTL - the only way out of the blind alley

[Luke Kenneth Casson Leighton]

On 12/13/16, dumblob <dumblob at gmail.com> wrote:
> Hi Luke,
>
> sorry for the few months delay - I was stuck with moving, family, job
> applications, etc.
>
> I would like to bring up again the painful topic of a long-sustainable
> graphical interface in the EOMA68 specification (
> http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/ ) as the
> RGB/TTL solution is so utterly bad choice.

 nope.  been over this many many times.

> RGB/TTL is way too slow

 no it's not.  most mid-end SoCs can do up to 2048x2048 @ 30fps, and
can certainly do 1920x1080p60 over RGB/TTL.

 it's nonsense to say that it's too slow.

> and highly limited (alone, but even more in EOMA
> specifications):

 no it's not.  the 3.3mm card height is reserved for 1920x1080p60.

> c) maximum color depth 18 bits (3x6)

 that's because if you look at most mid-end LCDs they only do 18 bpp
anyway.  it also means that the extra 6 pins which were saved could be
dedicated to SPI and two more EINTs, which turned out to be crucial.

 most people's eyes are incapable of telling the difference.  really.

> f) easy (not requiring a chip) conversion to VGA output; conversion chips
> to all (!) other interfaces (which are modern, serial, and ubiquitous) is
> needed (and is more expensive than a serial->RGB/TTL because of very low
> purchaser interest)

 yep.  very easy.  or, for the low-cost products, it's not even needed
at all:  320x240, 480x320, 640x480, 800x480 and 800x600 LCDs are all
RGB/TTL.

 go look it up on panelook.com.

> g) easy implementation in FPGA (few hundreds of LUTs)
>
> Yet EOMA does not even allow adding any better display interface, because
> there are not enough "free" pins for any modern serial interface (MIPI DSI,
> eDP, HDMI, ...). This effectively totally (!) disallows manufacturers of
> EOMA cards to add an SoC <-> MIPI/eDP/HDMI circuity on an EOMA card

 nonsense.  they can always add a MIPI-to-RGB converter or an
eDP-to-RGB converter IC on-board the Card.

> to
> provide at least mainstream (!) resolution output with 24 bit colors for
> internal displays (not talking about 2017, when it will supposedly be 4K at
> 30 fps with 24 bit colors).

 the processors you're referring to are so power-hungry that they
require special cooling and/or fans.  in other words, they're *well*
beyond the thermal design capability of EOMA68 anyway.

 also, the attention to design when dealing with 4k displays is
EXTREME.  not even rockchip's own EVB for the RK3288 is capable of
driving a 4k HDMI display... because there's too much noise, degrading
the signal.

 the data rates you're talking about here are ... well, let's work it
out.  it's 1920*2*1080*2*60*8 = 3981312000.  that's close to FOUR
gigahertz.

 to create boards where the data rates are that high requires extreme
special care and attention to layout.  it's radio frequencies,
basically.

 now, here's the thing: at this early stage of the project, i can cope
with designing boards that are up to a maximum frequency of... 100mhz
for RGB/TTL, and even 1ghz for HDMI 1.4 (1920x1080x60*8), by following
some strict design rules that have taken me a long while to learn...

 ... but 3.7 ghz?  fuck no.  you must be joking.  with the upcoming
RK3288 prototype of course i'm going to try it out, but if it actually
works i'm literally going to end up laughing on the floor, manically
and hysterically at the complete fluke.

 bear in mind that for a standard to be successful its interface
capability must be MANDATORY, if you start FORCING the standard to
support 3.7 ghz data transfer rates, you just raised the bar - the
cost of development to a whooole new level.

 EOMA68 is designed to be *affordably* implementable (by even someone
like me who is self-taught).


> In other words, this only one fact degrades the whole EOMA

 repeat after me: there is NO SUCH THING as an EOMA standard.  there
is only a FAMILY of EOMA standards, of which EOMA68 was chosen as the
first "easily and affordably implementable" one.


> to the category
> of yet another toy (as every other libre general-purpose user computer HW
> failed up until now). By the way I had to publicly confess this during my
> talk at the conference OpenAlt 2016 (https://openalt.cz/2016 , there is a
> full recording).
>
> After reading through all the important emails from Arm-netbook beginning
> in 2010 (yeah, 571509 lines of text),

 ye gods man!

> many of your posts on different web
> servers, and watching nearly all your videos, I did some research on
> display interfaces. Few quick facts based on my findings follow (yes, I
> focus on lower mainstream and mainstream "fat" embedded and mobile segment,
> not on total low-end, because there we have zillion of existing PCBs all
> offering basically the same HW interfaces - some of them even libre).

 yeahyeah.  the 72mhz ECs.  none of them are capable of driving LCDs -
the framebuffer alone overwhelms their capacity both for internal
memory, internal bus rate and external data transfer rate.

 many of the low-cost ECs actually use SPI-based or MCU-based (8080)
LCDs (with something like an HX8357D controller IC) because these have
their own internal framebuffer RAM (on-board)... quite cool,
basically.  it's like a tiny embedded version of the x86 IBM PC with
its AT Bus....

...but i digress.


> From panelook.com (size >= 7.0", px density >= 160 PPI):
>
> * LVDS: 382 panels in MP YEAR 2016 (2015: 53) => ratio (the higher the
> better) 53/382 = 0.138
> * MIPI DSI: 239 panels in MP YEAR 2016 (2015: 50) => ratio 50/239 = 0.209
> * eDP: 233 panels in MP YEAR 2016 (2015: 66) => ratio 66/233 = 0.283
> * RGB/TTL: 15 panels in MP YEAR 2016 (2015: 2) ratio 2/15 = 0.133

 great: you _did_ look it up!  errr... except you didn't divide them
up by resolution.  that throws your enquiries off completely.
basically, RGB/TTL is only common for 320x240 up to 800x600 (which is
the low-cost end).  above 800x600 the parallel data bus skew is too
much... which is why these differential-pair serial buses were created
in the first place.


> (the ratio shows how much is the certain interface on rise)
>
> Video interfaces from data sheets of few tens of more performant (i.e.
> having more computing power) mobile SoCs (no AMDs, no Intels) in 2015 &
> 2016:
>
> * LVDS: nearly nowhere
> * MIPI DSI: everywhere (!)
> * eDP: nearly nowhere (in contrast to big chips like Intel i5/i6/i7, where
> eDP is largely prevalent)
> * RGB/TTL: nearly everywhere (but especially on smaller SoCs)

 yes.  so, as predicted, the decision to go with RGB/TTL makes
sense... and still stands.

 lower-cost SoC manufacturers don't like spending the money on royalty
licenses for MIPI or eDP, plus it makes absolutely no sense to use
MIPI or eDP for 320x240, 480x320 or 640x480 LCDs.

 plus, the cost of a converter IC is a far greater ratio of the BOM at
the lower-cost end than it is at the higher-end... and RGB/TTL is the
de-facto interface of choice at the lower end.

 ... you _did_ read the "interface selection" section in the white paper, right?


> bridges for his SoCs. Based on all that I'm confident, that in the upcoming
> 10 years, the SoC market will use MIPI DSI everywhere as the main standard
> and eDP for the few biggest chips.

 ... which we'll get to.... *with another standard*... with the 3.3mm
card height variant being an interim stand-in to cover the intervening
time... where profits from sales of designs based around the *CURRENT*
standard will help fund the next one.

 ... you didn't think i was going to stop at just the one standard, did you?


> Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
> having a HW way to choose from these?

 NO.

> Yes we can!

 NO.  absolutely not.


> EOMA already counts on several types of PC Cards (originally
> called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker
> (Type II - 5 mm). Let's declare the thicker cards to be high-end and offer
> only MIPI DSI while thinner cards low-end with just RGB/TTL. Problem
> solved!

 massive problem *created* which DESTROYS the standard even before
it's implemented.

 allow me to go through it.

 (updated: i spotted another problem, which is that it would be
impossible to prevent the 3.3mm "low end" cards from being inserted
into 5.0mm "high end" slots... potentially electrically damaging both
Card and Housing.  on this point alone what you're suggesting is a
non-starter.  even if you tried to make them interoperable it would
have to be 3.3mm which was the "high" end and 5.0mm the low end,
because 5.0mm low-end Cards would NOT PHYSICALLY FIT into a 3.3mm
slot.. so now we proceed to explain why *that* idea does not work,
either... ).

 af first glance, it seems like a great idea: add two different video
interfaces on the same pins.  so.

 which pins do you use for which functionality?

 * pin 1: RGB Red 0 *AND* MIPI lane 0 tx-
 * pin 1: RGB Red 1 *AND* MIPI lane 0 tx+

 ....
....

now let's design the housing boards around that.  let's make one which
has RGB/TTL, and the other which has MIPI.

so, we've got hard-wired pins for RGB on say a 7in tablet

and we've got hard-wired pins for MIPI on say a 14in laptop.

great!

ok, so now let's select some SoCs.

right.  first SoC we pick... we find that it has dedicated pins for
MIPI, and dedicated pins for RGB/TTL.  so we are forced to find an
ultra-high-speed multiplexer SoC.  problem "solved".

second SoC we pick... we find that it has shared pins (multiplexed)
for MIPI and RGB/TTL.  they DO NOT MATCH OUR ARBITRARILY CHOSEN
ARRANGEMENT.  now we try to use the same high-speed multiplexer SoC...
only to find that it requires SEPARATE inputs... and... err... now we
have to wire the same pins from the SoC to two sets of pins on the
multiplexer IC... now we have signal-bounce to deal with (dual
path)... and double-impedance-matching.... and it's getting alarmingly
complex.

third SoC we pick... we find that it has shared pins which are
COMPLETELY DIFFERENT FROM THE SECOND SoC.

fourth SoC we pick... has MIPI but does not even have RGB/TTL.

fifth SoC we pick... has RGB/TTL but does not have MIPI.

in ALL of these instances, it's simply flat-out impossible to do the
board layout... why?  because there's simply not enough room to fit
the converter IC onto the board.  have you _seen_ how tiny the EOMA68
PCBs are?  78.1 x 47.3mm with a height limit of 1.9mm on TOP and 1.6mm
on BOTTOM, that's with a 1.2mm PCB.  i don't even want to know how
much 0.8mm PCBs cost.

can you see how this quickly gets into absolute hell on earth, with
costs rapidly escalating?

what converter IC do you pick?  does one even exist?  is it common
enough so that it has alternative competition so that we don't end up
with the entire standard being critically dependent on ONE company's
IC and them going out of business?

can you also see how it would create total confusion for end-users,
thus DESTROYING all and any possibility of being a successful and
simple mass-volume standard?

can you imagine the conversations of the sales people, "oh i'm sorry,
you bought that 7in tablet which only does RGB/TTL?  i'm sorry, you
can't use the more modern MIPI Computer Card, you have to THROW AWAY
that 7in tablet housing".

it's total nonsense... and in direct violation of the purpose of the
standard: to reduce e-waste.

so... NO.  not going to happen.

what *is* going to have to happen however is a new standard's created
[and it will either use MIPI or it will use eDP... or it will have
both on separate pins].  this would be much more suitable for the
incoming mid-end SoCs (intel and amd are going to have to take a back
seat until they sort out their backdoor co-processors and proprietary
hardware drivers].

but, it is necessary first to find a suitable connector.  funnily
enough there's a guy who has located games cartridge connectors... i
forget which one... NES?  Game Boy?  which has 100 pins....

 http://old.pinouts.ru/Game/CartridgeGameBoy_pinout.shtml

 nope, not that one, it's only 32...

 https://wiki.nesdev.com/w/index.php/Cartridge_connector#Pinout_of_72-pin_NES_consoles_and_cartridges

 NES - 72, ah HA!  err... except they're enormous:

 https://en.wikipedia.org/wiki/Nintendo_Entertainment_System_Game_Pak#60-pin_vs._72-pin_cartridges

 13.3 x 12 x 2cm or something mad.

 so, back to the drawing board on that one.


 basically it's not as simple as it sounds.  just add an extra
interface, right?  no problem, right?  wrong.  there's *really* good
reasons why the functions on EOMA68 only have GPIO multiplexing, and
it's because GPIO is the lowest common denominator function that can
reasonably be expected of any arbitrarily-chosen pin.

 we can't even multiplex say SPI and UART onto the same pins, because
there's absolutely no guarantee that any arbitrarily-chosen SoC *has*
SPI and UART multiplexed onto *EXACTLY* the same arbitrarily-chosen
pins [for a standard].  that leaves the burden on *software* to do
bit-banging of either UARt or SPI... and god help you if the SoC
doesn't support EINT capability on the chosen pins (because the others
had to be used for other purposes), and you have to do high-frequency
CPU-intensive polling.

 and the moment you start saying "ohh it's okay to have one function
but not the other on any given card" you've just fucked the entire
standard in the "salesman" scenario above.  nobody would EVER trust
the standard to be "eco-conscious" if you told them that they were
forced to throw out perfectly good Housings.

 i appreciate your thoughts, but there's far more to take into
consideration here than whether a particular interface is
"up-to-date".  at least six completely different inter-related
criteria had to be satisfied, with *none* of them being "open for
negotiation".





> Speaking about thermal dissipation, I'm not sure that in case of the
> high-end card type, this limit should be a fixed one.

 again it comes down to what the boards (chassis manufacturers) can
cope with.  remember, whatever is picked *has* to be covered by *ALL*
chassis manufacturers.

 so if you picked up to 15W, *ALL* chassis manufacturers *MUST*
provide up to a maximum of 15W...

 ... or it is necessary to put in the EOMA68 I2C EEPROM, "this chassis
can provide up to N watts power if needed, and has the thermal
dissipation capability to deal with it".

 it gets complicated, quite quickly, but would be doable.

 hmmm, and the nice thing is, it's an upwards-compatible expansion of
the EOMA68 standard which doesn't interfere with the existing release.

 i like it.

l.