New ARM Cortex Microcontroller Product Family from STMicroelectronics

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:jd6j739pqa6arpc8j2gcq97v9lb9lqp4a7@4ax.com...
> On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>><snip>
>>The initial Harvard's did indeed have no connection between memories
>>because programs were entered by hand. But no such computers are
>>in existence anymore as such a design doesn't make any sense at all.
>><snip>
>
> Sure it does.  The PIC remains, for such an example of what I was
> saying.  The old meaning of the term still has a lot of life left to
> it.

Are you saying PIC has no connection between the memories like the early
Harvards? If so, how does it execute the TABLRD/TABLWT instructions?

Wilco 

> It now says:
>
> "The disadvantage of a Harvard Architecture microcontroller is that 
> because
> instruction and data memory do not share the same PHYSICAL bus, there
> can be a reduced level of flexibility in the hardware for some 
> applications."
>
> That's incorrect. All Harvards have a connection between the instruction 
> and
> data memories. On micro controllers this is a direct physical connection 
> as
> you need a way to read constant data from flash. On cached cores both
> I&D caches connect to the same main memory bus.

Not neccessarily.
A true Harvard architecture you load data using immediate
instructions, and have no way to access the instruction bus.
A "modified" harvard architecture will allow you to read
(and maybe write) to the instruction bus.

> Finally, where did you get the idea that Luminary is owned by ARM?
> ARM's investment in Luminary is only minimal - ask them or read ARM's
> annual reports. It would be better if you sticked to the facts rather than 
> just
> make up exciting stories...

There sure seems to be tight relations and the official version
may or may not be true.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Jonathan Kirwan wrote:
> On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
> 
> 
>><snip>
>>The initial Harvard's did indeed have no connection between memories
>>because programs were entered by hand. But no such computers are
>>in existence anymore as such a design doesn't make any sense at all.
>><snip>
> 
> 
> Sure it does.  The PIC remains, for such an example of what I was
> saying.  The old meaning of the term still has a lot of life left to
> it.

So does the 80C51.. Lots of life in that one too...

(but Wilco likes to roll his own definitions..)

-jg

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679a411$1@clear.net.nz...
> Jonathan Kirwan wrote:
>> On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>>
>>><snip>
>>>The initial Harvard's did indeed have no connection between memories
>>>because programs were entered by hand. But no such computers are
>>>in existence anymore as such a design doesn't make any sense at all.
>>><snip>
>>
>>
>> Sure it does.  The PIC remains, for such an example of what I was
>> saying.  The old meaning of the term still has a lot of life left to
>> it.
>
> So does the 80C51.. Lots of life in that one too...
>
> (but Wilco likes to roll his own definitions..)

I guess I must have imagined the MOVC (Move Code Memory) instruction...

It's great to see you know what you're talking about - as usual.

Wilco

On Wed, 20 Jun 2007 08:43:06 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>
>"Bill Giovino" <contact1@microcontroller.com> wrote in message news:wPqdnfD32sqW1uXbnZ2dnUVZ_vWtnZ2d@comcast.com...
>>
>> "Simone" wrote...
>>> On 19 Giu, 11:40, Jim Granville wrote:
>>> > Bill Giovino wrote:
>>> > > http://www.microcontroller.com/news/arm_cortex_stm.asp
>
>It now says:
>
>"The disadvantage of a Harvard Architecture microcontroller is that because
>instruction and data memory do not share the same PHYSICAL bus, there
>can be a reduced level of flexibility in the hardware for some applications."
>
>That's incorrect. All Harvards have a connection between the instruction and
>data memories. 

Not necessary, unless you use some kind of immediate addressing mode
to load a constant value following the opcode into the data space.

>On micro controllers this is a direct physical connection as
>you need a way to read constant data from flash. 

In a Hardware architecture, there is no requirement that the flash
should reside only in the code space, you could have flash memories
also in the data space, possibly with a different word length than in
the instruction space.

Only if you have flash memory only in instruction space, it might make
sense to have some instructions to copy the initial constant values
from instruction space to data space at startup, but do you really
need instruction page data access after that ?

>On cached cores both
>I&D caches connect to the same main memory bus.

