I would not trust a logic simulator to do this work. There
is too much "simplification". A flip-flop sampling delay has
significant variation as your setup time approaches the
metastable point and somewhere, the captured states will
be unreliable before turning reliable again.
You might (if you get any capture, and why wouldn't you?)
apply a secondary layer of logic to determine the "most
likely center" of the "wavefront" as it slides past the clock
edge. There should be unbroken stretches of "0", a few
bits' worth of "flicker" and then unbroken stretch of "1",
right? If you can "bound the flicker" and "pick the center
of that", maybe you can assign a center "more reliably"
than the raw registered bits.
I did something like this on a burst mode clock recovery
unit design, once.
You could also (as I did there) use a scheme where you
"clock the clock, with the data" - let each stage of the delay
loop clock in the same 10ns master clock (sets the frame?)
which you'd presumably upscale to get bit-count in time
domain; the 'flops will now capture sequentially and the
code-transition in that field "marks the spot". Might work
cleaner (or not).
I'll note that to make my thing work, I had to hand-design
the FFs and use complementary bare-clocking to cut the
setup time (front latch) and raw delay (back latch) and
even cheat by using low-VT "RF only" devices in the FF
clock legs. That's SPICE w/ full parasitics design. Not a
prayer of reasonableness from a logic simulator (what
would I do with a pile of timing violations? The cell library
the company had, couldn't even self-toggle (D=Q!) over
300MHz and I was on the hook for 400MHz (and a wee
bit of 800) with feedback logic between register stages.
Now imagine 10kGates worth of this done by hand, and
at-speed functional verification in Spectre being the only
available option. 3 years of my life that I ain't getting back.