FPGA Replay Board

[mikej]

Yes Xc3s1600.
I am shipping one for to Daddy for the x500 case.
I am having problems getting enough 68060s of the correct mask set for the daughterboard. I am going to have to screen at the supplier, many of the chips are re-printed.
/Mike

[cunnpole]

A lot of us would be more than happy with just the base board. I'll probably want the expansion board when it's ready (not currently fussed about the 060, just the extra ports), but i'd be happier to wait if it meant i got the base board sooner.

It would be shame to see the base board held up further due to focus on the addons. Is there a technical reason why the button hasn't been pushed on mass production yet? Is there a fear that the addon board may require physical updates to the base board?

Sorry if this comes across as impatience, I'm just excited about getting my grubby mitts on one.

If the holdup is now a distribution problem I guess I'm not the only one that would be ok to buy through the path of least resistance (good faith gentleman's agreement with blatant disregard for consumer protection red tape).

[mikej]

I agree and I've decided to push the base board into production ahead of the daughter board.

The main reason for late shipping is low yield on the 50 production boards I had made in China. I needed to work out what was wrong with these  before making more.

There are two concerns.
1 - Backfeed through DVI. This was corrected in the B boards with a special regulator to the DAC. There is still some leakage and I need to make sure the additional load of the daughterboard would not fry anything.
2 - DRAM timing issues. The current core uses fixed timing and this does not work across a large run of devices. The new DRAM controller requires some software config and training, so this got tied up with the complete ARM code rewrite.

The ARM code is now up and running again. It is not universal yet (as in suitable for booting other platforms) but getting there.
I have just ordered most of the components and if my final memory testing goes well this weekend I'll get more boards assembled. Hopefully the 30 or so I have on my bench will also work fine with the new code and can be shipped.

Cheers,
Mike

[Darrin]

Yes Xc3s1600.
I am shipping one for to Daddy for the x500 case.
I am having problems getting enough 68060s of the correct mask set for the daughterboard. I am going to have to screen at the supplier, many of the chips are re-printed.
/Mike

If 68060s are turning into rocking horse poo then I'm sure some of us would be happy with a 68040 on the daughterboard.

[mikej]

I have no problem getting 68060's at a good price, just not the correct mask set.
I have 20 "fake" ones
So, plan is to get a tester down at the disti in shenzhen and screen every device.

I am looking at an adapter board which will fit in the pins of the 68060 daughter board and carry either a 680x0 or a much faster Virtex7 class FPGA running a soft CPU.

Full speed ahead chaps ....

[wawrzon]

@mikej
do you know how to identify the correct mask? i think there was a copyback issue that the previous mask were not capable of carrying up properly.

as for softcore in fpga, do you think this can be concurrent to a 060 already? has tg68 been worked on further, since tobias has given up? this is really a sad story this development has practically been killed by natami hype..

[Darrin]

I have no problem getting 68060's at a good price, just not the correct mask set.
I have 20 "fake" ones
So, plan is to get a tester down at the disti in shenzhen and screen every device.

I am looking at an adapter board which will fit in the pins of the 68060 daughter board and carry either a 680x0 or a much faster Virtex7 class FPGA running a soft CPU.

Full speed ahead chaps ....

Cheers for the update Mike.

Don't forget to release the new core to us betatesters.  

[mikej]

@mikej
do you know how to identify the correct mask? i think there was a copyback issue that the previous mask were not capable of carrying up properly.

as for softcore in fpga, do you think this can be concurrent to a 060 already? has tg68 been worked on further, since tobias has given up? this is really a sad story this development has practically been killed by natami hype..

We are just reading the product code register which contains mask revision. If you have any data this is not reliable I would love to know about it.

The TG68 is still being developed, I am also running some tests.
I have my own core which is smaller and faster, but I have not had time to work on it for a while. These are both 68020 (lacking MMU and FPU) but can run faster than a 68060.

/Mike

[cunnpole]

I'm loving the idea of a stonkingly fast 020 softcore (further down the road at least).

I guess it'd make upgrades easier when new fpgas become available?

Would it be technically possible for this approach to provide more fast ram too (not that I need it)?

[Darrin]

The TG68 is still being developed, I am also running some tests.
I have my own core which is smaller and faster, but I have not had time to work on it for a while. These are both 68020 (lacking MMU and FPU) but can run faster than a 68060.

/Mike

That would be nice!

[Darrin]

I'm loving the idea of a stonkingly fast 020 softcore (further down the road at least).

I guess it'd make upgrades easier when new fpgas become available?

Would it be technically possible for this approach to provide more fast ram too (not that I need it)?

The daughterboard contains extra RAM (128MB IIRC) which will add to what we already have on the main board.

[wawrzon]

We are just reading the product code register which contains mask revision. If you have any data this is not reliable I would love to know about it.

no, not that i knew. likely your method is good enough, why shouldnt it work?

The TG68 is still being developed, I am also running some tests.
I have my own core which is smaller and faster, but I have not had time to work on it for a while. These are both 68020 (lacking MMU and FPU) but can run faster than a 68060.

/Mike

good to hear! even though im not in a customer range as long as there is no fpu, even better some sort of mmu.

[matthey]

@mikej
I think there was a copyback issue that the previous mask were not capable of carrying up properly.

Nothing to do with caches. It's probably a data register forwarding issue/bug that you are thinking of. The store-load bypass needs to be turned off on all full "RC" 68060 masks except 0E41J (Rev 6). This bug is unlikely with properly optimized code. It can only happen when writing a data register to memory as a longword and immediately reading it back. There is an easy solution that doesn't affect performance much. There are 21 known bugs in a 1F43G mask, 20 in a 1G65V mask and 0 in a 0E41J mask. Most of the bugs are minor or have workarounds.

We are just reading the product code register which contains mask revision. If you have any data this is not reliable I would love to know about it.

Product Code Register? You must mean "Processor Control Register". Yes, that's a good way to get the 68060 Revision Number. When the Chinese are sophisticated enough to change the PCR revision number, they might as well make us some new 68060 processors .

[xyzzy]

A 68EC060 should work fine, shouldn't it? You might be missing the MMU and FPU but you still have the TTR registers to map out cache-inhibited regions and also FPU emulation libraries.

As far as I am aware, the resolution of the TTR registers is 16MB minimum, so the best scenario would be to map the lower 24 bits of address space, including chipram and custom chipset registers as cache-inhibited, serialised access.

Fortunately since the hardware is very flexible we can map all the other nice fast ram outside that range and mark it as fully cached and copyback enabled.

[kolla]

Didn't 68060 require MMU to be useable for AmigaOS? I seem to recall that there was some requirement for the 68060.library variants to work.

[freqmax]

Asfair, 68060 has builtin MMU so why would it not be available?