ARM/Atmel buses, architecture - Naimi

I don't understand points 2,3,4. In the Harvard Arch, we separate code 
and data flow. Eg:
LDI R16, 0F

0F is pulled from flash (using the data bus - operand) at the same time 
as the LDI (via the code bus - opcode). The register R16 is GPR so it's 
in the CPU.

What the heck is 2 for:
'a set of address buses for accessing the data' ?
And the others:
a set of address buses to access the opcodes

Why do we have:
In RISC processors, there are four sets of buses


http://storage8.static.itmages.com/i/16/0610/h_1465535771_9345089_c9fbeb90a9.png

RISC processors have separate buses for data and code. In all the x86
processors, like all other CISC computers, there is one set of buses for 
the address (e.g., A0?A24 in the 80286) and another set of buses for 
data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in and 
out of the CPU. 

To access any sec-tion of memory, regardless of whether it contains code 
or data operands, the same address bus and data bus are used. 

In RISC processors, there are four sets ofbuses:
(l) a set of data buses for carrying data (operands) in and out of the 
CPU, (2) a set of address buses for accessing the data, (3) a set of 
buses to carry the opcodes, and(4) a set of address buses to access the 
opcodes. The use ofseparate buses for codeand data operands is commonly 
referred to as Harvard architecture. We examinedthe Harvard architecture 
of the AVR in the previous section.

On 6/10/2016 1:29 AM, Veek. M wrote:
> I don't understand points 2,3,4. In the Harvard Arch, we separate code
> and data flow. Eg:
> LDI R16, 0F
>
> 0F is pulled from flash (using the data bus - operand) at the same time
> as the LDI (via the code bus - opcode). The register R16 is GPR so it's
> in the CPU.
>
> What the heck is 2 for:
> 'a set of address buses for accessing the data' ?
> And the others:
> a set of address buses to access the opcodes
>
> Why do we have:
> In RISC processors, there are four sets of buses
>
>
> http://storage8.static.itmages.com/i/16/0610/h_1465535771_9345089_c9fbeb90a9.png
>
> RISC processors have separate buses for data and code. In all the x86
> processors, like all other CISC computers, there is one set of buses for
> the address (e.g., A0?A24 in the 80286) and another set of buses for
> data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in and
> out of the CPU.
>
> To access any sec-tion of memory, regardless of whether it contains code
> or data operands, the same address bus and data bus are used.
>
> In RISC processors, there are four sets ofbuses:
> (l) a set of data buses for carrying data (operands) in and out of the
> CPU, (2) a set of address buses for accessing the data, (3) a set of
> buses to carry the opcodes, and(4) a set of address buses to access the
> opcodes. The use ofseparate buses for codeand data operands is commonly
> referred to as Harvard architecture. We examinedthe Harvard architecture
> of the AVR in the previous section.

You are confusing internal busses with external busses.  Yes, most CPUs 
have one external memory interface for both data and code, but 
internally they can any number of busses desired since there are many 
registers for data and/or operands in the code.

-- 

Rick C

On 10/06/16 07:29, Veek. M wrote:
> I don't understand points 2,3,4. In the Harvard Arch, we separate code 
> and data flow. Eg:
> LDI R16, 0F
> 
> 0F is pulled from flash (using the data bus - operand) at the same time 
> as the LDI (via the code bus - opcode). The register R16 is GPR so it's 
> in the CPU.
> 
> What the heck is 2 for:
> 'a set of address buses for accessing the data' ?
> And the others:
> a set of address buses to access the opcodes
> 
> Why do we have:
> In RISC processors, there are four sets of buses
> 
> 
> http://storage8.static.itmages.com/i/16/0610/h_1465535771_9345089_c9fbeb90a9.png
> 
> RISC processors have separate buses for data and code. In all the x86
> processors, like all other CISC computers, there is one set of buses for 
> the address (e.g., A0?A24 in the 80286) and another set of buses for 
> data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in and 
> out of the CPU. 
> 
> To access any sec-tion of memory, regardless of whether it contains code 
> or data operands, the same address bus and data bus are used. 
> 
> In RISC processors, there are four sets ofbuses:
> (l) a set of data buses for carrying data (operands) in and out of the 
> CPU, (2) a set of address buses for accessing the data, (3) a set of 
> buses to carry the opcodes, and(4) a set of address buses to access the 
> opcodes. The use ofseparate buses for codeand data operands is commonly 
> referred to as Harvard architecture. We examinedthe Harvard architecture 
> of the AVR in the previous section.
> 

