GARTHWILSON wrote:
I hate to persist, but there are too many problems with BDD's post to just let it go.
False, for two reasons. For one, his glue logic takes most of that 10ns, and for another, bus capacitance will easily hold the data for the rest of the time, as nothing else is driving the data bus yet. The small CMOS leakage along with the capacitive loading on the lines would hold the logic state for a good dozen microseconds (and possibly much longer) if you were to stop the clock immediately after phase 2 goes down.
Quote:
Therefore, the addressed device ***MUST*** stay open for access until tDHR has expired. There's no sure way to guarantee this if addressing is qualified by Ø2 as you are doing. In your design, as soon as Ø2 falls, your chip decode will become invalid, chip select will be deasserted following gate delays (very short with 74AC logic), and in the case of the SRAM, it is not likely you will meet the tDHR timing requirement. Ergo there won't be any data to read.
In the 1950s, the U.S. Air Force was using modified F104s to give pilots an opportunity to experience travel into low space without resorting to the use of full-blown rocket flight. The F104s were equipped with hydrogen peroxide catalyst rockets to propel the plane to altitudes exceeding 100,000 feet, a region in which the plane's J79 engine would, of course, be useless. HP thrusters were fitted to the wingtips for control as the plane left the atmosphere.
Gen. Chuck Yeager was involved with this program and, in fact, was largely responsible for working out the flight procedure. During a test flight in which he ascended to about 104,000 feet, he got into a situation that almost killed him, in part due to trying to take advantage of an undefined behavior of the F104.
The procedure was to climb to about 70,000 feet on jet power, fire the rockets to continue the ascent and shut down the J79 to prevent "hot section" damage due to insufficient intake air. After passing through the apex of the climb, the plane would be put into a (hopefully) controlled descent, using the rockets and wingtip thrusters to pitch the plane down. This action would bring it back into the atmosphere, at which time air rushing through the J79 would windmill the turbine ("spool") assembly and permit an engine restart.
Parenthetical note: the F104's controls were dependent on hydraulic pressure derived from a pump driven from the spool. If the spool wasn't turning, neither was the pump, and the pilot had no control to speak of. Therefore, getting the engine running during the descent was paramount. Alternatively, if unable to actually fire the engine during descent, the pilot could continue down to keep the spool windmilling so control could be maintained for a dead stick landing.
Anyhow, after passing through the apex of his climb, Gen. Yeager headed back down. Unfortunately, as the F104 got back into more solid air it went into a flat spin due to its tendency to pitch up during steep descent angles. Under normal conditions, Yeager would have had little difficulty in counteracting this behavior and getting out of the spin. However, he had no flight controls because the J79 wasn't running and, adding insult to injury, the spool wasn't windmilling, since in the spin, insufficient air was being rammed into the engine. Ergo he didn't have the ability to break the spin, and down he went, completely out of control.
At 30,000 feet, with the spin worsening, Yeager decided he would deploy the plane's drag 'chute to get the nose down and regain control. The 'chute was intended to assist in slowing the plane after landing—the F104's wing design required high takeoff and landing speeds. However, the 'chute's and the plane's behavior in flight was not quantified by the machine's builder. Yeager, of course, knew this but assumed the 'chute's drag immediately after deployment would force the nose down and get him out of the spin.
It didn't work that way. The 'chute deployed, momentarily forced the nose down, but then separated from the plane due to his airspeed being too high. The F104 promptly pitched up and went back into the flat spin. His efforts to save the specially equipped plane had failed and he (barely) ejected in time to save himself. The general was seriously burned, almost permanently lost vision, and had narrowly escaped death. The plane, of course, ended up punching a big hole in the ground.
My point is this: assuming that an undefined behavior of something will work to your advantage is fallacy. Assuming a circuit will behave in a predictable fashion due to the effects of an unquantified (in most designs) phenomenon like stray capacitance is fallacy. You might get away with it some or most of the time, but not always.
Quote:
Quote:
During a write cycle, you will have another circuit bug. As I said above, the data bus is never valid when Ø2 is low. If you directly connect the SRAM's /WE input to the MPU's R/W output, you will be telling the SRAM to accept data (assuming a write cycle) while Ø2 is low, a period during which the MPU is fiddling with the address lines. At higher clock speeds, it's very likely the SRAM may react to /WE while the address bus is in transition. The result is the invalid data on the data bus will be written to an invalid address in the SRAM.
.