How does this change anything ?

>
>So I'm not sure what you mean with reduced hardware flexibility? The only
>drawback some Harvards have is not automatically supporting self modifying
>code, 

Self modifying code was an issue in the 1950's when the computers did
not have a decent index register, but after that, how many people did
actually use it ?
 
>but that is a software issue and only applies to cached cores.

The last time I have seen a reference to self modifying code was in
the 1970's, when the VAX processor handbook stated that you should
perform a return from subroutine instruction, until the (self)modified
code was actually executed.

The Harvard architecture is nice, if the code and instruction length
is different or if the code and instruction size is about the same,
e.g. 64 KiB for instruction and 64 Kib for data with a 16 bit word
length.

Paul

Wilco Dijkstra wrote:
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679a411$1@clear.net.nz...
> 
>>Jonathan Kirwan wrote:
>>
>>>On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
>>><Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>>
>>>
>>>
>>>><snip>
>>>>The initial Harvard's did indeed have no connection between memories
>>>>because programs were entered by hand. But no such computers are
>>>>in existence anymore as such a design doesn't make any sense at all.
>>>><snip>
>>>
>>>
>>>Sure it does.  The PIC remains, for such an example of what I was
>>>saying.  The old meaning of the term still has a lot of life left to
>>>it.
>>
>>So does the 80C51.. Lots of life in that one too...
>>
>>(but Wilco likes to roll his own definitions..)
> 
> 
> I guess I must have imagined the MOVC (Move Code Memory) instruction...

Yes, MOVC is only for table lookup - In 80C51 there is no write to code 
memory, and no read code from ram, without special HW bridge steps.
Some devices add this, and FLASH Pgm is a special case, tho here often
one fix/trade-off is to stall the CPU during FLASH pgm. Saves needing
banked flash, at some small real time cost.

> It's great to see you know what you're talking about - as usual.

Thanks for the compliment :)

-jg

"Bill Giovino" <contact1@microcontroller.com> wrote in message news:zJqdnemp7tz4yuTbnZ2dnUVZ_hadnZ2d@comcast.com...
> "Wilco Dijkstra" wrote...
> :
>> Finally, where did you get the idea that Luminary is owned by ARM?
>> ARM's investment in Luminary is only minimal - ask them or read ARM's
>> annual reports. It would be better if you sticked to the facts rather than just
>> make up exciting stories...
>
> I have never written that Luminary was "owned" by ARM.

Never? Does "It now appears that Luminary Micro has a majority ownership by ARM -
whicn means that ARM Technologies is now competing with their own licensees!"
sound familiar? See http://www.microcontroller.com/news/luminary_micro_lawsuit.asp

> Ownership and seed funding are two dramatically different statements and you should take
> care with what you claim I have written. I have never written or implied that Luminary
> was "owned" by ARM. Luminary is most definitely NOT owned by ARM, and I have never
> implied that.

You have, see above.

> Luminary is a startup company whose management appears to have a very close relationship
> with ARM and received seed funding from ARM. Yes, I have read Luminary's annual report,
> as well as their articles of incorporation, as I do with most startup semiconductor
> companies as part of my job. But I never wrote or even implied that Luminary is "owned"
> by ARM.

Again, see above. If you had read ARM's reports you'd find a &#4294967295;274k investment in 2005.
The 2006 report mentions an additional investment. The total value of all such investments
was &#4294967295;1920k, spread between Palmchip, Pixim, Coware and Luminary, so probably around
&#4294967295;500k for LM. Compare that with LM announcing a $14M second round of funding...

> Because ARM was an initial investor in Luminary and their Cortex product line, it has
> already raised serious competitive concerns in the minds of potential licensees of the
> Cortex (you need to understand the business model to fully appreciate this).

Please explain what LM has that other licensees don't get. LM was a lead partner
for the Cortex-M3, so they did get early access to the core, but that is nothing special
in the ARM world. Being a lead partner gives you a time to market advantage but has
also significant risks and costs (early silicon is buggy for example).

ST and TI
> can compete easily with Luminary because they have amongst the best process technologies
> available in the Microcontroller industry, and this issue was specifically addressed in
> my briefing with ST.

