Snapdragon SoC 410E and 600E

[pyrat]

I'm confused. Is the Snapdragon 410 and 410E the same SOC ? The 410E brochure says "Develop using the DragonBoard 410c Community Board".
But the dragonboard 410c page at arrow says it has a Snapdragon 410.
According to this processor comparison at EOMA68, The dragonboard 410c needs a lot of signed blobs to boot.

Update 17 Jul 2016: We’ve kindly been contacted by someone who has investigated the Qualcomm 410c as they were seeking a processor that did not have arbitrary untrusted code execution as part of the boot sequence. On close inspection of the installation guide for the 410c they learned of a whopping 25 MB of arbitrary untrusted boot-sequence-level binaries which are RSA-signed and thus cannot be replaced even if people had the source code and associated compilers.

It also says the "Qualcomm Snapdragon 410C" (yet another SOC?) requires NDA and a proprietary driver for video acceleration (but freedreno for 3D is great, yes).
The NDA does not seem to match the cnx-software article ("no questions asked") so who knows, and I don't remember now what's the video acceleration support for the Pyra.

Also, the 600E has SATA, but the 410E doesn't.

I think none has LTE, but Qualcomm SOCs with modem are allegedly insecure in design, with the modem proprietary firmware controlling mic, gps, RAM, etc.
The LTE Pyra seems more securely designed, afaics. I mean it is not only cheaper to have a separate modem, it may also be more secure. That depends,
I guess in how free the firmware is, but it doesn't look like it is free enough (and testing modifications is kind of illegal without certification, then?). Even if it
was 100% free, bugs are always possible, and separation of concerns seems like a good idea anyway...

Well, I haven't used qualcomm or researched it well, just pointing to flags people have raised in case someone wants to investigate.

 

[Exophase]

Hmm, the 600e has four Krait with 1,5GHz... I wonder how fast these are?

Performance is pretty varied, it does okay on some stuff but badly on other stuff (compared to say, Cortex-A15). NEON performance is generally not very good.

 

[oskda]

Not so exciting:

Snapdragon 410E has 64 bit cores (ARM v8-A ISA) but has less DMIPS/core than actual Pyra Cortex-A15: 2760 DMIPS/core for Snapdragon 410E vs 5950 MIPS/Core for Pyra. With all cores, if you could use them properly, they will be like same theorical MIPS: like 11,000 DMIPS.

