I think you made a mistake of taking their marketing materials literally. Their marketing people wrote seriously confused and non-physical stuff like "approx 900W to 1kW per hour." It also confuses single ASIC chip parameters with the overall system parameters.

Do you really think that they have in that box a single chip dissipating 1kW with 2 USB, 1 Ethernet and 1 HDMI port?

To me it is quite obvious that they must be proposing a system containing many much smaller chips. Why this couldn't be a system with 64 chips with 0.5GB of eDRAM in each chip? Reconfigurable cryptographic processors are now being researched and produced for about 20 years.

I wouldn't rush to judgment just based on a single marketing blurb. Have you ever played "deaf telephone" as a kid? This is a standard game being played in the meetings between R&D and marketing.

Edit:

Before I succeeded at posting the above I received a warning there was a new post from somebody directed at GPUhoarder saying something to the effect "redo the calculations with HMC or HBM". I think that post had disappeared due to forum bug or possibly self-censorship.

Could someone familiar with any of those technologies make another post with relevant calculations?

Thanks.

https://en.wikipedia.org/wiki/Hybrid_Memory_Cube
https://en.wikipedia.org/wiki/High_Bandwidth_Memory

Start with something simple like SHA256D used in Bitcoin:

https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner

Or something from the official Xilinx marketing publication:

http://issuu.com/xcelljournal/docs/xcell_journal_issue_84/16

Have fun!

Edit: I forgot to include standard explanation about the difference between CPU programming and FPGA programming.

CPUs have von Neumann architecture with linear memory, e.g. from 0 to 4294967296. Compiling and running your first 10 line program will take seconds on your typical usable computer with 4GB of RAM.

FPGA have a completely generic two dimensional architecture that literally has kajilion of constraints. Most of those constraints are secret to the FPGA vendor. The XCVU9P FPGA discussed in this thread has about 2104 pads, just describing the pads that are actually connected with useful signals on the VCU1525 board is a file that has 25 pages in the manual. Those are the constraints that are visible and not secret.

When compiling your first 10 line FPGA program the Xilinx toolchain will still have to process those constraints even if you use less than 1% of 1% of the whole VCU9P chip. On the other hand the small XC7A35T chip on the training board has much, much less internal constraints that needs to be read by the toolchain.

You will observe that your small 10 line FPGA program will be completely compiled and done for a small device like like 7A35T while for the large device the Xilinx toolchain is still decrypting the secret VU9P constraints file. Amazon recommends that you run their FPGA development kit for VCU9P on a computer with 32GB of RAM to get sensible performance for nontrivial programs.

Just be aware of the above.

Edit2: Trying to learn logic design on a high-end device may seriously test your patience. Start with a low-end device.

Edit3: Grammar fixes.

I'm not buying it. You just lack introspection.

You don't talk like an investor. Investors are (generally) friendly or even overly friendly. Their suspiciousness is on the inquisitive side.

Your suspiciousness is on the paranoid side. And it shows like a "tell" in poker.

Read the past posts of the user senseless, he apparently wasted some considerable money doing a small world tour trying to solicit business, unsuccessfully. I bet that he now has some useful knowledge on how to distinguish gamblers from investors.

In my experience for the casino gamblers the road to recovery may be through learning how to really compute their odds.

For the cryptocurrency mining addicts the road to recovery may be through actually investing $99 in an FPGA training kit like Digilent Arty 7 and actually losing their logic design virginity.

Edit:

In order to effectively play a white knight here you actually need to show some knowledge, otherwise you just look funny.

Yeah, you've solicited at fiverr or mturk.

You can't fight bullshit with bullshit. You sound like one of those people that would say that they "hired a dentist" when they go for the tooth cleaning.

The anger that comes through your posts is the same of the anger of the compulsive gamblers, that know that they have problem but cannot deal with it. You get the rush from buying the proverbial "pig in a poke" or "cat in a bag", but just can't admit that to yourself. All the rationalizations you are posting are just for your own consumption, to convince yourself that you don't have a problem. I used to work in the entertainment and "gaming" (polite world for regulated gambling that they use for themselves), I've seen the type at many trade shows.

Quoting the rest for posterity:

Why it wouldn't pipeline efficiently? There are 8 transceivers available over QSFP28 that work at the raw speed of 32.75 Gbps for a total of 262 Gbps from one board to the other in one direction. No back-channel is required, also we don't care about protocols and error detection & correction over our link, it is for lottery purposes only.

If that is not enough there are 16 of the same transceivers connected to the PCIe edge connector. This may be a little more tricky, to run them at full blast without obeying PCIe protocols we would need to either do some simple trace cuts on the backplane or find a way to busy-out and/or disable the PCIe bridge chip.

