Talk:Control store

Untitled

In a microprogramed system there are two major components,. The first is the sequencer and the second is the control store., The output of the sequencer is the address of the current micro-instruction,. This address goes into the control store,. The control store contains the microprogram for the system., The outputs of the control store will fall into two main groups,. those that determine the address of the next micro-instruction and those which directly control the rest of the hardware in the system., The control store usually has on its outputs a register. It must be obvious that the outputs that go back into the sequencer to determine the next address have to go through some sort of register to prevent a race condition being created. However it turns out that in most designs it pays for all of the other bits to also go through a register. This is because the machine will work faster if the execution of the next microinstruction is delayed by one cycle. This register is known as a pipeline register. The point is that very often the execution of the next microinstruction is dependent on result of the current microinstruction that will not be stable till the end of the current microcycle. It can be seen that either way all of the outputs of the control store go into one big register. In the olden days it used to be possible to buy EPROMS with these register bits on the same chip.

I'm not at all happy with this paragraph. First of all even I am confused what the author is getting at. Please expound on what is meant with race condition, i.e. when there is more than one sequencer at work here etc. The predictive branching aspect is pretty interesting here too but I think we should keep the concepts presented here a little simpler...

Hell, do you know those wind up music toys with a metal drum with spikes on it...? The spikes on the metal drum.. that's the microcode (and the drum is the control storage). As the drum rotates the spikes cause the metal tabs to vibrate producing the melody..

That's a nice introduction to the concepts here and then we can move on and tell people what a microsequencer is and then go all the way and provide a sample microcode for an extremely simplified CPU. 84.160.239.19 23:19, 17 January 2006 (UTC)

I like the wind-up music example. When you figure out what we really meant by the confusing, ambiguous statements in this article, please edit the article to make it easier to understand, OK? (WP:TECHNICAL). Are the concepts of a control store and a microsequencer so closely intertwined that we should cover both of them in a single article, like block and tackle are covered in a single article?

what the author is getting at. It's an attempt to describe why some or all of the control store output bits are always registered. Some sequential circuits don't use a register or even a transparent latch -- in some sequential circuits, output bits loop directly back into the inputs. So why are the control store output bits invariably registered? Why do CPU designers deliberately hold back these signals until the next clock, when they seem so fixated on improving speed in other areas?

Allow me to expound on what is meant with race condition with an example:

For example, say our CPU is currently executing microinstruction 10000 -- i.e., the address currently being fed into the control store is 10000, and the bits on row 10000 are currently flowing out to the various parts of the CPU. Some of the bits on that row hold the "next microinstruction" field. To continue our example, let's say they hold 11110.

What happens if we design a CPU without a microinstruction register to delay the bits in that "next microinstruction" field?

If we wire the "next microinstruction" output field directly to the address input to the control store, then there is a small chance that everything will work perfectly. If all the lines have equal delay, then the control store smoothly transitions from row 10000 to row 11110 as desired. Then the "next microinstruction" and other fields of that row come out, as desired.

Alas, it is far more likely that one of those output bits will be earlier than the others, and some other bit will be delayed more than the others. Minor differences in speed briefly activate row 10010 or 10100 or 11000 -- and then whatever "next microinstruction" that row selects will start coming out.

There is a "race" between these microcode address bits that creates a race condition. There are several techniques to ensure that, no matter which bit(s) win the race, a sequential circuit will eventually settle down to the desired state (in this example, state 11110). (Which technique(s) do the people who design a clockless CPU use?) The vast majority of CPU designers use the Moore machine technique: "Insert a register somewhere in the loop, and clock it slowly enough that even the slowest bit has plenty of time to settle down to the desired value".

How can we change this article to make it easier to understand? --DavidCary (talk) 12:38, 9 July 2011 (UTC)

Diode rom?

The article says: "Modern VLSI CPUs also use a diode matrix for the read-only control store."

I would be surprised, if for example the pentium4 processor has a diode matrix in it. Maybe someone who knows more about such things kan change the article if the newest processors indeed don't have diode matrixes.

Improving the lead

I believe I have improved the lead, and I have removed the tag. If anyone has any problems, please let me know. RogueZephyr (talk) 23:45, 17 February 2016 (UTC)

Some problems:

1. The bit about diode arrays is a historical implementation detail, probably best left in the Implementation section.
2. Writable microcode is, as "writable" suggests, not stored in read-only memory, it's stored in writable memory, typically semiconductor RAM.
3. Diode arrays weren't the only technology used for "non-writable" microcode - a number of technologies were used, such as "capacitor read-only storage" (CROS) used in some System/360 models, "transformer read-only storage" (TROS) used in the System/360 Model 40, and various forms of semiconductor integrated-circuit ROM. Guy Harris (talk) 00:20, 18 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Control store. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120226174302/http://urbanmyth.org/microcode/ to http://urbanmyth.org/microcode/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:19, 12 August 2017 (UTC)