New ARM Cortex Microcontroller Product Family from STMicroelectronics

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

Reply to
Wilco Dijkstra
Loading thread data ...

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.

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

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

Reply to
Wilco Dijkstra

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

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

-jg

Reply to
Jim Granville

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

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 ?

How does this change anything ?

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 ?

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

Reply to
Paul Keinanen

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.

Thanks for the compliment :)

-jg

Reply to
Jim Granville

just

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

formatting link

should take

Luminary

never

You have, see above.

relationship

annual report,

semiconductor

is "owned"

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

it has

licensees of the

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

technologies

addressed in

So there are no competitive concerns then?

will see

representative

(which does

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

Wilco

Reply to
Wilco Dijkstra

memory, and no read code from ram, without

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

Reply to
Wilco Dijkstra

memory, and no read code from ram, without

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.

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

Reply to
Jim Granville

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

Reply to
Jonathan Kirwan

connection).

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

Reply to
Jonathan Kirwan

connection).

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

Reply to
Wilco Dijkstra

memory, and no read code from ram, without

connection).

std 80C51 has no Code-Data opcodes, and

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.

execute code from RAM. The semantics of how

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

Reply to
Wilco Dijkstra

RTL? Or as a user?

Jon

Reply to
Jonathan Kirwan

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

Reply to
Wilco Dijkstra

memory, and no read code from ram, without

connection).

std 80C51 has no Code-Data opcodes, and

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

Reply to
Jim Granville

including

Thanks. That is interesting to me.

Jon

Reply to
Jonathan Kirwan

article.

pinout -

implemented

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

-Bill.

Reply to
Bill Giovino

article.

wasn't for

;)

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

Reply to
Jim Granville

just

ARM -

formatting link

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

relationship

annual report,

semiconductor

is "owned"

in 2005.

investments

around

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.

line, it has

licensees of the

partner

nothing special

but has

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.

technologies

addressed in

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.

will see

representative

(which does

she was

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.

Reply to
Bill Giovino

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.