Yuri's Status Report - #3 of 15

[Yuri Gonzaga]

Hi, you all!

I am sorry for reporting my results only in the last moment.
I had a very busy week.

- Accomplishments:
- Receiving of Google's welcome package
- Account registration and card setting up
- Full Eksblowfish using Xilinx's RAM
- Results in a separate email
- Installation of Pico E-101 files for Linux
- I am using an Ubuntu 10.4 64-bit guest OS on VMware Workstation 7
- I had some trouble to put everything to work. Everytime the demo
example tried to communicate to the board it complained the
device was busy.
So, after several attempts, I figured out a workaround: a
process called
usbtest was locking the device. Then, before running any
application, I have
to call "sudo rmmod usbtest". It solved!
- Unfortunately, I spent so much time to set the VM and run the
demo example properly that I couldn't start to interface my own
applications.
- Get circuit diagram from Xilinx results
- I did this to bflike as reported in another email.
- Synthesis experimentations in bflike
- Synthesis for Spartan-6 device, from E-101 board
- State machine changes was postpone to interface step
- I couldn't improve pcadd() LUTs count
- Priorities:
- Run bflike on the board
- Report real results
- Real result means operation time?
- Interface to the board from software (Linux)
- Following the demo example, there are a lot of stuff to
understand in software and hardware sides
- Hardware side: SPI interface, FIFOs and anything else
needed to stablish communication using Cypress USB
device (used on e101
board)
- Software side: api initialization, write and read routines
- Revisit JtR to work with bcrypt on the board
- Actually, I revisited the code to found the right point to
call hardware.
- So, I need to finish this task

Anything else?

Regards,

Yuri Gonzaga

[Solar Designer]

Post by Yuri Gonzaga
- Installation of Pico E-101 files for Linux
- I am using an Ubuntu 10.4 64-bit guest OS on VMware Workstation 7
- I had some trouble to put everything to work. Everytime the demo
example tried to communicate to the board it complained the
device was busy.
So, after several attempts, I figured out a workaround: a
process called
usbtest was locking the device. Then, before running any
application, I have
to call "sudo rmmod usbtest". It solved!

You mean a kernel module (not "process"). Thank you for documenting this.

Post by Yuri Gonzaga
- Unfortunately, I spent so much time to set the VM and run the
demo example properly that I couldn't start to interface my own
applications.

OK. Perhaps you made progress at that since then?

Post by Yuri Gonzaga
- Run bflike on the board
- Report real results
- Real result means operation time?

