In designing a control unit, when the read instruction is executed the processor sends some signal to the RAM for read operation and address on the address bus. Processor has its own clock of operation lets suppose 900 MHz, now, RAM can work on just few MHz like 300 MHz. Control unit is a finite state machine, which sends the signals on each state and state changes with time. When the read instruction is executed the processor sends the control signal and address to the memory and after 3 clock cycles it is expected to get the data back on the data lines (3 x 300 = 900) so it will add two additional wait cycles. Now there is another RAM which is purchased and it operates at 600 MHz, so the data expected is after 2 clock cycles (2 x 300 = 600).

My confusion here is does the processor will dynamically change the read cycle operation and making it 2 clock cycles if Yes than what is the mechanism behind that and how the control unit dynamically adjust its states while communication with the devices ?

I also read some about the mother board clock and processor clock, does the processor internal operation works on its own clock and when it communicate with the external device it used mother board clock ?

Here I meant about syncronous communication or operations


closed as too broad by old_timer, Voltage Spike, ThreePhaseEel, tcrosley, Dmitry Grigoryev Jan 30 '17 at 14:08

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ It is two broad a question to answer but yes, in general, the processor has its own core clock for processing and will use another (slower) clock to communicate to synchronous RAMs. \$\endgroup\$ – Claudio Avi Chami Jan 28 '17 at 1:39
  • \$\begingroup\$ Any reference or read you can suggest that can detail explain this process. \$\endgroup\$ – Muhammad Usman Jan 28 '17 at 9:39
  • \$\begingroup\$ Modern high-perf CPUs can't execute anything directly from RAM. They tell the cache controller to load some code into the instruction cache and execute code from there. \$\endgroup\$ – Dmitry Grigoryev Jan 30 '17 at 14:13

It doesnt quite work like that anymore. You could design a system like that yes, but...

So lets say we are talking about DRAM, you have a dram controller, a dram reference clock for that controller, there are standard parameters the controller knows about but are specific to that vendors chip (although they are pretty much the same numbers for a particular technology and speed across vendors). The dram (ddr) plug in modules also include a small rom/flash that includes the parameters for those modules, the software reads that using i2c for example, using that information it causes the controller to train with the dram and find a speed and settings that will work. Now the controller knows the speed and other timings for that memory so when the processor via some controller in between and caches, etc, asks for something from dram, the dram controller knows how fast it can talk to it.

sram when you are talking at these speeds is similar you have a bus that you need to tune or train, normally not every boot though, dram is generally in plug in modules, sram soldered down, so the board vendor tunes that interface and using its bootloader gets that interface, up but in that case as well the sram controller now knows the speed to talk to the sram.

The procesor busses are not like the old days, you to some extent can/do have separate read address, read data, write address, and write data busses. the other side of that bus is a controller that queues up commands from the processor as there can be many in flight, and then sorts them and sends them down the right path. the processor may put out a read address request with a read id, some unique number on that part of the interface, the other side queues that request, and acks it, this allows for credits between the two so the processor doesnt overload the read command fifo. At some point when that read gets to the front of the queue, then it gets interpreted and sent along its way (based on the address bits of course). If that happens to be dram it gets sent, ideally through a cache so that the dram side is more efficient, but doesnt have to if you want to read one byte then you will read a whole 64 bits from the dram, send all 64 back or maybe 32 depends on the bus widths. and the processor based on features of that bus will isolate the byte it asked for, the buses and controllers, on a read wont normally know if it is actually only one byte, it is one bus width. Note the read data bus was involved the controller got the data from dram, then has to tell the processor, hey I have read id number 7 data for you. The processor queues up that request, when it has time it says, okay you can send me read id number 7 data. and then takes it.

