Looks like with the "less than or equal" comparison the interval (in your notation) is
[0-0x00000001FFFFFFFF]. In my notation it would be [0-0x00000001XXXXXXXX], where X stands for "don't care". Please check the data flow again.

I presume the 5ns propagation delay above would be through 128-levels of purely combinatorial logic. What would be your guess for the clock rate achievable with pipelining every X-stages (for X=1..64, picked at your choice)? Assume the same fully-unrolled architecture, just with some flip-flops in the intermediate stages.

Thank you very much for your valuable input. If you have a moment, could you please post a snippet of HDL code that shows how you convinced ISE DS to use DPS48s for adders? Does ISE have some flag to make it infer DSP48s from additions? Or did you have to explicitly instantiate them?

Since my last post in this thread I learned a lot about ISE software. The license is node-locked to the Ethernet MAC address using standard FlexLM technology. So it allows for designing on one system and running the design on another system. I was afraid of a node-locking technology that would require connecting the ML605 board to the system that runs ISE to allow it to check the license.

Also, would you dare to speculate what will be the initial pricing on the Kintex-7 KC705 evaluation kit? I hesitate to buy ML605 right now because I could not really start working on it immediately due to the need to reorganize and remodel my physical workspace. On the other had I'm completely fascinated with contemporary FPGA design after a long break from doing any hardware-oriented design.

You can use the appropriate BerkeleyDB utilities with the two caveats:

1) they need to be from the exactly same build as the BerkeleyDB library that you linked to;

2) manually create "DB_CONFIG" file contailing one line "set_lg_dir database".

Only inside the bunker FIX protocol and Zero MQ are called "something proprietary". (edited to add 0MQ).
It isn't how much money you spend. It is how you cooperate with the NOC personnel before, during and after a network event.

I work with providers who understand the difference between "null-route" and "policy-based null-route".

Absolutely. I'm not itching for a place in the Bitcoin Bunker. The weather outside is too gorgeous.

I'm fully with you that when sold on the open market they command premium prices.

But BFL seems to be a loft operation (and I don't know how loft in Kansas City compares to a garage in Silicon Valley, I presume they are about the same.) They may have gotten some engineering samples, some partially defective chips. They may have bought out from the bankruptcy assets of some networking equipment vendor who just lost their contract with the government of Egypt or Libya. Who knows? Speculation in this thread is a free fun.

IPSec VPN accelerators are designed with 3 5 objectives:
1) max PPS - packets per second, each packet requiring HMAC-hash which computes 2*hash for short byte-strings.
2) max flows - each packet flow uses different keys, chip minimizes required key reloading
3) max BPS - bytes per second, this is the least important objective, total throughput is the easiest to achieve and normally least important because it very rarely becomes a true limit of the whole design. This is where VPN accelerators differ from other designs: unlike pretty much everything else they do a lot of short-string hashes not a few long-string hashes.
4) min latency - do not require batching of packets for efficient work and no additional waits after each packet
5) testability - being able to do self-test while still operating, not only upon reboot.

I'm not aware of anyone selling individual VPN acceleration chips. Those things are usually sold as systems, and will typically require an NDA to get internal details. But the overall feel of those designs is that they provide lots of leeway to the driver-writers and digital designers: most of the combinations of control signals and registers are "reserved; do no use", "for internal test only" and so forth.

I'm actually not at all in the business, I got interested because of an effort to understand some historical project that went bankrupt.

OK, I'm officially registering a second bet with myself.

The BF Labs device uses a full-custom ASIC chip originally designed as a IPSec VPN accelerator.

The intellectual property of BFL consists of finding how to internally modify the behavior of the chip
to change the IP protocol 51 (AH - Authentication Header) HMAC-SHA-256 to a simple two nested SHA-256 hashes.

Somebody please quote my message.

Thanks,

No, too Mediterranean and Westernized. Not the Bitcoin peace pipe either. I think nowadays offering of a bottle of beer is a thing that crosses all cultures.

For those who may be interested how people from different cultures react to the perceived slight on an interned board: have a look at the OK-Pay thread:

https://bitcointalk.org/index.php?topic=51403.msg621678#msg621678

and see how the response of a Russian (Eastern European) is so different from an response expected from a Westerner or Far Easterner.

On the other hand I think they are. Russians are straight shooters: the best defense is a strong offense. Don't  expect passive-aggressive cotton-balling from them.

