Thank you. I successfully input my bitstream.
But I still get some problem which makes me confused.
Here is what I do:
I replace the original curve_mul_256.v with my own ecc algorithm (ECPM.v), also modify cw305_ecc_p256_pmul_top.v and cw305_reg_pmul.v file and do the simulation.
I think I get some promblems in these two lines
Rx = int.from_bytes(self.fpga_read(self.REG_CRYPT_RX, 32), byteorder=‘little’)
Ry = int.from_bytes(self.fpga_read(self.REG_CRYPT_RY, 32), byteorder=‘little’)
The “Target not done yet, increase clksleeptime” warning gives you a hint!
Maybe you need to increase CW305_ECC._clksleeptime (is your implementation slower than ours?).
Are you updating the REG_CRYPT_GO register when the operation is done? (you can see that this is what CW305.is_done() checks for before the above warning is reached).
It’s great that you have a working simulation; now work your way through what CW305_ECC.py does to run a capture to find what needs to be fixed.
Hi, thank you for your response.
But for this question “Are you updating the REG_CRYPT_GO register when the operation is done?”
How could I check the REG_CRYPT_GO register from the RTL code because the result from CW305.is_done() seems not don’t yet obviously, I think the update algorithm in rtl code is in the cw305_reg_pmul.v
the signal(busy_usb) will be down when the operation is done. and the reg_read_data will be 0, so the signal(busy) in the tb.v will go to 0.
I can’t see where is wrong actually. Is my work correct?
I don’t result = self.fpga_read(self.REG_CRYPT_GO, 1)[0] will read what signal corresponds to the hdl code?(is not corresponds to the busy signal from the 'REG_CRYPT_GO in wait_done task in the tb.v?
Can you check that you can reliably read and write registers from Python? E.g. write some random value to REG_CRYPT_K and verify that the same value is read back?
At this point if it were me, I would add ILAs to probe internal FPGA signals to figure out what’s going on. Start with the “go” and “done” signals and keep going from there.
Random thought: if you use X’s (unknowns) in your Verilog, it’s possible to have a mismatch between simulation and FPGA. X’s don’t exist on the FPGA, so the synthesis tool has to pick a 1 or a 0, and this may cause the design to behave differently from what you see in simulation.
ILAs allow you to observe your design’s internal signals on the real target FPGA, not the simulated one. You can instantiate ILAs wherever you wish. Our example is just that. Your design is different from ours so you may wish to probe different signals.
There is a bit of a learning curve to using ILAs, but they are an essential tool for FPGA development and definitely worth learning. It’s like the software developer’s debugger.
Alternatively, you can route internal signals to the CW305 GPIO header and use an actual logic analyzer or oscilloscope to probe them.
Hi, just want to make sure if my thought is right.
In the beginning, I just comment out curve_mul_256 U_curve_mul_256 in the cw305_ecc_p256_pmul_top.v and replace with my ECPM.v
And if I noticed that the bram width in the curve_mul_256.v is 32 bits, it means the computation of the ecc encryption in the curve_mul_256.v is 32 bits once?
Beause in my design I directly use 256 bits data to do the ecc encryption, this is my ecc algorithm verilog code register declare:
I want to ask about if the previous question(the bram cause) is correct, and I need to add bram to my design to save the computation data, should I use 32 bits width bram?Or I can use 256 bits for my design?
Thank you
Oscar
How is the CW305 connected to your PC?
In order to connect from Vivado, you need something like this connected to the CW305’s “FPGA JTAG” header (lower-right corner).
Hi I noticed that ecc encryption in the curve_mul_256.v is 32 bits input and 32 bits output, but in my design I want to use 256 bits input and 256 bits output, is it work?
Because I see vivado synthesis, it didn’t synthesis the
input wire [255:0] brom_g_x_dout;
input wire [255:0] brom_g_y_dout;
Again, the internal data path width is an implementation choices which is completely irrelevant to a functionally correct implementation.
Vivado (or any other synthesis tool) will remove any logic that is determined to not have any effect on top-level outputs. If you look at the synthesis log files, you will see messages indicating this. So it looks like your problem is a Verilog problem, not a CW305 problem.
If you can share your complete Verilog source code I can have a quick look to see if anything jumps out, but I can’t tell anything from those screenshots.
Hi, thank you for your help.
Here is my design ECPM.v that I use this to replace curve_mul_256.v
also I modify something in cw305_ecc_p256_pmul_top.v and cw305_reg_pmul.v cw305_ecpm.zip (13.3 KB)
What I can see in this source code looks fine.
The first thing I would check is whether the ECPM module is getting its clock (crypt_clk).
Are the red and green LEDs on the CW305 board flashing?
Hi, I successfully fix the synthesis didn’t match my RTL logic error through the warning message in synthesis(multi-driven and latch), thank you for your help.
Now I’m still working on LUTs number exceed the maximum LUTs of CW305 35T
