Using the Falcon's expansion connector

[frank.lukas]

When I had a chance to beta test I mod a nova falcon so it´s fit ...

[mpattonm]

Co-incidentally I was able to run happily at 43 MHz yesterday, but not 48.

Consider yourself lucky. Plastic case 68030s can typically be overclocked to 40MHz max. Ceramic CPUs can go above 50MHz, rarely up to 60MHz with proper coolong and not for long.

[Badwolf]

Co-incidentally I was able to run happily at 43 MHz yesterday, but not 48.

Consider yourself lucky. Plastic case 68030s can typically be overclocked to 40MHz max. Ceramic CPUs can go above 50MHz, rarely up to 60MHz with proper coolong and not for long.

Ah no, I'm using a ceramic for > 40. That photo was the old Rev 1 to demonstrate the long pins.

My issues are (and all my recent research is) with getting SDRAM to work at rated speed > ~43 MHz.

Basically, if I have a one cycle delay on initiating the SDRAM cycle, it's stable at 48 but not 50. If I try to claw back that extra cycle (more complex logic), it'll run at 43, but not 48. Everything points to my bad HDL code being too slow.

I generate the CPU and RAM clock on the same CPLD that's doing the SDRAM driver, so I've been at a loss on how to set up the timing constraints.

I plan to play with a few different approaches (my next attempt will be to start an SDRAM bus cycle for every assertion of /AS but only assert /STERM if the address decodes as AltRAM) for a while then either:

* build a separate piggy-back SDRAM board with its own CPLD for experimentation, or
* wrap in all the lessons learned to date and spin a new board revision and publish. It'd have 'slow' SDRAM and a stated max speed of 48MHz, but the community might be able to improve it with faster firmware.

The second option seems the most attractive so far.

BW

[mpattonm]

That sounds great. I do not have much details, but maybe it would also be benefitial to re-align both memory chips on PCB, so their RAS/CAS and data line tracks are of constant lenght. I mean @50MHz this is not yet critical, but it is already something to consider.

[Rustynutt]

When I had a chance to beta test I mod a nova falcon so it´s fit ...

Don't go anywhere and hold that thought

[Rustynutt]

Hello Badwolf, please desgin your Falcon speeder such a Falcon Nova Graphiccard Adapter can fit on top.

Side note:
Have used the NOVA/ATI on both Mighty Sonic and Afterburner at speeds up to 44/22 reliability. Never was able to go higher, but that wasn't due to the NOVA adapter.
Both accelerators had identical clock ceilings, and both used the same type MACH chips. Simms were 60ns, both used MC88916 CMOS PLL clock drivers. No DSP issues.

Co-incidentally I was able to run happily at 43 MHz yesterday, but not 48. Very similar limits, but I can't see why -- I doubt there's anything in common.

Not sure about Nova card, by the way. If there's room to put piggyback expansions on top, then it could be done (although not a priority), but whether anything is compatible is another matter. One option for those who want to piggyback would be to use long-pinned sockets when building the board, like I had on the rev 1.



BW

Here's a message from Doug Little, likely around 1999.
Need to see if he'll respond to some questions I've come up with now that much time has passed, and an effort to resurrect the AB in all it's glory.
Surely, he's added a few more ground wires to the aluminum foil shielding around the AB bus control and Nemesis clock lines

Actually, JoEven I think still has contact with a few of the AB users that were active at that time. Geir, Peter and Guillermo come to mind, but there were many others. This kind of all predates how you are integrating the 030, but the circuitry is relevant.

Just learned how to "insert code", why doesn't word wrap work?