write pretty much the same but it is one direction and fire and forget, write address request goes out, gets acked, queues up in the bus controller, eventually the bus controller asks the processor for the data from that write id, queues up, processor eventually says here is the data, then the controller now has everything it needs the address, data, transaction type, (exclusive, cacheable, write bufferable, etc). Other bus features are required, you can probably do byte addressable transactions so there will be a scheme to identify the byte or bytes on the bus that are real, the rest are garbage, and if it is not a bus widths or dram widths worth of data the dram controller has to do a read-modify-write to read the width, modify the byte or bytes in question, and then write them to dram. a cache can help here as it isolates this everything on the dram side is ideally in multiple units of the bus width, and stuff on the processor side can be that or less, the cache is faster so the read-modify-writes are less costly. at the same time though you need the data in the cache so you might have to read a bunch of data, in order to write one byte, on the first access to that cache line if it misses. then later write some number of bus widths even if that one byte is the only difference when it is evicted.

so with a modern processor (x86, arm, etc) with a modern bus, the simples transactions can take many to dozens of clock cycles, when you touch dram even if 2133Mhz it is still really slow and can take tons of clock cycles, dozens, hundreds.

So to your question, it depends on the memory interface, it is very unlikely that the processor has any clue what is at any address, it doesnt know memory from flash from a peripheral to a hole in the wall, only the programmer knows that. the processor just performs the instructions it is given at the addresses given. The board/chip designer has implemented the address space and from that the memory side is managed by a memory controller and that memory controller is configured by the programmer for the proper speed memory for that board design, or by a detected method if it is removable memory. When the processor does its request even if a simple wishbone bus, the memory controller will eventually get hit and it will take as long as it takes to perform the transaction and ack back or return data. Writes can be but not always are fire and forget, the processor can send out the address and data and it is done it can move on to the next task. Reads require the round trip the processor has to wait for the address to go all the way out and wait for the data to come all the way back. so writes are fast for random access, for sustained stuff though they both are throttled by credits between fifos and the speed of the memory ultimately controls the speed of the traffic jam.

If you are talking about the old days like 8088 the memory had to be as fast or faster than the processor and there were no wait states, then later wait states were allowed but the logic that attached to the processor would be designed to request the wait state. If you were to do a modern design with a traditional bus, then you would likely have a programmable memory controller and on boot the software would configure the controller based on knowing the board design or some detection mechanism, and then the memory controller would request the right amount of wait states based on that configuration.

this is all very vague since you have not provided enough detail for a specific answer.

  • \$\begingroup\$ Hi, Thanks for your response, your answer is very helpful but there is some part of the confusion is still left, my main concern in designing the control unit and what mechanism should be done in order to keep full filling the requirement for being synchronous and still managing the proper communications. \$\endgroup\$ – Muhammad Usman Jan 29 '17 at 9:27
  • \$\begingroup\$ The solution which I devised involved little bit asynchronous where in the state diagram of control unit when the load command is sent it will send some specific control signals to the memory on the control bus and when memory controller receives the signal it will send the device ready signal to the control unit after the data is ready and the state machine will continuously in wait state until the ready signal is received, when the ready signal is received it will open the data path and get the bits in the register \$\endgroup\$ – Muhammad Usman Jan 29 '17 at 9:37
  • \$\begingroup\$ Or Second logic for keeping the things synchronous by adding a special register or timer in the design where the value in the register is initialized after looking the data from the memory controller chip during the POST, and the timer is initialized based on the value in the register and the state machine is looking on the timer status when the timer is expired it will get the data \$\endgroup\$ – Muhammad Usman Jan 29 '17 at 9:42
  • \$\begingroup\$ Hope now you are clarified what I actually want :) \$\endgroup\$ – Muhammad Usman Jan 29 '17 at 9:42

Your question seems quite clear. The answer is that the microprocessor must be told how long the memory access cycle should be.

Its bus design may complete a memory access in as few clocks as possible unless you assert its WAIT/etc input to extend the access.

Or its bus design may use a request/acknowledge design where it asserts REQ/etc to start an access which only finishes when its ACK/etc is asserted.

Both these mechanisms may have programmable on-chip circuitry to control WAIT or ACK.

In all circumstances, its the responsibility of the designer/programmer to work out what the memory needs and give it to it.

Have a look in your PC's BIOS or EFI and you'll see programmable timings for the SDRAM.


Not the answer you're looking for? Browse other questions tagged or ask your own question.