New ARM Cortex Microcontroller Product Family from STMicroelectronics

On Wed, 20 Jun 2007 23:29:12 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

><snip>
>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

I really think you need to do some hardware design and maybe some CPU
design.  You'd connect up some ideas quickly, then.

On the 8051 that Jim mentioned (and I've a boxes of 80C32s or 80C31s
here and have designed and built systems from them, too), there are
special hardware lines used when accessing memories.  You can, if you
like, wire these up in a kind of OR case going to a single RAM, ROM,
or various combinations in order to make it "appear" that the system
has a single address space.  In the 8051 case, it uses the same
address lines either way, so this is pretty easy.  In the case of the
MIPS R2000, the code and data spaces had separate address buses pinned
out externally and separate data spaces, too.  In the case of the
ADSP-21xx DSP, it is more analgous to the 8051 in that there are
various control lines to signal various 'spaces' (boot memory, code
memory, data memory, etc), but where the address bus is shared and the
data bus is also similarly shared (in odd ways.)

Things go deeper than this, though.  Internally in the ADSP-21xx
(because I've had the discussions with the designers to know), even
through the external pinout shows a single set of address pins and a
single set of data lines, internally (just inside and not deeply into
the CPU) these are actually separate buses which are "wire OR'd" in a
funky way onto the actual pads that are pinned to the package.  Bugs
found when accessing memory via the BDMA (boot memory) may not show up
at all when accessing memory via the IDMA because they go through a
distinct logic block inside and actually also through different pin
drivers.  Internally, the CPU is inherently mult-memory, despite the
fact that externally the memory may be implemented as a single memory
system.  In no way would I call this CPU 'von Neumann', even IF the
external memory was a single, shared memory system that combined the
internal, distinct buses.

Nothing these days is much like the early Harvard.  No vacuum tubes
(valves to the British), for one thing.  But the distinct buses still
exist and for an embedded programmer, Jim's comment is a good one.
"Can you run code from what is normally considered data space by the
instructions?"  The fact that there may be a distinct instruction
designed to be specially decoded so that the execution unit can know
to re-route the internal data bus from a different memory doesn't mean
the CPU isn't Harvard, for example.  It's just that the CPU designer
took the time to add another instruction to the set so as to use a
memory bus for a non-default purpose.

There are many interesting CPU designs, today.  And still many more
different ways a hardware designer may incorporate them into a real
system.  Some of these instances aren't going to fit well into just a
binary definition set of "von Neumann" and "Harvard," which is
probably why we are at logger-heads over this, now.

But to me, as one somewhat familiar with designing simple CPUs (yes,
I've done that) and somewhat familiar with designing full up computers
using micros and external memories (yes, I've done that too), but
speaking now as an embedded programmer (which is what I really
consider myself to be), the useful meaning (as opposed to getting lost
in the details) for Harvard vs von Neumann is about the CPU design. If
the CPU was designed so that program code and data share the same
conceptual memory system (there are no distinctions) then it is von
Neumann.  If there is any inherent difference in treatment between
instruction space and data space, it's Harvard.  Even if you take a
Harvard CPU design and hack its memory system so that it shares one
memory system, the CPU remains Harvard because that is really a CPU
design decision that still has all the earmarks of Harvard even with a
single memory.  This is a CPU thing.  It is, or isn't.  And this is a
fundamental design decision you make conceptually before you actually
do any of the rest of the CPU design.  It's central and shapes all the
rest.

To make this clearer still, I don't separate a Harvard CPU design
where a hardware board designer chooses to implement a single memory
system and attach it to a Harvard processor design and one where the
chip manufacturer does this wiring right at the pin level (like Analog
does for the ADSP-218x, for example) so that there is only one set of
address pins and one set of data pins present for the board designer
to access.  Either way, it's still a Harvard CPU.  It's been
bastardized to use one memory, but it is still a Harvard architecture.
In the ADSP-218x case, for example, there are separate parts of the
ALU (special registers which can only be used with one memory or only
with another) and special instructions set aside __because__ the
memories are conceptually, if not actually, distinct.

The simple ability to access both code and data memory as data does
NOT make it von Neumann.  It may be that you are using special
registers which are tagged for special purposes like that or else
special instructions.  None of that takes away the fact that the CPU
is still, at its core, a Harvard design.

And it makes a difference to know this.  Jim's question is a good one.
Not the only one.  But one of the better ones and one I've to find out
quickly one way or another.

Jon

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:0slj735a4jsknten1nj61tvg8ga92t528u@4ax.com...
> On Wed, 20 Jun 2007 23:29:12 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>><snip>
>>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
>
> I really think you need to do some hardware design and maybe some CPU
> design.  You'd connect up some ideas quickly, then.
>
> On the 8051 that Jim mentioned (and I've a boxes of 80C32s or 80C31s
> here and have designed and built systems from them, too), there are
> special hardware lines used when accessing memories.  You can, if you
> like, wire these up in a kind of OR case going to a single RAM, ROM,
> or various combinations in order to make it "appear" that the system
> has a single address space.  In the 8051 case, it uses the same
> address lines either way, so this is pretty easy.  In the case of the
> MIPS R2000, the code and data spaces had separate address buses pinned
> out externally and separate data spaces, too.  In the case of the
> ADSP-21xx DSP, it is more analgous to the 8051 in that there are
> various control lines to signal various 'spaces' (boot memory, code
> memory, data memory, etc), but where the address bus is shared and the
> data bus is also similarly shared (in odd ways.)
>
> Things go deeper than this, though.  Internally in the ADSP-21xx
> (because I've had the discussions with the designers to know), even
> through the external pinout shows a single set of address pins and a
> single set of data lines, internally (just inside and not deeply into
> the CPU) these are actually separate buses which are "wire OR'd" in a
> funky way onto the actual pads that are pinned to the package.  Bugs
> found when accessing memory via the BDMA (boot memory) may not show up
> at all when accessing memory via the IDMA because they go through a
> distinct logic block inside and actually also through different pin
> drivers.  Internally, the CPU is inherently mult-memory, despite the
> fact that externally the memory may be implemented as a single memory
> system.  In no way would I call this CPU 'von Neumann', even IF the
> external memory was a single, shared memory system that combined the
> internal, distinct buses.
>
> Nothing these days is much like the early Harvard.  No vacuum tubes
> (valves to the British), for one thing.  But the distinct buses still
> exist and for an embedded programmer, Jim's comment is a good one.
> "Can you run code from what is normally considered data space by the
> instructions?"  The fact that there may be a distinct instruction
> designed to be specially decoded so that the execution unit can know
> to re-route the internal data bus from a different memory doesn't mean
> the CPU isn't Harvard, for example.  It's just that the CPU designer
> took the time to add another instruction to the set so as to use a
> memory bus for a non-default purpose.
>
> There are many interesting CPU designs, today.  And still many more
> different ways a hardware designer may incorporate them into a real
> system.  Some of these instances aren't going to fit well into just a
> binary definition set of "von Neumann" and "Harvard," which is
> probably why we are at logger-heads over this, now.
>
> But to me, as one somewhat familiar with designing simple CPUs (yes,
> I've done that) and somewhat familiar with designing full up computers
> using micros and external memories (yes, I've done that too), but
> speaking now as an embedded programmer (which is what I really
> consider myself to be), the useful meaning (as opposed to getting lost
> in the details) for Harvard vs von Neumann is about the CPU design. If
> the CPU was designed so that program code and data share the same
> conceptual memory system (there are no distinctions) then it is von
> Neumann.  If there is any inherent difference in treatment between
> instruction space and data space, it's Harvard.  Even if you take a
> Harvard CPU design and hack its memory system so that it shares one
> memory system, the CPU remains Harvard because that is really a CPU
> design decision that still has all the earmarks of Harvard even with a
> single memory.  This is a CPU thing.  It is, or isn't.  And this is a
> fundamental design decision you make conceptually before you actually
> do any of the rest of the CPU design.  It's central and shapes all the
> rest.
>
> To make this clearer still, I don't separate a Harvard CPU design
> where a hardware board designer chooses to implement a single memory
> system and attach it to a Harvard processor design and one where the
> chip manufacturer does this wiring right at the pin level (like Analog
> does for the ADSP-218x, for example) so that there is only one set of
> address pins and one set of data pins present for the board designer
> to access.  Either way, it's still a Harvard CPU.  It's been
> bastardized to use one memory, but it is still a Harvard architecture.
> In the ADSP-218x case, for example, there are separate parts of the
> ALU (special registers which can only be used with one memory or only
> with another) and special instructions set aside __because__ the
> memories are conceptually, if not actually, distinct.
>
> The simple ability to access both code and data memory as data does
> NOT make it von Neumann.  It may be that you are using special
> registers which are tagged for special purposes like that or else
> special instructions.  None of that takes away the fact that the CPU
> is still, at its core, a Harvard design.
>
> And it makes a difference to know this.  Jim's question is a good one.
> Not the only one.  But one of the better ones and one I've to find out
> quickly one way or another.

So I guess we're mostly in agreement then. You may not like it, but the fact is
that most people use the term any CPU that have separate memories that can
be accessed in parallel. If you look at my list of variations, then you can see that
is indeed the common characteristic (and what Wikipedia defines). This definition
and variants are widely used. It doesn't matter whether you agree with them or not.
The problem is when people read "XXX is a Harvard" and suddenly start making
incorrect assumptions based on their own narrow definition...

FYI I've worked on various CPU architectures and micro architectures, including
ARM9, ARM10, ARM11, Cortex-M3, Cortex-A8, ARMv5, v6, v7 and Thumb-2.

Wilco

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679cb90$1@clear.net.nz...
> 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.

There are various ways of implementing such a bus, including reusing the
fetch bus if you only need read-only access. That doesn't make it any less of
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).
>
> 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.

As I said before that is a good indicator to differentiate between the pure Harvard
and the modified version. Separate address spaces imply you can execute code
only from the code memory.

Wilco 

On Thu, 21 Jun 2007 08:01:48 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

><snip>
>FYI I've worked on various CPU architectures and micro architectures, including
>ARM9, ARM10, ARM11, Cortex-M3, Cortex-A8, ARMv5, v6, v7 and Thumb-2.

RTL?  Or as a user?

Jon

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:bnck73llt7rq2uktl9o5vif0liv4665f6i@4ax.com...
> On Thu, 21 Jun 2007 08:01:48 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>><snip>
>>FYI I've worked on various CPU architectures and micro architectures, including
>>ARM9, ARM10, ARM11, Cortex-M3, Cortex-A8, ARMv5, v6, v7 and Thumb-2.
>
> RTL?  Or as a user?

As an architect, above RTL. You can do a patent search if you like, the early
ones have been granted. I've got a mixture of software, micro architecture and
architectural patents.

Wilco 

Wilco Dijkstra wrote:

> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4679cb90$1@clear.net.nz...
> 
>>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.
> 
> 
> There are various ways of implementing such a bus, including reusing the
> fetch bus if you only need read-only access. That doesn't make it any less of
> a connection.

You've lost me. You have claimed a "conection between code and data 
memories", and unless you somehow claim the accumulator is DATA memory, 
there is no such link. The 80C51 does not have a MOVC Data,@A+PC opcode
it only has the single MOVC A,@A+PC opcode. Code -> ACC. From there,
you have to use other opcodes to move ACC to various Data memory 
choices. There are many more Acc-> Data Space opcodes.

-jg

On Thu, 21 Jun 2007 08:42:08 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>
>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:bnck73llt7rq2uktl9o5vif0liv4665f6i@4ax.com...
>> On Thu, 21 Jun 2007 08:01:48 GMT, "Wilco Dijkstra"
>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>>><snip>
>>>FYI I've worked on various CPU architectures and micro architectures, including
>>>ARM9, ARM10, ARM11, Cortex-M3, Cortex-A8, ARMv5, v6, v7 and Thumb-2.
>>
>> RTL?  Or as a user?
>
>As an architect, above RTL. You can do a patent search if you like, the early
>ones have been granted. I've got a mixture of software, micro architecture and
>architectural patents.

Thanks.  That is interesting to me.

Jon

"Jim Granville" wrote...
> Bill Giovino wrote:
>
> > http://www.microcontroller.com/news/arm_cortex_stm.asp
> >
> > I've received a clarification from ST, and it is reflected in the above article.
> >
> > The USB and the CAN may *not* be enabled together. It is not an issue of the
pinout -
> > the issue is that both share the same packet buffer, and therfore cannot be
implemented
> > at the same time.
>
> ** bangs head on desk **
>
> They had better get that GEM onto the front page of the data sheet, and
> call it USB _OR_ CAN !!
>
> ** wanders off, shaking head at school-boy error **
>
> -jg

Hey, Jim, look at it this way - this never would have been made public if it wasn't for
you!

-Bill.

Bill Giovino wrote:

> "Jim Granville" wrote...
> 
>>Bill Giovino wrote:
>>
>>
>>>http://www.microcontroller.com/news/arm_cortex_stm.asp
>>>
>>>I've received a clarification from ST, and it is reflected in the above article.
>>>
>>>The USB and the CAN may *not* be enabled together. It is not an issue of the
> 
> pinout -
> 
>>>the issue is that both share the same packet buffer, and therfore cannot be
> 
> implemented
> 
>>>at the same time.
>>
>>** bangs head on desk **
>>
>>They had better get that GEM onto the front page of the data sheet, and
>>call it USB _OR_ CAN !!
>>
>>** wanders off, shaking head at school-boy error **
>>
>>-jg
> 
> 
> Hey, Jim, look at it this way - this never would have been made public if it wasn't for
> you!

;)

One clarify : How credible is your ST contact ? - as I cannot see "share 
the same packet buffer" anywhere in the user manual, or drawings, and 
nothing suggests that conflict.
Search cannot find 'USB' inside the CAN chapter, nor 'CAN' inside the 
USB chapter ?
It also does not make chip-design sense, surely it is harder to 
lock/overlap some block resource like that, in this cut/paste world ?

That said, it is a strange thing to 'make up'/ admit to if untrue, so 
perhaps it is coming via the errata pipeline ?

-jg

"Wilco Dijkstra" wrote...
>
> "Bill Giovino" wrote...
> > "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

That might have been valid over a year ago - with the Company's additional funding, it
may not be so. I've modified the passage you referenced to reflect the current status.
:
> > 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 �274k investment in 2005.
> The 2006 report mentions an additional investment. The total value of all such
investments
> was �1920k, spread between Palmchip, Pixim, Coware and Luminary, so probably around
> �500k for LM. Compare that with LM announcing a $14M second round of funding...

You are talking funding statistics, which is fine, but it does not completely reflect
the back story. Unlike you, I'm trying to avoid making this a much bigger issue.

>
> > 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).

You are asking for details which would require me to name names, which would jepordize
my sources. If that is indeed your intention, I can't oblige you. Your followup is
surely to bait me, but I wont bite.


>
> 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?

There are MAJOR competitive concerns here.

As a startup, it appears that Luminary may have received more than the customary amount
of help than any other semiconductor company has gotten. With such a vested interest in
seeing the success of the Cortex at Luminary, it raises the question of whether or not
Luminary received preferential treatment (which it appears they did).

The real issue here is the IP business model, which has a glass ceiling. Any IP company
(such as ARM) can only grow so much by *only* selling just IP. Everyone in the industry
knows that the real money is in making and selling semiconductors. But ARM is a smart
company, and they know that blantantly engaging in a semiconductor spin-off can be seen
as competing with their own licensees - at the very least, it can be used for FUD (which
is a useful way of competing in front of inexperienced customers). However, investing in
spin-offs can be a non-threatening way of breaking through that glass ceiling.

At the end of the day, the customer wins in this situation - the real churning is within
the semiconductor community.

If you want to know more, take a day off and read up on the business models of
semiconductor companies, and pure-play IP companies. You'll find that just figuring out
how to keep your fab at maximum profitability is less like economics and more like
juggling. Winning in a market segment can often be based upon very slim factors - as
slim as one less layer on your wafer process, or saving a fraction of a second at final
sort, or a slightly tighter layout - or a better licensing agreement (which I have
successfully negitiated for my clients).

The semiconductor business model is much more complex than most customers realize.

I've been told, and it's probably true, that I report the news not from the viewpoint of
a customer, but more from the viewpoint of a semiconductor company.


> > 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?

Of course I do! But if you are asking me to make private correspondance public, then as
a member of the SPJ, and as a Primary Source, I must politely write "No".

Wilco, your behavior is what we commonly call "baiting the journalist", which is to draw
me out, to get me to provide details that would hint at my sources. We both know I'm
protected by the Massachusetts Shield Law, and I'm too experienced a journalist to bite.

-Bill.