I seriously don't see the inter-board bandwidth as an important limitation. I haven't done the above with the Ultrascale+ technology, but I've successfully found ways to abuse the older connectivity standards (for an application not related to cryptocoins, but also tolerating occasional noise.)

Yeah, for X16r coins thats 16^2=256, for X16s coins thats 16!/14!=240. Certainly doable.

Thank you very much. It will be very interesting to see how those statistics evolve over time, especially with regards to the unwanted traffic.

what is the percentage of traffic that comes in via IPv6? I presume that the forum server only sees IPv4 traffic and Cloudflare handles the reverse-proxying from IPv6 down to IPv4. Also does Cloudflare give some raw vs. DDoS filtered statistics of the traffic? What percentage of IPv4 traffic gets filtered vs. what percentage of IPv6 traffic gets filtered as DDoS?

Just curious about some rough numbers from 2018.

Thanks.

It doesn't help much and in my opinion it is actually detrimental. Those devices you mentioned have the similar conceptual limitation: they encourage thinking of solving tasks in terms of sequences of steps. Very much like many early "home computers" programmable with BASIC.

The thing is that a random guy can conceivably be much better at FPGA programming, even without previous exposure to computers.

I believe it starts much earlier and is conditioned with the type of toys one played as a kid. Here's my theory:

If as a kid somebody played

(1) with mechanical toys that allow to build working things out of building blocks

or

(2) with electrical toys that allow building working circuits out of components connected with pluggable wires

then as an adult such person will have natural aptitude for

(a) FPGA programming

or

(b) parallel programming

or

(c) electronic engineering

To such a person the FPGA development kit is very much like their dream toy from the childhood upgraded to a true professional tool with nearly unlimited quantity of building blocks and connecting wires.

So I disagree with your premise that the aptitude for FPGA programming is rare, it just isn't discovered and developed in many people.

In the past I was frequently surprised that some people with advanced computer science degrees from reputable schools have extremely hard time understanding that some device can concurrently work doing many things simultaneously. No need to explicitly state the order in which things need to be done.

You may now know it, but FPGAs don't need to be programmed using some language like Verilog or VHDL. They can be designed using schematic capture of assembling blocks and connecting them with wires. And this comes naturally to some grade school kids with no computer science exposure whatsoever.

So the TL;DR of the above is: it really depends on what kind of toys you played with when you were a kid.

I actually went ahead and RTFM'd the "UltraScale Architecture SYStem MONitor User's Guide". It looks like it is very close to being a "magic button", it takes only one line of code:
On the other hand the whole guide to the SYSMON block has 113 pages, so it must be also relatively easy to accidentally mis-configure it.
 

OK, so both Xilinx and Bittware boards have 16 xcvrs hooked to PCIe edge connector.

I mentioned "PCIe passive backplane" to emphasize that to use that we wouldn't need to obey the full protocol stack, including BIOS discovery & negotiation, transport layer packetization, etc. If the passive backplane contains only cards running "our" project then we could violate many if not most constraints in the official protocol.

All that really matters are the mechanical fit and signal margins on the electrical connectors. Given the simplicity and low cost it wouldn't be a problem to even cut some traces on the backplane PCB to make it electrically independent and improve noise margins by cutting out unnecessary copper.

Admittedly, I haven't played this game with PCIe devices, but in the past with older technologies all the way to PCI and PCI-X. Additionally, mining is essentially a lottery, so it can profitably tolerate bit error rates that wouldn't be acceptable in conventional applications. I get a sense that most of the devices utilizing QSFP28 are designed for either longer distances or higher reliability than what would be required here.

Or maybe you just thought about PCIe 4.0 motherboards instead of passive backplanes?

So, is it better or worse than connecting those cards through the transceivers connected to the PCIe and plugged into a PCIe passive backplane? What are the trade-offs? According to the Xilinx docs that card has twice as many xcvs hooked to the PCIe edge than to the both of QSFPs.

The ASIC doesn't need to be completely static to beat alternative implementations using GPUs or FPGAs.

Reconfigurable cryptographic processors are now fairly well developed field. The market for them was initially for network cryptographic accelerators for IPsec and SSL. It all started sometime before the turn of the century.

Here's a sample from the open scientific literature:

https://www.sciencedirect.com/science/article/pii/S2090123217301170

Optimization of a novel programmable data-flow crypto processor using NSGA-II algorithm

but many such accelerators are developed in secret by the network hardware vendors.

Personally, I suspect that many "ASIC-resistant" algorithms are doomed to fail their goal because their designers just don't understand digital design and think that every possible hardware device must be some version of von Neuman architecture from 1945. But even in next decade (1950-1959) there were other architectural concepts developed that lead to significantly more efficient implementations at a cost of being less generic.

I'm not currently interested in buying anything. I was more interested in the technical trade-offs.

