• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 5177 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data Flow diagram in Sloss book, ARM Development

Sean de grae
Note: This was originally posted on 20th October 2009 at http://forums.arm.com

Hi to all on the ARM forum,

I'm new to ARM and have some questions:

The DATA FLOW diagram in the Sloss book, Arm Development, has several connections/buses which do not exist in the ARM documentation ( as far as I can see ).

They are :(1) connection direct from the MAC to the ALU bus
(2) a bus from the Register File direct to the MAC labeled Acc ( Accumulator bus )

ARM documents indicate that the MAC connects ONLY between the A and B buses

Can someone explain where I am  misinterpreting , or missing the point somewhere ?

Any help will be very much appreciated, thanks
Skippy
Parents
  • Arm Employee Badge
    Note: This was originally posted on 20th October 2009 at http://forums.arm.com

    The DATA FLOW diagram in the Sloss book, Arm Development, has several connections/buses which do not exist in the ARM documentation ( as far as I can see ).


    Well.... it will depend what you call "the documentation" - there are quite a few different ARM processors in the field with very different internal designs. I'd guess that most diagrams in the TRMs are illustrative of the key microarchitectural features, but are likely to be simplifications - ARMv6 and ARMv7 cores such are ARM1176 and Cortex-A8 are substantially more complex than an ARM9 processor and so are likely to have a very different internal structure than the one outlined in the Sloss book.. 

    Can someone explain where I am  misinterpreting , or missing the point somewhere ?


    I think this is one of those areas where the TRM may not be showing all of the detail for sake of clarity - there are normally some forwarding paths between various parts of the pipeline to remove interlocks. However, MAC integration is one area which has evolved over the years to give better performance. If you look at the cycle times for the processor you are using it might be possible to work out precisely what forwarding paths exist. (My general principle is that all of this detail is internal to the core, so users of the processor don't need to worry about it - the cycle timings typically give all of the detail you need to write software).

    Iso
Reply
  • Arm Employee Badge
    Note: This was originally posted on 20th October 2009 at http://forums.arm.com

    The DATA FLOW diagram in the Sloss book, Arm Development, has several connections/buses which do not exist in the ARM documentation ( as far as I can see ).


    Well.... it will depend what you call "the documentation" - there are quite a few different ARM processors in the field with very different internal designs. I'd guess that most diagrams in the TRMs are illustrative of the key microarchitectural features, but are likely to be simplifications - ARMv6 and ARMv7 cores such are ARM1176 and Cortex-A8 are substantially more complex than an ARM9 processor and so are likely to have a very different internal structure than the one outlined in the Sloss book.. 

    Can someone explain where I am  misinterpreting , or missing the point somewhere ?


    I think this is one of those areas where the TRM may not be showing all of the detail for sake of clarity - there are normally some forwarding paths between various parts of the pipeline to remove interlocks. However, MAC integration is one area which has evolved over the years to give better performance. If you look at the cycle times for the processor you are using it might be possible to work out precisely what forwarding paths exist. (My general principle is that all of this detail is internal to the core, so users of the processor don't need to worry about it - the cycle timings typically give all of the detail you need to write software).

    Iso
Children
No data