exxos's Atari, Amiga & retro forum

mfro wrote: 05 Aug 2019 14:24 From what I understand (from variable names etc.) this is the Suska implementation of the blitter?

Yep.

mfro wrote: 05 Aug 2019 14:24 As this works fine in the Suska board itself, I would assume the problems have something to do with the integration of the IP core.

I don't think it does though. If you look at suska benchmarks its scores seems to suggest its more running like a 16MHz machine.. and blitting ends up like 200% over a stock machine to start with (with blitter disabled) So your starting from in effect a 200% blitting speed.

Now turning the blitter on... so if you take 600% as suska blitting score and drop it down to a 100% base line CPU speed, it means the blitting test is half of 600% , 300% which is what we see. So in both cases there seems to be a 50% discrepancy in the blitter tests.

exxos wrote: 05 Aug 2019 14:54 ... If you look at suska benchmarks its scores seems to suggest its more running like a 16MHz machine...

Yes. You did recognise that the Suska RAM is clocked at 32 MHz?
Without looking into details, I would assume the core needs some adaption if transplanted to a machine with much slower RAM?

mfro wrote: 05 Aug 2019 14:58 Yes. You did recognise that the Suska RAM is clocked at 32 MHz?
Without looking into details, I would assume the core needs some adaption if transplanted to a machine with much slower RAM?

That is what we are looking at now. We see ROM related tests are close to 100%, but more RAM related tests are not. Icky and I already talked about this via email a lot and I worked out the core would need to be running at least 28.5MHz to get to 100% speeds. But the bus access is still being synced to 8MHz... you can't run the suska core at 32MHz as is screws up the 8MHz bus access... So it would need 2 clocks to work.. and a huge code re-write. Either way, the code for it is like I said before, it just to slow to work at 8MHz. So we need Ijors core to try.

exxos wrote: 05 Aug 2019 15:09 But the bus access is still being synced to 8MHz... you can't run the suska core at 32MHz as is screws up the 8MHz bus access... So it would need 2 clocks to work

just to clarify, the BLiTTER is clocked with 8Mhz but the bus is 4MHz, but only every other cycle is granted.It means that we have 4 cycles for one bus access

Does anyone knows how to patch the suska code to work properly on the ST ?

Cyprian wrote: 05 Aug 2019 15:39

exxos wrote: 05 Aug 2019 15:09 But the bus access is still being synced to 8MHz... you can't run the suska core at 32MHz as is screws up the 8MHz bus access... So it would need 2 clocks to work

just to clarify, the BLiTTER is clocked with 8Mhz but the bus is 4MHz, but only every other cycle is granted.It means that we have 4 cycles for one bus access

This is true.

But if you look at the Suska blitter core (wf101643ip_top_soc.vhd), you can see that processes operate on both clock edges of the 8 MHz clock (probably some wouldn't call that proper synchronous design, but that's how it's done for now), effectively doubling frequency.

Of course you can't do 'outside' bus cycles at 'odd' edges, but you can do other things internally.

Maybe it helps when we examine what the blitter really does:
For each blit cycle and depending on the intended operation, worst case it needs to read the source word, read the destination word, do the logic op and write the destination word. It can't do memory accesses any faster than the CPU as it is bound to the same bus protocol and speed.

Now, why is it faster than the CPU doing the same?

- It does not need to read instructions from memory inbetween
- Skew requires a shift on the source data. the 68000 is very slow when shifting, the blitter can do this (barrel shifter) any width in a single cycle.

If you want that blit cycle at maximum speed, you need to align the memory accesses together as close as possible and try to fit internal operations (source skew shifting, halftone logic op, logic op and endmask masking operations) in between.

I would assume this is not optimal in your implementation. Maybe/probably you need to clock the blitter internally at higher speed (not a real problem, since your FPGA has probably unused PLLs that can provide that clock) to gain additional clock cycles for this internal operations.

Icky is working on just that. We are trying to clock the core at 32Mhz and clock the state machine (8MHz access) to still be a 8MHz clock.

Technically I did this with a real blitter years ago during booster work. I clocked the blitter at 16MHz when not accessing the bus. it gave 1% higher speeds, but its to be expected. But based on that, we could clock the suska core at 100mhz and it shouldn't really matter.

I still think its just the inefficiency of the code causing the requirement for a faster clock. I doubt the compiler can beat a pure logic design.

exxos wrote: 06 Aug 2019 08:26 Icky is working on just that. We are trying to clock the core at 32Mhz and clock the state machine (8MHz access) to still be a 8MHz clock.

I would just clock the complete blitter (including the bus logic state machine) with 32 MHz. Then make sure signals going to the 8MHz side are kept stable for 4 (or whatever clock multiplication factor you have) clock cycles. Otherwise you'll likely run into lots of unnecessary headaches with clock domain crossings.

exxos wrote: 06 Aug 2019 08:26 I still think its just the inefficiency of the code causing the requirement for a faster clock. I doubt the compiler can beat a pure logic design.

No. 'Pure logic design' ist what synthesis generates. It can't do anything different than what you tell it to do, however.

If I understand correctly, you basically took a state machine designed for 32 MHz memory bus speed and transplanted it into a design where RAM needs four times longer to respond. You can't possibly expect the compiler to somehow 'magically' rewrite your state machine to adapt to this severely modified conditions?

mfro wrote: 06 Aug 2019 09:15 If I understand correctly, you basically took a state machine designed for 32 MHz memory bus speed and transplanted it into a design where RAM needs four times longer to respond. You can't possibly expect the compiler to somehow 'magically' rewrite your state machine to adapt to this severely modified conditions?

When talking to Wolfgang he said it was a "drop in replacement" so I literally took it as that. I did not know at the time that was incorrect and it was designed for a 32MHz bus. So no, I don't magically expect it to work, we are not stupid!