The book is explaining things very badly - it is mixing up logical and
physical buses, internal and external buses, and address spaces.  It is
also making terrible generalisations in its distinctions between RISC
and CISC, and appears to have a view of "Harvard vs. von Neumann" from
the 1970's.

It is much more common to talk of a "data bus" as including the address
lines and the data lines needed for reading and writing data, and an
"instruction bus" as including the address lines and data lines needed
for reading instructions and opcodes.  On some systems, such as the AVR,
these are physically separate and access separate memory blocks.  On
most modern cpus, they are physically separate from the cpu core, and
may be connected to independent L0 caches or buffers, but are later
combined in a multiplexer, crosspoint or bus controller, perhaps along
with a unified cache, before connecting to a single memory space.  And
on smaller or older cpus, the pathways may never be independent - there
is just one bus coming out of the core.

On Fri, 10 Jun 2016 09:13:28 +0200, David Brown wrote:

> On 10/06/16 07:29, Veek. M wrote:
>> I don't understand points 2,3,4. In the Harvard Arch, we separate code
>> and data flow. Eg:
>> LDI R16, 0F
>> 
>> 0F is pulled from flash (using the data bus - operand) at the same time
>> as the LDI (via the code bus - opcode). The register R16 is GPR so it's
>> in the CPU.
>> 
>> What the heck is 2 for:
>> 'a set of address buses for accessing the data' ?
>> And the others:
>> a set of address buses to access the opcodes
>> 
>> Why do we have:
>> In RISC processors, there are four sets of buses
>> 
>> 
>> http://storage8.static.itmages.com/i/16/0610/
h_1465535771_9345089_c9fbeb90a9.png
>> 
>> RISC processors have separate buses for data and code. In all the x86
>> processors, like all other CISC computers, there is one set of buses
>> for the address (e.g., A0?A24 in the 80286) and another set of buses
>> for data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in
>> and out of the CPU.
>> 
>> To access any sec-tion of memory, regardless of whether it contains
>> code or data operands, the same address bus and data bus are used.
>> 
>> In RISC processors, there are four sets ofbuses:
>> (l) a set of data buses for carrying data (operands) in and out of the
>> CPU, (2) a set of address buses for accessing the data, (3) a set of
>> buses to carry the opcodes, and(4) a set of address buses to access the
>> opcodes. The use ofseparate buses for codeand data operands is commonly
>> referred to as Harvard architecture. We examinedthe Harvard
>> architecture of the AVR in the previous section.
>> 
>> 
> The book is explaining things very badly - it is mixing up logical and
> physical buses, internal and external buses, and address spaces.  It is
> also making terrible generalisations in its distinctions between RISC
> and CISC, and appears to have a view of "Harvard vs. von Neumann" from
> the 1970's.
> 
> It is much more common to talk of a "data bus" as including the address
> lines and the data lines needed for reading and writing data, and an
> "instruction bus" as including the address lines and data lines needed
> for reading instructions and opcodes.  On some systems, such as the AVR,
> these are physically separate and access separate memory blocks.  On
> most modern cpus, they are physically separate from the cpu core, and
> may be connected to independent L0 caches or buffers, but are later
> combined in a multiplexer, crosspoint or bus controller, perhaps along
> with a unified cache, before connecting to a single memory space.  And
> on smaller or older cpus, the pathways may never be independent - there
> is just one bus coming out of the core.

To expand (I hope) on what David is saying:

A "pure" (or maybe "old-time") Harvard architecture is one where 
instructions and data are _entirely_ separate -- see, for instance, the 
ADSP-21xx series of processors, where the program memory space is not 
only separate from the data memory space, but it's a different width (24 
bits as opposed to the data memory width of 16 bits).  It is, in fact, 
awkward to read instruction memory, and IIRC you can't access the upper 8 
bits.

Ditto for Von Neumann architecture, e.g. the MC68HC11, which had one 
unified memory space out of which everything came (and no problems 
reading anything at all).