Most common problem I see with switches is that they go crazy when the MAC address of some card is all zeros. Check the "locally administered MAC address", "network address" (or equivalents) has "not present" checked in the device manager. It is really easy to accidentally click on the "Value" textbox without filling the valid value, thus you'll get a card with MAC address of all zeros.

Can you write down your arithmetic that computed 750kH/s? Do you assume same chips looping data back to itself or a pair of chips working as a pipeline?

I see a design with 200MHz clock, 16-bit wide streaming data input/output and 68 cycles of latency. 512-bit width of block shouldn't matter, this is an internal detail. From my place I can't get the #1 citation in this paper: "A hardware interface for Hashing Algorithms".

Thank you again for your valuable input. It seems to me that I have inadvertently touched some nerve of yours. I apologize for that. I'll definitely follow your advice, but not this year.

Our whole conversation here reminded me of the important lesson about the difficulty of the trans-continental personal relations. What is acceptable between acquaintances over a beer in a Western world is not acceptable even in an informal conversation in the Eastern world, especially over the long-distance communication links.

What this world needs more urgently than bitcoin is a bitbeer: a way to instantaneously transfer a small token peace offering over the trans-oceanic distances.

This is what I would call a perfectly rigged bet. 

Your insistence on HTTP with long polling is the perfect example of the bunker mentality and obsession with reinventing the wheels prevailing at the top of the Bitcoin pyramid.

That and 3 years now with not even a single entity with an audited accounts (even pro-forma) is the reason why the Bitcoin implementation has to change before it can become successful.

It isn't "weak investor hands" that need to shaken off. It is fly-by-night opportunists that will stifle the progress until shaken off.

Oh, one more suggestion that for sure ISE will not synthesize for you.

Adders in Spartan-6 are slow but you have free ROM lying around. How about decomposing the adders? Here's the classroom example:

You need 8+8->8 adder. You decompose it to two halves: (4*4)->(4+1) ROM table lookup and (4+4+1)->4 adder. You could either save on carry-lookahead logic or gain some timing margin that way. This is what I meant by "mangling the design to fit the resources".

This is the type of transformation that I haven't seen anyone trying. I'm not saying that they WILL work in Spartan-6. But they COULD work and they DID work for some ancient FPGA chips.

One thing is for sure: no amount of brute force smartXplor-ing will help to verify that. I'm not blaming anyone for using smartXplorer, but there are just the tricks of the trade that even the oldest computer ponies haven't learned yet.

Edit: Actually the ROM isn't free. You have to carry it around and it costs you by sucking the leakage current. How about putting it to work on the least-significant bits? It's a common sense, really.

Thank you for your very valuable comment. However I'm not really interested in mining Bitcoin. I got involved in another project to reverse-engineer a faulty silicon that uses 2*SHA-256 in a HMAC-like fashion. I need more chip real estate to simulate the faults thus my interest is in at least Virtex-6 or Kintex-7, depending on the costs. Bitcoin is just an additional stimulant, it is good to be able to compare own work with other people's work, even if it isn't the exact equivalent.

One think I disagree with you is that deep-pipelines will require shift-register-type resources (SLR16 or such). With abundant BRAM as ROM one can store multiple copies of magic constants and save in the address encode/decode stages.

Excuse me, but I was working on defending against attacks on financial institutions even before DDOS become a common word.

If you have long-lasting (hours or days) TCP/IP connections you can ignore most SYN packets early on the switch.

Long-lasting sessions also allow you to do filtering by origin IP address.

Today's DDOS defense business is so focused on the HTTP protocol that it completely forgot the basic lessons in inter-networking. Overuse of HTTP does rot the brain. Edit: This does include the Paypal code monkeys who had fallen into the HTTP rut.

I mostly agree with you, with the exception where you call SLICEXs shit.

I don't know your HDL code and your design, but I've took a look at the ones published by ZTEX and fpgaminer. They both don't balance the use of available resources.

Three points worth checking:

1) use the adders in DSP48's
2) use the BlockRAM as ROM for the storage of the SHA-256 magic numbers instead of spreading them all over the implementation in LUTs
3) stream the pipeline stages: no matter how many stages, produce one result per clock (in honor of Mr. Cray)  

Both Virtex-6 and Spartan-6 have some DSP48 and BlockRAM. Obviously they are different. But the two things I learned about FPGA design in school were:

1) you don't leave available resources unused, even if you have to mangle your source design.
2) watch the floor-plan for unnecessary long wires.

I had a long break in FPGA design, so I can't come up with quick specific answers. But I downloaded ISE evaluation, played a little with it and will most likely buy a ML605 or KC705 next year when they become available.