On Wed, Mar 10, 2010, . wrote: > Hello everybody. > > We are two students doing a project about accelerating encryption on an > embedded system. This system is build upon a ARM processor (180MHz) and an > FPGA. > We have built and implemented OpenSSH into the system (running Linux), and > tested the AES encryption in software. > The task is now to come up with a hardware component implemented on the FPGA > which will accelerate the encryption/decryption on the system. > We are trying to use the OpenSSL padlock as a reference and help. > Currently the ARM cpu usage is 100% when we transfer a file over OpenSSH > (SCP) in software encryption mode. > We are wondering if we implement an AES core on the FPGA and calls this core > from OpenSSL. What will happen with the CPU usage? > How can we tell if it will drop or not? > Where should we look in software? > > We have looked at the padlock.c file to get an overview of the > implementation of this engine, and tried to figure out if there is a > "special kind" of programming which > makes the cpu usage fall if using this engine. > > So we guess the main question is, if we design an AES cryptocore(FPGA) how > do we ensure that the cpu utilization will drop? This is more important than > getting a higher throughput > > PS. we are two electrical engineers so we are not that strong in software > development :-) > > Hope to hear from you soon.
Well with software implentations of algorithms the CPU implements the whole algorithm. With hardware the CPU sends instructions to the hardware to perform the operation and it will notify (e.g. via an interrupt) that it has finished. The drop in CPU utilisation is because the CPU is no longer implementing the algorithm and is just waiting for the hardware to finish. With some ENGINEs looking at the source wont help much because it may just call an external and propreitary library to do most of the work. I'd say that a good place to start would be the cryptodev ENGINE aka OCF-linux. For that you have an ENGINE and it interacts with a device directly. The device driver (also open source) then talks to the hardware. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