Looking at the data I have for the ARM Cortex, at least the M4 core seems 
to expose multiple busses, one of which is for instructions and another 
of which is for data.  In a processor designed to take advantage of this, 
you could have separate memory spaces that could be accessed 
simultaneously by code and data fetches, speeding things up.  I've seen 
this sort of thing called a "Harvard architecture", but I'm not sure that 
I'm fully convinced that it's really the best nomenclature to use, 
because while it may be a Harvard architecture physically, logically it's 
Von Neumann.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On 6/10/2016 1:22 PM, Tim Wescott wrote:
> On Fri, 10 Jun 2016 09:13:28 +0200, David Brown wrote:
>
>> On 10/06/16 07:29, Veek. M wrote:
>>> I don't understand points 2,3,4. In the Harvard Arch, we separate code
>>> and data flow. Eg:
>>> LDI R16, 0F
>>>
>>> 0F is pulled from flash (using the data bus - operand) at the same time
>>> as the LDI (via the code bus - opcode). The register R16 is GPR so it's
>>> in the CPU.
>>>
>>> What the heck is 2 for:
>>> 'a set of address buses for accessing the data' ?
>>> And the others:
>>> a set of address buses to access the opcodes
>>>
>>> Why do we have:
>>> In RISC processors, there are four sets of buses
>>>
>>>
>>> http://storage8.static.itmages.com/i/16/0610/
> h_1465535771_9345089_c9fbeb90a9.png
>>>
>>> RISC processors have separate buses for data and code. In all the x86
>>> processors, like all other CISC computers, there is one set of buses
>>> for the address (e.g., A0?A24 in the 80286) and another set of buses
>>> for data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in
>>> and out of the CPU.
>>>
>>> To access any sec-tion of memory, regardless of whether it contains
>>> code or data operands, the same address bus and data bus are used.
>>>
>>> In RISC processors, there are four sets ofbuses:
>>> (l) a set of data buses for carrying data (operands) in and out of the
>>> CPU, (2) a set of address buses for accessing the data, (3) a set of
>>> buses to carry the opcodes, and(4) a set of address buses to access the
>>> opcodes. The use ofseparate buses for codeand data operands is commonly
>>> referred to as Harvard architecture. We examinedthe Harvard
>>> architecture of the AVR in the previous section.
>>>
>>>
>> The book is explaining things very badly - it is mixing up logical and
>> physical buses, internal and external buses, and address spaces.  It is
>> also making terrible generalisations in its distinctions between RISC
>> and CISC, and appears to have a view of "Harvard vs. von Neumann" from
>> the 1970's.
>>
>> It is much more common to talk of a "data bus" as including the address
>> lines and the data lines needed for reading and writing data, and an
>> "instruction bus" as including the address lines and data lines needed
>> for reading instructions and opcodes.  On some systems, such as the AVR,
>> these are physically separate and access separate memory blocks.  On
>> most modern cpus, they are physically separate from the cpu core, and
>> may be connected to independent L0 caches or buffers, but are later
>> combined in a multiplexer, crosspoint or bus controller, perhaps along
>> with a unified cache, before connecting to a single memory space.  And
>> on smaller or older cpus, the pathways may never be independent - there
>> is just one bus coming out of the core.
>
> To expand (I hope) on what David is saying:
>
> A "pure" (or maybe "old-time") Harvard architecture is one where
> instructions and data are _entirely_ separate -- see, for instance, the
> ADSP-21xx series of processors, where the program memory space is not
> only separate from the data memory space, but it's a different width (24
> bits as opposed to the data memory width of 16 bits).  It is, in fact,
> awkward to read instruction memory, and IIRC you can't access the upper 8
> bits.
>
> Ditto for Von Neumann architecture, e.g. the MC68HC11, which had one
> unified memory space out of which everything came (and no problems
> reading anything at all).
>
> Looking at the data I have for the ARM Cortex, at least the M4 core seems
> to expose multiple busses, one of which is for instructions and another
> of which is for data.  In a processor designed to take advantage of this,
> you could have separate memory spaces that could be accessed
> simultaneously by code and data fetches, speeding things up.  I've seen
> this sort of thing called a "Harvard architecture", but I'm not sure that
> I'm fully convinced that it's really the best nomenclature to use,
> because while it may be a Harvard architecture physically, logically it's
> Von Neumann.

I haven't seen any references that would refer to this as "Harvard". 
The distinction of a Harvard architecture is at the ISA level.  It 
really doesn't say much about the physical structure of the CPU.  In the 
case of the M4, I expect the two buses are connected to I and D caches 
rather than directly to memory, but I haven't see the diagram.  I don't 
recall for sure that the M4 has I and D caches, but I believe they are 
at least optional.

-- 

Rick C

On Fri, 10 Jun 2016 14:05:15 -0400, rickman wrote:

