I'm still green when it comes to implementing these brute force cores, but I'm picking up.
I was browsing through your code and one thing struck me; you are using the 256 bit "data" input both for setting the internal state of the first sha round and as the end part of whats hashed in the first round.
In the Icarus and Open-Source-FPGA-Bitcoin-Miner code they have separate 256 bit init state and 96 bits of "data" that is appended to the nonce.
I can't quite work out what those 96 bits are. Bit 64 to 127 of the header. Reversed or not, it doesnt make much sense to me. It should at least not be the same as the init of the hash round.
I was browsing through your code and one thing struck me; you are using the 256 bit "data" input both for setting the internal state of the first sha round and as the end part of whats hashed in the first round.
In the Icarus and Open-Source-FPGA-Bitcoin-Miner code they have separate 256 bit init state and 96 bits of "data" that is appended to the nonce.
I can't quite work out what those 96 bits are. Bit 64 to 127 of the header. Reversed or not, it doesnt make much sense to me. It should at least not be the same as the init of the hash round.
Probably belongs in a SHA-256 thread, but I think what you're referring to has to do with precalculated(or -able) round values, and the initial value for those.
If there's a problem with the core.vhd, well, that's cause it's a work in progress, it'll get worked out. And smaller...
I had a second look. I think I was right in the first place. There are 76 'static' bytes in the header before the nonce. The midstate is the internal state of the hash core after hashing the first 64 bytes. The remaining 12 bytes will be paired up with the 4 byte nonce and 48 bytes of padding (The header is 80 bytes, but will be padded up to even multiple of 64 bytes - the sha256 blocksize).
So you really do need both the 32 byte midstate and the 12 byte 'data'.
But as you said; that's all in the control logic and I understand it's under development
Nice work!