Ah right, that makes sense, thanks!
And the flipflops, they're synced to the clock signal, I assume then.

Anyway, the LUTs integrated as RAMs makes sense. I'm wondering though how the wiring works, physically. And also what a corner turn is, but I guess that's about it not being easy to switch direction in the wiring, due to implementation details. I'll look it up myself when I have some time though. Unless you feel like explaining

Also, Wikipedia claims that CPLDs don't actually use LUTs to implement logic, which makes sense given that they're descended from PALs and those were purely sum-of-products. (The first ones were pretty much just several PALs glued together with some routing logic, from what I can tell.)

All modern ones have active routing that buffers the signal somehow, though the original ones did have hard-wired lines.

At 1-hash-per-clock (two rings) I am at 143Mhz (mining right now) and close to 150mhz (just one route fails timing).

On a lark I tried out the 1.5-hashes-per-clock (three rings) setup.  It works, but very slowly, mostly because I need to do some extra work to leave space between the rings, and I haven't even begun working on that yet.  Once I have the two-ring design where I want it to be I will backport all of those improvements to the three-ring design.

Still lots of work to be done, and lots on my plate.

Ok, fine.



The corner turn on the right hand side wasn't all that difficult.  Unfortunately there's a lot of irregular stuff around the first and last stage (in red), and algorithmically placing that stuff is not feasible.  So instead I've arranged for the top row to gradually "jog" upward which leaves a triangluar "hole" near the first and last stage, and I let Xilinx's tools autoplace the random crap in that hole.  This is what lets me get close to 150mhz.  Right now the hole is way bigger than it needs to be (in the plot a cell is purple even if it's nearly empty); once I get to my target clock speed I'll start shrinking the hole down to a more reasonable size.


Well, we'll see; no guarantees yet.  I have not taken any careful power measurements; last time I checked my 100mhz two-ring design pulled 5W per board measuring a cluster if 6 boards with a crude kill-a-watt at the wall, so this figure includes inefficiencies introduced by the ATX power supply.

I expect power consumption per-hash-per-second to be similar to any other design with one layer of registers per SHA256-stage, and of course much less than those with two layers of registers per stage.

I see your user icon has changed.

I for one welcome our new S6-LX150 300MH/s overlord.

Ah, not so fast yet.

As expected, moving up the frequency ladder turns into a game of whack-a-mole... fix one thing, something else becomes the critical path.  I'm back to fighting the corner turn.

What was not expected was how hard it would be to get control over the routing from Xilinx's tools.  I can get them to route the corner turn by itself, and I can get everything-but-the-corner turn to route, and I can show that the routing resources used are disjoint, but I can't get them both to route at once!

The sad reality is that Xilinx really does not provide any mechanism at all that says to the router "you absolutely must route this wire along this path". There are placer directives that can force placement, but even the "DIRT strings" used to try to force routing can be ignored by PAR under some circumstances, and I'm hitting them.  Ditto for SmartGuide.

Very frustrating.  I know where the wires should go, but I've spent countless hours trying to "trick" Xilinx's tools into doing what I already know how to do.

The very, very, very last resort is to write my own router by scripting fpga_edline.  I know that sounds desperate, but that's what it might come down to.

On the plus side, if you go that route the result should be more stable— small changes won't cause the darn thing to fail or to achieve drastically worse timing in unrelated areas.

Yes, I have considered it.  Spartans won out for two reasons:

- A quarter of the LUTs on a Spartan can be turned into rather large shift registers (SRL16), and I use these a lot.

- Much higher register density

Each Spartan SLICE has eight registers, but half of them are very difficult to use (and often ignored by the automatic synthesis tools).  One of the reasons my design is so compact is that I made sure to use those registers.  I have 91% register utilization within the occupied slices of my design (obviously lots of slices are unoccupied so the overall utilization is much lower).

So, a lot of designs port nicely from Spartan to Altera because they were wasting half the registers to begin with.  I'm not, so I would pay a steep penalty.

I have, however, looked at a couple of SASIC platforms that I could port to fairly easily.  If an investor were to fall out of the sky, I know which one to go with.

Thank you. I'll do that. Hard to get here so I may work out another oven alternative.

Edit: I have an SMD rework station that I haven't used in 3 years but I'm not sure hot air from above would be good enough to do it and may stress the chip too much. Have you tried something like that?

I'll be doing the on-board regulator method as running 1.2V isn't feasible. I want these to connect together in an array that can grow to 64 units or more. I'm thinking about 2x 5A reg. (like AOZ1037 at $1.41 instead of the more typical high amp reg seen on other boards so far. (If I use the same one for 3.3V I can buy 3x qty to save cost.) I'm not too happy with the 80% efficiency or less though.

I tried to find the AOZ1025 but they seem to be hard to get. Can't find any stock.
Edit: Found it at Arrow... 3000 qty. only.
(Actually I found a couple good alternates from IR and Fairchild. Higher efficiency (90% under load) and pretty cheap. FAN2108, IR3871. Looking at them now as Digikey has.

What happens when you put two AOZ1021 AOZ1037 in parallel? I thought that would work but then DC-DC regs are new to me. I've only used linear parts before.No longer the plan.

I'll likely drop the 3.3V anyway as an ATX PSU has regulated 3.3 already. Then just drop 12V to 1.2V as that seems to be more efficient and most PSU have more watts available on 12V. So a 20/24 pin adapter with non-standard onboard connector so users don't accidentally plug in a Molex and blow it.