<GitHub86>
[artiq] sbourdeauducq commented on issue #837: Does it make sense that Oxford send us some problematic devices so that we can reproduce this locally? We also have a 1G switch here, I can try connecting the KC705 through it (it's on another 100M one at the moment for the current tests). https://github.com/m-labs/artiq/issues/837#issuecomment-339851457
<GitHub176>
[artiq] sbourdeauducq commented on pull request #842 dfe666b: I would call those consistently with ``io_config`` and with better names, e.g. ``clk``, ``ser_data``, ``latch``. https://github.com/m-labs/artiq/pull/842#discussion_r147309600
<GitHub41>
[artiq] sbourdeauducq commented on pull request #842 dfe666b: There are other shift registers in the system, e.g. for the Novogorny PGIA, with other lengths. It makes sense to make this function generic to transfer any number of bits (not just 32), document it, and move it into some library (e.g. ``artiq.coredevice.shiftreg``). https://github.com/m-labs/artiq/pull/842#discussion_r147309883
<GitHub105>
[artiq] sbourdeauducq commented on pull request #842 dfe666b: There are other shift registers in the system, e.g. for the Novogorny PGIA and the Zotino LEDs, with other lengths. It makes sense to make this function generic to transfer any number of bits (not just 32), document it, and move it into some library (e.g. ``artiq.coredevice.shiftreg``). https://github.com/m-labs/artiq/pull/842#discussion_r147309883
<GitHub115>
[artiq] sbourdeauducq commented on pull request #842 dfe666b: And this function could be turned into a device that uses and depends on the TTL devices, just like the DAC driver that depends on a SPI device for the data and a TTL device for LDAC. https://github.com/m-labs/artiq/pull/842#discussion_r147310046
sb0 has quit [Quit: Leaving]
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 260 seconds]
bunnie has quit [Ping timeout: 260 seconds]
<GitHub66>
[smoltcp] pothos commented on issue #62: Thanks for looking at it, now I have to read the RFCs along with the code. Rightnow I don't see where the retransmit would be involved… I'll continue tomorrow. https://git.io/vFJSp
<GitHub186>
[smoltcp] pothos commented on issue #62: Thanks for looking at it, now I have to read the RFCs along with the code and find out how the timer is supposed to be set and kept. https://git.io/vFJSp
<rjo>
sb0: are you asking how to generate 13 GHz RF? or raman?
<rjo>
i can dig out phd theses for you
<sb0>
RF, for sending microwaves into a trapped ion
<sb0>
apparently this needs a sizable amount of power, they're saying 4-20W
<rjo>
oscillator, switch, amplifier, antenna. that's it.
<sb0>
yeah I digged out some devboards they can use
<sb0>
they == the team in Zhuhai
<rjo>
what rabi rate do you need?
<sb0>
10us
<rjo>
why that short?
<sb0>
I don't know
<rjo>
then yes. that power sounds about right.
<rjo>
get a big amplifier or build a near-field antenna into the trap.
<rjo>
or do raman
<rjo>
sb0: any progress with ethernet on sayma?
<sb0>
haven't looked into it
<rjo>
what's the plan?
<sb0>
_florent_ was going to have a look
<sb0>
my plan is to get the Zotino support in tree (shouldn't be much work) and then fix the DMA/SED bug
<rjo>
you are not working on sayma at all?
<sb0>
not at the moment, will look into my clocking code after DMA, if _florent_ hasn't done so already
<sb0>
but the boards are up and you can use them from the server. one has the 1V8 problem, but the other one looks solid. both have RTMs installed. the 3rd one is powered down as it is regularly affected by the 1V8 bug.
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.3.0/20170811091919]]
<rjo>
whitequark, sb0: is there an issue to track the rtio_counter transfer problem? do you have a repro?
<whitequark>
rjo: not an issue, and I have a very bad repro that needs to be reduced
<whitequark>
what's more important, this or ethernet?
<rjo>
you do ethernet. i was trying to get a better understanding of the rtio/sed/dma/rtio_counter issue complex.
<rjo>
whitequark: on ethernet, i have a netgear gs110tp here. if you want to test on that.
<whitequark>
rjo: that doesn't seem to match either of the netgear switches cjbe uses
<whitequark>
I can try, sure, why not
adamgreig has joined #m-labs
<adamgreig>
hi all, using migen with a de0nano and trying to use some pins on gpio_0 as input and others as output, but the verilog puts the whole gpio_0[33:0] as output, eg: http://dpaste.com/2Q5BTX4 -> http://dpaste.com/2Q3BGEM
<adamgreig>
if I only use it as input it's fine, or if I put all inputs on gpio_0 and all outputs on gpio_1 that works too, but I can't find any way to split it up
<adamgreig>
do I need to change the de0nano.py platform file to break gpio0 into multiple entities so some can be in and some out, like the LEDs are?
<rjo>
adamgreig: that or use TSTriple().get_tristate() on the pin.
<adamgreig>
ah, I was looking at that but thought it wouldn't be relevant for things that i want to be fixed in/out for my whole design
<adamgreig>
thanks, I'll give it a go
<adamgreig>
I guess it's not unreasonable to make a new platform that describes what i've actually plugged in to each gpio, anyway
<rjo>
well not really ;) we have some mechanism for that. look at the FMC things in kc705. it's not perfect but duplicating the entire platform is worse.
<rjo>
it's also ok to inherit that platform and add another resource that has the pins split. resources exposing different use cases for the same pins is also fine. look at the quad spi and spi stuff in e.g. kc705 (iirc).
<adamgreig>
that latter sounds perfect, if I can inherit and then just add new resources for the things it's now plugged in to
<adamgreig>
gives them sensible names too
_whitelogger_ has joined #m-labs
_whitelogger_ has quit [Ping timeout: 246 seconds]
<adamgreig>
aiming for a little baseband comms demo, with a prbs, pulse shaping, gaussian rng, various receiver things, and fast adc/dacs. just for fun really
<adamgreig>
with sort of half a view of replacing a 25 year old undergrad lab that does something similar but in discrete logic :P
<sb0>
cool, I guess you've seen the artiq phaser code
<sb0>
/sawg
<adamgreig>
very briefly
<adamgreig>
I was just going to hook up a 100MS/s parallel ADC/DAC to some gpios
<adamgreig>
I plan on writing everything from scratch as a learning exercise but it's very helpful to have some actual implementations to reference, especially for general migen project structure and stuff too