Slow processor speed

[Tim]

Pardon me if my question is not phrased well, but I am not experienced working with microprocessors (or even hardware in general). I am handling the software development while others designed the hardware.

I have 2 different types of hardware (many of each) each with ZX44a processors. They should have identical EEProms and identical 14.7MHz crystals. The hardware guys tell me things are wired identically. However, on one of the types of hardware, the processor runs almost exactly 2.93 times slower than on the other. I have run many different types of tests with identical code and these results are consistent, the most basic test being a simple FOR loop while incrementing an UnsignedInteger.

Does this ratio of running almost exactly 2.93 times slower indicate anything to anyone? Please let me know if more information is necessary.

[dkinzer]

[O]n one of the types of hardware, the processor runs almost exactly 2.93 times slower than on the other.

If the serial I/O is working correctly that means that the main clock is running at the correct frequency. It is possible that there could be a defect/failure in the chip that causes the SPI clock to run too slow. Since instructions are fetched from the SPI EEPROM that would have a significant effect on execution speed. If you have a logic analyzer you could look at the SCK signal (pin 8 ) when the SS signal (pin 5) goes low. It should have a frequency of 7.37MHz.

It is also possible that the CPU is getting spurious interrupts due to an internal defect. This would be much harder to detect. Have you tried swapping out the processor or the EEPROM?

Would it be possible for you to send me the board that is acting strangely?

[Tim]

Thank you for your reply.

If the serial I/O is working correctly that means that the main clock is running at the correct frequency

Yes the serial I/O is working correctly and the main clock appears to be running at the correct frequency

If you have a logic analyzer you could look at the SCK signal (pin 8 ) when the SS signal (pin 5) goes low. It should have a frequency of 7.37MHz

The frequency appears to be exactly 7.37MHz

It is also possible that the CPU is getting spurious interrupts due to an internal defect. This would be much harder to detect. Have you tried swapping out the processor or the EEPROM?

This occurs on many boards (actually on all) with many different processors and EEPROMs. I have one "simulator" board and its processor is the only one that does not display this slow processor speed.

Would it be possible for you to send me the board that is acting strangely?

Unfortunately I wouldn't be able to send one anytime soon. However I could send the data from the logic analyzer if that would be useful information. After the SS pin goes low, the SCK pin appears to have 2 groups of 8 periods of 7.37MHz signal with the 2 groups separated by about 500 ns. Does this sound correct?

Thank you

[dkinzer]

After the SS pin goes low, the SCK pin appears to have 2 groups of 8 periods of 7.37MHz signal with the 2 groups separated by about 500 ns. Does this sound correct?

Yes. The first group of 8 is probably the fetch of the first (perhaps only) instruction byte. The second group is either the fetch-ahead of the next instruction or the retrieval of the second byte of the instruction.

Try compiling and running the program below. (If you change the pin, you'll need to adjust the line with the Xor so that it toggles the state of the I/O port bit corresponding to the specified pin.) The half-period of the resulting signal should be approximately 31.8uS on a ZX device that uses external serial EEPROM like the ZX-24a, ZX-44a, etc.

Code: Select all

Const testPin as Byte = A.7
Sub Main()
  Call PutPin(testPin, 1)
  Do
    Register.PortA = Register.PortA Xor &H80
  Loop
End Sub

As an aside, on a native mode ZX device the square wave has a half-period of about 330nS.

[Tim]

Again thank you for your help. I apologize for the slowness of my responses but it had been difficult to get ahold of the hardware to test with. I now have one and am able to test.

Try compiling and running the program below. (If you change the pin, you'll need to adjust the line with the Xor so that it toggles the state of the I/O port bit corresponding to the specified pin.) The half-period of the resulting signal should be approximately 31.8uS on a ZX device that uses external serial EEPROM like the ZX-24a, ZX-44a, etc.

The half-period is indeed approximately 31.8 us on my ZX-44a that is running slow.

The following is a snippet of the code I am using to compare the processer speed between multiple devices by measuring the time required to increment a byte variable.

Code: Select all

Public Sub SpeedTest()
	Dim n As Long
	Dim nRuns As Long
	Dim i As Byte
	Dim cTime As Single
	Dim eTime1 As Single
	Dim eTime2 As Single
	
	nRuns = 20000
	cTime = Timer
	For n = 1 To nRuns
	Next
	eTime1 = Timer-cTime
	
	i = 0
	cTime = Timer
	For n = 1 To nRuns
		i = i+1
	Next
	eTime2 = Timer-cTime
	Console.WriteLine(CStr(CSng(nRuns)/(eTime2-eTime1)) & " bips")
	
End Sub

I also have other code where I transition a pin to verify that the reported times are correct (and they are).

Any additional advice would be appreciated.

[dkinzer]

The half-period is indeed approximately 31.8 us on my ZX-44a that is running slow.

That shows that the processor itself is running at the correct speed. There must be some other aspect of your test environment that causes the performance of the test mechanism to be lower than expected.

As an example of this, consider the test program below that calls your speed test subroutine. With USE_SW_UART defined, the program reports a result of 67814.57 bips. With USE_SW_UART not defined, the program reports a result of 103434.3 bips. This demonstrates the load placed on the system by simply opening a SW UART channel.

Code: Select all

Const chan as Byte = 3
' uncomment this line to include use of a software UART
'#define USE_SW_UART
Sub Main()
#if defined(USE_SW_UART)
  Dim iq(1 to 20) as Byte
  Dim oq(1 to 20) as Byte
  Call DefineCom(chan, 5, 6, &H08)
  Call OpenQueue(iq)
  Call OpenQueue(oq)
  Call OpenCom(chan, 9600, iq, oq)
#endif
  Call SpeedTest()
End Sub

This suggests a means to identify which parts of your program are contributing significantly to lower performance. Start with just the call to SpeedTest() and then incrementally add other parts to the program observing the effect of each addition. Using the compiler's conditional code capability helps to facilitate this kind of incremental testing.

[Tim]

Tada!

I had assumed all other extraneous code was "disabled", but now I realize one functionality was still on and that it is exposing a difference between the two systems.

Thanks so much for your help.