I like Snapdragon 410E being 64 bits (ARM v8-A), because we could run 64 bit OS and soft, but in some aspects it is a downgrade: when you use only one core (most soft isn't designed to use multi-core CPU) you have halve the DMIPS than Cortex-A15.

And this SOC only offers USB 2.0.

With Snapdragon 600E we could be near to Cortex-A15 MIPS with only one core, and near double when using all 4 cores (vs 2 in actual Pyra). But this Snapdragon 600E Krait cores are 32 bits (ARM v7 ISA) and even it needs secure boot.

We end with a lot of BLOBs and more code we don't know about.

PD: Here you can see some MIPS data of different ARM chips: https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures

Waiting for open RISC-V dream to came real and evolve some future time. I don't know if ot would be possible, if others will let it to be, but dreaming is free.

Correction: DMIPS (Dhrystone MIPS) instead of MIPS.

 

[fusion_power]

Well, even if these SoC's are not (much) faster than the one in the Pyra, they could need less power or maybe even stay cooler under equal load. Which would be a good reason to upgrade an older SoC in the future, especialy within a small handheld device that is critical hanging on battery and can have more or less serious heat issues combined with more or less CPU throtteling.

Or to make it short: efficiency>speed imho. Are there any TDP's known for these new chipsets?

 

[Exophase]

Not so exciting:

Snapdragon 410E has 64 bit cores (ARM v8-A ISA) but has less MIPS/core than actual Pyra Cortex-A15: 2760 MIPS/core for Snapdragon 410E vs 5950 MIPS/Core for Pyra. With all cores, if you could use them properly, they will be like same theorical MIPS: like 11,000 MIPS.

I like Snapdragon 410E being 64 bits (ARM v8-A), because we could run 64 bit OS and soft, but in some aspects it is a downgrade: when you use only one core (most soft isn't designed to use multi-core CPU) you have halve the MIPS than Cortex-A15.

And this SOC only offers USB 2.0.

With Snapdragon 600E we could be near to Cortex-A15 MIPS with only one core, and near double when using all 4 cores (vs 2 in actual Pyra). But this Snapdragon 600E Krait cores are 32 bits (ARM v7 ISA) and even it needs secure boot.

We end with a lot of BLOBs and more code we don't know about.

PD: Here you can see some MIPS data of different ARM chips: https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures

Waiting for open RISC-V dream to came real and evolve some future time. I don't know if ot would be possible, if others will let it to be, but dreaming is free.

Caveat: those MIPS numbers actually mean "Dhrystone MIPS" which is the result of a really old and mostly meaningless benchmark that has a ton of problems. Even though it continues to be used for marketing today I wouldn't put too much stock in it.

Real performance is going to vary quite a lot from program to program. My very, very, very rough observations are, at the same clock speeds:

Cortex-A7 is about the same as Cortex-A8, but significantly weaker for NEON heavy code
Cortex-A9 is 25% better than Cortex-A8, a little weaker for NEON heavy code
Cortex-A53 is a little weaker than Cortex-A9
Cortex-A15 is about 50% better than Cortex-A9
Cortex-A57 is maybe 20% faster than Cortex-A15
Cortex-A72 is maybe 15% faster than Cortex-A57
Krait 300 is somewhere from around Cortex-A9 to halfway to Cortex-A15 depending on the application
Mongoose is around Cortex-A72, a little better sometimes
Kyro is a little lower than Cortex-A72, except in NEON floating point where it's better

The latter couple are mostly just based on Geekbench so take with particular salt. Oh and anything currently in Apple's SoCs wipes the floor with these cores in single threaded performance (and especially perf/MHz) but that's not really here nor there.

Also, going from 32-bit to 64-bit might make a significant improvement, or might result in something a bit slower... For a lot of emulators with recompilers it could make a big difference because of the extra registers and flags-less cmp+branch instructions, and well if you're emulating something 64-bit...

If there were the option for a Cortex-A53 that could run one core at 2+GHz using significantly less power than the Cortex-A15 @ 1.5GHz in Pyra, could sustain two cores at that clock, and had 4+ cores total, I would say that it's worth considering as a replacement. But Snapdragon 410E only clock sat1.2GHz, and Qualcomm is not known for having a very power efficient A53 implementation.

 

[Linux-SWAT]

What's a flag-less cmp+branch instruction ?

 

[oskda]

Caveat: those MIPS numbers actually mean "Dhrystone MIPS" which is the result of a really old and mostly meaningless benchmark that has a ton of problems. Even though it continues to be used for marketing today I wouldn't put too much stock in it.

I have correct my message, with DMIPS that I wrote incorrectly as MIPS.

Real performance is going to vary quite a lot from program to program. My very, very, very rough observations are, at the same clock speeds:

Cortex-A7 is about the same as Cortex-A8, but significantly weaker for NEON heavy code
Cortex-A9 is 25% better than Cortex-A8, a little weaker for NEON heavy code
Cortex-A53 is a little weaker than Cortex-A9
Cortex-A15 is about 50% better than Cortex-A9
Cortex-A57 is maybe 20% faster than Cortex-A15
Cortex-A72 is maybe 15% faster than Cortex-A57
Krait 300 is somewhere from around Cortex-A9 to halfway to Cortex-A15 depending on the application
Mongoose is around Cortex-A72, a little better sometimes
Kyro is a little lower than Cortex-A72, except in NEON floating point where it's better

The latter couple are mostly just based on Geekbench so take with particular salt. Oh and anything currently in Apple's SoCs wipes...

Thank you very much for that info.

I know about incredible Apple SOC. Apple bought very good CPU companies (for example PA Semi) and she must have a lot of very good people working there. Recently I read they are preparing Mac OS to run on ARM (obviously its own Apple ARM). Even if only Apple can get those SOCs, it is pleasant for me as it push other manufactures.

But Snapdragon 410E only clock sat1.2GHz, and Qualcomm is not known for having a very power efficient A53 implementation.

What do you mean with Qualcomm A53 implementation?

Cortex-A53 is designed by ARM, so I suppose the differences with other Cortex-A53 are in memory inetrface, cache...

 

[TrashyMG]

Cortex-A53 is designed by ARM, so I suppose the differences with other Cortex-A53 are in memory inetrface, cache...

It could even be how it's Fabricated, ARM provides a design, but manufacturing techniques vary a bit from company to company.

 

[Exophase]

What do you mean with Qualcomm A53 implementation?

Cortex-A53 is designed by ARM, so I suppose the differences with other Cortex-A53 are in memory inetrface, cache...

ARM supplies their CPUs in one of two forms: a "hard macro" that is designed directly for some manufacturing process and can be dropped directly into an SoC for it, and an RTL description that needs to be laid out/synthesized. Smaller companies will tend to choose the latter because they don't have the money/resources to do the "hardening" themselves, but this doesn't apply to large companies like Qualcomm. Suffice it to say, while they performed this work themselves, they didn't do a good job and the efficiency of their Cortex-A53 (and Cortex-A57) has shown poor results compared to some competitors. Or at least this is true for their 20nm big.LITTLE parts; it may not be true for the 28nm Snapdragon 410E but I don't have high hopes.

 

[oskda]

What's a flag-less cmp+branch instruction ?

In machine code usually, when you want to do a conditional branch, usually the conditional jump instruction is executed depending on flag status, which are set by effect of a previous instruction.

For example (in no particular architecture) you have 2 instructions on most computer architectures to do a conditional jump:

1/ CMP r1,r2 ; "CoMPares" register r1 and r2 (CPU subtracts r2 from r1), and the result in this operation changes a few processor flags (for example carry flag, zero flag, plus flag, ...).
2/ BEQ address; "Branch if EQual (to zero)" instruction jumps to address if zero flag is set (if r1=r2, then subtract r2-r1=0, and zero flag was set).

Previous example is common (with different instructions) to a lot of architectures:

1/ An instruction that modifies CPU flags (it may be a compare instruction, an increment instruction, a logical instruction, anyone that produces a change in flags).
2/ An instruction executing code depending on flag contents.


On modern 64 bit ARM, you have one instruction that compares and takes branch if condition is meet. For example:

CBZ x1, address ; "Conditional Branch if Zero" branches to address if x1 is zero.

This one instruction, in 32 bit ARM equivalent, would require 2 instruction: one to determine if register is zero (sets zero flag according) and other to take jump depending on previous flag setting.

PD: There are other changes that make 64 bit ARM faster to execute over previous 32 bit ARM. Of course, 64 bit ARM also support a 32 bit mode where it can run old 32 bit soft.
[doublepost=1475628703,1475627687][/doublepost]

ARM supplies their CPUs in one of two forms: a "hard macro" that is designed directly for some manufacturing process and can be dropped directly into an SoC for it, and an RTL description that needs to be laid out/synthesized. Smaller companies will tend to choose the latter because they don't have the money/resources to do the "hardening" themselves, but this doesn't apply to large companies like Qualcomm. Suffice it to say, while they performed this work themselves, they didn't do a good job and the efficiency of their Cortex-A53 (and Cortex-A57) has shown poor results compared to some competitors. Or at least this is true for their 20nm big.LITTLE parts; it may not be true for the 28nm Snapdragon 410E but I don't have high hopes.

I was knowing about companies designing its own implementation of ARM ISA, as have made Qualcomm with Krait and Kyro, for example, or Apple with its own SOCs, but I was thinking Cortex-Ax is an implementation, done by ARM, of the ARM ISA, so they were equal in that core (they may differ with caches, memory interfaces, etc). I knew they can have of course different manufacturing process and different results in energy consumption, heat and speed.

 

[Exophase]

This one instruction, in 32 bit ARM equivalent, would require 2 instruction: one to determine if register is zero (sets zero flag according) and other to take jump depending on previous flag setting.

To expand on this, the reason why I see this as valuable for some recompilers is less because it can save an instruction sometimes and more because it preserves the current flags. This is useful if you're storing emulated flags or some other emulated state in native flags.

 

[oskda]

To expand on this, the reason why I see this as valuable for some recompilers is less because it can save an instruction sometimes and more because it preserves the current flags. This is useful if you're storing emulated flags or some other emulated state in native flags.

Of course, flags preservation is other improvement over old way.

In 64 bit ARM there are a lot of improvements over previous 32 bit ARM, apart of 64 bit registers and 64 bit operations, to get better performance. So I would like to have a 64 bit ARM CPU even if it has less GHz. Obviously, to take those improvements we need 64 bit SO/soft, because if we run in 32 bit mode all time, we don't get them.

 

[levi]

I kind of miss the universal conditionals that Aarch32 had, which helped with code density, but I guess they weren't actually that great for pipeline utilisation - you hit a conditional add, say, decide that you don't need to execute that command, and later pipeline stages end up with a hole in them. Branches used to be pretty bad for performance though, as they meant a pipeline stall, and you ended up having to wait another pipeline length ticks to execute the first command after the branch. Does Aarch64 give us some form of branch prediction to go along with those compare and branch instructions to reduce the likelihood of a pipeline stall?

 

[Exophase]

I kind of miss the universal conditionals that Aarch32 had, which helped with code density, but I guess they weren't actually that great for pipeline utilisation - you hit a conditional add, say, decide that you don't need to execute that command, and later pipeline stages end up with a hole in them. Branches used to be pretty bad for performance though, as they meant a pipeline stall, and you ended up having to wait another pipeline length ticks to execute the first command after the branch. Does Aarch64 give us some form of branch prediction to go along with those compare and branch instructions to reduce the likelihood of a pipeline stall?

It's up to the particular CPU whether or not instructions have branch prediction applied, but there's no good reason why cmp+branch instructions wouldn't work with branch prediction.

 

[levi]

Do the reference designs have any form of branch prediction, do you know?

 

[Letalis Sonus]

Do the reference designs have any form of branch prediction, do you know?

Branch prediction is an ancient concept, not just in the theoretical sense - the question is not whether they implement it, you should better be asking how extensive and efficient it is. Even the embedded Cortex-M series have branch prediction. Basic branch prediction is a very trivial thing with close to zero costs, it's the complex algorithms that make it more efficient that matter.

 

[levi]

As I recall, ARM processors up to ARM8 didn't have any form of branch prediction, to save transistors, so I guess those early engineers disagree with you saying it has close to zero cost. But I guess you could classify a scheme that always predicts you're not going to branch as a type of branch prediction which takes absolutely no transistors to implement, if you were to be awkward.

 

[Letalis Sonus]

ARM processors up to ARM8

You do realize that was 20 years ago?

 

[levi]

Very true, but that was the last chips I coded raw assembler on, so am more familiar with this kind of stuff than later chips where there's almost always been a compiler between me and the chip.

 

[oskda]

I kind of miss the universal conditionals that Aarch32 had, which helped with code density, but I guess they weren't actually that great for pipeline utiliation - you hit a conditional add, say, decide that you don't need to execute that command, and later pipeline stages end up with a hole in them. Branches used to be pretty bad for performance though, as they meant a pipeline stall, and you ended up having to wait another pipeline length ticks to execute the first command after the branch. Does Aarch64 give us some form of branch prediction to go along with those compare and branch instructions to reduce the likelihood of a pipeline stall?

I suppose original ARM conditional execution coded inside each instruction (near all instructions) was a good idea in those original times, where execute was in order, and there were less registers/instructions (when you enter 64 bits you need more addressing modes to manage more bits in registers/operations and different combinations). Even I think conditional execution coded inside instructions was very elegant, but today it is negative for various reasons.

1/ Including conditional execution in near all instructions consumes memory. In each Arch32 instruction (most of them) you have that conditional code weighting for 4 bits. If you count half byte for each instruction, you end up with a lot of memory making no sense, because most instructions doesn't need conditional execution (most of then use "execute always" conditional code).

Even in Arch64 you have more registers (and instructions), like double: 31 registers vs 16 registers. You need 1 bit more for identifying each register in an instruction code, or 2 or 3 bits more, if that instruction operates with 2 or 3 registers. So it makes more sense to save those bits for more registers than for conditional code wich in most intsructions isn't used.

2/ The implementacion cost in advanced designs. I supose Out-of-Order execution is more exepensive to implement with conditional codes inside (not impossible, in fact COrtex-A9 had OoO exec, but more expensive/complicated; it consumes more transistors and that means more energy, more space).

Here you have a good answer (the 1st one with 17 points): http://stackoverflow.com/questions/...ructions-not-present-in-later-arm-instruction

Very true, but that was the last chips I coded raw assembler on, so am more familiar with this kind of stuff than later chips where there's almost always been a compiler between me and the chip.

I have hobby coded ASM in a lot of diferent CPU architectures, and I think ARM v8-A is really cool, better than ARM v7 in all aspects (and even ARM v7 was really nice).

And I think you can jump from ARM v7/Arch32 to ARM v8-A/Arch64 very easily. Of course, for most people, not using assembler, there is no change in programming.

I hope next CPU for Pyra will be 64 bits.