<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
<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 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
<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
<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/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] 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]
<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...