Just a background on my setup before I get into the issues I'm having.
There are 3 parts, the CY8CKIT-042 Pioneer Kit
This is hooked up to 1 ( eventually 2 ) Xilnix XC9572XL CPLDs ( the dangerous prototype's dev boards ) 10ns pin to pin.
It/Those are then connected to a Commodore 64 Computer. For those who were born post 1990 it is a 1Mhz 8bit computer with 64KB of RAM using the 6510 processor which is a custom variant of the 6502.
Although it is 1Mhz the CPU runs at 2Mhz but is only active for half the time ( 470~500ns ) so the timings are 2Mhz but it only does stuff for 1Mhz of those 2. The VIC chip takes the other half.
My theory was 1Mhz VS 48Mhz the 48Mhz will be able to easily outfox the 1Mhz and I will have no worries doing anything before the 6510 catches me. So far not so much.
The 64 has a Dot Clock of 7.88Mhz ( PAL ) which is /4 to get the two 2mhz phase clocks. I use the Dot Clock to Clock the CPLD side that talks to the C64. So the CPLD sees and talks in terms of 7.88mhz pulses.
I want to use the ARM to be able to feed 28bits of data down to the CPLD for it to use when perfroming operations on the C64 and then sometimes pull back 8bits .16bits Address and 8 Bits data and probably 4bits of contol lines. Once the CPLD detects the C64 saying "Do something" it will fire a 1 7.88mhz pulse at the ARM (~125ns) .To which the ARM should trap and then respond with more instructions. Ultimatly forming something like this CPLD ARM
Do This take over, addr, data ,write done addr, data, write done addr, data, write done stop
Where done to done is about 1000ns the addr has about 470ns to get set up and the data has about 800ns to set up.
I have tried using a simple loop of
Branch Equal to Zero -1
When I would attemp to count 4 'done' the CPLD had actually said 'done' 16 . so it seemed the ARM was missing the pulses. I put the ARM into release mode, and turned all the optimsations to max. I wasn't happy with the ASM so I worked the C code until I was resonably happy. Given the ARM has 6 clocks for each Dot Clock, and 24 clocks for each 6510 clock, and has 48 clocks per 64 clock.
I then tried Interupts. 3 happen per 1 desired in this case, which has a knock on effect of starting the loop again and again and again.
How should I do this, what is the right way?
Welcome in the forum!
I am afraid that interrupts will need too many clock cycles.
Another approach could be to use UDBs for the handling. Programming can be done in VeriLog, Max frequency of the UDB is 48MHz and there is some programmable logic and a tiny programmable ALU inside.
The UBDs might be able to handle some of the work, I was thinking to push/pull data down/up I could use the built in FIFO blocks and then have the CPLD pulse them for the data over a shared 8bit bus. However the data that goes into the FIFO still needs to come from/go to the ARM and SRAM, so I will need a solid way to get the ARM to react, can the UBDs help with that?
Each UDB has got registers where the CPU may write to or read from. You may define signal sets to connect to pins, additionally the pin-component has got OE-inputs which can be handled by UDB.
There are some (2) "Cheat Sheets" for the UDBs which are very helpful seeing which operation with which registers are valid and what internal paths for the data exist.
And: No, not VHDL, but VeriLog. Quite easy to understand....
Ok, looked through the documents. The give solid detail on each pecee, but for the put it together tutorials it is 'Here is the premade component and you call the handy C function it makes for you', so I'm not quite sure how you set them up to talk to each other properly yet, but to make sure I'm on the right track this is what I can see as a potential use.
So I would turn one of the PLD blocks into a SR , then the input pins from the CPLD would then Set it. And the CPU polls the output of the SR to know when it is wanted? Once wanted it would Reset the SR. This would mean it won't "miss" a request but it would seem that it would add a lot of delay, is that true?
Maybe a PSoC5LP chip might be better? 80MHz and better instruction set.
If not, then you might consider an ARM from another vendor. It's obvious that every microcontroller chip in the world isn't a perfect match to do everything, and no chip vendor can claim their product can do everything either. If something doesn't meet your requirements, then find another ARM that does meet your needs. https://en.wikipedia.org/wiki/Template:Embedded_ARM-based_chips