Cpu For Pandora 2 ?

[ari64]

It looks so far from the tests Ari64 and I have done before that the fetch unit is stalled during L1 dcache misses (even though I don't really see why it would have to), so you don't gain a chance to get ahead there. There are still probably enough interlocks (dependencies, load-use, address generation, issue restriction, etc) that let normal code get one ahead with fetching but it could still cost a cycle on highly optimized loops.

I haven't seen any direct evidence that the fetch is stalled during d-cache misses. It's possible though. How did you determine this?

There's a catch to aligning branches. The GHB is indexed by the low bits of the instruction address. If you put all branches at the end of a 64-bit block, then you're only using half of the GHB, and branch misprediction will increase due to collisions. That's what happens in ARM mode anyway, I didn't test thumb.

 

[Exophase]

I haven't seen any direct evidence that the fetch is stalled during d-cache misses. It's possible though. How did you determine this?

Actually I guess it wasn't determined, I just assumed it with the L1 hit vs miss tests earlier and cycle counts.. So I guess to best determine something like this we should try adding a branch (to next PC) and see if it only increases by 1 cycle?

There's a catch to aligning branches. The GHB is indexed by the low bits of the instruction address. If you put all branches at the end of a 64-bit block, then you're only using half of the GHB, and branch misprediction will increase due to collisions. That's what happens in ARM mode anyway, I didn't test thumb.

I guess it would be helpful to know which low order bits are used and how they're combined with the 10-bit history to form the 12-bit address - we do know that it only applies to the bottom four bits of the address and that a XOR is used. You don't necessarily lose half the GHB entries.

I should have clarified though, I only mean for branches that are very likely to be taken like loops. If anything, branches in a tight inner loop that are unlikely to be taken could be purposefully misaligned in order to avoid possible aliasing in predicting the loop branch.

Another note - this doesn't apply to unconditional branches since those don't access the GHB. The BTB will mark a branch as unconditional. We should actually check to see if an unconditional branch has the two cycle latency too, which has a major impact on function calls. This should apply to indirect branches too, including the return stack predicted function returns. Function returns might specifically avoid the stall because they bypass reading the value out of the BTB and instead from the much smaller return stack, although by this point it's probably moot since the BTB hit has already been resolved. It'd also be moot if the stall is due to predecoding the instruction to detect if it's a branch or not. Achievable throughput for indirect branches and returns can have a large impact on where it's suitable to use switches inside tight loops, and function calls over inlining can spare icache pressure for costs that are sometimes hidden by other delays, so this is worth looking into.

By the way, I'm thinking of buying "Unique Chips and Systems", which, as you probably recall, is the currently best known source for these implementation details. The Google books copy (http://books.google.com/books?id=RBmvxQ9BV6wC&printsec=frontcover#v=onepage&q&f=false) is only missing a few pages from the Cortex-A8 implementation section, but it could still be good information. What do you think, should I buy it? It can be had for ~$70.

Oh, and I guess I should stop looking for an official confirmation from ARM addressing the correctly predicted branch latency because this about sums up what you've said:

"The decoupling afforded by the queue allows the I-fetch unit to prefetch ahead of the rest of the integer unit and build up a backlog of instructions that are ready to be decoded. This backlog often hides the latency involved in predicting a change in the instruction stream and starting to fetch instructions from a new location."

Wish I paid more attention to that first time around. Too bad you lose that backlog on a branch mispredict. I wish branch mispredicts were resolved earlier in the pipeline. It's like they shifted the whole branch resolution part ahead just to get them to pair with condition code updates, but it cost them a good 2 cycles if they could otherwise guarantee PC results in E2 (let's say multiplies and saturations and whatever else E3 and E4 are used for aren't allowed to touch PC, I'm pretty sure the ISA says that it isn't supported)

I guess another benefit is that ldr pc is only two cycles instead of what you'd get if pc was resolved earlier due to load-use latency.. assuming it's properly predicted, which is a huge assumption. Still better for threaded switches.

 

[ari64]

Actually I guess it wasn't determined, I just assumed it with the L1 hit vs miss tests earlier and cycle counts.. So I guess to best determine something like this we should try adding a branch (to next PC) and see if it only increases by 1 cycle?

The TRM suggests that the pipeline is restarted on a cache miss, so it's likely that the fetch is stopped... I just hadn't thought about it before.

I guess it would be helpful to know which low order bits are used and how they're combined with the 10-bit history to form the 12-bit address - we do know that it only applies to the bottom four bits of the address and that a XOR is used. You don't necessarily lose half the GHB entries.

I was able to consistently cause branch mispredictions with the following:

 mov r0,#16777216
loop:
 (some not-taken branches)
 teq r0,r0
 beq .+4
 (repeat 10 times)
 nop
 nop
 nop
 nop
 nop
 nop
 tst r0,#255
 beq .+4 <-mispredicts
 ...
 teq r0,r0
 beq .+4
 (repeat 10+ times)
 ...
 subs r0,#1
 bcs loop

The tst r0,#255 will be zero only once in 256 times, so this branch should be predicted not taken, but with a history of ten taken branches, it can alias with one of the taken branches in the GHB and be consistently mispredicted. Conditional branches which are never taken get no entries in the BTB or GHB, so the above only mispredicts if the branches are taken.

There is a 3-cycle latency before the recent branch history is updated, so the nops in the above example are required.

The GHB seems to be indexed by bits 2 & 3 of the instruction address, plus the 10-bit history. It's possible that some more bits are xored, but it didn't look like it to me. You can experiment with the above code and see what you find.

I should have clarified though, I only mean for branches that are very likely to be taken like loops. If anything, branches in a tight inner loop that are unlikely to be taken could be purposefully misaligned in order to avoid possible aliasing in predicting the loop branch.

If you intend a branch to be predicted not taken, you can use add pc,#offset, since the branch predictor ignores instructions with immediate values. This instruction seems to issue in the pipeline the same as any other branch.

Another note - this doesn't apply to unconditional branches since those don't access the GHB. The BTB will mark a branch as unconditional. We should actually check to see if an unconditional branch has the two cycle latency too, which has a major impact on function calls. This should apply to indirect branches too, including the return stack predicted function returns. Function returns might specifically avoid the stall because they bypass reading the value out of the BTB and instead from the much smaller return stack, although by this point it's probably moot since the BTB hit has already been resolved. It'd also be moot if the stall is due to predecoding the instruction to detect if it's a branch or not. Achievable throughput for indirect branches and returns can have a large impact on where it's suitable to use switches inside tight loops, and function calls over inlining can spare icache pressure for costs that are sometimes hidden by other delays, so this is worth looking into.

I'm guessing returns are marked in the BTB too. It's possible that it decodes the instruction, but the check is very specific - it has to be a mov, bx, or pop - so it's probably cached in the BTB. We should test whether these unconditional branches are updating the GHB or not.

By the way, I'm thinking of buying "Unique Chips and Systems", which, as you probably recall, is the currently best known source for these implementation details. The Google books copy (http://books.google.com/books?id=RBmvxQ9BV6wC&printsec=frontcover#v=onepage&q&f=false) is only missing a few pages from the Cortex-A8 implementation section, but it could still be good information. What do you think, should I buy it? It can be had for ~$70.

I noticed the missing pages on Google books. If you get it, let me know if there's anything informative there.

I guess another benefit is that ldr pc is only two cycles instead of what you'd get if pc was resolved earlier due to load-use latency.. assuming it's properly predicted, which is a huge assumption. Still better for threaded switches.

Are you writing an emulator for a dual-processor system? How often do you need to switch between threads?

 

[Exophase]

The TRM suggests that the pipeline is restarted on a cache miss, so it's likely that the fetch is stopped... I just hadn't thought about it before.

Unique chips says that the pipeline is replayed 8 cycles on an L1 dcache miss, not restarted. Fetch and decode shouldn't even know about it, although I don't know how the > 8 cycle part happens. The whole pipeline was designed around 8 cycle L2 cache misses, so I think there's some external reason why we're not getting anywhere close to that; possibly a design decision in OMAP3530's L2 macros, although we don't see anything in the registers to suggest extra latencies there :/

The GHB seems to be indexed by bits 2 & 3 of the instruction address, plus the 10-bit history. It's possible that some more bits are xored, but it didn't look like it to me. You can experiment with the above code and see what you find.

I think I'll pass on that code for now >_< Unique chips says 4 bits of instruction address. It's possible bit 1 is used in Thumb-2, although I doubt it.

If you intend a branch to be predicted not taken, you can use add pc,#offset, since the branch predictor ignores instructions with immediate values. This instruction seems to issue in the pipeline the same as any other branch.

That's an interesting trick, although your range is very limited (at least in ARM mode). It's probably not usually a huge deal to end up adding an entry to the GHB/BTB and branch history register when it finally does hit.

I'm guessing returns are marked in the BTB too. It's possible that it decodes the instruction, but the check is very specific - it has to be a mov, bx, or pop - so it's probably cached in the BTB. We should test whether these unconditional branches are updating the GHB or not.

Yes, they're marked in the BTB as being returns (Unique chips says this); the BTB contains at least a few bits of metadata per entry. But the BTB target value obviously isn't used.

I noticed the missing pages on Google books. If you get it, let me know if there's anything informative there.

I'm thinking about it.. there aren't really that many missing pages for that section, it's kind of a lot of money per page :/

Are you writing an emulator for a dual-processor system? How often do you need to switch between threads?

"Threaded switches", not "thread switches." Meaning that it's a loop executing a switch, but where each case performs the switch dispatch at the end instead of branching back to somewhere central. The indirect branch prediction rate will catch more simple patterns this way (barring BTB collisions), and it's more relevant to consider the cost of the switch dispatch itself.

 

[ari64]

Another note - this doesn't apply to unconditional branches since those don't access the GHB. The BTB will mark a branch as unconditional. We should actually check to see if an unconditional branch has the two cycle latency too, which has a major impact on function calls.

I can confirm that unconditional branches do not get GHB entries. I was unable to create GHB collisions between conditional branches and unconditional branches, as occurs between two conditional branches. So the unconditional branches do seem to be flagged in the BTB. It also seems to correctly predict which of the two instructions is the unconditional branch, so maybe there's two bits of metadata there.

The 2-cycle latency is the same for conditional and unconditional branches.

This should apply to indirect branches too, including the return stack predicted function returns. Function returns might specifically avoid the stall because they bypass reading the value out of the BTB and instead from the much smaller return stack, although by this point it's probably moot since the BTB hit has already been resolved. It'd also be moot if the stall is due to predecoding the instruction to detect if it's a branch or not.

It appears that the instructions are decoded to detect if it's a branch or not, but this information is used only for the ten-entry recent branch history. The three-cycle delay before the branch history is updated presumably reflects the time needed to decode the instructions. The branch prediction, which takes only one cycle, is done without fully decoding the instructions.

 

[Dead1nside]

I don't know about CPU but it strikes me that not having open drivers for the Pandora's SGX is a big hindrance, I know there weren't any other practical options for this but in the future perhaps ARM's Mali (http://www.malideveloper.com/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers.php) is a good choice?

Edit: After a bit more reading, how open the driver is, and whether the 3D parts aren't just a skeleton for a binary, I'm not sure.

 

[Exophase]

How is not having open GPU drivers on the Pandora a big hindrance?

 

[Dead1nside]

How is not having open GPU drivers on the Pandora a big hindrance?

It's not a completely philosophical view point, it's just such things as the driver not playing well with X, and only allowing the framebuffer, until the driver was updated, I believe demonstrates that if it was open then we wouldn't have to wait.

However, the driver being open doesn't mean anyone is necessarily going to work on it. Just how, because our emulators are open, doesn't mean suddenly we're going to get all these features that everyone's requesting: it takes someone with the ability and desire to code it.

Also, in cases where the driver is a bottleneck we are an unable to improve on it.

Not a magic bullet, and that's with my very limited knowledge.

Who does make the graphics drivers, ImgTec or TI?

 

[Exophase]

I understand how being open could, in theory, produce better drivers, but it's a little shortsighted to say it's a hindrance and make this a primary criteria.

As it stands I'm not aware of any quality handheld GPU options that are open, either in detailed specifications or having open source drivers available. Like you suspected, Mali just makes the X11 glue code open, which is probably required anyway. It's still using a binary blob like SGX for the actual interesting OpenGL ES stuff.

Since GPU IP is determined by the SoC manufacturer the options are further limited based on what is otherwise a good GPU. Of course that applies to CPU as well. This whole thread should really be "SoC for Pandora 2."

 

[Dead1nside]

I understand how being open could, in theory, produce better drivers, but it's a little shortsighted to say it's a hindrance and make this a primary criteria.

As it stands I'm not aware of any quality handheld GPU options that are open, either in detailed specifications or having open source drivers available. Like you suspected, Mali just makes the X11 glue code open, which is probably required anyway. It's still using a binary blob like SGX for the actual interesting OpenGL ES stuff.

Since GPU IP is determined by the SoC manufacturer the options are further limited based on what is otherwise a good GPU. Of course that applies to CPU as well. This whole thread should really be "SoC for Pandora 2."

I must admit, I think I jumped the gun by the journalism of the article I read. When I did explore further, I got the misgivings that in fact this was just a bit more open, as you say 'the glue'. What I do worry about is the regularity of the driver updates, and the nature of them. TI seem to, as perhaps they only need to, update their drivers to support new products, not to introduce performance improvements or features. A lot of devices use this SoC, but when everyone moves onto OMAP4 will we stop seeing updates?

It's not the biggest factor, like you say though.

 

[Exophase]

There have been lots of SGX driver updates on OMAP3 and derivatives. A lot of SGX540 driver updates probably directly apply to the other SGX platforms, so I don't think we'll see TI update one and not the other.

My guess is that IMG does a lot of if not the majority of the core driver work, they have way too much in the way of software resources to not be doing a lot of in-house driver development.

 

[Exophase]

http://pandaboard.org/pbirclogs/index.php?date=2010-11-05

Someone here (mru) claims 9 cycle L2 latency on OMAP4, 13 cycles on DM3730 (tested on a Beagleboard-xM). I don't know the test methodology, someone might want to ping him on this. But it at least suggests that OMAP4 has better L2 latency, not worse, which is encouraging, and DM3730 might have improved it over OMAP3530 (also suggests main memory latency is better which is good news too). It'd be nice to see if things like Mupen64plus are significantly faster on the xM, not that it really matters.

 

[ldesnogu]

Someone here (mru) claims 9 cycle L2 latency on OMAP4, 13 cycles on DM3730 (tested on a Beagleboard-xM). I don't know the test methodology

The test methodology is probably broken, as the number for OMAP4 looks too low (see this and keep in mind this is what happens in pl310, so this doesn't take into account A9->PL310 and PL310->A9 added latencies).

Seeing he claims L2 miss on Tegra is 43 cycles, he probably ran some lmbench test without trying to defeat the prefetcher given that I measured L2 miss at ~120 ns for a CPU @ 1Ghz when increasing strides just to make sure no prefetching was going on.

 

[Exophase]

Laurent, do you know what clock speed OMAP4 runs AXI at? I've always wondered, especially since Linley group calls the cache behind AXI a big disadvantage vs Snapdragon. You're probably right though. Do you want to go on IRC and ask him about it?

 

[ldesnogu]

Laurent, do you know what clock speed OMAP4 runs AXI at? I've always wondered, especially since Linley group calls the cache behind AXI a big disadvantage vs Snapdragon. You're probably right though.

I have neither OMAP4 HW or specific information (which I probably couldn't share anyway)
Anyway even if the AXI interface between A9 and PL310 was at full speed (A9 frequency) then 9 cycles isn't doable.

Do you want to go on IRC and ask him about it?

I'll e-mail him, that will be faster

EDIT: Mans kindly made more tests on his OMAP4 board and it seems L2 miss latency is ~160 cycles.