and I quote (hopefully he doesn't mind)

Code: Select all

I take that back! :-D

I just replaced all of the capacitors on the Falcon PSU with low ESR versions and slightly higher values (68uF vs 33uF for the 400V, and 1500uF vs 1000uF for the output filter caps).

The Afterburner is now burning running at 48MHz for the first time and is able to complete a Nembench test... I should probably now look at a PicoPSU to replace it with.

One of the things that I have been wondering about on the Afterburner is the lack of bypass capacitors on the board. I can only see a single SMT ceramic near the cpu. There might be more under the CPU - I don't remember looking when I swapped the chips. But there are 9 big ICs on there and it seems to be relying on ground/power plane capacitance or the Falcon mainboard, and that's on the other side of the expansion port.

Anyway I'm thinking of adding a tantalum & ceramic cap on the underside of the AB at the expansion port where the power comes through, to see if it helps the board at higher frequencies.

I'll also replace the mainboard 4700uF cap while I have access to the board.

Will report back if I find out anything useful.

[UPDATE]

One of the chips on the Afterburner board is 'MC88915 FN 70' which is a PLL / clock doubler intended for driving the PCLK of a 68040 CPU. The '70' signifies a maximum operating frequency of 70MHz (or 35MHz x 2) so it's only just rated for a 32MHz 68040. It probably doesn't cope well as the BCLK approaches 50MHz (PCLK >= 100MHz). I have also noticed this chip gets warm at BCLK == 40MHz. It is probably the limiting factor on the board.

[Badwolf]

Here's a message from Doug Little, likely around 1999.

Thanks for this -- but there's a lot of difference between an Afterburner 040 and my, pretty bare-bones, board.

Mine is much more like (ie. it uses virtually the same hardware) a Terriblefire 536. The TF536 works at 50MHz, so therefore mine should be capable of it.

The difference is Stephen Leary knows what he's doing in terms of board design and HDL whereas I'm a physicist-cum-computer programmer who did a bit of board design as part of a work experience placement when I was 17 and had never seen verilog until last year!

That accounts for the memory speed issues I think and is a problem that can be crowdsourced away down the line.

The DSP issues (the only other real outstanding item of concern) are entirely down to me not knowing how the DSP works nor how to test it and is likely to remain on hold until I'm happy with the memory.

BW.

[Rustynutt]

Here's a message from Doug Little, likely around 1999.

Thanks for this -- but there's a lot of difference between an Afterburner 040 and my, pretty bare-bones, board.

Mine is much more like (ie. it uses virtually the same hardware) a Terriblefire 536. The TF536 works at 50MHz, so therefore mine should be capable of it.

Fully acknowledge this.
The idea was even unsuspected/suspected but not tested/suspected but pass on could cause some timing issues. You are virtually on a nats behind there, to the point is a single connection to your analyzer flubbing up timing
That was all.
What interest me is the old devices hardwired to the GALs are able to perform at the speeds they do even with flywires.
Obviously, the CT shows it's possible to do this on chip, as with the work you are doing, it's complicated for the average enthusiast. Some of us are senior citizens

[Badwolf]

What interest me is the old devices hardwired to the GALs are able to perform at the speeds they do even with flywires.
Obviously, the CT shows it's possible to do this on chip, as with the work you are doing, it's complicated for the average enthusiast. Some of us are senior citizens

Yes, I think the problems are in my HDL now*.

Too many gates between input and output means it misses timings. I don't understand the system well enough to implement proper timing constraints and what I instinctively think of as being quicker may not always be.

This is a pretty stereotypical result when computer programmers do hardware description languages!

My current mindset is to keep experimenting with the HDL to try and find a *properly* stable configuration at 48MHz (was still getting a couple of memory errors last night) and work on the rev4 board in the background. If rev 4 needs 2 or fewer patch wires, then it'll be beta quality and I can start crowdsourcing HDL.

That's the theory anyway

BW

* Although I hope to be getting my first >10MHz oscilloscope so I may be able to rule out clock trouble, finally!

[Mindthreat]

Fun thread, cool to see! Congrats on progress, looking forward to seeing everything else =D

[qq1975b]

Impressive and promising!

[Rustynutt]

What interest me is the old devices hardwired to the GALs are able to perform at the speeds they do even with flywires.
Obviously, the CT shows it's possible to do this on chip, as with the work you are doing, it's complicated for the average enthusiast. Some of us are senior citizens

Yes, I think the problems are in my HDL now*.

Too many gates between input and output means it misses timings. I don't understand the system well enough to implement proper timing constraints and what I instinctively think of as being quicker may not always be.

This is a pretty stereotypical result when computer programmers do hardware description languages!

My current mindset is to keep experimenting with the HDL to try and find a *properly* stable configuration at 48MHz (was still getting a couple of memory errors last night) and work on the rev4 board in the background. If rev 4 needs 2 or fewer patch wires, then it'll be beta quality and I can start crowdsourcing HDL.

That's the theory anyway

BW

* Although I hope to be getting my first >10MHz oscilloscope so I may be able to rule out clock trouble, finally!

Guess the people that worked on the old projects have long moved on. Never seen anyone from GE Soft on the English forums every really chime in even as far back as 93, when most of the conversations were on usenet or maus net for that matter.

Rodolphe Cubza is the exception.
He actually has quite the sense of humor, though sometimes it's lost in translation. Asked the right questions, he always replies.

[alexh]

If you wanted to share the HDL for your design (perhaps privately) I could advise on the coding style and suggest pipelining techniques to reduce your combinatorial logic depth.

I probably won't be able to comment on the functional design as I don't remember enough about the 680x0 bus.

Same goes for your timing constraints, happy to talk through them with you.

I have been a VHDL/(System)Verilog designer for 20+ years.

[Badwolf]

If you wanted to share the HDL for your design (perhaps privately) I could advise on the coding style and suggest pipelining techniques to reduce your combinatorial logic depth.

I probably won't be able to comment on the functional design as I don't remember enough about the 680x0 bus.

Same goes for your timing constraints, happy to talk through them with you.

I have been a VHDL/(System)Verilog designer for 20+ years.

Thanks, Alex. That'd be very kind. I'll definitely take you up on it, if I may.

It's absolutely my intention to publish it all once I've something that's repeatable, I just don't want to put out there something that I know can only possibly work on one board as of now.

Right at this moment I've a setup that is actually pretty stable at 50MHz with a five CPU clock read cycle (although it *should* be four...) but it's entirely by luck and I've yet to understand why. It works when my RAM clock is delayed by pi/2 from the CPU clock. Doesn't work if they're in phase, doesn't work if they're in anti phase (how I designed it). It's only pi/2 through the vagaries of the synthesis, not design! When I optimise for speed, they come into phase and it stops working. Very odd.

I need to understand how to specify my time constraints properly in ISE -- I've been trying and failing. Timing is the Wild West at the moment (see above!).

Cheers,

BW.

[mfro]

That really sounds like a sole matter of missing/wrong timing constraints.

[Badwolf]

That really sounds like a sole matter of missing/wrong timing constraints.

I can guarantee it’s a problem, as the contraints I added were doing precisely nothing (I clearly didn’t know how to specify them), so I removed them!

Whether it’s the sole problem? I very much hope it is.

I want to add constraints based out output clocks rather than input ones and that doesn’t seem to work. Perhaps From-To constraints is what I need.

Anyway, I’m going to go through and comment my verilog, then take up @alexh on his kind offer.

BW

[sporniket]

Do you have a testbench that would allow to spot this troublesome behaviour ? I am aware that it could be very easier said that done.

[Badwolf]

Do you have a testbench that would allow to spot this troublesome behaviour ? I am aware that it could be very easier said that done.

I've a (very simple) verilog simulation for a few randomly timed memory accesses, which seem OK to me, but nothing for the whole project. That would involve thousands of variations of input sequence, unfortunately.

I've zipped up a commented ISE project and will message Alex. This one *almost* works in 'Speed' optimised mode, but not as efficiently as a far sloppier branch in density mode! I'm guessing the planets just happen to align for that other one -- perhaps that one is simply so slow it's actually operating on the next cycle

Still can't figure out how to specify meaningful timing constraints. The key problem with that seems to be that I'm synthesising my own clocks my multiplexing a 'fast' one and the Falcon one, rather than driving everything from an external clock.

BW

[Badwolf]

Ha, this is crazy.

The 'speed' optimised version of the code I've sent Alex *almost* works -- Gembench will run to completion, the desktop's fine but it can't boot MiNT and Doom hangs. Everything looks OK on the scope, though.

Change it to 'density' optimisation and it works wonderfully!

IMG_4123.jpeg

IMG_4126.jpeg

So, what's going on?

My design produces two separate clocks, one for the CPU and one for the RAM (as my original intention was to clock the RAM at a fixed frequency and vary that of the CPU -- that hasn't come to pass for probably related reasons: they're basically outputting the same register now). When optimised for speed, they're beautifully in-phase. Less than a 1ns delay over a 20ns period. This doesn't work. Neither does anti phase (for no reason I can deduce -- anti phase should be the optimum).

But when I relax the optimisation by selecting density mode the ram clock, by happy co-incidence, gets lazily driven and lags the CPU clock by almost exactly a quarter phase.

IMG_4124.jpeg

This seems a nice compromise between me triggering signals on the clock falling edge (to be valid on the clock rising edge) and the CPU sampling on its falling edge. This is not what I was expecting, but does seem to be very stable indeed. So much so I'm considering running a 100MHz clock and deliberately phasing the clocks.

But we'll see what happens when I make further changes to the HDL, it could completely mess up that happy timing accident and we be back to square one. Before I got my 1 GSa/s scope, I had *no* idea what was happening here as my logic analyser wasn't accurate enough. So whilst I still don't understand it (and still have *no* idea how to constrain these times formally), I can now, at least, see WTF is going on!

Getting closer to a rev4 now, at least.

BW

[alexh]

I've got a deadline of Thursday for some work. But I'll set aside Thursday evening to take a good look.

Traditionally FPGA designs work much better if you use a single clock and if you need slower rate logic use a clock enable.

Code: Select all

always@(posedge cpu_clk or negedge reset_n)
begin
	if (~reset_n)
	begin
	end
	else if (ram_clk_en)
	begin
		// Slower logic here
	end
end

The FPGA synthesis tools will notice this code and do clock gating, use the CE pin on the flops rather than 2x clocks, making timing much better.

I am sorry if this is too basic, I can have a look at how you're recovering / generating your clocks and generating and resampling your I/O on Thursday.

ijor on this forum is also a HDL expert with extensive knowledge of Atari designs and FPGA work. He created the cycle accurate recreation of the Atari ST.

P.S. I've got Xilinx ISE 13.3->14.7 (all installed as different installations) plus Vivado 2012.4 -> 2020.2. You never know when you'll come across a device or a set of scripts from an older project.

[Badwolf]

I've got a deadline of Thursday for some work. But I'll set aside Thursday evening to take a good look.

Thanks, I appreciate it.

Traditionally FPGA designs work much better if you use a single clock and if you need slower rate logic use a clock enable.
<snip>
I am sorry if this is too basic, I can have a look at how you're recovering / generating your clocks and generating and resampling your I/O on Thursday.

No, not too basic at all.

In fact, not basic enough as I can't quite see what you mean, I'm afraid!

Are you saying effectively synthesise a slower clock by turning the faster one on and off?

What I have at the moment is the main oscillator clock and the Falcon's on-board clock. Call them CLK50 and CLK16, say.

Basically, when my board has to talk to the Falcon it drops everything (including the RAM as it wasn't stable when I didn't) to match CLK16, otherwise it runs at CLK50. To do that it uses a double-flip-flop multiplexer to avoid clock glitches. Obviously this creates a substantial offset from the oscillators so my timing edges are derived -- this output -- rather than an input pin.

ISE doesn't seem (or at least I haven't found a way) to allow me to set constraints against such a derived clock.