So there are no competitive concerns then?

> If you will read the linked article on the Luminary/Microchip lawsuit, you will see
> more. From my own experiences, I have had early dealings with a Luminary representative
> named Rebecca Rostetter, who's behavior pattern was much less than ethical (which does
> not imply that her unethical behavior reflects that of all of Luminary).

That's a serious accusation you're making, do you have any hard facts to prove she was
unethical?

Wilco 

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679acae$1@clear.net.nz...
> Wilco Dijkstra wrote:
>> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679a411$1@clear.net.nz...
>>
>>>Jonathan Kirwan wrote:
>>>
>>>>On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
>>>><Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>>>
>>>>
>>>>
>>>>><snip>
>>>>>The initial Harvard's did indeed have no connection between memories
>>>>>because programs were entered by hand. But no such computers are
>>>>>in existence anymore as such a design doesn't make any sense at all.
>>>>><snip>
>>>>
>>>>
>>>>Sure it does.  The PIC remains, for such an example of what I was
>>>>saying.  The old meaning of the term still has a lot of life left to
>>>>it.
>>>
>>>So does the 80C51.. Lots of life in that one too...
>>>
>>>(but Wilco likes to roll his own definitions..)
>>
>>
>> I guess I must have imagined the MOVC (Move Code Memory) instruction...
>
> Yes, MOVC is only for table lookup - In 80C51 there is no write to code memory, and no read code from ram, without 
> special HW bridge steps.

So you agree table lookup can read code memory. That means there is a
connection (at least an uni-directional bus) between code and data memories,
so it is not at all like the initial Harvards (which did not have such a connection).

The bottom line is there are 3 Harvard variants:

* initial Harvard: separate memories, separate address spaces, NO connection
* pure Harvard: separate memories, separate address spaces, connected
* modified Harvard: separate memories, unified address space, connected

Jon mentioned MARK as an example of the first, the second includes PIC and
8051, the last includes just about everything else (most DSPs, RISCs, CISCs).

Wilco

Wilco Dijkstra wrote:
>>
>>Yes, MOVC is only for table lookup - In 80C51 there is no write to code memory, and no read code from ram, without 
>>special HW bridge steps.
> 
> 
> So you agree table lookup can read code memory. That means there is a
> connection (at least an uni-directional bus) between code and data memories,
> so it is not at all like the initial Harvards (which did not have such a connection).

Not quite, all it means is a connection between code and the 
accumulator. The std 80C51 has no Code-Data opcodes, and only one 
Code-ACC opcode.

> The bottom line is there are 3 Harvard variants:
> 
> * initial Harvard: separate memories, separate address spaces, NO connection
> * pure Harvard: separate memories, separate address spaces, connected
> * modified Harvard: separate memories, unified address space, connected
> 
> Jon mentioned MARK as an example of the first, the second includes PIC and
> 8051, the last includes just about everything else (most DSPs, RISCs, CISCs).

It's a moot point, as a better practical indicator (to me) is if a uC 
can execute code from RAM. The semantics of how many variants one can 
imagine do not matter much.

Wiki says this
"Harvard architecture is a computer architecture with physically 
separate storage and signal pathways for instructions and data"

-jg

On Wed, 20 Jun 2007 21:44:41 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>
>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:jd6j739pqa6arpc8j2gcq97v9lb9lqp4a7@4ax.com...
>> On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>>><snip>
>>>The initial Harvard's did indeed have no connection between memories
>>>because programs were entered by hand. But no such computers are
>>>in existence anymore as such a design doesn't make any sense at all.
>>><snip>
>>
>> Sure it does.  The PIC remains, for such an example of what I was
>> saying.  The old meaning of the term still has a lot of life left to
>> it.
>
>Are you saying PIC has no connection between the memories like the early
>Harvards? If so, how does it execute the TABLRD/TABLWT instructions?

I don't see your question.  What do you mean by "PIC has no
connection?"  And it's quite obvious that using special instructions
can easily indicate to the decoder how to route data onto the internal
buses (there are more buses than just the memory paths, as I'm sure
you are aware.)

Jon