sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<cr1901_modern>
sb0: It's meant to be a microcontroller. Perhaps pipelining isn't a huge deal?
fengling has joined #m-labs
kuldeep has quit [Ping timeout: 260 seconds]
kuldeep has joined #m-labs
<sb0>
avr is pipelined
<whitequark>
pic8 isn't pipelined
<whitequark>
it's also shit though
<whitequark>
seriously, 4cpi at 20mhz max, *and* memory bank switching means you can occasionally do one useful thing per 12 cycles
<sb0>
only student toy projects are not
<cr1901_modern>
sb0: PRUs aren't pipelined :P
<sb0>
yes, i tried using pic, then quickly switched to avr :)
<whitequark>
pretty sure pic has scarred me for life. i will forever remember starting on 16f628a
<cr1901_modern>
I like PIC b/c 5V and vintage shit. I HATE how difficult they are to program
<whitequark>
everything about pic is garbage (also, AVRs run on 5V...)
<sb0>
5V logic is slow and inefficient
<cr1901_modern>
Fair enough. I never really got into AVR.
<whitequark>
AVRs even run on 12V if you are brave enough
<whitequark>
(or so I'm told; that atmega8's survive Vcc=12V for more than several days, somehow)
<sb0>
yea, you can even connect dc motors to gpios directly. no freewheeling diode. or at least the arduino folks do it...
<whitequark>
interestingly I once killed a pin by connecting it to a FET without a resistor
<whitequark>
(to the gate, of course)
<cr1901_modern>
sb0: only student toy projects are not It's funny how both of us had uni projects to design a non-pipelined CPU that didn't resemble any modern CPU
<cr1901_modern>
pipelining made me dislike comp arch b/c of all the extra state that I have to keep in my head to track how a CPU works
<whitequark>
you could also use an abacus, that doesn't have any unnecessary state
<sb0>
non pipelining made me dislike comp arch because it was boring and the results were lame
<cr1901_modern>
I thought it was utterly fascinating to see that magic layer "peeled" away, even with a non-pipelined CPU
<sb0>
what do you learn anyway designing a non pipelined cpu? hardware wants to be parallel
<sb0>
you might as well write a trivial emulator in C
<cr1901_modern>
C doesn't tell me how voltages on the wires move electrons to do math
<sb0>
neither does verilog
<cr1901_modern>
It did for me. We went over how memory/flip flops work physically, how verilog is (supposed to) convert to gates, and then stepped through clock cycles of a stupid useless CPU to see how the voltages changed
<sb0>
alright, maybe, but then the next question should be how to pipeline
<cr1901_modern>
At that point, it became less enjoyable for me b/c while pipelining is wonderful for performance, and there is definitely a nice transition from "non-pipelined" to "pipelined" if you design your datapath right, dealing with all the possible hazards became too much for me to handle without help.
<cr1901_modern>
I guess I was just "too stupid" to understand all the possible things that could go wrong once pipelining was introduced
<cr1901_modern>
whitequark: Not sure I get the "abacus" comment :P. I don't think state is "bad". I am just frustrated that I hit a wall for being to understand even simple MIPS-like CPUs.
<sb0>
you will get similar problems in many semi-complex hw design projects. it's a good exercise.
<cr1901_modern>
sb0: I've gotten better with dealing with complexity/recognizing my limits since that class (this was 4 years ago, btw). I'm also smarter now than I was back then. But I still hesitate lmao. I have batted around a pipelined Migen RISC-V at some point to get past that wall.
<sb0>
whitequark, if I understand correctly: if you input a clock to the Si5324, turn it off, then input another, it is capable smoothly transitioning its output?
<GitHub145>
artiq/phaser 5f7229e Robert Jordens: ad9154: tweak jesd prbs test
<rjo>
_florent_: have you had a chance to look at my use of the jesd204b core?
<whitequark>
sb0: hm, I'm not sure about "smoothly", let me recheck
<rjo>
_florent_: still no luck with SYNC_LOCK. it does however release SYNC at some point, otherwise your core doesn't become _ready.
<rjo>
whitequark: it has that holdover thingy
kuldeep has quit [Ping timeout: 260 seconds]
<sb0>
yes, but is the holdover activated automatically, and what happens to the output when it is enabled/disabled?
<rjo>
whitequark: i am getting very frequent 502s and 504s from irclog.whitequark.org
<whitequark>
rjo: looking into it
_whitelogger has joined #m-labs
<whitequark>
rjo: fixe
<whitequark>
*fixed
<whitequark>
some crawler found a URL to a special command that evidently no one used before (and I forgot to test after migrating to postgres)
<rjo>
whitequark: ack.
rohitksingh has quit [Read error: Connection reset by peer]
<rjo>
_florent_: your clocking doesn't make sense to me. with 5 G line rate, you transmit 250 M samples. with a 500 mhz dacclock, that would need 2x interpolation.
kuldeep has joined #m-labs
<whitequark>
sb0: I don't think Si5324 can do what you are saying
<whitequark>
as far as I see, it supports this: "The Si5324 supports hitless switching between the two
<whitequark>
synchronous input clocks "
<whitequark>
it can smoothly transition from presence of external clock to absence of external clock (i.e. to digital hold)
<whitequark>
it can also smoothly switch from one external clock to another, if both are present
<whitequark>
but I don't think it can go from external clock 1 -> no clock -> external clock 2 without any phase change
fengling has quit [Ping timeout: 268 seconds]
<sb0>
there would be a phase (and frequency) change, of course
<sb0>
and this is what I want
<sb0>
but I want it slow and without glitches, "hitless" as they say I guess
<whitequark>
it says "two synchronous input clocks"
<sb0>
yes, I also saw this from the datasheet, and the transition to "digital hold"
<whitequark>
doesn't that preclude them from having two different frequencies?
<sb0>
but it's rather vague, and if it can do that, it's not impossible it can do what I want
<whitequark>
I think I see what you mean, yes
<sb0>
the clocks I'd be switching would have the same frequency within the precision of a crystal.
<whitequark>
let's see what GR-253-CORE says
<whitequark>
oh, it's a telecom standard where the table of contents alone is 20 pages...
<sb0>
during the switch, there would also be a period during which the clock input is garbage, and idk if the Si5324 would detect/ignore/recover from it without messing up its input
<sb0>
or if I should manually keep it in digital hold while its input is unstable
<sb0>
*messing up its output
fengling has joined #m-labs
<_florent_>
rjo: starting working on the jesd, I'm going to run the transport layer tests. You are right for the clocking, it seems weird.
<_florent_>
rjo: but it seems consistent with the working setup of larsc:
<GitHub48>
artiq/phaser 18d18b6 Robert Jordens: phaser: add sync ttl input for monitoring
<GitHub48>
artiq/phaser f5f7acc Robert Jordens: ttl_simple: add pure Input...
<GitHub48>
artiq/phaser e27228f Robert Jordens: ad9516: duty cycle correction
<rjo>
_florent_: 5g qpll works here
<_florent_>
rjo: ok good thanks
fengling has joined #m-labs
<_florent_>
rjo: first tests results with 10G: I tweaked transceiver initialization (bypasse the last states) to get transceiver ready (will investigate)
<_florent_>
rjo: with this CGS is OK, 3 lanes are fine for ILAS, 1 not
<_florent_>
rjo: so not so bad for a first test
<rjo>
_florent_: good.
<rjo>
_florent_: if you don't mind i'd like to focus on the transport layer stuff first before moving to faster rates.
<_florent_>
rjo: yes that's what I was going to do, I was just doing a quick test
<rjo>
_florent_: ack.
fengling has quit [Ping timeout: 268 seconds]
<rjo>
whitequark: when you get to the lab, could you reset the scope?
<whitequark>
rjo: ok
<whitequark>
what are you doing with it, I wonder?
<rjo>
whitequark: setting it up to capture the dac outputs. i have no idea why and when it crashes.
<whitequark>
don't you get a response to every command you send?
<whitequark>
or do you pipeline those
<rjo>
whitequark: i am not doing anything fancy. just a handfull of vxi11 commands.
<rjo>
whitequark: i am checking for errors every few commands
<whitequark>
rjo: tomorrow i get the esp8266s so i'll actually rig those up such that you can reboot
<whitequark>
well, assuming the SCR can be directly controlled by GPIOs...
<rjo>
whitequark: yay.
<rjo>
_florent_: hmm. are you sure that the polarity of sync is "correct"?
<_florent_>
the sync we are using for the core?
<rjo>
_florent_: SYNCOUT0+-
<_florent_>
rjo: yes, it's 0 before CGS, 1 after
<_florent_>
rjo: I was triggering my analyzer on this signal
<rjo>
_florent_: yes. does it remain 1
<rjo>
?
<_florent_>
rjo: yes
<rjo>
_florent_: for me it doesn't.
<_florent_>
rjo: ah ok, I haven't checked on the last implementation, I'll do that
<rjo>
_florent_: even before (with cpll) it went 0 again.
<_florent_>
rjo: ok I'll look at that here
<rjo>
_florent_: is it correct that the core would not do ILAS when SYNC never went high?
<_florent_>
rjo: yes sync is triggering ILAS
<rjo>
_florent_: ack. so it does go high at some point.
<rjo>
_florent_: high meaning "1".
<_florent_>
rjo: I redirected sync to a led, it stays at 1 here
<_florent_>
rjo: going to test with your sync config
<rjo>
_florent_: i compared our dac config sequences and can't find any significant difference. even after testing out a few of those differences.
<_florent_>
rjo: I also see that when I do a prbs test, sync goes to 0 which is the correct behaviour
<rjo>
_florent_: yeah that's fine
<rjo>
_florent_: can i merge the phaser branch in jesd204b into master and delete the former?