Yuri's Status Report - #11 of 15

[Yuri Gonzaga]

Hi, there!

I am sorry for the lateness of this report.


- Accomplishments
- David has set a remote machine with a M501 board. It is working
fine!
- Helloworld example run properly both by "purty" (using ssh -X) and
"PicoBus128_Helloworld.cpp"
- Eksblowfish loop verilog was adapted to PicoBus128, including some
simulation
- Modification to JtR code to communicate with a single loop core.

In this point, I need some help.
I changed the JtR's Makefile to include the search path
"$PICOBASE/software/include" in CFLAGS variable.
Moreover, I run make on folder $PICOBASE/software/pico_drv and copied pico.o
to JtR's source folder.
So, I included the pico.o to JOHN_OBJS variable in JtR's Makefile.

make[1]: *** No rule to make target `BF_std.o', needed by `../run/john'.
Stop.
make[1]: Leaving directory `/home/yuri/john-1.7.8/src'
make: *** [linux-x86-64] Error 2

How is the best way to tell make where to find Pico includes and compiled
library for PicoDrv?


- Verilog for multiple cores manager (not finished)
- Priorities
- Correct JtR's makefile to compile and link properly
- It will be useful both to one as multiple cores
- Test JtR's on M501 for single core
- Finish verilog for Manager of multiple cores
- Integrate to Alexander's patch for JtR multiple cores
- Test JtR's on M501 for multiple cores


Best Regards,

---
Yuri Gonzaga Gonçalves da Costa

[David Hulton]

Yuri,

The pico_drv project is the actual pico driver, the software APIs are
located in $PICOBASE/software/source and $PICOBASE/software/include. I
would look at the object files that are used when compiling the hello
world application and just make sure that they are included in the
build of JtR.

-David

Post by Yuri Gonzaga
Hi, there!
I am sorry for the lateness of this report.
Accomplishments
David has set a remote machine with a M501 board. It is working fine!
Helloworld example run properly both by "purty" (using ssh -X) and
"PicoBus128_Helloworld.cpp"
Eksblowfish loop verilog was adapted to PicoBus128, including some
simulation
Modification to JtR code to communicate with a single loop core.
In this point, I need some help.
I changed the JtR's Makefile to include the search path
"$PICOBASE/software/include" in CFLAGS variable.
Moreover, I run make on folder $PICOBASE/software/pico_drv and copied pico.o
to JtR's source folder.
So, I included the pico.o to JOHN_OBJS variable in JtR's Makefile.

make[1]: *** No rule to make target `BF_std.o', needed by `../run/john'.
 Stop.
make[1]: Leaving directory `/home/yuri/john-1.7.8/src'
make: *** [linux-x86-64] Error 2

How is the best way to tell make where to find Pico includes and compiled
library for PicoDrv?
Verilog for multiple cores manager (not finished)
Priorities
Correct JtR's makefile to compile and link properly
It will be useful both to one as multiple cores
Test JtR's on M501 for single core
Finish verilog for Manager of multiple cores
Integrate to Alexander's patch for JtR multiple cores
Test JtR's on M501 for multiple cores
Best Regards,
---
Yuri Gonzaga Gonçalves da Costa

[Solar Designer]

Hi Yuri -

Post by Yuri Gonzaga
- Accomplishments
- David has set a remote machine with a M501 board. It is working
fine!
- Helloworld example run properly both by "purty" (using ssh -X) and
"PicoBus128_Helloworld.cpp"
- Eksblowfish loop verilog was adapted to PicoBus128, including some
simulation
- Modification to JtR code to communicate with a single loop core.

Sounds good. I don't know what you mean by "purty", though.

Post by Yuri Gonzaga
In this point, I need some help.
I changed the JtR's Makefile to include the search path
"$PICOBASE/software/include" in CFLAGS variable.

Do you mean you used the "-I" option to list that include directory?

Post by Yuri Gonzaga
Moreover, I run make on folder $PICOBASE/software/pico_drv and copied pico.o
to JtR's source folder.
So, I included the pico.o to JOHN_OBJS variable in JtR's Makefile.

make[1]: *** No rule to make target `BF_std.o', needed by `../run/john'.
Stop.
make[1]: Leaving directory `/home/yuri/john-1.7.8/src'
make: *** [linux-x86-64] Error 2

How is the best way to tell make where to find Pico includes and compiled
library for PicoDrv?

As David wrote, you need object files built from
$PICOBASE/software/source, not $PICOBASE/software/pico_drv. Yes, you'd
include them in JOHN_OBJS. For the header files, I suggest that rather
than use -I... in CFLAGS, you simply place the directory at a specific
relative path to your JtR tree, then use directives like:

#include "../pico/whateverfile.h"

in your interfacing code in the JtR source tree.

As to the specific build error you mention above, this means that you
made an error in editing the Makefile. I can't guess what exact error
you made. You might want to run "diff -u" on the original and your
edited Makefile and post this "patch" - then I'd be able to comment.

Post by Yuri Gonzaga
- Verilog for multiple cores manager (not finished)
- Priorities
- Correct JtR's makefile to compile and link properly
- It will be useful both to one as multiple cores
- Test JtR's on M501 for single core
- Finish verilog for Manager of multiple cores
- Integrate to Alexander's patch for JtR multiple cores
- Test JtR's on M501 for multiple cores

You really should _start_ by integrating the patch I provided, even when
interfacing to just one core. You'd simply set BF_N to 1 initially, or
you'd interface to your one core from a loop with a higher BF_N - this is
up to you. When you actually have multiple cores, you'd simply make
sure to have BF_N set to higher than 1 and you'd adjust the interfacing
loop accordingly.

With one core, the loop may be like:

for_each_index() {
send_to_fpga(BF_current INDEX, salt, BF_exp_key);
wait_for_fpga();
read_from_fpga(BF_current INDEX);
}

When you revise the code for multiple cores and set BF_N to exactly
match the number of cores, the loop will be split in two:

for_each_index()
send_to_fpga(index, BF_current INDEX, salt, BF_exp_key);
for_each_index() {
wait_for_fpga(index);
read_from_fpga(index, BF_current INDEX);
}

Please don't hesitate to ask if anything is unclear.

Thanks,

Alexander