How to Break down Speeds (mcu,clocks,ns,mips)

I already mentioned in a prior thread that I know nothing about timing.

I was wondering how to calculate such things as I have a flash chip that runs at xx ns, how to best select a clock frequency for the MCU to best flash that chip without having to delay.

Something along that line. Or simply, I have no idea the relationship between the speed of the chips my MCU works with, and speed of executing instructions, and how that area all fits together.

So I've used a 6,12,16Mhz clock for instance, but I have no idea what's best, or if fastest = best. Then I wonder if there are better ways, and how maybe better knowing the timing relationship between all of the components can better help my approach and understanding of the whole shebang.

Ok, so first of all, we'll start with clocks vs instructions. This actually varies between architectures. The AVR architecture will execute most instructions in a single clock cycle, while the PIC architecture requires 4 clock cycles per instruction, but I believe they also implement pipelining to basically complete 1 instruction every clock cycle. MIPS = million instructions per second, used to compare processor speeds between architectures that have a different number of clock cycles per instruction, since instruction execution is really what you care about in such a comparison.

As for memory access speeds, typically you'll have a host system that performs memory accesses at a certain speed, then you choose your memory accordingly so that your memory can perform at that speed or faster. This is why you want Flash ROMs that are 120ns or faster, because of the FastROM access speeds. However, in a situation where the memory has already been selected and you are designing your system to work with it (e.g. a microcontroller being used to burn Flash ROMs), you have to account for the memory access speeds so that you don't try to access the chip too quickly. The reason for this is capacitance. I think I explained this before in one of your other threads, but think of a capacitor as a small rechargeable battery. When you apply power to the capacitor, some of that power goes into charging the "battery" instead of into the rest of the circuit. This causes the voltage to rise slowly until the "battery" is fully charged. Now, when you remove the power source, the "battery" slowly discharges, causing the voltage to slowly drop as the capacitor discharges, instead of dropping instantly like you'd expect from "pulling the plug". Now, you have to understand that EVERY electronic component has capacitance, even if it's not a capacitor. Even wires, or copper traces on a PCB. These are usually MUCH lower capacitances than an actual capacitor, but it is still capacitance. This is true of chips too. That capacitance, the fact that it takes awhile for voltage to slowly raise or lower, means that it actually takes time for a pin to go from a 0 to a 1 and vice versa. This is also true of all of the transistors inside the chip itself. So it takes time between you setting up your address lines and toggling the control lines before the chip actually produces the correct data on the data lines. The chip is rated to perform at or better than the specified speed, but the rated speed is the fastest that you should expect the chip to perform.

So what does that mean to you? Well, let's try some pseudocode:



That delay depends on the speed of the chip. Looking at the AM29F032B datasheet, the time between OE going low and data being valid is 40ns, while the time between CE going low and valid data is 90ns. This means CE should go low before OE, but then we look at how long we actually need to wait. Assuming an AVR running at 8MHz, one instruction per clock cycle, 8MHz is 125ns per clock, so a single NOP should be sufficient delay between OE going low and reading the data, and actually, you probably don't even need it because it will take 125ns between the "pull OE low" instruction and the "read the data lines" instruction. However, I've had issues whenever I omit the delay with a 16MHz clock, so it really doesn't hurt to have it, other than a slight (to the point of being negligible) speed hit.

Address and data hold times for write operations on the AM29F032B are both in the 45ns range, so again, a single NOP is plenty. Also, the entire write cycle is only 90ns, so you shouldn't have to delay at all between writes, especially if you are using C and have a WriteByte function, because the stack frame code for entering/leaving a function would be plenty of delay even if you did need it. If you're using a 16MHz clock crystal instead of the internal 8MHz oscillator, your instruction period is half as long, about 65ns, so you have to figure that into your timing calculations.

For the most part, faster is better for the microcontroller clock source, unless you're trying to save power, such as in a battery operated project. You can always add delays for timing critical functions, but when you're dealing with timing critical functions, you will almost always rather have the extra breathing room given by a higher clock speed.

Did you mean to say: "The chip is rated to perform at or better than the specified speed, but the rated speed is the slowest that you should expect the chip to perform."

He meant what he said. If a chip is labeled for...let's say, 30ns, then the fastest you should expect it to operate reliably is the inverse of 0.000000030, or 33.33Mhz.

so my AVR runs at 16 Mhz. That is 1 s / (16,000,000 Hz) * (1000000000 ns / 1 s) = 62.5 ns. AVR is one instruction per clock cycle, thus 62.5 ns per instruction.

Then, adding in the capacitance or "Time it takes for voltage to propagate on an I/O line" theorem, it will probably take a little longer (how much longer. Is worth discovering?).

Either way, I'm probably looking for a flip flop (related to my other thread on MCU and the 2 i/o pins) that operates around 60ns. Then I can disregard delays between instructions.

That's all correct. Your confirmation is always welcome and anticipated.

Honestly, you're dealing with relatively low-speed devices, timing is hardly critical or difficult at all. The most you'll have to do is throw in a NOP or two if the chip you're interfacing with isn't fast enough for your clock speed. At 16MHz, if you want to read SlowROM, 3 NOP's between /OE low and reading your data (or between setting up the data and pulling /WE high for writes) should be a sufficient delay. Don't worry about the capacitance delay on the microcontroller. For the sake of practicality, it doesn't matter, because it's consistent, and what really matters is the delay between the microcontroller changing its value and the memory device responding.


I know you're trying to understand this stuff conceptually, but in this case you're overthinking it. This is what we like to call solving a hardware problem in software

conceptually is exactly what I'm going for. Universal understanding

This is one of those things you could spend the next decade learning how to do right, or spend that same decade just doing it the way that "just works". Kinda like the rules-of-thumb about pull-up resistor and decoupling capacitor values. Given the choice, get the faster part unless power saving is a strong consideration (e.g. battery powered devices), and if the processor is faster than the peripheral, just throw in a delay, especially if it's only the cost of a couple of clock cycles.