It's not all bad news, though. The bit of tidying up I've done of the last day or two has actually allowed me to shave one cycle off my memory access, so I'm now actually hitting my speed targets! Of course, it's still all by accident with this inadvertent 5ns delay on the RAM clock versus the CPU clock.

BW.

[alexh]

Are you saying effectively synthesise a slower clock by turning the faster one on and off?

No. You use the faster clock but gate the logic transitions with the enable. Depending on the enable you can produce logic which is synchronous to the faster clock but transitions at a fraction of that clock. The effective rate depending on the nature of the enable.

I have to see the techniques you're using. And the capabilities of the clocking primitives in the CPLD you're using

[Rustynutt]

Have either of you guys looked at the delay of the COMBEL clock divider from the 32mhz input to 16mhz output?
Assuming there must be some.
Thanks.

[Badwolf]

No. You use the faster clock but gate the logic transitions with the enable. Depending on the enable you can produce logic which is synchronous to the faster clock but transitions at a fraction of that clock. The effective rate depending on the nature of the enable.

I have to see the techniques you're using. And the capabilities of the clocking primitives in the CPLD you're using

I think I understand in principle, I'm not sure how I'd go about applying it exactly, but I'll try to bear that in mind if I do a respin of the HDL.

Thanks,

BW.

[Badwolf]

