My Discord is Wolf9466#9466 - unique ID is 598179163160969216.
My Telegram is @Wolf9466.
My personal Discord server is here!
If you're looking for my writings, you can find them here!
If you're looking for my NSFW galleries, you can find them here!
Hey, I'm Wolf0/Wolf9466/OhGodAPet, and I have worked in cryptocurrency mostly,
looking to branch out with performance optimizations and work with FPGAs in
general. I started doing stuff when was nineteen, so it was seven years ago now.
There was a new crypto coin launched, Monero (XMR) with only CPU mining. This
is how I got into mining - I looked over the code, and it was... awful. I HAD
to fix it. It was like an OCD "tick." After a short time... someone paid me to
He had deep pockets, and had already teamed up with a dev to use AWS to mine with an improved miner. Later, he had me improve it for him, for money. My final improvement was around 6x. He used me to cut his previous dev out of it - I was naive. Ever since then... I've just been doing things freelance.
So... there's this new FPGA miner which is being produced, the Osprey E300, and I have good reason to believe that quite a sizable amount will be made and sold. The current firmware has very little to offer in terms of easy management capabilities, or detailed statistics reporting. It does have a WebUI, but it is rather barren. The few tunable options which are available (such as limited control of clock speeds and voltages) are only offered via miner programs - and those options are *FAR* from complete, compared to what is possible on this machine.
For background, almost all of my projects (even those I've made money off of, interestingly enough), I have done mainly for dumb reasons or pure fun. This means that even if I do decide to try this and I succeed, I haven't the foggiest idea what I'd do with it. My writeup on it, which I'll try to update as I go along, is here!
Xilinx are underclocking the HBM2 (forcibly - the user is unable to change it as
their encrypted HBM IP will not generate settings for its internal PLL to run the
memory above 900Mhz. The part is Samsung Aquabolt HBM2, and it's actually specified
by Samsung for 1000Mhz - 1200Mhz (depending on binning). Many researchers,
companies, and others benefit from the performance of these parts. They also
hide the details of the configuration ports for their hard memory controllers and PHYs...
So I'm working on reverse engineering over a hundred registers, and changing the clock speed, but it's not that simple. You see... one does not simply change PLL settings. You must to put the MCs in reset, put the PHYs in reset, then change with whatever you want, but then you gotta bring up the PHYs, make sure they don't spew garbage during init, then release MCs from reset, then calibrate them... In short, you have to bring the entire memory system back up. By yourself.
I recieved an official reply from Xilinx, and in my opinion, their answer was quite good - they do admit I was right about the HBM parts - they are specified for 1000Mhz. However, due to the reliability guidelines stated in the datasheet (which seem to confirm the idea that it's the FPGA fabric is the limiting factor - speedgrade -1 devices have a max of 800Mhz, while the faster -2 and -3 speedgrades have a max of 900Mhz), there's a real chance that it won't be able to maintain those data rates when process variations are considered, and having to meet power rail requirements, as well as reference clock quality guidelines. Further, there is no way for the user to make those changes, because it would force them to take returns/RMAs on parts which meet the expectations laid out by the datasheet, but would fail at higher HBM data rates. It's also a support issue - allowing users to exceed the max speed of the supported use case could cause failures for end customers, and that would put Xilinx in a bad light. Their official answer can be found here.