sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
proteusguy has quit [Ping timeout: 240 seconds]
<sb0> _florent_: I meant, the variation is always ~55ns
proteusguy has joined #m-labs
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/afe4405becdbc76539f0195c319367187012b05e
<GitHub-m-labs> migen/master afe4405 Sebastien Bourdeauducq: sayma_rtm: add si5324_clkout_fabric and rtm_master_aux_clk
<bb-m-labs> build #368 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/368
rohitksingh_work has joined #m-labs
jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined #m-labs
<sb0> _florent_: btw what python distribution do you use on windows?
jevinski_ has joined #m-labs
jevinskie has quit [Ping timeout: 245 seconds]
<GitHub-m-labs> [artiq] sbourdeauducq pushed 3 new commits to master: https://github.com/m-labs/artiq/compare/ec8560911fb1...bdb6678cec10
<GitHub-m-labs> artiq/master fa3b401 Sebastien Bourdeauducq: hmc830_7043: document sayma clock muxes
<GitHub-m-labs> artiq/master d3c608a Sebastien Bourdeauducq: jesd204sync: reset and check lock status of DDMTD helper PLL in firmware
<GitHub-m-labs> artiq/master bdb6678 Sebastien Bourdeauducq: nix: bump migen
<bb-m-labs> build #2363 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2363
proteusguy has quit [Remote host closed the connection]
<keesj> any arty board you guyes recommend from this list https://store.digilentinc.com/arty
<bb-m-labs> build #2364 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2364
proteusguy has joined #m-labs
<sb0> you have to appreciate SiLabs interface design. the si5324 reset# pin has a built-in pull-up, so, fixing the sayma bug is as simple as cutting the trace
<sb0> unlike basically every other silicon vendor, they do put some thought into how their chips are actually going to be used and what mistakes will be made
rohitksingh has joined #m-labs
<sb0> (I'm trying to move DDMTD to the RTM FPGA right now, so I need both HMC and Si at the same time)
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #m-labs
<_florent_> sb0: so not sure i could advice on the best python distribution on windows (i'm using the official one) and i switched to linux for most of my work
<_florent_> keesj: i would recommend the original arty, the fpga is already large enough to do interesting things, the S7 variants don't have ethernet
rohitksingh has quit [Ping timeout: 250 seconds]
hartytp has joined #m-labs
ohsix has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
<hartytp> afaict this returns a 17-bit signed value, stored within the bottom 17 bits of an int32
<hartytp> so, doing arithmetic directly on the returned value does not work
<hartytp> wrap all signed reads with something like https://hastebin.com/qihuyikivu.py
<hartytp> ?
<keesj> the 17 bits (18 bits according to the documentation) are signed. I would expect (but don't know) the msb bit to be the sign. and to me this is also what your code tries to handle but the documentation looks odd
<keesj> e.g. Convert signed numbers stored in the LSB of an int32 to a 32-bit signed number
<keesj> well perhaps it does. but an other problem (byte order) also can happen here.
<hartytp> yes, it's basically fixing twos complement representations when only the lower 17 bit have been set
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Quit: Leaving.]
keesj has quit [Ping timeout: 246 seconds]
keesj has joined #m-labs
<keesj> so.. flash_boot_address is for the rom(bios.bin) code to know where to load the next stage (e.g. some userland/app) but is not related to the load address of the rom code
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: @jordens another thing I don't understand:... https://github.com/m-labs/artiq/issues/1256#issuecomment-459299677
rohitksingh_work has joined #m-labs
<keesj> or does spi get mapped to address 0 and used this flash_boot_address to load from spi at this given offset
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] hartytp opened issue #1258: SUServo coefficient readback https://github.com/m-labs/artiq/issues/1258
<GitHub-m-labs> [artiq] jordens commented on issue #1256: Could you check whether this is a regression from release-4? There were the new rtio register API and the compiler changes. https://github.com/m-labs/artiq/issues/1256#issuecomment-459308943
<GitHub-m-labs> [artiq] jordens commented on issue #1256: Well 4.0 if the compiler change already landed in releaee-4. https://github.com/m-labs/artiq/issues/1256#issuecomment-459309272
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: @jordens I'll have a look at that soon. However, looking over the coredevice code it seems to me that there are issues that need addressing anyway, even if they only became symptomatic after the compiler changes. https://github.com/m-labs/artiq/issues/1256#issuecomment-459309359
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: I've started pushing fixes here: https://github.com/hartytp/artiq/tree/suservo https://github.com/m-labs/artiq/issues/1256#issuecomment-459309577
<sb0> gah, my hack to get DDMTD on the RTM kinda works
<sb0> hartytp: did you investigate by any chance how to add LVDS termination resistors to the RTM FPGA clock inputs?
<hartytp> nope
<sb0> right now I'm running them unterminated, which isn't good for SI, and might even damage the RTM FPGA. I cannot reach anyone at WUT since yesterday about where to solder those resistors..
<hartytp> pitch is too fine, looks nasty
<sb0> it's 0402, no?
<hartytp> what's 0402?
<sb0> the bias resistors
<sb0> that's where I'd add the terminations
<hartytp> what bias resistors? the ones on the hmc7043? that's pretty far from the fpga isn't it
<sb0> or, another dirty hack is to make the bias resistors 200 ohm
<sb0> R310/R313/R314/R315
<sb0> those should be near the FPGA, they are after the AC-coupling capacitors
<hartytp> can you remind me which those are to save me having to download the schematics?
<hartytp> anyway, tl;dr I haven't thought about it much
<sb0> well they are the 0.9V bias resistors for CDR_CLK_CLEAN2 and RTM_MASTER_AUX_CLK
<sb0> okay I just got the bias resistor locations from greg
<sb0> it should be straightforward indeed to solder terminations there
<hartytp> sounds good
rohitksingh has quit [Ping timeout: 240 seconds]
<keesj> trying to follow https://github.com/m-labs/misoc/issues/60 and add spi mapping to be able to read the data in spi
<sb0> now the SFP DRTIO looks broken. though that may explain why ethernet also didn't work, since that's the board I was using for that...
<keesj> by itself reading from flash works e.g. I configured rom code + flash_boot_address and now reading memory at 0x70000 results in reading the spi flash contents at offset 0x70000.
<keesj> for a correct boot from spi (xip) I will need to map the rom code at offset 0 to the spi code at offset 0x (e.g. reading from 0x0 should result in reading spi at offset 0x7000)
<keesj> where does that magic happen?
<sb0> and I am of course out of 100 ohm resistors to rework the other board. and with CNY I just can't order them without a 1-week delay
<keesj> with enabling the spiflash I also got the flashboot command in bios to work but it does not accept the bios.bin (as this is a flash binary with no header/crc)
<keesj> can I convert the bios.bin to an image to test this out?
<sb0> keesj: what you load also needs to be linked at the correct address
<GitHub-m-labs> [artiq] sbourdeauducq pushed 4 new commits to master: https://github.com/m-labs/artiq/compare/bdb6678cec10...ec230d65608f
<GitHub-m-labs> artiq/master 8bbd420 Sebastien Bourdeauducq: si5324: use consistent bitmask
<GitHub-m-labs> artiq/master 82106dc Sebastien Bourdeauducq: si5324: add bypass function
<GitHub-m-labs> artiq/master 8119000 Sebastien Bourdeauducq: sayma_rtm_drtio: use Si5324 soft reset...
<keesj> so.. you mean to just change the elf load address (this also happens when you configure the cpu_reset_addres (the elf start address gets changes).
<keesj> is it not possible to do a tranlsation inside the spi driver e.g. map the wishbone address 0 to the spi address 0x70000
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/ea431b6982d67e29778ef5ca1ca82d9ef8096385
<GitHub-m-labs> artiq/master ea431b6 Sebastien Bourdeauducq: sayma_rtm: use 150MHz RTIO freq for DDMTD
<bb-m-labs> build #1018 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1018
<bb-m-labs> build #2881 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2881
rohitksingh_work has quit [Read error: Connection reset by peer]
<hartytp> rjo: any pointers as to where to look for the cause of #1258
<hartytp> and, can you reproduce it?
<bb-m-labs> build #2365 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2365
<bb-m-labs> build #2366 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2366
<keesj> I got boot from spi working but needed to change the rom mapping in soc_core .e.g https://hastebin.com/icicoqidid
<keesj> this also make the elf load address to 0x6000.
<keesj> how I can I make this modification in a nicer way?
<bb-m-labs> build #2882 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2882 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: @jordens one thing that got us here (but which isn't necessarily a bug) is that the adc machine units can be negative, but are stored as the LSB of a 32-bit number. So, doing arithmetic on the raw mus for negative voltages can get one into trouble. I suggest that we either (1) convert all numbers to proper twos complement 32 bit numbers; or (2) make this clear in the do
proteusguy has quit [Remote host closed the connection]
<GitHub-m-labs> [artiq] jordens commented on issue #1256: Iirc sign extending the read port on that memory is fine. The coefficient memory might be trickier. https://github.com/m-labs/artiq/issues/1256#issuecomment-459355451
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: Okay, I'll sign extend at least `get_adc_mu`, and have a think about what to do with coefficients.... https://github.com/m-labs/artiq/issues/1256#issuecomment-459358046
ohsix has joined #m-labs
proteusguy has joined #m-labs
<GitHub-m-labs> [artiq] hartytp commented on issue #1258: i.e. won't the following fail:... https://github.com/m-labs/artiq/issues/1258#issuecomment-459363685
cedric has quit [Ping timeout: 244 seconds]
cedric has joined #m-labs
cedric has joined #m-labs
cedric has quit [Changing host]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] hartytp opened pull request #1259: Suservo (master...suservo) https://github.com/m-labs/artiq/pull/1259
<hartytp> rjo: can you have a look over that and check I'm not doing anything obviously daft. AFAICT that fixes all the issues we have, but we'll do more tests tomorrow
hartytp has quit [Quit: Page closed]
rohitksingh has quit [Ping timeout: 250 seconds]
m4ssi has quit [Remote host closed the connection]
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #m-labs
<keesj> that does one typically load from the bios. is ther some fancy rtos or.. perpahs even lua , or micropython?
mumptai has joined #m-labs
q3k is now known as ```q3k```
```q3k``` is now known as `q`3`k`
`q`3`k` is now known as q3k
<adamgreig> whitequark: any idea why two memories, write ports in the same clock domain, would simulate with different behaviours but apparently work the same when synthesised?
<adamgreig> https://imgur.com/a/CUCNhoF the second image does what i expect, i.e. when addr is 1 and data is 1, 1 gets written to location 1 in the next cycle
<adamgreig> but the top image writes the last cycle's data to the address instead
<whitequark> two identical memories?
<adamgreig> user_rx_mem is Memory(8, 32) with a read_port() and a write_port() (i.e. all defaults)
<adamgreig> tx_mem is a Memory(8, 64), likewise
<adamgreig> so aside from being slightly deeper yes
<adamgreig> (just checked, behaviour is the same if they are both 64 deep)
<whitequark> that's bizarre
<whitequark> what feeds them?
<adamgreig> a horrible bundle of synchronous logic i guess
<adamgreig> haven't managed to narrow it down yet but could try and make a small reproducer
<whitequark> that would help
<adamgreig> i'll see if i can figure it out
Gurty has quit [Read error: Connection timed out]
Gurty has joined #m-labs
<adamgreig> tx_mem is driven from a comb block in a fsm state wiring it to a register from another module, while user_rx_mem is driven from a sync block outside an fsm state
<adamgreig> so if anything I'd have thought tx_mem would be the one getting confused :P
<adamgreig> in each case data and addr are driven from the same block though
q3k is now known as ][
][ is now known as [`]
[`] is now known as q3k
<whitequark> i wonderif it's the transparency logic that's wrong...
<adamgreig> huh, that's.. not the same bug exactly
<adamgreig> it has the same problem in the end, but it changes mem(2) on the same clock cycle that 2 is present on addr
<whitequark> alright. please file it, i'll look when i wake up
<adamgreig> will do, thanks
mumptai has quit [Quit: Verlassend]