Notices by Andrew Zonenberg (azonenberg@ioc.exchange)

https://github.com/raspberrypi/rp2350_hacking_challenge_2

Some of my proudest achievements as a hacker have been those that resulted in rule changes.

Like the time that we came back to a CTF a year after Fun Things (tm) happened and the player, judge, and staff shirts were all different colors.

I think this is up there too.

Asking for no reason whatsoever: Lots of oscilloscopes have protocol decodes for various flavors of Ethernet.

Have you ever encountered one, from any manufacturer, that is able to decode 100mbit ethernet in real time without dropping packets?

@dalias @becomethewaifu oh interesting.

I assumed it was spyware but figured it was mostly just the PRC making sure you're not sharing rubber ducky gifs or something

@dalias @becomethewaifu (since all of my attempts to run either WeChat or Whatsapp or the other supported messengers in a VM or emulator resulted in pain... probably not the app's fault, just android being android)

@dalias @becomethewaifu That (minus the VNC) is what I do for WeChat already.

@becomethewaifu @dalias Mobile deposit is evil.

My bank used to (until ~5 years ago) allow me to scan a paper check and upload front/back side jpegs through the website.

There are exactly zero security features in a paper check that you can't trivially forge well enough to fool a phone camera. It makes no difference if the image is coming from a camera or a flatbed scanner or what. The numbers and amounts are what matters and they'll be reconciled with the sending bank when the check clears.

I'm very tempted to get a dedicated phone just to do mobile deposits of the few checks a year I have to cash, so I don't have to ever install the app (and so I don't have to trust my banking credentials to my phone rather than the isolated VM I normally use)

@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".

@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.

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

@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.

@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

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.

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)

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*.

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.

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.

@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?

@whitequark Ok so I figured out *that* one, it was multiple drives in the testbench due to a copy paste error (trying to instantiate two different implementations of a module for A/B comparisons and I mistyped the output signal name).

No idea how it did this instead of outputting an X on conflict.

I feel like something is fundamentally broken with my simulation setup and I have no clue what it is.

Look at stage3_en here. There are no negedge clocked blocks in my RTL.

This is a simple always_ff @(posedge clk) stage3_en <= stage2_en;

How is this even possible???

@whitequark Are you just talking synchronization primitives, or actual thread creation emulated somehow by a cooperative multitasking mechanism?