> On 6/10/2016 1:22 PM, Tim Wescott wrote:
>> On Fri, 10 Jun 2016 09:13:28 +0200, David Brown wrote:
>>
>>> On 10/06/16 07:29, Veek. M wrote:
>>>> I don't understand points 2,3,4. In the Harvard Arch, we separate
>>>> code and data flow. Eg:
>>>> LDI R16, 0F
>>>>
>>>> 0F is pulled from flash (using the data bus - operand) at the same
>>>> time as the LDI (via the code bus - opcode). The register R16 is GPR
>>>> so it's in the CPU.
>>>>
>>>> What the heck is 2 for:
>>>> 'a set of address buses for accessing the data' ?
>>>> And the others:
>>>> a set of address buses to access the opcodes
>>>>
>>>> Why do we have:
>>>> In RISC processors, there are four sets of buses
>>>>
>>>>
>>>> http://storage8.static.itmages.com/i/16/0610/
>> h_1465535771_9345089_c9fbeb90a9.png
>>>>
>>>> RISC processors have separate buses for data and code. In all the x86
>>>> processors, like all other CISC computers, there is one set of buses
>>>> for the address (e.g., A0?A24 in the 80286) and another set of buses
>>>> for data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in
>>>> and out of the CPU.
>>>>
>>>> To access any sec-tion of memory, regardless of whether it contains
>>>> code or data operands, the same address bus and data bus are used.
>>>>
>>>> In RISC processors, there are four sets ofbuses:
>>>> (l) a set of data buses for carrying data (operands) in and out of
>>>> the CPU, (2) a set of address buses for accessing the data, (3) a set
>>>> of buses to carry the opcodes, and(4) a set of address buses to
>>>> access the opcodes. The use ofseparate buses for codeand data
>>>> operands is commonly referred to as Harvard architecture. We
>>>> examinedthe Harvard architecture of the AVR in the previous section.
>>>>
>>>>
>>> The book is explaining things very badly - it is mixing up logical and
>>> physical buses, internal and external buses, and address spaces.  It
>>> is also making terrible generalisations in its distinctions between
>>> RISC and CISC, and appears to have a view of "Harvard vs. von Neumann"
>>> from the 1970's.
>>>
>>> It is much more common to talk of a "data bus" as including the
>>> address lines and the data lines needed for reading and writing data,
>>> and an "instruction bus" as including the address lines and data lines
>>> needed for reading instructions and opcodes.  On some systems, such as
>>> the AVR,
>>> these are physically separate and access separate memory blocks.  On
>>> most modern cpus, they are physically separate from the cpu core, and
>>> may be connected to independent L0 caches or buffers, but are later
>>> combined in a multiplexer, crosspoint or bus controller, perhaps along
>>> with a unified cache, before connecting to a single memory space.  And
>>> on smaller or older cpus, the pathways may never be independent -
>>> there is just one bus coming out of the core.
>>
>> To expand (I hope) on what David is saying:
>>
>> A "pure" (or maybe "old-time") Harvard architecture is one where
>> instructions and data are _entirely_ separate -- see, for instance, the
>> ADSP-21xx series of processors, where the program memory space is not
>> only separate from the data memory space, but it's a different width
>> (24 bits as opposed to the data memory width of 16 bits).  It is, in
>> fact, awkward to read instruction memory, and IIRC you can't access the
>> upper 8 bits.
>>
>> Ditto for Von Neumann architecture, e.g. the MC68HC11, which had one
>> unified memory space out of which everything came (and no problems
>> reading anything at all).
>>
>> Looking at the data I have for the ARM Cortex, at least the M4 core
>> seems to expose multiple busses, one of which is for instructions and
>> another of which is for data.  In a processor designed to take
>> advantage of this,
>> you could have separate memory spaces that could be accessed
>> simultaneously by code and data fetches, speeding things up.  I've seen
>> this sort of thing called a "Harvard architecture", but I'm not sure
>> that I'm fully convinced that it's really the best nomenclature to use,
>> because while it may be a Harvard architecture physically, logically
>> it's Von Neumann.
> 
> I haven't seen any references that would refer to this as "Harvard". The
> distinction of a Harvard architecture is at the ISA level.  It really
> doesn't say much about the physical structure of the CPU.  In the case
> of the M4, I expect the two buses are connected to I and D caches rather
> than directly to memory, but I haven't see the diagram.  I don't recall
> for sure that the M4 has I and D caches, but I believe they are at least
> optional.

I looked at the ARM architecture spec, which didn't say much about it, 
and the ST document, which talks about three different busses.

