iCE40HX -- can it be clocked from any input pin?

[ebastler]

I am tossing around design ideas for a "universal legacy chip emulator" -- essentially a smallish FPGA on a DIP-40 sized PCB, with bidirectional level converters on all DIP pins and jumpers to connect +5V and GND to any pin.

It would be helpful if the logic implemented in the FPGA could also be clocked from any pin. The iCE40HX series looks like a plausible platform, and this technical note suggests to me that it has that clocking flexibility:

See e.g. fig. 2.1 on page 7 and the bullet point list just below. I understand that I can drive a global clock buffer via any input pin and a bit of general interconnect -- right? I realize that it is preferred to use one of the dedicated global clock inputs, which will minimize the clock delay; but for the slow legacy chips I can accept some clock delay and take a detour.

Thanks for confirming or correcting my understanding!

[woofy]

Yes, but its not ideal to take clock signals through the routing fabric. iCE40HX includes a number of pins which connect directly to the clock net, you should choose one of them if possible.

[woofy]

One more thought.
It might be better to clock the iCE40 at high speed and treat the incoming legacy clock as just another signal. Otherwise you may struggle to do everything that the legacy chip does in a single cycle.

[ebastler]

Thanks, woofy. I agree on both counts:

The dedicated clock inputs were what I meant in my post when mentioning them as a preferred option. I will give some thought to which "popular" chips I want to emulate, and can try to connect the iCE40 clock inputs to those DIP pins which are clocks in these chips.

And of course polling the legacy clock while clocking the iCE40 much faster is always an option. It will imply some timing jitter on the outputs however, which may or may not be acceptable depending on the legacy system's clock rate and timing requirements. But come to think of it, does the iCE40 even allow clocks as slow as a few MHz? Proabbly not, at least not as a PLL input... So running it faster and polling the legacy clock may always be needed?

[woofy]

Min clk to the PLL is 10MHz, so if the legacy clk is greater than that, you can multiply it up. The HX will run up to 275MHz.
If its less than that, say 2MHz and you use a 200MHz clk, that only 1% jitter, which probably won't matter too much. It really depends on the chips you want to emulate.

[SiliconWizard]

Why would you want to get internal clocks faster than what is provided from the outside? None of the vintage chips you want to emulate did that.

And if you just want an extra internal clock to clock some emulated peripherals or something that would benefit from a much faster clock you can just use a completely separate clock for this. You'll just have to do some clock domain crossing.

Or do you just want to be able to emulate say, CPUs at a much higher internal frequency while still being sync'ed to the external provided clock? So, wondering what you want to achieve exactly.

But otherwise, yes, if all you need is to get a clock at a few MHz and use it throughout your design, an iCE40HX should have no problem meeting timings even if it's not able to use the dedicated clocking resources.

[woofy]

On a recent project I couldn't to do what I wanted in a single clock cycle. It involved calculating an address and getting data from a RAM block. I needed 2 cycles because the HX RAM is synchronous. With an asynchronous RAM a single clock would have been fine. That's pretty much what drove my comment that a higher clock might be needed. Without knowing what the OP wants to emulate, its all speculation though. To begin I would certainly try to use the supplied clock directly.

[ebastler]

Why would you want to get internal clocks faster than what is provided from the outside? None of the vintage chips you want to emulate did that.

What I would expect to be a pretty regular need is to trigger some activities on the external buses on the positive clock edge and others on the negative edge. That might require doubling the host clock so that everything can happen on positive edges of the internal FPGA clock?

In principle I would like to be able to emulate "any digital IC in a DIP-40 package". Hard-to-find 8-bit CPUs like the 65cxx derivates used by Commodore and Atari, or other unobtainium like the 6530 RRIOT used in the KIM-1 and elsewhere. All relatively simple logic, so I am confident the iCE40HX could keep up with the external clocks of a few MHz max.

[SiliconWizard]

OK. Anyway, routing external clocks to proper dedicated input pins is a good idea.

The ICE40HX has 8 global inputs you can use for this purpose. Cf. "3.1.3. Clock/Control Distribution Network " in the datasheet.

You could use two different approaches:
- Make a list of typical vintage 40-pin ICs you'd like to be able to emulate, and see if 8 different pins out of 40 would be enough to cover a significant range of devices;
- If you want more flexibility, you could always add a series of solder jumpers on the board to be able to route any of the 40 pins to one of the 8 dedicated pins of the FPGA.

[ejeffrey]

Or use a few analog mux chips to select a clock pin.

[ebastler]

I don't think that routing a "vintage" 1 MHz clock through a general I/O pin and a bit of general FPGA interconnect would do much damage. 

