FPGA design: bus size vs die size

[josuah]

I recently discovered that the CPU core was often a rather small size of a microcontroller.

Is it also true for the bus size?

· 8-bit sized bus is smaller: "input [7:0]" and "outputs [7:0]".
· 32-bit sized bus means extra logic to select 16-bit and 8-bit out of 32-bit, like Wishbone's SEL_I.

But does it have a significant impact upon LUT number (FPGAs) or die size (ASICs)?

See also: https://www.eevblog.com/forum/microcontrollers/tiny-mcu-architectures-avr-pic-8051-stm8-msp430-custom-risc/

[ataradov]

Byte selects on their own do not add a lot of logic. Better designed peripherals would ignore them anyway, so it only matters for memories.

But obviously wider bus would take more logic than narrower bus even without additional byte select  signals.

It is hard to judge die area used by the bus, since it by definition has to go everywhere, so it ends up being spread all over the place.

And in more complicated designs there is more than one bus with bridges between them. This simplifies the routing and lets you use different bus types trading speed vs simplicity.

[SiliconWizard]

The question is unclear.
Is it just "bus size" or the actual size of registers/ALU/...? Two different things.

Obviously if the data or instruction bus size is a different width from the register/instruction size, this will usually require additional logic. Potentially making things significantly more complex. Sure multiplexing data is not very expensive, but what can be is all the underlying logic required to make use of that, such as more instructions required, and/or handling unaligned instruction or data fetching, thus a larger core.

[josuah]

Better designed peripherals would ignore them anyway, so it only matter for memories.

Fascinating. Peripherals would then be 8-bit bus, with multiplexing in the rare case of 16/32-bit fetches/writes from a 32-bit CPU core.
Getting each peripheral simper/smaller sounds a good yield given their number in a typical MCU.
That will help me with my next FPGA designs.

Is it just "bus size" or the actual size of registers/ALU/...? Two different things.

I had no idea it was possible or practical to have register size different than bus size, as I thought instructions would go fill registers by issuing read/writes requests through a bus of their same size, providing atmoic read/writes to SFR.

I am focused on the "bus size", such as the [31:0] vs [8:0] of a DAT_I/DAT_O (in Wishbone terms).

Obviously if the data or instruction bus size is a different width from the register/instruction size, this will usually require additional logic. Potentially making things significantly more complex. Sure multiplexing data is not very expensive, but what can be is all the underlying logic required to make use of that, such as more instructions required, and/or handling unaligned instruction or data fetching, thus a larger core.

So the multiplexing involved would at least prevent increasing the peripheral size, while still increasing the core size.

Thanks all for the answers, once again!

[ataradov]

Fascinating. Peripherals would then be 8-bit bus, with multiplexing in the rare case of 16/32-bit fetches/writes from a 32-bit CPU core.

No, on a good 32-bit MCU peripherals will use 32-bit registers. And byte and half word access would be prohibited or results undefined. 

I had no idea it was possible or practical to have register size different than bus size, as I thought instructions would go fill registers by issuing read/writes requests through

This is extremely simplistic view. This was  true in the 80s designs. Look at Cortex-M7 core. It is a 32-bit core, but it uses 64-bit AXI bus because it uses a dual-issue pipeline and 32-bit bus would be a constant bottleneck.

And core registers are separate from the bus by a lot of other logic (prefetch units, IO buffers, caches and stuff like this). There is no direct connection between them at all.

And there are no peripherals on this bus, only memories. All the peripherals are located on the slower buses, often behind multiple bridges.

[SiliconWizard]

I had no idea it was possible or practical to have register size different than bus size,

You may have missed a large chunk of the computing history then.

- 8088/8086
- 68k (in particular the 68000 and 68008)

and lots more. And, for more recent architectures, it's a lot about MMUs (for address buses) and various caching strategies.

If we're talking about multiplexing external buses, such as what the 808x or 6800x did, main reason was system integration rather than die size. Reducing external bus size made it much less expensive on a system level.

Now die size depends on many factors. If you have a small design relative to the CMOS process node, you are quickly pad-limited. Meaning that beyond a small number of pads, you will need a lot of extra die area mostly empty. Which is one reason those very cheap modern 8-bitters only have  a few GPIOs. And which is also why the complexity of the design and the number of IOs are often linked, something you'll see in particular with FPGAs.

[ataradov]

I'm not sure how fair it is to include the external bus into this. If you do, then you can get some interesting combinations. 80386SX uses 16-bit external bus and 24-bit internal bus, while 80386DX uses 32-bit external and internal bus.

[josuah]

Thank your pointers.

I might have glossed over all the setup that the memory<->core highway.

No, on a good 32-bit MCU peripherals will use 32-bit registers. And byte and half word access would be prohibited or results undefined. 

I suppose that if we have:

logic [31:0] reg0x00 = { DATA[7:0], STATUS[7:0], CTRLA[7:0], CTRLB[7:0] };

With DATA[7:0] clearing an interrupt flag upon reading, we would have some trouble if reading the status flag, or while writing to CTRL registers.
We would have to spend a bit of address space (which is not a scarce resource on 32-bit!) to space out the registers and have one 8-bit register at the beginning of the 32-bit register.

