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
<sb0>
rjo, on the Sayma RTM, the Si5324 I2C will be programmed autonomously by the Artix FPGA
<sb0>
it won't go through any bus bridge
<sb0>
rjo, also, considering the funding available, I think we can already kill things like IPMI and playing with DC/DC converter monitors from the FPGA
<sb0>
the clock mezzanine also will be unsupported at this point
<sb0>
the onboard HMC830 should already be very good, as I understand
<sb0>
_florent_, any update on the Artix FPGA link? note that you don't have to use GTP, we have enough LVDS IO for using the IOSERDES (with phase detector)
<sb0>
there are RTM_FPGA_LVDS_1, RTM_FPGA_LVDS_2 and RTM_MASTER_AUX_CLK
<sb0>
(see Sayma schematics on github)
rohitksingh_work has joined #m-labs
<cr1901_modern>
What is the ARTIQ_EE section of the sinara repo?
larsc has quit [Remote host closed the connection]
lars_ has joined #m-labs
hartytp has joined #m-labs
<hartytp>
sb0, will you support user control of the clock muxes on Sayma RTM?
<hartytp>
if so, the clock mezzanine doesn't really require any additional support
<hartytp>
the PLL ICs are configured by pin-strapping on board
<hartytp>
HMC830 is pretty good, so the mezzanine isn't really needed for the DAC clock, but we intend to use it as a LO for our up converting mezzanine.
<hartytp>
cr1901_modern, this folder stores all PCBs designed using the "Xpedition Enterprise" software
<hartytp>
it's basically all the more complicated uTCA boards
<hartytp>
the simpler Kasli boards are made using Altium
hartytp has quit [Ping timeout: 260 seconds]
<rjo>
sb0: sure. i'd just put it onto the our feature list to have a handle in case somebody asks. it will come.
<rjo>
sb0: i also pushed back on all expectations re being able to do stuff with the i2c bus through the kernels.
<rjo>
hartyp, sb0: let's treat the digital pins of the clock mezzanine and the clock muxes the same way as e.g. the rf switches on allaki, i.e. for now as some non-rtio but still kernel-controllable devices that goes over DRTIO-AUX traffic and then over the RTM-AUX wishbone bridge.
hartytp has joined #m-labs
<sb0>
rjo, okay. the feature list I'm putting in that spreadsheet is the minimum to do interesting things with the hardware, considering the available funding in Joe's contract #2
<sb0>
so let's remove i2c gadgets etc. from there
<hartytp>
rj0: that works for me. On current plans, the only use of the clock mezzanine digital pins is the PLL locked indicators, so real-time control isn't important.
<hartytp>
sb0, rjo: thanks for doing this. I'm still unclear as to which features are funded atm, which makes it hard to plan things
<rjo>
sb0: ack. but we should nevertheless have one master feature list for "everything"
<rjo>
hartytp: ack. the troublesome things are where/if something is needed for (autononmous) bootstrap _and_ then later also should be accessible by kernels.
<sb0>
rjo, I would add those as for-contract artiq issues
hartytp has quit [Quit: Page closed]
<sb0>
rjo, I'm going to remove those lines from the spreadsheet, ok?
<rjo>
sb0: ack.
<sb0>
and afaict we don't really need any spi or i2c over drtio-aux
<sb0>
but gpio is nice to have
<rjo>
sb0: why don't we need spi over drtio-aux?
<sb0>
well, it's useful to enable DAC options
<sb0>
but I'd think this is low priority, though I don't have a strong opinion about it. do you disagree?
<sb0>
it's not a lot of work, so we can put it in sinara2
<rjo>
for attenuator settings, adc, dac, clocking config
<sb0>
we don't do clocking config here
<sb0>
getting one configuration to work will be a frustrating fight with the xilinx transceivers, and surely we'll have to start over again if we touch the clock because the CPLL will crap out or something
<rjo>
maybe not clock config. but attenuators definitely. unless it's all static. but for proper usefulness that should be controllable from the kernels.
<sb0>
shouldn't the RF switches be DRTIO?
<rjo>
as hard as it is to admit: sticking with the xilinx stack at least seems to gives you better debugging tools.
<rjo>
sb0: can bei either. for full usefulness yes.
<rjo>
so the stack is DRTIO link, AMC, RTIO2WB, WB-AUX link, WB-SPI core?
<sb0>
yes
<sb0>
just look at how many "answer records" they have about transceivers. even using the official shitware it still breaks all the time.
lars__ has joined #m-labs
lars_ is now known as larsc
<rjo>
ok. with that stack at least it will be transparent. yet potentially jittery from the clocking beat.
<sb0>
but yes, the official stuff also silently implements some of the fixes they figured out for their crappy silicon
<sb0>
I suppose we should actually have a different workflow for those things, have separate designs that have only transceivers and PRBS
<sb0>
reduces compilation times, and allows the use of the loopback debugging features which for once is a decent idea that the xilinx transceiver designers had
<sb0>
one advantage of the RTM FPGA is we can reload the ultrascale without touching the clock chips...
<rjo>
this is more about the source of the clock (from DRTIO or RF backplane) and less about the RTM FPGA, right?
<sb0>
one problem I have right now is that reloading KC705 FPGAs resets the clock chips, and they need to be reprogrammed at each attempt to get the transceivers to work
<sb0>
this go against the "minimal design with transceivers" debugging idea
<rjo>
sb0: SI5326_RST gets pulled low? can't you just not do that then?
<rjo>
sb0: the other problem seems to be implied by your brute force configuration method, right?
<sb0>
it seems it happens during JTAG loading. haven't looked into it much, and probably fixable with at some soldering in the worst case...
<sb0>
what other problem?
<sb0>
the "brute force" method does a regular initialization (as per the datasheet), then checks the comma position, and if it's not right restarts the initialization
<rjo>
afaict you are resetting the clock chip actively in the runtime.
<sb0>
indeed, but even without doing that, there is still some reset happening
<rjo>
or the init value for that register ist just 0.
<sb0>
iirc I had disconnected reset_n in the fpga design
<sb0>
probably a default weak pull-down problem
<rjo>
the i guess it's floating.
<sb0>
iirc as soon as you begin loading the new bitstream, the si5324 goes down
<rjo>
hmm.
<sb0>
probably some vivado options or soldering a pull-up would fix that, but haven't investigated yet
<_florent_>
sb0: about the Artix FPGA link: I'm not able to get RX working with the transceiver for now (probably a stupid issue but haven't found it yet...) so OK I'll use IOSERDES
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
key2 has joined #m-labs
<key2>
hi
<key2>
I have a weird behavour maybe someone has enconter before: I have a device that has an internal pullup, when I set a 0 with my FPGA, the device doesn't see it. as if the 0 was not letting enough current goes to the GND. Is there something to set that on a Xilinx (a bit like Drive strenght )
<larsc>
the minimum driver strengh is 4mA. You could do the math how small the pull-up had to be to be able to overwrite it
<key2>
thx
<key2>
it's the fuckin ARTY board from digilent that has 200R on its IO lines :(
<larsc>
but still the internal pull-up would have to be exeptionally small for it to be able to pull the node to logic 1
<key2>
looks like it is
kristianpaul has quit [Ping timeout: 245 seconds]
<cr1901_modern>
Well, the FPGA is sinking current at logic 0 on that pin, correct?
cr1901_modern has quit [Read error: Connection reset by peer]