Have either of you guys looked at the delay of the COMBEL clock divider from the 32mhz input to 16mhz output?
Assuming there must be some.
Thanks.

Hi Rustynutt,

Not sure what you're getting at here. Looked at the delay with an eye to what? The delay in me responding to the existing 16MHz clock is of the order 20ns when the clock is 62ns in period, so none of these timing issues apply at the speed the COMBEL is dishing out.

Timing only becomes an issue because the clock speed is higher (I have 20ns [sometimes 10]) to complete some transitions at 50MHz. The slower it runs, the less it's an issue.

Anyway, I suppose I should give a quick update from the weekend.

* Full speed SDRAM access is now working (by happy chance, nothing more) yielding AltRAM read benchmarks of ~24MB/s.
* Burst mode caching has been show to work at 4 cycles of caching (brings it up to ~30MB/s), but isn't stable.
* Two cycle burst mode seems stable as a compromise (~27 MB/s).

Like-for-like comparison (EmuTOS no blitter, stock machine is 100%):

IMG_4134.jpeg

And just for a test I disabled the on-board ROM and put TOS 4 in the motherboard. You have to run NVDI if you want to use TOS4 because you can't disable blitter and blitter + AltRAM doesn't work, so don't worry about the absolute times, it's the relative that's important -- and the fact it works at all.

IMG_4140.jpeg

If anyone would like to have a go at patching TOS4 to have software blitting, I'd be grateful!



I think my next step, pending feedback from Alex, is to try building another version of this board to try to prove it's not a one off, then it'll be onto rev 4.

IMG_4141.jpeg

BW