Honored Contributor
Honored ContributorHi Rysc,
thanks very much for the detailed explanation, I think it's starting to make a bit more sense to me now - your note helps a lot. What I am trying to do is to use the CPLD to create clocks for two reasons :- 1. The first is to give me the option of clockiing the whole system at 16, 8 or 4 MHz to cope with legacy software that can't handle the 16MHz clock In this case, the CPU clock speed will be selected in hardware to pick one of the three, so there won't be any transfer of data between them. 2. The second case is where the CPU could run quite happily at the higher speed, but some peripherals may need to run more slowly, typically 4MHz. As you have no doubt worked out, this is all very much a learning exercise for me, but I don't think there will be any issues off the clocks are slightly skewed in this case - I guess that I'll know for sure when I try it. The other use for the CPLD will be to do the memory decode logic for the ROM & RAM. That logic will be driven in response to other inputs that change at the CPU clock speed, things like the Z80 /M1 machine cycle, Input/Output Request (/IORQ), Memory Request (/MREQ), Read (/RD), Write (/WR) etc. There won't be any internal communication between the clocks, the input data will just change at the selected clock speed, so I don't think there is an issue there either. I did also want to create a very slow clock for testing, i.e., as slow as 2Hz so that I can watch the CPU operation at a manageable speed. I had planned on doing this by further dividing the 2Mhz clock by 1000 to give 2khz and then by a futher 1000 to give 2 Hz. The functional simulation seems to suggest that this will work, but the delays are way too long for TimeQuest to be able to make sense of. (The clock periods come out as a number bigger than TQ can handle). Other than being able to run a timing analysis, is it reasonable to do this, given that there will be no internal clock comms ? Thanks again for your help (and patience) regards Dave
