Yes it does. While all Cortex M controllers will share the same core, and some of the core peripherals, all other peripherals are vendor specific.
Even using CMSIS won't help you much in that scenario as it will only cover things provided by ARM, which is the core and the core peripherals (NVIC, Systick...)
So in the end if you switch from one vendor to another, you will have to read the data sheet, the reference (or user) manual and figure out how stuff works. You don't necessarily have to learn every register names as vendors now provide peripheral libraries which put an abstract layer on top of the hardware.
But it's not hard or challenging, it's what you gotta do - I'd say it's even one of the more fun parts figuring out how those peripherals work.
And after you realized this, you might want to write a Hardware Abstraction Layer to prevent your firmware being completely unusable for another controller. If you have a stable HAL, you can at least get the device drivers and application layers over to your next controller and only have to implement the HAL again.
Even though the vendors offer peripheral libraries, which function as a HAL, there is no standard across vendors. So at the lowest level you will have to adapt your software, which is why I said, that you yourself might want to write a HAL (in which you can use the HAL of the vendor).
If you want to implement a stable HAL, your features will most likely be limited to the very basic functionality of the common peripherals, so every controller can be abstracted. Typically you will loose some more advanced features of the peripherals, because they are not available everywhere (say a baudrate detection mechanism or automatic dead time between PWM channels). That will be the price to pay. If we need those mechanisms for our application, we write a specialized hardware driver for that purpose, so the rest can still work with the common HAL.
Using this approach I ported an application to two other microcontrollers just implementing the HAL, the rest could be compiled without a single change in the software.
The arm has something called macrocels, the most used are,
Information Macrocel,
Trace macrocell,
Embedded trace Macrocell,
Bus macrocell and so on.
The main use of these is that it provides an insight of what is actually happening inside the processor. These macrocells are hardware inside the processor which collect information about the what was being processed and sends this information to the PC via the Jtag usually. And on the PC you have a software development kit whihc shows you the results that were obtained from these. Thus giving us an insight on whats happening inside therby helping us for example debug the code, view the interrupts that occured etc.,
Best Answer
You're using those terms wrong. "Computer organization" is a rarely-used term for the microarchitecture, and "computer architecture" is a superset of that.
Integrated circuit IP blocks come in two basic forms:
A soft macro is the RTL (VHDL or Verilog) that describes the functional implementation of the IP. This is compiled into a gate-level netlist, which is then turned into a physical layout to produce the mask set for manufacturing. Here's an example from Cadence -- an Ethernet MAC. When you buy it, you get Verilog files, documentation, and a Verilog testbench for verification.
A hard macro is a physical layout of the IP suitable for a given process. It's added to the larger chip layout as a single block, which saves some steps in the design process. Here's another Cadence example -- an Ethernet PHY. It's offered in 180nm and 130nm processes at TSMC, UMC, and SMIC, and is delivered to the customer in the form of GDSII layout files.
ARM sells both of these. The MCUs I've worked on usually use soft macros of ARM Cortex CPUs. We had some older product with ARM7 hard macros, but I don't know if they were hardened by ARM or us. Today, ARM has hard macro versions of the Cortex-A series listed on their web site. Most of their products are synthesizable (soft macros), though. It looks like you can download the (soft) Cortex-M0 for free for non-commercial use on the ARM DesignStart site.
In an SoC, the ARM part is just the CPU. (The designer can also buy peripheral IP from ARM, but it's not required.) The SoCs I've worked on have a mix of third-party and internal IP.