Yes, I'm sure that they just go to the pertinent caches.  I've seen that 
sort of thing called "Harvard" before: I don't know if either ARM or ST 
is committing that sin.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On 10/06/16 20:05, rickman wrote:
> On 6/10/2016 1:22 PM, Tim Wescott wrote:
>> On Fri, 10 Jun 2016 09:13:28 +0200, David Brown wrote:
>>
>>> On 10/06/16 07:29, Veek. M wrote:
>>>> I don't understand points 2,3,4. In the Harvard Arch, we separate code
>>>> and data flow. Eg:
>>>> LDI R16, 0F
>>>>
>>>> 0F is pulled from flash (using the data bus - operand) at the same time
>>>> as the LDI (via the code bus - opcode). The register R16 is GPR so it's
>>>> in the CPU.
>>>>
>>>> What the heck is 2 for:
>>>> 'a set of address buses for accessing the data' ?
>>>> And the others:
>>>> a set of address buses to access the opcodes
>>>>
>>>> Why do we have:
>>>> In RISC processors, there are four sets of buses
>>>>
>>>>
>>>> http://storage8.static.itmages.com/i/16/0610/
>> h_1465535771_9345089_c9fbeb90a9.png
>>>>
>>>> RISC processors have separate buses for data and code. In all the x86
>>>> processors, like all other CISC computers, there is one set of buses
>>>> for the address (e.g., A0?A24 in the 80286) and another set of buses
>>>> for data (e.g., D0?Dl5 in the 80286) carrying opcodes and operands in
>>>> and out of the CPU.
>>>>
>>>> To access any sec-tion of memory, regardless of whether it contains
>>>> code or data operands, the same address bus and data bus are used.
>>>>
>>>> In RISC processors, there are four sets ofbuses:
>>>> (l) a set of data buses for carrying data (operands) in and out of the
>>>> CPU, (2) a set of address buses for accessing the data, (3) a set of
>>>> buses to carry the opcodes, and(4) a set of address buses to access the
>>>> opcodes. The use ofseparate buses for codeand data operands is commonly
>>>> referred to as Harvard architecture. We examinedthe Harvard
>>>> architecture of the AVR in the previous section.
>>>>
>>>>
>>> The book is explaining things very badly - it is mixing up logical and
>>> physical buses, internal and external buses, and address spaces.  It is
>>> also making terrible generalisations in its distinctions between RISC
>>> and CISC, and appears to have a view of "Harvard vs. von Neumann" from
>>> the 1970's.
>>>
>>> It is much more common to talk of a "data bus" as including the address
>>> lines and the data lines needed for reading and writing data, and an
>>> "instruction bus" as including the address lines and data lines needed
>>> for reading instructions and opcodes.  On some systems, such as the AVR,
>>> these are physically separate and access separate memory blocks.  On
>>> most modern cpus, they are physically separate from the cpu core, and
>>> may be connected to independent L0 caches or buffers, but are later
>>> combined in a multiplexer, crosspoint or bus controller, perhaps along
>>> with a unified cache, before connecting to a single memory space.  And
>>> on smaller or older cpus, the pathways may never be independent - there
>>> is just one bus coming out of the core.
>>
>> To expand (I hope) on what David is saying:
>>
>> A "pure" (or maybe "old-time") Harvard architecture is one where
>> instructions and data are _entirely_ separate -- see, for instance, the
>> ADSP-21xx series of processors, where the program memory space is not
>> only separate from the data memory space, but it's a different width (24
>> bits as opposed to the data memory width of 16 bits).  It is, in fact,
>> awkward to read instruction memory, and IIRC you can't access the upper 8
>> bits.
>>
>> Ditto for Von Neumann architecture, e.g. the MC68HC11, which had one
>> unified memory space out of which everything came (and no problems
>> reading anything at all).
>>
>> Looking at the data I have for the ARM Cortex, at least the M4 core seems
>> to expose multiple busses, one of which is for instructions and another
>> of which is for data.  In a processor designed to take advantage of this,
>> you could have separate memory spaces that could be accessed
>> simultaneously by code and data fetches, speeding things up.  I've seen
>> this sort of thing called a "Harvard architecture", but I'm not sure that
>> I'm fully convinced that it's really the best nomenclature to use,
>> because while it may be a Harvard architecture physically, logically it's
>> Von Neumann.
>

Often it is referred to as a "modified Harvard architecture", which 
makes a bit more sense - though I think any use of the terms "Harvard" 
or "von Neumann" on modern cpus is confusing.

