An other CPU discussion. Rockchip RK3399 sounds good


Another important factor is the number of available interfaces - here is some minimum:
* 3xSDIO (plus something internal for eMMC)
* 2xUART
* 4xI2C
* 1xMIPI
* 1xHDMI
* 3xUSB2 (the OMAP5 boards has an on-board 3-port hub for that purpose)
* 1xUSB3-OTG
* 1xSATA or USB3 (then 2xUSB2 is sufficient)
* Audio: 2x Handsfree speaker, Microphone, Line/Headset in/out, 1x vibramotor
* ~30-40 GPIOs
I'm not quite sure I agree with you on this list... But to me a "minimum" I consider essential to turning on and operating the device - not necessarily with all the bells and whistles.

For example:
HDMI isn't a minimum - sure it's nice to be able to connect an external display, but as a handheld with it's own display, you can survive without it.
Same with SD cards/eMMC; a minimum to me would be one form of storage. Sure, the device will physically support more slots, but as long as some form of storage is available, it'll work.
 
0.4mm is already entering tin foil thinnesses (it's about double the standard gauge apparently). You could use thinner things and back them with plastics and things, but the crosssection of the transmissive surface is proportional to the rate of heat transfer I assume, so anything that isn't doing that is a bad thing. As far as I recall, copper is generally a better conductor of heat, but it's also a lot more costly than aluminium. Actually, if cost weren't a concern you could probably use pure gold.

Gold actually performs worse than Copper.
The best you're going to get from commonly available materials is silver.
If money is truly no object, use diamond.

https://en.wikipedia.org/wiki/List_of_thermal_conductivities
 
I'm not sure how many buyers you'd get for a specific CPU card if half of their ports suddenly stopped working. I'd guess quite a few of those could be multiplexed out of the available lines if there's enough space for the circuitry though, just as the OMAP5 board includes a 3 port usb-2 hub. Say it only has line level out and microphone in, line level can be easily adapted to speaker impedences and levels I think, and I'd have thought microphone and headset in are basically the same, although you might need something clever to cut the internal microphone when you plug in a headset.

I also didn't realise the OMAP5 had a dedicated rumble motor output; I assumed that was just driven by PWM from one of the GPIOs.

And I'd like at least 2 sdios, as I can see uses for the internal microSD card and there'll always be a use for an external SD card in this house.
 
I'm not sure how many buyers you'd get for a specific CPU card if half of their ports suddenly stopped working.
They wouldn't "suddenly stop", you'd be aware of that picking the cpu board.

Considering the Pyra is a pretty expensive device, I thought if you considered cheaper, if not fully compatible CPUs, you might be able to produce a cheaper version that has some redundant ports that makes some sales. Then you also have the follow up, that if they like the device and decide that they now want those ports, they can upgrade the CPU board fairly cheap. I'll be honest, I don't know what sort of price difference you could get from a CPU board.

Alternatively, you might find a faster, more-core, and/or better supported (ie open source drivers etc.) CPU, but it only has 1xSDIO line. If you don't need access to all three SD card slots, the trade-off for the better CPU might be worth the investment.

IMO, both would be reasons to still consider the CPU, even if they don't provide access to all the Pyra features. They are trade-offs... but clearly you'd have to weigh up the pros vs cons
 
Another important factor is the number of available interfaces - here is some minimum:
* 3xSDIO (plus something internal for eMMC)
* 2xUART
* 4xI2C
* 1xMIPI
* 1xHDMI
* 3xUSB2 (the OMAP5 boards has an on-board 3-port hub for that purpose)
* 1xUSB3-OTG
* 1xSATA or USB3 (then 2xUSB2 is sufficient)
* Audio: 2x Handsfree speaker, Microphone, Line/Headset in/out, 1x vibramotor
* ~30-40 GPIOs

OK - I'm curious about the 3xUSB2. I know where two of them are... There is a microUSB port, but I thought that was strictly for charging..? Is that a full/active microUSB 2.0 host port too?
 
I'm curious about the 3xUSB2. I know where two of them are...
I think the third one is the cell modem.
Arguably not everyone will be getting a mobile version, of course, but I think hns was talking about minimum for a feature complete comparison against the existing board, so it would need it to be "at least as good"
 
Is 21mm X 21mm flip chip BGA too big physically if it might simplify a good chunk of peripheral work?
https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html

Example:
4 native channels of SDR104
2 native MMC channels
(Is the duplex control system for the eMMC Vs microSDXC on the existing Pyra design living on the SoC daughterboard or the peripheral board? If on the SoC board, this could potentially eliminate it.)

Automotive SoC - long shelf/service life expectation. Insane number of connections.

Linux listed 1st on product sheet for OS compatibility - not an afterthought.

Heat could be an issue if ran full-flat-out on all 10 cores. Cost could be prohibitive.
 
Yes, judging by that big empty space next to the CPU on these boards, and the radiator mounting holes across it, I guess this is designed to be used with a radiator and fan combo. The question is of course, how fast can you run it with the Pyra's cooling solution and for how long, but it seems like it might run hot to me.
 
Is 21mm X 21mm flip chip BGA too big physically if it might simplify a good chunk of peripheral work?
https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html

Example:
4 native channels of SDR104
2 native MMC channels
(Is the duplex control system for the eMMC Vs microSDXC on the existing Pyra design living on the SoC daughterboard or the peripheral board? If on the SoC board, this could potentially eliminate it.)

Automotive SoC - long shelf/service life expectation. Insane number of connections.

Linux listed 1st on product sheet for OS compatibility - not an afterthought.

Heat could be an issue if ran full-flat-out on all 10 cores. Cost could be prohibitive.

I would not want to go with A57.
At the time we'll get it ready it will be as outdated as the OMAP is now.
 
That's a good point. The automotive ones are probably designed to use fans and such.
 
The automotive ones are probably designed to use fans and such.
Nope, quite the contrary. Active cooling is something you include for LED head light modules, not ECUs.

They are about to move back to unified mega-ECUs, though - >10 cores running several different OSes in parallel within a single device do require some kind of active cooling at some point.
 
Nope, quite the contrary. Active cooling is something you include for LED head light modules, not ECUs.

They are about to move back to unified mega-ECUs, though - >10 cores running several different OSes in parallel within a single device do require some kind of active cooling at some point.

Well these automotive devices likely can use a fairly large passive cooling solution. These SoCs are likely more geared for the stereo head unit vs just the ECU.
 
We should not use any AUTOMOTIVE SoCs, as they will eat your battery and heat your home.
We need the MOBILE versions of the SoCs.

Shouldn't this be more a question of efficiency?
I.e. if the automotive SoC is designed to run flat out 100% on 10 cores continuously with a giant heat sink & fan in an automotive application, it could still hypothetically be more thermally efficient with only 2 cores running and underclocked to fit the Pyra thermal envelope than option B if option B is made on a larger process and requires more external components.

It isn't just a matter of what a chip has as a rated maximum power draw, but what chip is most efficient when restricted to the device's maximum power draw. Efficiency is more complex than the raw ratings.

That said, I have no idea what would be able to be enabled/not and how far it would have to clock down to get the power draw/dissipation within the Pyra's envelope. BUT - this automotive SoC will likely have long availability and has a readily available dev kit.

Any dev kit should/could be able to be 'tuned' via core count & underclocking to match the Pyra's thermals (to be determined) so that the package thermals fit inside the envelope - then benchmarked to see if that SoC performs better/worse than other options when limited to the device constraints.

The above argument is not specific to any one SoC, but a concept proposal for SoC selection where we don't simply look at raw 'flat out 100%' numbers for heat OR performance. Rather, what performance can be wrung from any given SoC at the power levels allowed by the rest of the package (Pyra)?

Yes - race to 0 and all of that too. It's complicated. As a general rule though, maybe define the needed capabilities (peripherals, # of cores) then find the SoC meeting those capabilities while running on the smallest lithography process (28nm, 14nm, 10nm, etc.) then underclock to fit the thermal envelope.

OMAP 5432 is 28nm
RCAR H3 is 16nm

Of particular interest to this crowd is graphics.

OMAP 5432 uses SGX544 MP2 rated at 6.2 Gflops
https://en.wikipedia.org/wiki/PowerVR

RCAR H3 uses GX6650 rated at 230.4 Gflops
https://en.wikipedia.org/wiki/PowerVR

I have no idea how much of that graphics processing horsepower would be available with the main CPU throttled way back to maximize the GPU's proportion of the thermal envelope. I'm using this SoC as an example. There are likely better ones out there. Mostly phrasing the questions to find answers to in the selection process.

Efficiency is tied more or less directly to the proportion of directly on-chip supported peripherals, unit price, and the lithography used in the die. Beyond that, isn't just a matter of underclocking to fit the thermals?
 
I don't really know, but I suspect graphics would be the main problem. You can certainly scale down CPUs and turn cores off and they behave pretty linearly (at least in terms of performace, power draw tends to be more complicated), but I'm not sure that's quite true for GPUs. Can you tell them to shut down a certain number of shaders and instead spend more cycles to do the same work with fewer shaders?
 
I don't really know, but I suspect graphics would be the main problem. You can certainly scale down CPUs and turn cores off and they behave pretty linearly (at least in terms of performace, power draw tends to be more complicated), but I'm not sure that's quite true for GPUs. Can you tell them to shut down a certain number of shaders and instead spend more cycles to do the same work with fewer shaders?

Very possible. But - in the above conversations we spend a lot of time talking about the CPU's portion of the SoC's power draw. In the case of a Pyra, though, where does the balance of needs/consumption lie between CPU and Graphics portions? Have CPUs gotten fast enough to be less relevant than the graphics side of the equation?
 
Back
Top