Electronic – 8086 Memory segment falling on 16-byte boundaries

Well, I'm really not sure. This CPU description is incomplete, for example there is no branch nor data memory access.

• For the non-pipelined version, there is only one visible clock, the program counter. It is possible to calculate the next PC address while doing the ALU operations, propagation time is 6+3.5+4+4+1+6=24.5 ns All the decoders (source, operand...) are parallel, so only the longest delay is part of the timing "critical path". There is no clear indication of the delay needed for writing into the register file, maybe 4 ns more.

• For the pipelined version :

F : I-cache : 6ns ( in parallel with the program counter update )

ID1 : Instruction decoder : 3.5ns

ID2 : Destination decoder : 4ns ( parallel with the other decoders, which are faster) + register file : 4ns

EX : ALU + MUX : 7ns

WB : register update : ??? ns

Max delay is around 8ns.

Alternatively, all decoding in ID1 (so 7.5ns) and register access in ID2 (4ns). Traditionally, the ALU is part of the EXECUTE stage.

Anyway, I think that this exercise is really poorly written.

In the 8086 each segment is, yes, 64KiB. Those segments can move though.

You set a "segment pointer" which defines where a segment starts. It acts as an address offset, which is added to the internal 16-bit address of the program counter (or other indexing register).

Changing the segment pointers is a trivial matter, so although you can only access 64KiB at a time, you can move that 64KiB window around at will to access the whole 1MiB of memory space.