On the other hand I know that small PCIe passive backplanes are nearly free and many people already have them as a riser cards for their rack-mount servers.

I was wondering about other ways of setting up the communication between the boards.

Looking at the VCU1525 user's guide they have 8 transceivers hooked to Ethernet ports and 16 transceivers hooked to PCIe, remaining transceiver blocks aren't connected. Also, it looks like the required intellectual property block for the PCIe support.

Have you considered plugging those boards into a PCIe passive backplane type of interface, not to the actual PCIe computer motherboard? This should be very simple to interface, even to the point of not really obeying the official PCIe protocol rules if the passive backplane contains only the boards running our project.

Can you write a paragraph or two about the relative logic overhead required to implement inter-board communication over Ethernet versus PCIe?

I currently have all my development hardware in storage, so I can't even make a dry-run with an evaluation version of the software.

I don't find that odd. In my opinion false-positives are quite common and technically an expected trade-off.

While any one ordinary skilled practitioner can write the required working code, the choice (and order!) of the external sites that it tries to contact were very peculiar. IIRC the original engineer that helped Satoshi with that code was Hungarian. In turn that code they developed triggered IDS systems when run in Germany and France, but it would not trigger them when run in the USA or Canada. When AT&T changed their IDS vendor in North America then those false-positives started popping up on AT&T U-Verse, which was then a new residential offering.

The details above are all hearsay, personally I've only experienced that problems when using old version of Cisco IDS option for Cisco IOS version that was deprecated and no longer officially supported.

If you are limited to the Internet searches, then actually try some IRC channels, especially the ones that were frequented by genjix, phantomcircuit and Mircea Popescu. I don't think they read this site anymore, but there must be people here who regularly attended the dev meeting on the appropriate IRC channels.

Edit: One piece of warning: connecting to the IRC channels from the same IPv4/IPv6 addresses that participate in Bitcoin P2P network will most likely attract vicious vulnerability scans of your hardware. So use a VPN or other means of rapidly changing your network address in case you get noticed by those who will try to help you configure and secure your network.

Edit2: By a dint of accident I'm writing this on the same laptop I used when I originally joined this forum, with just few software updates installed since then. I started my Xchat IRC client to see if I still have the list of channels I used to read then. But the vulnerability scanners killed my IRC client in less than one minute. So please be careful.

If you searching just on the Internet then you are missing around 50 years of history of networking and software in general.

I'm not sure if it is practical for you, but a lot of information is available in printed magazines, but not in their official "articles", but in the "classified ads" and other cheap less-than-full-page advertisements. Researching those would be extremely time consuming, even if you can find the library that has those magazines undamaged with all pages available.

One more avenue for search is to look at the nearby code, not just strictly IRC-related. There were multiple methods used to discover node's own external IPv4 address. Those also aren't all invented by Satoshi, but borrowed/copied from the pre-existing code. Those were the other things that tended to trigger false-positives.

Are you a CS history researcher associated with an accredited university? Because if you are really into history of CS I may be able to put you in touch with people who may be willing to donate their personal archives fairly soon. But you would really need to be able to read obsolete media like open-reel magnetic tapes or U-Matic and SVHS video cassettes with PAL/SECAM color.

I don't have any reference beyond the personal recollection of:

(1) getting false positives from the Cisco NIDS option in the Cisco IOS 12.something
(2) second hand accounts of similar false positives from Sandvine Inc. large-scale network management tools

You will find that lots of the code in the Bitcoin client isn't completely new, but an existing code reformatted and re-factored to use Satoshi's peculiar C++ style and his collection of C preprocessor macros.

My best recollection of base58 (and other similar nearly-human-readable schemes) is from license strings for artistic 3D modeling software from Softimage or Wavefront. They were working on transmitting those license strings via fax machines and have them correctly entered on computers with artistically designed fonts with indistinguishable characters (O vs. 0, 1 vs. l, etc.).

The code was originally developed for command-and-control of botnets. I doubt you'll find any legitimate scientific publication as a source. You should better look through some underground hacker publications.

Alternatively, you may be able to find genuine information from the vendors of behavioral antivirus software or the network intrusion detection tools.

The code that was included in the Bitcoin client was such an exact functional copy of the botnet C&C code (e.g. identical obfuscation scheme for IPv4 addresses) that it used to trigger false positives in many of the above tools. You may want to search for those stories to narrow down which vendors to approach.

Ha, ha! I'm stealing this. This forum is not only "schoolyard from some school in the slums". It also has an underground tunnel to the recreation yard in some low-to-medium security prison and an overhead bridge connecting with a backyard of some mental institution.

And I'm not even joking. All those types of personalities were seen here.

Edit: I'm going to preserve the entire message, just in case. It is such a beautiful example of clutching one's pearls.