<sb0>
it's just a github permission issue it seems
stekern has quit [Ping timeout: 260 seconds]
<whitequark>
done
<sb0>
thanks
<sb0>
whitequark, why did the DDS programming get a lot slower?
<whitequark>
sb0: not sure.
<whitequark>
haven't looked into it yet
stekern has joined #m-labs
stekern has quit [Ping timeout: 260 seconds]
stekern has joined #m-labs
stekern has quit [Ping timeout: 244 seconds]
stekern has joined #m-labs
stekern has quit [Ping timeout: 260 seconds]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
stekern has joined #m-labs
<sb0>
whitequark, the si5324 is not working.
<sb0>
output is not toggling at all as far as I can tell
<whitequark>
hm, odd.
<whitequark>
oh, I know what's wrong
<sb0>
btw, regarding the crappy lab wifi, it does seem that the problem was my broadcom card and upgrading the kernel fixed it
<whitequark>
ack
<whitequark>
sb0: fix pushed
<sb0>
I'm using both kc705s right now, let me know if you need to touch them
<whitequark>
ok
<whitequark>
hm, this pulse_rate_dds problem is puzzling
attie has quit [Ping timeout: 248 seconds]
attie has joined #m-labs
<sb0>
whee, drtio link init passes
<whitequark>
excellent
<whitequark>
so, it's puzzling because there was literally no change in those parts
<sb0>
hm, almost
<whitequark>
the DDS stuff is still in C and there wasn't any change on the compiler side
<whitequark>
and I have removed the code that proxied stuff through Rust
<whitequark>
so... it should be directly resolved, as before...
FabM has joined #m-labs
<sb0>
fucking xilinx garbage
<sb0>
resetting the RX part of a transceiver disturbs the TX
<sb0>
is there any single Xilinx IP block that doesn't suck?
stekern has quit [Ping timeout: 260 seconds]
kuldeep has quit [Ping timeout: 245 seconds]
sandeepkr has quit [Ping timeout: 265 seconds]
sandeepkr has joined #m-labs
<cr1901_modern>
Are there two separate resets (one for RX/TX)?
<cr1901_modern>
I mean, not that I'm defending hard IP blocks, but that seems fairly standard that a reset would clear both queues
stekern has joined #m-labs
<sb0>
there are two separate resets (and then some more), but for some reason they interfere with each other
<cr1901_modern>
Sounds like an IP bug. Perhaps contact Xilinx on their forums so they sit on it and do nothing :)?
<sb0>
whitequark, are you sure the si chip is configured for "hitless" clock transitions?
<whitequark>
sb0: I don't think you can configure that
<whitequark>
or at least, not as far as I'm aware. I can go through everything again if you want.
<sb0>
yes. the behavior I'm seeing right now is weird, I don't know if it's from the Si chip or not...
kuldeep has joined #m-labs
<sb0>
there's something fishy about the clock, but maybe it's just that xilinx's little snowflake PLL must be powered down when the input clock is not valid and then reset
fengling has quit [Ping timeout: 268 seconds]
sb0 has quit [Quit: Leaving]
sandeepkr has quit [Ping timeout: 260 seconds]
sandeepkr has joined #m-labs
rohitksingh has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
stekern has quit [Remote host closed the connection]
<hilmipilmi>
If you want to read quartus binary format (3des) or xilinx synthesis format (custom aes keys) drop me a line. All have been reversed: pilmihilmi@tutanota.com
fengling has joined #m-labs
<whitequark>
wtf just happened
<sb0>
hilmipilmi, so what do those commands do exactly?
<hilmipilmi>
They unlock the private key that is used with all simulation files of Xilinx
<sb0>
doesn't work here
kuldeep has joined #m-labs
<sb0>
oh it does
<cr1901_modern>
hilmipilmi: huh... how'd you figure that out?
<cr1901_modern>
oh, reversed
fengling has quit [Ping timeout: 268 seconds]
<hilmipilmi>
yes. vivado is doing the obviouse. know how rsa password works and you can set a breakpoint.
<cr1901_modern>
I wouldn't even know WHERE to set the breakpoint
<hilmipilmi>
in america this is illegal stuff. in japan also. actually this is only one part. the synthesis files are protected by aes static keys. they are different depending on type:
<hilmipilmi>
XlxV50EB marked ttcl files: first split into chunks then aes decrypt with -K b0e430fb8e024fb4ac0732270d9c3a88 -iv 2c7f9eebae5d40bb8f6bc0b5ef240526
<hilmipilmi>
Or XlxV64EB: aes-256: -K 57d2680c0ad24bd38cfc2f0842da67e5791207b8178042918dd7fc23b284d13a -iv 18c9fbce90144be997f910fa993fe28f
<cr1901_modern>
Does this work w/ ISE (only thing I have installed)?
<hilmipilmi>
tries only for vivado
<hilmipilmi>
ncsim rc5 encryption is also broken: iv0,iv1: 0x65646163 0x65636e and key: 0x93, 0x98, 0x62, 0xca, 0x1f, 0x7a, 0x4e, 0x5b. round count: 20
<hilmipilmi>
vcs is basically shit. It lets you debug with gdb.
<cr1901_modern>
vcs? And what protections are there to prevent gdb debugging?
<hilmipilmi>
vivado protect against gdb, unless you patch. To patch you need to remove dll crc check. Then you can gdb debug. vcs does no protect.