Conversation

Notices

1. Embed this notice
   Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:45 JST Andrew Zonenberg

   Going back to first principles on this debugging. Which is definitely not going to be done tonight.

   1) The baseline configuration (MULT_AREA_OPT=0), regardless of REGFILE_OUT_REG setting, works in hardware. It gives answers that match the NaCl curve25519 implementation to every query I've tried, and is interoperable with OpenSSH (when I put the bitstream on a board, I can SSH to it).

   With that in mind...

   2) The original test vector in my simulation that I had thought was wrong (because it wasn't lining up with observed behavior) is in fact correct.

   So *none* of my simulations, even with my recent hacks, are giving correct output. But the RTL synthesizes correctly and works in FPGA (at least, on Kintex-7... not yet tested on Trion)

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:42 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark can you explain why stage1_en and en, which will synthesize to the same signal, would behave differently in a clocked always_ff block?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 18:40:42 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg it's a race condition in zero time; try `assign` instead

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:43 JST Andrew Zonenberg

     in reply to

     The all zeroes output is intriguing to me as it suggests a timing error where something is perhaps reading an old value in simulation due to a flag being read incorrectly or something.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:43 JST Andrew Zonenberg

     in reply to

     Progress! This ugly hack is enough to make the baseline run with correct results in simulation.

     Now I have ground truth in simulation that I can validate other parts of the design against.

     I still do not understand why. If I don't do this, stage2_tmp.blocks[j] doesn't update the first time I assert en. and later on I get garbage results.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:44 JST Andrew Zonenberg

     in reply to

     So far the conclusion is... I can't.

     Simulating the same baseline RTL as I have working in synthesis, I expect 00a98249329ef0af94d3047370a21a2b8605cb775f344de032e8ca13a429231ce2 square to equal 00339257802109016f508d7a0225cd63d7e816d54a1b148cdfee8d601fd2568826

     And the first few intermediate results of individual multiplication passes should be

     00fd77fc
     010e9224
     00dee2c6
     00efeae0
     00cbd555
     00ee6b9a

     What I actually get out of Vivado simulator is 002f0196accc10b92a49c24bfe542abf4c8c0289aa825fa46e7d7e5f11870a386e.

     And the first few intermediate results in simulation are
     00000000
     00facc10
     010b3b3d
     00daf951

     Not even *close*.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 18:40:45 JST Andrew Zonenberg

     in reply to

     Next step (in progress) is to build an instrumented bitstream for my AC701 devkit that has ILA probes at various points so I can dump intermediate states of the known-working test vector.

     And then try to figure out exactly where my simulations of the *working* code are diverging from hardware behavior.

     I need to be able to trust my simulations before I even think about optimizing or debugging optimizations.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 18:42:37 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg oh wait I might've misunderstood

     do you have the full source uploaded somewhere?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 23:16:07 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg I can't answer this without seeing the actual source

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 23:16:08 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark there should be no races, there's no combinatorial loops or anything (to my knowledge). it's a single signal that seems to be magic wrt the clock such that you need a zero length delta T before you can use it

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 23:16:08 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark So it seems like the "en" signal was generated by a blocking assignment in the previous module.

     Somehow this confused xsim the following clock cycle. Refactoring the block to have an always_comb followed by a nonblocking register fixed it, although I don't understand why this should have produced different simulation results when both synthesize the same.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 23:16:09 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark I haven't pushed my latest changes gimme a few to sync what i have in my working copy

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 23:17:24 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg that being said, have you never heard of "simulation-synthesis mismatch"? Verilog has a ton of those

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 23:19:51 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg no linter?

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 23:19:52 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark Yes, and I generally try to avoid them :P

     This is clearly one I missed when originally writing the code. I was all over the place looking at the *new* code and somehow never thought to look at what was driving the enable signal.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 28-Jul-2025 23:25:05 JST ✧✦Catherine✦✧

     in reply to

     @azonenberg using a language full of footguns and not using a linter is the dictionary definition of living dangerously

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Monday, 28-Jul-2025 23:25:07 JST Andrew Zonenberg

     in reply to

     • ✧✦Catherine✦✧

     @whitequark Not as of now. And if vivado generated any warnings during synth (there were none in the simulation) they got lost in the sea of meaningless warnings like "optimizer was working as intended".