Vivado shows different values when the unit is switched to Fahrenheit, though.
I got similar values with minerator, so I ruled out interpretive errors on my side.
It's pretty annoying as minerator throttles down as a result and the hashrate drops to 1/10 of
what it is supposed to be.

Some of the temperature sensors of my BCU-1525 seem pretty messed up.
At idle, I see on Vivado Lab Edition:

TEMPERATURE: 92.7
LOWER_OT: 93.5
UPPER_OT:98.4
MAX_TEMPERATURE: -280.2
MIN_TEMPERATURE: 229.1

This cannot be right as the card itself is not even warm to the touch at all.
I confirmed this problem both bitstreams that are available with minerator.
I hope this is not a hardware defect... Could it be a problem with the SYSMON components
of these bitstreams?

I am currently targeting BCU1525. I would buy a better model now, though.

I'm developing bitstreams independently for myself.
I am still optimizing Ethash. I am planning to work on ProgPoW and CryptoNight variants, too.

I will answer these questions once I get back to GPU mining.

I thought the last few "quotes" of mine were like the biggest giveaway ever.
Anyway, I am extremely busy with FPGA development and other stuff.
I had no idea Xilinx's SDK was such a major pain in the rear...

It seems like I should be able to come up with a ridiculously fast implementation of Ethash.
After all, the illusion of Ethash'es memory-hardness hinges upon the false assumption that
algorithmically-generated DAG's are comparable to a series of true random numbers
in terms of randomness, which is just not true. I will publish everything
after I make enough money to buy a house in Berkeley...

OK, OK. I will disclose as much as I can. I am not going to reveal everything as I still need to pay my bills, though.

There is a critical flaw in Ethash'es memory-hardness as you can generate DAG on the fly with enough computing power.
This is probably impractical with GPU's, but it seems that it is quite possible with FPGA's and ASIC's.
I found an efficient way to represent an Ethash DAG with a memory footprint in the order of several MB's,
which is three orders of magnitude less than the original DAG. I might be able to implement this method
with Vega if I can squeeze everything onto Vega's 4MB L2 cache.

I only work if there is an advanced payment. Too bad!

Actually, I am quite busy right now anyway.
I *think* I found a crack in one of the major algorithms.
If rumors are correct, somebody must have been taking advantage of it for quite some time now.

I actually started porting the new miner to Linux in my (very limited) spare time.
I would rather release a complete miner instead of keeping fixing work in progress this time around.

Thank you. Actually, I updated the kernel and it is running even faster, especially on Vega.
I cannot do anything about BIOS mods for Craymore's, though. 

You need to update Windows for the AMD driver.

I need to see the "message about OpenCL." You might have to install Windows 10 April Update for the AMD driver.

The command-line version is already there, but Linux is not my priority now.
Unless somebody pays for it, that is.

You mean something like this?

That doesn't seem to do too much to my Sapphire Nitro+ Vega 64, though.
What a bummer... Oh well, let me try this with another Vega card...

I guess I have to resort to that method as tightening memory timings do not seem to have any effects.

By the way, this looks very nice... Thanks!

https://github.com/OhGodACompany/OhGodADecode/pull/6/commits/caf53f5f486f49979c9836a34f28dd1b86da2b8a

As for Ethash and Vega, I don't think we would ever be able to maximize the usage of HBM2's bandwidth (4096 bits)
as memory access to anything greater than sizeof(compute_hash_share), which is 512 bits, would be subject
to tCAS and tRAS. Just my two cents.

I did locate Vega's registers for memory timings, but it is taking forever to find the right combination of values for these registers as they are not documented anywhere, not even in the Linux kernel GitHub repository. *sigh*

Well, I need to take another deep dive...