Now die size depends on many factors. If you have a small design relative to the CMOS process node, you are quickly pad-limited. Meaning that beyond a small number of pads, you will need a lot of extra die area mostly empty. Which is one reason those very cheap modern 8-bitters only have  a few GPIOs. And which is also why the complexity of the design and the number of IOs are often linked, something you'll see in particular with FPGAs.

Mostly empty? I thought it would get filled with extra peripherals instances, but this would get in the way of having the same feature set across multiple pin counts.

This means as as soon as there are more than just a few pins, there is a rather large die size budget to fill. Interesting.

[EDIT] fixed the formatting, sorry!

[ataradov]

Doing this CTRLA, CTRLB thing always results in a disaster. What if at some point you need more than 8 bit for the status? You will have to use a register at some random offset. It is a good idea to allocate full 32 bits and then if you are already on the initial pass use more than half, then allocate a dummy register nearby, just in case.

And even if you can get away with 8 bits, this often comes at a price of limiting  things right away. You will end up with situations like one bit describes multiple events and then you have to look at some additional register to figure out what actually happens.

Peripherals are usually small. You would have to add a lot to fill the space And extra peripherals come at the price of routing, which not only takes space, but also makes timing closures more complicated, reducing maximum clock speed. There are ways to address this, but it increases overall design, so you don't really want to add 20 timers if there is no practical way they can be used in a real application.

There is an argument to be made for more complicated and feature rich peripherals though. I personally would not put 8- or 16- bit timers into any device. And then have more channels per timer. Add FIFO buffers for UARTs. and stuff like this.

But often peripherals are common for big and small device, so design suffers.

[josuah]

I am surprised by the amount of tradeoff through the process of engineering ASICs. Maybe something particular to MCUs...

Doing this CTRLA, CTRLB thing always results in a disaster. What if at some point you need more than 8 bit for the status? You will have to use a register at some random offset. It is a good idea to allocate full 32 bits and then if you are already on the initial pass use more than half, then allocate a dummy register nearby, just in case.

Good to be planning ahead, and when I think of it, I often had surprises about how bits were packed onto these tight 8-bit budget, such as 9-bit UART or SPI, 10-bit ADC, i.e. with buffering on one of the bytes.

[tom66]

On bus complexity:  It scales somewhat with peripherals count too.  If the microcontroller has a lot of peripherals, then potentially these peripherals need muxes to select their data output onto the bus, which requires a more complex address decoder.   Things like AXI are point to point, so in theory peripheral count is irrelevant, but you still effectively need interconnect blocks, whereas AHB in typical practice is shared but with mux blocks.

[NorthGuy]

Generic FPGA's fabric doesn't have any tri-state logic. Therefore, buses implemented in FPGA are much more complex than buses in real MCU. There's nothing in common.

[DiTBho]

Old gold days ... when "cross bar matrix" chips were solid chips.
Like my "IBM-xbow" (that's the label on the big chip) one

[tom66]

Generic FPGA's fabric doesn't have any tri-state logic. Therefore, buses implemented in FPGA are much more complex than buses in real MCU. There's nothing in common.

Is tri-state logic used in microcontroller buses at all? (I am talking of buses that do not exit the processor; things like I2C excluded.)

It's my understanding that this is not a common design practice.  One major disadvantage would be that you would need internal sinks or sources to keep the bus in a defined state when no slaves were responding.  This would consume additional power in steady-state.  Therefore even a small ARM microcontroller will use something like AHB or APB for its peripherals which implies a multiplexer for all data outputs (with data inputs shared with all slave peripherals.)

[DiTBho]

Is tri-state logic used in microcontroller buses at all?

only if you have to interface asynchronous parallel devices.

[ataradov]

Is tri-state logic used in microcontroller buses at all? (I am talking of buses that do not exit the processor; things like I2C excluded.)

There is not tri-state logic, but there are pass transistors that are used as switches, which greatly simplifies the design.

[dmills]

Given that the usual implementation of a flipflop uses transmission gates, an odd sort of tristate bus inside a processor is possibly reasonable.

[SiliconWizard]

Bus multiplexing is certainly something that is suboptimal in FPGAs compared to synthesis on silicon.

[NorthGuy]

Is tri-state logic used in microcontroller buses at all? (I am talking of buses that do not exit the processor; things like I2C excluded.)

There are many things sitting on the bus. One of them is driving the bus (high or low). Others don't - they're in high impedance state and have no influence on the bus. FPGA cannot simply disconnect a driver and hence needs a mux.

I2C devices have only 2 states - driving low and high impedance.

[T3sl4co1l]

I can't speak for any particular chip, but many embedded CPUs read an "open" data bus same as previous data -- i.e. evidence of a tristate bus with enough capacitance that the level doesn't leak away between transactions.

This is relevant in a number of game console emulators, where open-bus logic has been found necessary to replicate certain obscure glitches in programs on those platforms.

And, while most of those use external memory, I believe some are wholly integrated as well??

Fascinating. Peripherals would then be 8-bit bus, with multiplexing in the rare case of 16/32-bit fetches/writes from a 32-bit CPU core.

No, on a good 32-bit MCU peripherals will use 32-bit registers. And byte and half word access would be prohibited or results undefined. 

What about x86? -- Oh wait, you said "good"...

Tim