DFB1r4 design discussion thread

[Badwolf]

Question for the CPLD aficionados:

The three Global Clock pins on the XC95XLs: are they best used for clock inputs or clock outputs?

I'm going to have the following:

• Oscillator in
• Falcon Clock in
• 500kHz in (not really a clock, more a fixed freq counter)
• CPU Clock out
• RAM Clock out
• FPU Clock out

My last design had all in the input clocks routed to the GCLK pins but when trying to work out the ISE TIMESPEC commands, this didn't seem particularly useful, except for maybe the Falcon Clock line where being able to specify the maximum delay between that line and (say) the mobo's address strobe made sense.

I was thinking therefore it might be better to route the output clocks to these pins to be able to specify tighter specs for the synchronous stuff (like the RAM)?

Am I right this time? Right the first time? Is it irrelevant?

Cheers,

BW

[exxos]

IIRC global clock pins go to each logic block internally. So you can assign clocks to stuff without it taking up parts of the arrays . it may help with timings and keep things a fraction smaller if your pushed for space.

[Badwolf]

IIRC global clock pins go to each logic block internally. So you can assign clocks to stuff without it taking up parts of the arrays . it may help with timings and keep things a fraction smaller if your pushed for space.

So I'm thinking clocks that'll appear in multiple dependencies?

That'd be the Falcon's clock (input), the CPU clock (output) and the RAM clock (output).

Annoyingly they're on three different sides of the CPLD and the pins are all in the same corner. Grr!

BW

[exxos]

This is the ATF1508 I use mostly.. You can see the GCLK (global clock) at the bottom and that its on a "global bus" between all logic cells.

Capture.JPG

A breakdown of a cell.. See global bus at the bottom..

2.JPG

I guess you have to imagine global clocks as going to every flipflip in the PLD. Its hardwired , so doesn't take up much space.

OTOH, if you used a different clock input, the compiler would have to route that to every cell its used on..

Take the humbal 22V10 layout..

3.JPG

Now imagine the chaos to route clocks to cells via this array..

Note pin 1 is the global clock pin on the 22V10..

4.JPG

The path from any input pin to a cell Can quite literally be chaos across the array.. Add in a few more clocks to various "random" cells and you end up with a right sh*t sandwich :lol:

So using the global clock pins pretty much means the routing is "free" as its already hardwired across the global bus.

[Badwolf]

Mmm. Thanks.

So my thinking is it doesn't make much sense for me to route the main oscillator to a global clock because it only gets broken down and fed to other pins.

*Those* pins feed my various flip-flops across the CPLD, so making sure those pins are the global clocks might yield better fabric use/timing tightness.

I'm going to spin my chip through 90 degrees and change it round then, I think.

Screenshot 2021-08-10 at 22.03.09.png

Not the end of the world, a few reassignments in the schematic and a couple of the clock tracks relaid.

Cheers,

BW.

[exxos]

So my thinking is it doesn't make much sense for me to route the main oscillator to a global clock because it only gets broken down and fed to other pins.

*Those* pins feed my various flip-flops across the CPLD, so making sure those pins are the global clocks might yield better fabric use/timing tightness.

I don't use the global clock much. Though you can always feed in 100Mhz into GCLK0, downclock to a pin and output back to GCLK1 input etc. Then GCLK1 will be 50Mhz which can feed directly all your FF's. The roundtrips will help with noise immunity and with complex designs it will help to keep the compiler happier.

[Badwolf]

I don't use the global clock much. Though you can always feed in 100Mhz into GCLK0, downclock to a pin and output back to GCLK1 input etc. Then GCLK1 will be 50Mhz which can feed directly all your FF's.

*nods*

I'm not sure you have to physically route one out to one in, do you? The timespecs seem happy writing directly to the GCK pin and yet you can still use it as a clock source.

Anyway, hoping the above is true, I think this is all the upstairs stuff routed. Touch wood, I probably could have got away with a slightly tighter footprint after all

Screenshot 2021-08-11 at 20.04.37.png

Started getting a bit squiggly as I decided to route some traces where I think they'll be close to others in the equations. Hope that helps in the long run.

Now for the "birdseed", the regulator, etc. :?

BW

[Badwolf]

The Mona Lisa, it is not.

Screenshot 2021-08-11 at 23.05.47.png

Next: DRC...

BW

[exxos]

Looks good to me :)

[Badwolf]

Passes DRC. Need to do an evening or so of sanity checking & feeding the new pin assignments into ISE to make sure it'll build before ordering.

Top:

Screenshot 2021-08-12 at 13.06.04.png

Bottom:

Screenshot 2021-08-12 at 13.37.31.png

Power:

Screenshot 2021-08-12 at 13.39.19.png

I've made a couple of design decisions differently to my other boards which may be dangerous, though.

There are no debug headers. This saves a lot of space and hopefully improves signal integrity, but will make bringing it up harder, obviously. This is a gamble that I'm getting close to a release version.

I've removed some pull-up resistor packs. A[31:24] and A[0] (ie. the address lines not pulled up by the motherboard) were all pulled high with resistor networks before. I've noticed the TF534 doesn't seem to need these, though so I'm rolling the dice.

I did bottle out of not pulling up D[15:0], though, as I think my second choice level shifters probably need them.

Anything I've obviously f*cked up from the above?

Ta,

BW