> I haven't seen any references that would refer to this as "Harvard". The
> distinction of a Harvard architecture is at the ISA level.

The problem is that different people use it for different levels - some 
for the ISA level (which is really the important difference, at least 
for users of the processor), and some for the physical buses.

> It really
> doesn't say much about the physical structure of the CPU.  In the case
> of the M4, I expect the two buses are connected to I and D caches rather
> than directly to memory, but I haven't see the diagram.  I don't recall
> for sure that the M4 has I and D caches, but I believe they are at least
> optional.
>

They are indeed optional.  Typically, slower and cheaper M4 devices have 
no cache, while bigger and faster ones have I and D caches (and often 
single-precision hardware floating point support).  For M4 up to about 
80 MHz and only internal ram, caches are not needed - a flash buffer 
with double-width flash banks keeps the instruction bus reasonably close 
to saturation, while internal ram is zero wait state for data.  It is 
only with faster operations and external memory that you really make use 
of caches.

And yes, some people (and even some manufacturers) will tell you that 
such an arrangement is a Harvard architecture, despite the single 
unified address space which is the key characteristic of von Neumann. 
I'd hate to think what these folks would say to a core with more than 
two buses (some ARMs have extra buses to tightly-coupled memories, for 
example).

On Fri, 10 Jun 2016 12:22:10 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>A "pure" (or maybe "old-time") Harvard architecture is one where 
>instructions and data are _entirely_ separate 

The most commonly seen Harvard CPUs are the "modified" variant which
allows code and data to be together in a common memory, but *cached*
separately.  [DSPs obviously have other ideas].

>-- see, for instance, the 
>ADSP-21xx series of processors, where the program memory space is not 
>only separate from the data memory space, but it's a different width (24 
>bits as opposed to the data memory width of 16 bits).  It is, in fact, 
>awkward to read instruction memory, and IIRC you can't access the upper 8 
>bits.

Yes.  I used the ADSP-21k which was similar.  It had 48 bit
instructions and 16/32/40 bit data [16/32 bit integer, 32/40 bit FP].
However, on the 21k, code and data could be together in the same
memory space - just having different alignment requirements.  One of
the DMA channels could do 16/32 <> 48 bit packing/unpacking to
facilitate loading code [e.g., so you could use 16 or 32 bit ROMs].

George

On 6/10/2016 9:07 PM, George Neuner wrote:
> On Fri, 10 Jun 2016 12:22:10 -0500, Tim Wescott
> <seemywebsite@myfooter.really> wrote:
>
>> A "pure" (or maybe "old-time") Harvard architecture is one where
>> instructions and data are _entirely_ separate
>
> The most commonly seen Harvard CPUs are the "modified" variant which
> allows code and data to be together in a common memory, but *cached*
> separately.  [DSPs obviously have other ideas].

I guess my question would be, what is the point of drawing a distinction 
between Harvard, modified Harvard and von Neumann?  Sure there are a few 
advantages to separating code and data cache, but I consider that to be 
an issue of cache design.  I have never even given any thought to which 
of the three basic architectures a given CPU used.

-- 

Rick C

On Fri, 10 Jun 2016 22:35:27 -0400, rickman wrote:

> On 6/10/2016 9:07 PM, George Neuner wrote:
>> On Fri, 10 Jun 2016 12:22:10 -0500, Tim Wescott
>> <seemywebsite@myfooter.really> wrote:
>>
>>> A "pure" (or maybe "old-time") Harvard architecture is one where
>>> instructions and data are _entirely_ separate
>>
>> The most commonly seen Harvard CPUs are the "modified" variant which
>> allows code and data to be together in a common memory, but *cached*
>> separately.  [DSPs obviously have other ideas].
> 
> I guess my question would be, what is the point of drawing a distinction
> between Harvard, modified Harvard and von Neumann?  Sure there are a few
> advantages to separating code and data cache, but I consider that to be
> an issue of cache design.  I have never even given any thought to which
> of the three basic architectures a given CPU used.

In the 90's, "Harvard architecture" was something of a buzzword for "way 
fast" -- this was back when the usual embedded processor had just one 
memory bus and no cache or a vestigial one.  Generally a Harvard 
architecture processor was significantly faster by virtue of having two 
entirely separate memory systems.

To some extent having a pair of independent memory systems for 
instructions and data (which some of the ST ARM chips have) still does 
help speed things along, which is important if you're running the 
processor to the limit.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com