<GitHub55>
[smoltcp] m-labs-homu commented on issue #136: :umbrella: The latest upstream changes (presumably c418b60b5db93753999ae51d33ec4dc1d1631c69) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/136#issuecomment-366131241
<GitHub139>
[smoltcp] m-labs-homu commented on issue #140: :umbrella: The latest upstream changes (presumably c418b60b5db93753999ae51d33ec4dc1d1631c69) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/140#issuecomment-366131280
<_florent_>
hartytp: thanks a lot for the tests on the HMC7043, that's something i wanted to do but haven't the right scope
<_florent_>
hartytp: the code is up to date, value are set to 0, but i was ajusting value manually
<_florent_>
hartytp: i also saw that i was not setting the mux correctly for the analag delay, but then i was trying with the digital delay, but was not able to see difference on the dac synchronization, so i was not able to conclude
<_florent_>
hartytp: if you want to continue testing, we should try to get the digital delay working.
<_florent_>
hartytp: one thing i was thinking about the digital delay is that we may need to set another register that would do the update
<_florent_>
hartytp: or that is must be program in a specific (undocumented order)
<_florent_>
hartytp: on tests that can be mabe is to change this value in the gui export
<_florent_>
hartytp: and reprogram the entire hmc7043 and see if it's digital delay is then working
<hartytp>
_florent_ thanks for the info!
<hartytp>
hmmm...
<hartytp>
let me look over the register map/datasheet and see what I can find
<_florent_>
hartytp: are you using the gui?
<hartytp>
no
<hartytp>
planning to use the registers you have there as a starting point
<hartytp>
am copying them directly to the rust code, and in parallel reading the datasheet to make sure I understand everything
futarisIRCcloud has joined #m-labs
<hartytp>
_florent_ if you want to try changing the digital delay with the GUI and then send me a diff that would be great
<hartytp>
_florent_ nb the register writes aren't as bad as they look; most of the writes in the code you exported just program registers to their defaults
<hartytp>
also, there are a few other things we probably want to change, like enabling "high performance" mode
<_florent_>
hartyp: yes sure, i'm going to do that
<hartytp>
_florent_ two questions for you, looking at regs 0xA and 0xB
<_florent_>
hartytp: sclkout1 digital delay set to 1, sclkout3 digital delay set to 3
<hartytp>
I would have thought that clkin0 was the input we're using, but that input buffer is disabled
<hartytp>
thanks!
<hartytp>
_florent_ well, other question is do you understand the termination settings, the datasheet is a bit vague
<hartytp>
you have the high-Z input setting enabled, but not totally sure what that does...
<rjo>
hartytp: do a synoptic datasheet reading with the hmc7044.
<hartytp>
does the 7044 give more info?
<rjo>
hartytp: sure. it disentangled the labeling.
<hartytp>
okay, will have a look, thanks!
<_florent_>
hartytp: sorry i have to go, i'll try to answer your question a bit later
<hartytp>
np
<rjo>
clkin0/rfsyncin (44) is rfsyncin (43) and clkin1/fin is clkin (43)
<hartytp>
yes, that's what I assumed from the fact that _florent_'s registers worked
<larsc>
I hope to get on the phone with the designer of the HMC7044 next week, if you have any questions I can try to sneak them in
<hartytp>
_florent_ digital phase shift may be fine.
<hartytp>
need to look more carefully, but you are using the div/2 on the clock input, so AFAICT the digital phase shift shifts by a complete cycle of the 1.2GHz clock, so I don't see it
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<hartytp>
_florent_ a lot of those register writes are to read-only registers
rohitksingh_work has quit [Read error: Connection reset by peer]
attie has quit [Ping timeout: 260 seconds]
attie has joined #m-labs
<rjo>
larsc: thanks! i'd like to know where the 7044 git its "upper half" (the PLL part that the 7043 is lacking) from. is that a new design? and what's his take on choosing between hmc830 + hmc7043 over hmc7044 (for simplicity and performance)?
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
rohitksingh has joined #m-labs
<larsc>
rjo: you mean if the pll section is taken from a differnt part?
<rjo>
larsc: yes. specifically what the pll heritage of the hmc7044 is. is it the hmc830? the register interface looks pretty different.
<larsc>
I believe it is anew design, but I'll ask
rohitksingh1 has joined #m-labs
<GitHub189>
[artiq] sbourdeauducq commented on issue #902: Yes, my code completely discards oversized packets on purpose. If you truncate them, they will fail FCS and get discarded later - why do you want to keep this behavior? https://github.com/m-labs/artiq/issues/902#issuecomment-366239749
rohitksingh1 has quit [Quit: Leaving.]
<whitequark>
sb0: probably has little to do with path?
<whitequark>
given that it always worked before
<whitequark>
i'll take a look in a moment
<hartytp>
anyone know which 7043 outputs we're planning to use out of: GTP_CLK{1,2}, FPGA_DAC_SYSREF, {AMC, RTM}_MASTER_AUX_CLK?
<hartytp>
yes, both digital and analog phase shifts work
<hartytp>
nb previously you were shifting the SYSREF by 180deg steps relative to the 600MHz DAC clock because you were using the input divider instead of the channel dividers
<hartytp>
may explain the lack of DAC synch errors...
<hartytp>
regs labelled wtf are set by eval software but not mentioned on HMC7043 datasheet...
<hartytp>
or have a different value to the defautls without any explanation.
<hartytp>
okay, unless anyone has any comments about that code, I'll tidy it up and submit a PR
<sb0>
hartytp, no regression on either DAC? PRBS etc. passing?
<sb0>
if so this looks awesome, thx
<hartytp>
haven't checked that
<hartytp>
not sure PBRS was passing on my board anyway :(
<hartytp>
but, what I have done is to check that both DAC_CLK and DAC_SYSREF outputs have the correct frequency and that I can shift the both SYSREF phases using the analog and digital modes
<hartytp>
if that works, it's not likely that any PRBS issues would come from my changes
<sb0>
ah. it passes on the HKG boards without - for once - any problem (if there hasn't been some other DAC init issue before).
<hartytp>
okay, will check in a bit (atm, my code just loops changing delays so I don't get to the PBRS rests)
<hartytp>
let me fix the last few issues with the code and then submit a PR so you can look at PBRS on your board
<hartytp>
okay, feel free to change the FPGA_DAC_SYSREF to LVDS if you want, but my guess is LVPECL is better in the long run
<hartytp>
you need the jitter on those outputs to be very low
<_florent_>
ok
<hartytp>
whoo! So, the phase shifts now work and nothing is obviously borken from my end
<hartytp>
I'll leave that there for now, but let me know if anything else comes up
<_florent_>
hartytp: great, then i'll be able to do more tests on sc1
<hartytp>
good
<hartytp>
good luck :)
<GitHub93>
[smoltcp] jonaskeller commented on issue #93: Looking at ARP packets from the FPGA in all packet captures since then, I don't see an instance besides those mentioned above. I have to admit that I haven't been constantly monitoring it, though - this is more a side-effect of looking into other issues. https://github.com/m-labs/smoltcp/issues/93#issuecomment-366290379
<hartytp>
note to self: check the output resistors and input terminatio
<hartytp>
sb0: one final thing, there are probably a few more places in the build scripts that you need to remove the 7043 csv stuff.
<hartytp>
hmmm...one other piece of good news
<hartytp>
I now see ramps on all channels with no issues with the JSED links dying
<hartytp>
!
<hartytp>
so, I get clean RM
<hartytp>
RF
<hartytp>
(well, looks clean by eye -- no obvious junk)
<hartytp>
If it weren't for the RAM issue I'd love to put this on a specturm analyzer
<hartytp>
with the SAWG
<hartytp>
well, I see some quantization noise and somethign with approx 720ps period, but nothing that's clearly unexpected. Need a spectrum to know more
<GitHub67>
[smoltcp] fintelia commented on issue #166: I also like that this proposal has the potential to enable smoltcp to be used for only part of a network stack. As best I can tell, this isn't really possible right now (though if it is, I'd be interested to hear!) https://github.com/m-labs/smoltcp/issues/166#issuecomment-366346456
<GitHub108>
[smoltcp] batonius commented on issue #166: @whitequark It would be nice to be able to use `std`-depended crates for some fancy data structures, for example, something `managed` won't support. Then again, with the proposed scheme, there's nothing stopping Redox from implementing its own routing layer using whatever we want and then just putting it in between stock layers. https://github.com/m-labs/smoltcp/issue
hartytp has joined #m-labs
<hartytp>
rjo: looking at one of the faster ramps I see a bit of a staircase pattern with small but quite noticeable discrete steps in the output level.
<hartytp>
This is as expected for a DAC without an AA filter.
<hartytp>
rjo: "larsc: thanks! i'd like to know where the 7044 git its "upper half" (the PLL part that the 7043 is lacking) from. is that a new design? and what's his take on choosing between hmc830 + hmc7043 over hmc7044 (for simplicity and performance)? "
<hartytp>
fwiw, I still think that, for our particular case, the HMC7043 + HMC830 is the right option
<hartytp>
IIRC the 830 noise is a bit lower
<hartytp>
the 7044 has a bunch of features that we don't want to use, and which could cause issues
<hartytp>
and, it's nice that the 830 is a separate chip, so we can debug it separately from the 7043
<hartytp>
obviously, if we don't get the 830 working soon I'll change my mind on that
<hartytp>
but, I do like that I can stick a scope probe on the 830 output and confirm that there is no rf present -- despite the fact that the registers are programmed correctly
<hartytp>
it this was a node internal to the 7044 then we couldn't probe it to figure out the issue.
<hartytp>
these mammoth all-in-one chips are great when they do exactly what one wants, but can be a pain otherwise
hartytp has quit [Quit: Page closed]
<rjo>
hartyp: the ramps are doing much bigger steps than the dac quantization.
<rjo>
hartypt: that's an argument against integrated circuits in general. imho the risks are different. the matching argument pro integration is that it prevents all classes of design and implementation issues and wins in terms of cost, power, and size.
hartytp has joined #m-labs
<hartytp>
rjo: i take that point, but it's still my opinion that the HMC7044 wasn't the right choice for what we wanted to achieve. Just too much unused complex functionality.
<hartytp>
There is always a trade-off between modularity and integration
<hartytp>
modularity gives simple blocks which can be intedepdently developed and tested. It also allows one to pick components that give exactly the features one needs for one's application, rather than one-size-fits-all solutions which usually have many more features than one needs
<hartytp>
In my view, for our particular use case, those benefits (together with, IIRC, the lower noise performance of the 830) outweigh the benefits of the integration provided by the 7044.
<hartytp>
e.g. what would the power saving of switching to the 7044 be as a fraction of the power budget of Sayma? More than a rounding error? Same for the cost.
<hartytp>
Once we scrap the clock mezzanine, remove the RF BP, potentially remove the ADCs Sayma has plenty of free board space, so I don't think that the board area saved by the 7044 is a benefit
<hartytp>
anyway, there's no point having an argument about this -- we have the solution we have and there's no strong argument I can see for ripping that up and starting again (unless we really can't get the 830 to work properly, but that still seems unlikely)
<hartytp>
and, asking a designer "which approach is better, the 7044 or the 830" seems a little naive. It's totally application dependent, so the only sensible answer is "it depends on what you want to achieve"
hartytp has quit [Quit: Page closed]
hartytp has joined #m-labs
<hartytp>
"hartyp: the ramps are doing much bigger steps than the dac quantization. "
<hartytp>
hmm...well, I saw a staircase pattern on the raw DAC output.
<hartytp>
I haven't looked at the ramp generator code closely, so not sure what to expect