But it seems that using such a slow clock to actually clock the iCE40 is out of the question anyway, since it will be well below the minimal clock frequency of 10 MHz in most cases. (Or does that lower limit only apply when one wants to drive the PLL? And can one bypass the PLL and use the clock directly?)

[woofy]

The 10MHz is the PLL minimum only, the HX is static and its clock can go down to zero, and yes you can use it directly.

[SiliconWizard]

I don't think that routing a "vintage" 1 MHz clock through a general I/O pin and a bit of general FPGA interconnect would do much damage. 

Probably not if you're directly clocking logic with it, and your design doesn't have unreasonable logic levels.
Thing is, if the clock is not on one of the global inputs, the FPGA won't be able to use all the clock distribution resources, and even if the frequency is quite low, you may possibly get excessive clock skew. In particular if you want to be able to act on both rising and falling edges.

But it seems that using such a slow clock to actually clock the iCE40 is out of the question anyway, since it will be well below the minimal clock frequency of 10 MHz in most cases. (Or does that lower limit only apply when one wants to drive the PLL? And can one bypass the PLL and use the clock directly?)

That limit is just about driving the PLL. And unfortunately, I don't think you can drive the PLL from a non-global input anyway.

But if you don't need the PLL, you can of course use the clock directly.

[ebastler]

Thing is, if the clock is not on one of the global inputs, the FPGA won't be able to use all the clock distribution resources, and even if the frequency is quite low, you may possibly get excessive clock skew.

Hmm, I may have misunderstood the technical note mentioned in the original post then. I interpreted fig. 2.1 on page 7 like this: Each global clock buffer has an input mux, where the clock can come either directly from a dedicated clock input or from "somewhere else" (presumably including from another input pin via a bit of regular interconnect). From thereon, the clock is always distributed via the dedicated clock network in the FPGA.

Is that not how it works? If I understood it right, wouldn't that mean that a clock fed in via a general input may suffer from some input delay, and maybe jitter -- but should not see any excessive skew across the FPGA since the regular clock distribution nets are used?

[SiliconWizard]

Well yes, it would appear to be the case.

[voltsandjolts]

Hmm, I may have misunderstood the technical note mentioned in the original post then. I interpreted fig. 2.1 on page 7 like this: Each global clock buffer has an input mux, where the clock can come either directly from a dedicated clock input or from "somewhere else" (presumably including from another input pin via a bit of regular interconnect). From thereon, the clock is always distributed via the dedicated clock network in the FPGA.

On the PCB you could link GCLK pin to an adjacent IO pin, then route your 10MHz clock (or whatever) from any pin to that IO pin, and into the GCLK pin. Looks like the diagram you linked is allowing the same but without needing the link on the PCB.

What package are you planning to use? Some of these bga parts are quite close pitch. For cheaper prototype stuff, I'd like to try using standard vias for 'diy via in pad', just prefill them with solder prior to fitting the bga device, but not had the opportunity yet.

[ebastler]

For the package, I was looking at the 121-ball BGA with 0.8 mm pitch. That pitch still allows for routing tracks between pads with the 5 mil design rules offered by JLCPCB and other low-cost vendors, and also allows for regular vias inbetween the pads. (Preferably tented with solder mask.)

I have used a slightly larger Spartan-6 BGA with the same pitch on my 65F02 and it has worked alright. A few of the boards I hand-placed and soldered in a pizza oven didn't work, but most were and are fine.

[voltsandjolts]

65F02 project is cool.
121caBGA looks relatively user friendly
Do you have devices already? Like many fpga right now they seem tough to find.

[ebastler]

Yes, availability of these FPGAs (and so many other parts) is a pain in the neck these days... Mouser expects a batch of iCE40HX4K in January; for the 8K variant all bets are off.  

The timing for the 4K version is OK for me: I have other projects to complete first, and also need to look into compatibility of the level converters which I favor (NXB0108) with typical host environments.

[woofy]

Yes, availability of these FPGAs (and so many other parts) is a pain in the neck these days... Mouser expects a batch of iCE40HX4K in January; for the 8K variant all bets are off.  

Digikey has them in stock, however I would prototype with a dev board first.

[ebastler]

Digikey has them in stock, however I would prototype with a dev board first.

Thank you -- how did I miss that? I was considering a little custom board to evaluate the NXB0108 level shifters anyway, so I might as well put an iCE40 onto it right away...

[SiliconWizard]

Any reason you're after the iCE40HX specifically? Cost maybe?

[ebastler]

My main reasons for the iCE40HX are cost and package size (0.8 mm pitch, total width fits between the pins rows of a DIP-40 package).

The fact that an open source development environment is available might be a plus for some users; personally I am fine with using proprietary tools. (Heck, the chip is proprietary too...) But I like the fact that there is an open-source solution for programming via USB, the TinyFPGA bootloader and TinyProg Python software by Luke Valenty.