Make sure that it works reliably - producing the correct results
reliably (without a single error) when run for a long time. I think
that you'll need to bump up Nrounds to a much higher value in order not
to saturate your USB link. Then have the host send test inputs, and
verify the test outputs (vs. those computed on the CPU). For just one
core, your CPU should be fast enough to compute the expected results in
time (to compare FPGA's results against).

And, yes, I am also interested in actual speed data. But correct
operation is to be verified first.

Post by Yuri Gonzaga
- Interface to the board from software (Linux)
- Following the demo example, there are a lot of stuff to
understand in software and hardware sides
- Hardware side: SPI interface, FIFOs and anything else
needed to stablish communication using Cypress USB
device (used on e101 board)

Isn't this hidden behind a software abstraction layer when you use
Pico's driver? Anyway, it is good to be familiar with what goes on
under the hood.

Post by Yuri Gonzaga
- Software side: api initialization, write and read routines
- Revisit JtR to work with bcrypt on the board
- Actually, I revisited the code to found the right point to
call hardware.
- So, I need to finish this task

Sounds good.

Post by Yuri Gonzaga
Anything else?

See my replies to your messages on the separate topics.

Thanks,

Alexander

[Solar Designer]

Yuri -

Post by Solar Designer

Post by Yuri Gonzaga
- Run bflike on the board
- Report real results
- Real result means operation time?

Make sure that it works reliably - producing the correct results
reliably (without a single error) when run for a long time. I think
that you'll need to bump up Nrounds to a much higher value in order not
to saturate your USB link.

Correction: I meant Niter, not Nrounds. Please keep Nrounds at 2.

Alexander

[Yuri Gonzaga]

Post by Solar Designer
You mean a kernel module (not "process").

Yes. You are right!

OK. Perhaps you made progress at that since then?


Yes. But I still can't communicate my module.
Using the linux drivers and examples it's is being complicated to put
everything to work.
As I said previously, it is necessary to understand how to interface to
FIFOs and SPI channels in USB device on the board. So, I have done some
attempts but it is not working properly yet.

It looks like the windows approach is different. On linux, it is more
complex...

Isn't this hidden behind a software abstraction layer when you use

Post by Solar Designer
Pico's driver?

The problem is not the software side but the hardware one, where I have to
use all the signals correctly to read and write data through USB.

[David Hulton]

Yuri & Alexander,

I apologize for this. We only developed the 32-bit Windows side of
this so that's all I'm really experienced with and just recently got
it working with 64-bit Windows but haven't fully tested it. Are you
able to work on this in Windows? The examples make a lot more sense in
Windows and honestly none of us here have had a chance to play with
the linux code...

-David

Post by Yuri Gonzaga

Post by Solar Designer
You mean a kernel module (not "process").

Yes. You are right!

Post by Solar Designer
OK.  Perhaps you made progress at that since then?

Yes. But I still can't communicate my module.
Using the linux drivers and examples it's is being complicated to put
everything to work.
As I said previously,  it is necessary to understand how to interface to
FIFOs and SPI channels in USB device on the board. So, I have done some
attempts but it is not working properly yet.
It looks like the windows approach is different. On linux, it is more
complex...

Post by Solar Designer
Isn't this hidden behind a software abstraction layer when you use
Pico's driver?

The problem is not the software side but the hardware one, where I have to
use all the signals correctly to read and write data through USB.

[Solar Designer]

David,

Post by David Hulton
I apologize for this. We only developed the 32-bit Windows side of
this so that's all I'm really experienced with and just recently got
it working with 64-bit Windows but haven't fully tested it. Are you
able to work on this in Windows? The examples make a lot more sense in
Windows and honestly none of us here have had a chance to play with
the linux code...

Ouch. Does this apply to E-101 and USB specifically, or to your PCIe
boards as well?

Sure, it's possible for Yuri to proceed on Windows now, but this merely
postpones the problem. We'll need something that can be deployed in
authentication servers - both on software side (which means a Unix-like
OS) and on hardware side (which means PCIe).

I was under impression that E-101 was similar enough to your PCIe boards
in terms of software interface to it - that is, I thought that you'd
simply provide different OS drivers and different interfacing cores
(Verilog code or the like), which would mostly hide the difference from
us, and Yuri's code developed on E-101 would be easily reused on the
PCIe boards. Is this not the case?

How do you suggest we achieve our goal of getting something usable in
production by the end of Yuri's GSoC project?

Thanks,

Alexander

[David Hulton]

Alexander,

Ouch.  Does this apply to E-101 and USB specifically, or to your PCIe
boards as well?

This is just for the E-101, our other boards have really good Linux
support (M-501, etc). Windows was a higher priority for the E-101
because it's more of a board we use for training and most of our
customers do their FPGA development on Windows whereas the PCIe
M-modules are geared more toward the HPC server market so it was a
higher priority for them to run well in Linux..

Sure, it's possible for Yuri to proceed on Windows now, but this merely
postpones the problem.  We'll need something that can be deployed in
authentication servers - both on software side (which means a Unix-like
OS) and on hardware side (which means PCIe).
I was under impression that E-101 was similar enough to your PCIe boards
in terms of software interface to it - that is, I thought that you'd
simply provide different OS drivers and different interfacing cores
(Verilog code or the like), which would mostly hide the difference from
us, and Yuri's code developed on E-101 would be easily reused on the
PCIe boards.  Is this not the case?

Yeah, our APIs are very similar between the E-101 and M modules the
only difference is that the E-101 has much better support for Windows.
If Yuri does his development on Windows it will be easy to port it
over to the M modules on Linux...

How do you suggest we achieve our goal of getting something usable in
production by the end of Yuri's GSoC project?

For now I think the best thing is to do PoC in Windows on the E-101 so
he doesn't waste more time on trying to get the Linux code working.
This can be done by just synthesizing code and running/testing using
our PicoUtil software in Windows just to make sure the logic runs on
hardware. In the meantime I can set him up with remote access to a
Linux system here with an M-501 for the final implementation... Does
that work?

-David

[Solar Designer]

David,

Post by David Hulton
For now I think the best thing is to do PoC in Windows on the E-101 so
he doesn't waste more time on trying to get the Linux code working.

OK.

Post by David Hulton
In the meantime I can set him up with remote access to a
Linux system here with an M-501 for the final implementation... Does
that work?

Yes, this is probably the best we can do given the circumstances.

BTW, this will be needed not just for the final implementation, but also
to get the FPGA and software components of the hashing method working
together at all.

Thanks,

Alexander