sha256
sha256 copied to clipboard
secworks
how to run your verilog code?
Hi there,
I am trying to use yosys to synthesize your verilog script to visualize the sha256 algorithm. How can I run the verilog correctly? Thank you!
Hi! You need to be more precise. What are you trying to accomplish? And what do you mean with "run the verilog correctly?". Do you get an incorrect result?
There is a Makefile under the toolruns dir. That makefile will build a simulation executable with Icarus Verilog. You can run that executable to simulate the behaviour of the sha256 core.
If you want to syntesize, implement the sha256 into a device using Yosys you need to add a suitable chip top level that instantiates and wrap the sha256 core, a constraint file (for pins, clock source). And then simply add the source files in src/rtl.
Thank you. I have successfully got the yosys result. It is pretty big. I have some other questions about this github repo.
- My supervisor ask me if this repo is the real cryptographic hash function that is applied in bitcoin. If not, what are the differences between your repo and the really applied one.
- What is the input and output for your Verilog file? How many bits for input. also output?
- What is the difference between sha256.v and sha256_core.v? I used the sha256.v to generate the yosys result.
Good to hear that you've made progress!
"I have successfully got the yosys result. It is pretty big." The size of the core is comparable in size to other iterative SHA-256 cores that can do 1 iteration/cycle. Depending on the target technology one can map the block memory W into hard memory blocks, which will reduce the number of registers quite drastically.
To answer your questions:
- Yes it is. This core has been used in a number of bitcoin miners - implemented in FPGAs as well as ASICs (I would dare to say it might be the most used sha256 core used in miners that don't do a custom sha256 core). Some of the miner designs I've seen modify the core to be fully pipelines also, which makes it VERY big. But most often the design is used as is, and they instead instantiate massive number of cores on the chip.
The core implements the SHA-256 functionality as specified by NIST in SP 180-4, but does not include the final padding. It is designed as a co-processor, and as such the CPU can easily perform the final padding. In bitcoin miners the padding can be fixed for a number of hash attempts (the data have the same size) and would just add unneeded complexity. Someday I will do a version that includes final padding. (I have implemented final padding for other hash cores.)
-
the sha256_core.v implement the full functionality of SHA-256 as specified by NIST and width wide interfaces. That is 512 bit block as input and 256 bit digest as output.
-
(As described in the README), the sha256_core.v implements the actual SHA256 hash functionality. The sha256.v is a simple wrapper that provides a minimal, synchronous interface that allow for easy integration with CPUs in System on Chip (SoC) designs. Given an 8 bit address, 32 bit data and two one bit control signals (chip select and write enable), a simple CPU can use the core with this interface memory mapped into its address space to use the core to perform SHA-256 hash operations.
In many designs the sha256.v is replaced with a wrapper that implements a standard interface, such as AMBA AXI, AMBA AHB, WISHBONE etc. But the interface implemented by sha256.v is so simple that it makes for easy testing. I've actually seen quite a few designs where the sha256 core is integrated using this interface. Your test implementation is a good example of when using sha256.v is useful.
If you look at my other cores (aes, blake2s, prince, sha512 etc) they all have the same strucure - a file <core_name>_core.v file that acts as top level for the core functionality, and then a <core_name>.v file that impplements a minimal interface that always works in the same way. I try my best to use the addresses in the API to same way. For example core name and version at addresses 0x00, 0x01 and 0x02. Core control at 0x08 and status at 0x09.
Thank you for the explanation. I appreciate it very much. My target is to generate a single graph that can represent SHA256 algorithm (gates are viewed as nodes, wires are viewed as edges). Since I am not familiar with Verilog, I may have some stupid questions. I have a further question after your answer. ////////////////////////////// This are the yosys commands I used to run your sha256.v ////////////// read_verilog ../sha256.v flatten splitnets -ports hierarchy -auto-top proc techmap opt abc -g NOR,AND,NAND,OR opt hierarchy -auto-top opt_clean -purge show -format pdf -prefix ../sha256/sha256_yosys //////////////////////////////////////////////////////////////////////// I will use the sha256_core.v later instead of sha256.v. When I run yosys commands, I only need to let it read the single file sha256_core.v, is it correct? Because some repo divide their Verilog modules into different files and need to be run together. Thank you!
For the complete sha256 functionality you need these files:
sha256_core.v sha256_k_constants.v sha256_w_mem.v
The sha256_core instantiates the sha256_k_constants and the sha256_w_mem modules internally. Without them the design will contain black boxes and not have the complete functionality.
Yes. You can just run something like: read_verilog sha256_core.v sha256_k_constants.v sha256_w_mem.v
Thank you for your answer, I have all the benchmarks I need from SHA256 now. My supervisor also wants me to check our algorithm in MD5 and I saw it in your repo too. I synthesized it on my local computer, but I found the MD5 with 128bit output has more gates than SHA256. Is it correct? Because SHA256 seems should be more complicated than 128-bit MD5. Here is the MD5 git link in your repo: https://github.com/secworks/md5/tree/54a6308d4d432daf4f6c6baa8c56ec204f106b4e
No, that does not seem right. There are build results for SHA-256 and md5 in their repos, and SHA-256 is normally 2-3 times bigger when it comes to gates, cells.
But you may want to talk to your supervisor about the reason for comparing with MD5. MD5 is a broken algorithm that nobody should use, and therefore the comparison is not very relevant. One algorithm you could compare SHA-256 with instead is BLAKE2s. BLAKE2s provides the same strength as SHA-256, it has the same input block size. But is much faster and a good alternative. I do have a core form BLAKE2s too: https://github.com/secworks/blake2s
If you want to compare to a legacy algorithm then SHA-1 is much better than MD5. And yes, I have a core for SHA-1 too: https://github.com/secworks/sha1
Thank you! After I read your explanation, I came back to check my yosys commands and found the issue there. Now it looks correct, MD5 has nearly 1/2 gates of SHA256. I will take your suggested BLAKE2s to my PI too.