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
<GitHub>
[pythonparser] trotterdylan opened pull request #17: Detect source encoding to properly interpret string literals (master...master) https://github.com/m-labs/pythonparser/pull/17
<cyrozap>
Hi, all, I've started doing MiSoC stuff again after a long break, and I'm having some trouble building. On fresh git pulls of the master branches of asyncserial, migen, and misoc, when I try to build any target, I get an exception: "ValueError: Cannot extract CSR name from code, need to specify."
<cyrozap>
I'm using Python 3.6 in a virtualenv on Arch Linux.
<cyrozap>
I'm not sure where exactly I need to specify the "CSR name", nor why it can't extract it from the code.
cr1901_modern1 is now known as cr1901_modern
<rjo>
cyrozap: try python 3.5
<sb0>
cyrozap, or you can use the patch in the migen issue
<sb0>
I haven't thoroughly tested it though, and it needs some cleanup
hedgeberg is now known as hedgeberg|away
kuldeep has quit [Remote host closed the connection]
kuldeep has joined #m-labs
<sb0>
who proposed I2C EEPROMs for identification of kasli extensions?
<sb0>
how exactly is the software supposed to use those? is it just a random Joe idea?
<rjo>
sb0: proposed by greg.
<rjo>
sb0: what is your problem?
<sb0>
they need a bit of production support to load them, their content needs to be defined consistently, and they are useless unless there is solid software support for them
<rjo>
sb0: you would read the eeprom and then get mux the correct RTIO PHY.
<rjo>
sb0: absolutely.
<rjo>
sb0: it's like the FMCs. imho this is first and foremost a safety feature that you don't plug in extensions into the wrong slots with IO contention and wrong IO standards.
<rjo>
sb0: but yes. it needs production, gateware, software support.
<sb0>
so we should support runtime-muxed RTIO PHYs?
<sb0>
no gateware rebuilds?
<rjo>
sb0: this is what the discussion in the issues gravitated towards.
<sb0>
should the software also scan all those I2C EEPROMs and generate the device_db, or parts of it?
<rjo>
sb0: there would be up to two different phys per pin/group of pins.
<rjo>
sb0: not necessarily.
<rjo>
the phys are just there, enumerated like now. automatic device_db building would help but is orthogonal.
<sb0>
the main issues is reconfiguring the Xilinx IOS
<sb0>
we can easily handle the muxing of an arbitraty amount of rtio phys with migen
<rjo>
sb0: yes. if you read the issues, i explained that to the others.
<rjo>
sb0: not without building n^m bitstreams.
<sb0>
we need some sort of I/O router
<sb0>
in the best case, use the FPGA native routing, but this is tricky :-)
<rjo>
the RTIO phys for the kasli extensions appear to fall into two categories: SERDES and regular. SERDES (higher latency) are the serdes-ttls and e.g. cameralink. regular are regular TTL, SPI, ....
<sb0>
I think the SERDES have bypass ports
<rjo>
we seemed to agree on having at most two PHYs per pin group.
<rjo>
ah.
<sb0>
let me check
<rjo>
the important thing is probably fixing the IO standard.
<sb0>
we can change the I/O standard at runtime if we reverse engineer the bitstream a bit and use the ICAP
<rjo>
but yes. there would be an IO muxing shim between the PHYs and the pins.
<sb0>
that shouldn't be extremely complicated actually
<rjo>
sb0: maybe it's not necessary and we can save time by fixing the IO standard.
<sb0>
ISERDESE2 has a combinatorial bypass
<sb0>
the O pin
<rjo>
that's cool. then there is just one category of PHYs. and they can be all IO-muxed. but restricting the cardinality of a pin to two PHYs max is probably still wise.
<sb0>
OSERDES doesn't, but usually you want to register outputs anyway
<rjo>
sb0: iirc OSERDES has more than one cycle latency.
<sb0>
hm, yes
<sb0>
regarding muxing: the smallest mux in a 6-LUT FPGA is a 4:1
<sb0>
so having 4 possibly PHYs per pin is fine
<sb0>
as long as it doesn't cause routing problems, but the PHYs we have, except the phaser, are quite small
<rjo>
sb0: sure. but thy still all need to get their signals and logic close to the mux.
<rjo>
each PHY tends to need at least one BRAM.
<rjo>
but anyway. we'll see how much we can mux there.
<sb0>
one BRAM? for the FIFO?
<rjo>
yes.
<sb0>
we can have a central set of FIFOs and route that to the PHYs too
<sb0>
actually more than one set, to avoid large muxes
<sb0>
do something a bit like x-way set-associative cpu caches
<sb0>
but yeah, that will need a bit of redesigning of the rtio core. is the plan to fund that via opticlock?
<sb0>
it does seem one cannot bypass a OSERDES at runtime without some bitstream reverse engineering
<rjo>
sb0: FWIW then the pragmatic approach would be to have the SERDES and non-SERDES classes of PHYs and restrict the MUXing as required.
<rjo>
sb0: and write the IO MUX shim.
<sb0>
yeah. but messing with bitstreams is kinda fun :-)
<rjo>
sb0: absolutely.
<rjo>
and if yosys gives us a good backend for 7 series i'd love to use that.
<sb0>
Clifford told me he's working on it
<rjo>
i would consider the pragmatic approach above to be funded in part by opticlock and in part by the sayma/metlino VHDCI extension breakout suppport that needs to be funded.
<sb0>
regarding the ISERDES combinatorial bypass: I'm not sure if it this pin makes it behave exactly like a normal IOB
<sb0>
IOBs have dedicated input registers that fix the timing despite the P&R non-determinism without requiring additional timing constraints
<sb0>
I don't know if those are placed after the ISERDES O pin or not
<rjo>
sb0: yes. also for IOSERDES they are on the fast clock domain and not on the slow one.
<sb0>
those two domains are from the same oscillator, so it doesn't really matter
<sb0>
also, for the regular I/O pins: do we enable all the dedicated registers?
<rjo>
sb0: for regular IO i would just do a combinatorial mux and then hope that xilinx figures out how to get registers through the mux logic into the IOB. or is that dreaming?
<sb0>
whether the dedicated IOB register is enabled or not is set in the bitstream
<sb0>
you cannot disable or enable it at runtime without messing with the bitstream
<rjo>
sb0: sure. but vivado/ise are able to extract those registers themselves. i.e. i would hope they can push registers in the PHYs through the MUX comb logic and into the IOB.
<sb0>
hm, maybe, one has to make sure then that the mux control signal is also registered with the same clock
<sb0>
we can also bring the bitstream hacking to another level and use partial reconfiguration to dynamically load PHYs
<sb0>
the main thing I dislike about this is non-portability
<sb0>
and it'll probably take a good decade before there is a generic library to do this sort of thing across FPGAs
<sb0>
and cameralink will likely need a different serdes clock than rtio
<rjo>
you want to accurately time the frames coming in.
<rjo>
yes. it needs a different clock.
<sb0>
that's a serious problem
<rjo>
you'd want to gate, timetag, and process/bin/crop the frames.
<sb0>
the pragmatic option is to disallow phy muxing on the cameralink pins...
<rjo>
well. accurately is ~tens of µs here. so i'd imagine a grey transfer of the TSC would do.
<rjo>
sb0: yes. if they need a different clock then we'd have to disallow them.
<rjo>
good point.
<rjo>
well. there are clock muxes...
<sb0>
for high speed serdes clocks? I don't think so
<sb0>
well
<sb0>
actually we can have a dedicated PLL for the cameralink capable pins, and mux the pll input
<rjo>
500 MHz? pretty sure that BUFGMUXes can roll that.
<rjo>
also. cameralink is not needed now. i just want to keep it on the radar so that we design the rest without needlessly barricading e.g. cameralink phys.
<sb0>
doesn't pll to serdes use dedicated clock routing?
<sb0>
if it's only 500MHz, we can also put cameralink on the non-SERDES IO and use IODDR
<sb0>
oh actually
<sb0>
we can also never use the hard SERDES, only IODDR
<GitHub172>
[smoltcp] whitequark closed pull request #6: add connection mode for udp sockets (work in progress) (master...master) https://git.io/vDz8g
Gurty has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<cr1901_modern>
Ahh, I was thinking about resurrecting migen.build.sim... oh well, I suppose a generic "per project" sim target works as well
<cr1901_modern>
"The RAM description <twenty_kilobyte_RAM> will not be implemented on the device block RAM because of limited available resources." That's good. That's fine.
<GitHub>
[artiq] cjbe commented on issue #669: @whitequark here is the UART output after applying your patch and trying to run an experiment from the dashboard (using artiq_run still works fine):... https://github.com/m-labs/artiq/issues/669#issuecomment-279072689