I was wondering what is the reason behind branding a MCU as 32 bit or 64 bit. In the simplistic architecture like Harvard or Neumann architecture it used to be width of data bus. But in the market I have seen MCUs which have 64 bit data lines and yet marketed as 32 bit MCUs. Can somebody explain?
It is not true that the bit width of a processor was defined by the data bus width. Intel 8088 (used in the original IBM PC) was a 16bit device with an 8 bit data bus, and Motorola 68008 (Sinclair QL) was a 32bit device with an 8 bit bus.
It is primarily defined by the nature of the instruction set (width of operands) and the register width (necessarily the same).
When most devices had matching bus and instruction/register widths (i.e. prior to about 1980), there was no need for a distinction and that it was unclear whether it refered to bus or register/insttruction width was of little consequence, when narrow bus width bus versions of wide instruction/register devices were introduced it represented a marketing dilemma. The QL was widely advertised as having a 32 bit processor despite its 8 bit bus, while the 8088 was sometimes referred to as an 8/16 bit part. The 68008 could trivially perform 32bit operations in a single instruction - the fact that it took 4 bus cycles to get the operand was transparent to software, and the total number of instruction and data fetch cycles was still far fewer than it would take an 8 bit processor to perform the same 32 bit operation.
Another interesting architecture in this context is ARM architecture v4 that supports a 16 bit mode known as "Thumb" in addition to the 32bit ARM mode, In Thumb mode both the instruction and register set is 16 bit. This has higher code density than ARM mode. Where an external memory interface is used, most ARM v4 parts support both a 16 or 32 bit external bus - either ARM or Thumb may be used with either, but when a 16 bit bus is implemented, Thumb mode generally runs more efficiently than the 32 bit instruction set due to the single bus cycle per instruction or operand fetch.
Given the increasing variety of architectures instruction/register sets and bus widths, it makes sense now to characterise an architecture by its instruction/register set.
Related
I am having a project that design a RISC V processor on DE10 kit and I've already created Verilog files for processor.
Because the processor has 32 bits data bus but the available external SDRAM has only 16 bits data, so how to connect them together?
DE10 Standard is a Cyclone V SoC, and SDRAM is controlled by the ARM HPS, you don't need to talk to it directly. The easiest way is to talk via Avalon bus (can be up to 128bit wide). You'll need to enable a port with a U-Boot script, see an example here
HPS clock frequency is higher than what you can get in your logic, so a 128bit bus is still an efficient way to talk to a DDR.
Now, you'll need to connect your 32 bit data bus to a wider data bus, not a more narrow one. For reading, you should be using a cache anyway, with a line width a multiple of 128bits.
Hi I am new in embedded system. I do not know the true reason we classify microprocessor into 8 bit, 16 bit, 32 bit.
In a document I read, it explained it is because of number of the bit we used to number the address of register. But I think it is not true, because if we need 32 bit to number the register address of a processor so we must have more than 232 registers. It seem nonsense, it is too much register. So I think maybe, it is depended on the size of register or maybe the size of bus or the number of the bit, which microprocessor can work with a time.
Please help me to clarify this issued.
It is clear that you have either misunderstood your reference, or it is poorly worded. It should presumably state:
... number of the bits used for an address register
This means that the address range of the processor is then 2n, so perhaps your reference is referring to memory locations rather than registers.
i.e. it refers to the bit-width of a register, not the enumeration of a register.
However I would suggest that data path width is the more common and useful measure of processor architecture by "bit-width". For example 8-bit processors commonly have 16 bit address buses, and 16 bit address registers. And 16-bit 8086 devices use two 16 bit registers (32 bits) to represent a 20-bit address, but it is neither a 20 nor 32 -bit processor. 32 and 64 bit processors tend to have equal address and data register widths, which may be the cause of this erroneous statement.
As described here, the natural size of an integer (i.e. the integer size that single machine instructions take as operands) is the usual method of classification in this context.
It isn't the address of a register but the width of the register.
We have a system based around an Atom Z510/Intel SCH US15W Q7 card (running Debian Linux.) We need to transfer blocks of data from a device on the Low Pin Count Bus. As far as I know this chipset does not provide DMA facilities, meaning the processor has to read the data out a byte at a time in a software loop. (The device driver actually implements this using the "rep insb" x86 instructions so the loop is actually implemented by the CPU if I understand correctly.)
This is far from optimal, but it should be possible to hit a transfer rate of 14Mb/s. Instead we can barely manage 4Mb/s with transactions on the bus no closer than 2us apart even though each read to the slave device is is done in 560ns. I don't believe other traffic on the bus is to blame, but am still investigating.
My question is:
Does any one know if there are any configuration registers on the SCH that could affect the LPC bus timing?
I cannot find any useful information on the device on the Intel website, nor have I spotted anything in the Linux Kernel code that appears to be fiddling with any such registers (but I'm a noob when it come to Linux Kernel stuff.)
I'm not an x86 expert so any other factors that might come into play or any other 'war stories' relating to this device would be good to know about too.
Edit: I have found the datasheet. I've not seen anything in it that explains this behaviour, but I am investigating the possibility of mapping our device as a firmware device as the firmware bus cycles don't seem to suffer the same delays.
For the record, the solution was to modify the FPGA firmware such that the chip's data in/out register was mapped to four adjacent addresses and the driver modified to do 32 bit inb/outb instructions. Although the SCH does not implement 32 bit LPC read/write operations, the result is 4 back-to-back 8 bit operations followed by the same dead time as I was getting previously with a single byte, meaning it averages about 1us per byte. Not ideal, but still a doubling in throughput.
It transpires the firmware cycles were quicker because the SCH transfers 64 bytes at a time from the firmware flash - after 64 bytes there is the same 1.4us gap, indicating this is the per-transaction latency of the device. Exploiting this may have been slightly quicker than the above solution however the trade-off is that it is limited to 64 bytes chunks and each byte takes longer (680ns IIRC) due to the additional cycles required to do a firmware read.
In Randall Hyde's Art of Assembly it says the 8088 CPU was 8 bits whilst the 8086 was 16 bits solely because of the width of the data bus.
I have always thought that the address size determined the size of the CPU.
Please shed some light on this issue.
From Wikipedia
The 16-bit registers and the one megabyte address range were unchanged, however. In fact, according to the Intel documentation, the 8086 and 8088 have the same execution unit (EU)—only the bus interface unit (BIU) is different.
So the processor is functionally identical, but the memory bus is smaller. The main purpose was for compatibility with 8-bit interfaces. If a 16-bit interface was wanted, then it would take 2 CPU cycles to accomplish what the 8086 could do in one.
There was a greater availability of 8-bit chips at the time.
I can't find any official definition of the property "x-bit cpu", i suppose it does not exist.
I would say that "x-bit cpu" property indicates that the cpu can manipulate the data (inside the chip) with the size of "x-bits" at once. To be more specific it has so called general registers with the size of "x"bits. So it can add (subtract, divide, multiply, xor etc) the data of "x-bits" length at once.
8086 has 16-bit general registers = 16-bit cpu
8088 has 16-bit general registers = 16-bit cpu
80510 has 32-bit general registers = 32-bit cpu
Again, the official definition of the property is unknown.
the wiki about ia-32 says =
The primary defining characteristic of IA-32 is the availability of
32-bit general-purpose processor registers (for example, EAX and EBX),
32-bit integer arithmetic and logical operations, 32-bit offsets
within a segment in protected mode, and the translation of segmented
addresses to 32-bit linear addresses.
I prefer to think that the bitnes of general registers is enough to determine the x-bit cpu property.
The funny thing is intel itself defines cpu bitness by using different criteria from time to time. if you look at the official intel doc it says
8088 is 8-bit hmos microprocessor
( i suppose they defined 8-bit cpu based on 8-bit data bus interface. remember this criteria). At the same time they say at the same document that the cpu has
16-bit internal architecture
Thats funny.. 8-bit cpu with 16-bit internal architecture.
Okey. Lets look at another example Intel pentium 510.
They say it is
32-bit microprocessor
the cpu has 64-bit data bus, so based on previous example we would need to say that intel 510 is 64-bit cpu however it is wrong.
The conclusion - to determine cpu bitness look at the size of general registers.
I have a small confusion.
When we talk about 32-bit architecture and 64-bit architecture what do we actually mean. Do we mean that a 32 bit architecture has 32 bit registers OR 32 bit address-bus OR 32-bit data bus.
What is generally implied?
I would say that usually, this would mean that a 64-bit system has 64-bit address registers. In modern systems, data registers are usually at least as large as the address registers, so the data registers and data bus would likely be equivalently sized.
A 64-bit system, however, usually does not have a 64-bit address bus. There's no point, since there hasn't been enough RAM manufactured in the history of the planet to need a full 64 bit physical address bus. A given system will have a maximum amount of physical RAM that it can address, based on the width of its address bus.
We mean that we have 64 bit of address space for programs.
This usually means that we have 64 bit registers in the CPU (makes sense to have the registers in pointer size) and so on...
a 32 bit architecture means that the ALU (description) is capable of computing 32-bit words. The databus (width) and the registers are included in this definition, as well as adressing.
It means that the registers and stack (!) have a width of 32/64 bits. Address-spaces are often much smaller, see here:
In principle, a 64-bit microprocessor can address 16 exabytes of memory. In practice, it is less than that.
For example, the AMD64 architecture as of 2011 allows 52 bits for physical memory and 48 bits for virtual memory.
wikipedia-link
Well! Thanks a lot for your inputs.
After reading through a lot of articles and online material, I think now I my confusion is no more.
So I would like to briefly summarize.
n-bit CPU:
An n-bit CPU only means that it has n-bit registers which implies an n-bit word size. Don't give a second thought on address/data bus size.
As an example, consider Motorola 68000 processor - which comes in a 32-bit variant ie it is called a 32-bit processor but it has 16-bit data bus and 24-bit address bus. Due to its 24-bit address bus, it can address only 2^24 ie 16 MB of RAM.
Address bus only tells how much RAM can be addressed whereas data bus tells how many units of data can be transferred in one cycle.
68000 processor can thus transact only 2 Bytes of data due to 16 bits in data bus.