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
antgreen has joined #m-labs
fengling__ has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
fengling_ has joined #m-labs
fengling has quit [Ping timeout: 245 seconds]
ylamarre has quit [Quit: ylamarre]
rohitksingh has joined #m-labs
<GitHub18> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vcngK
<GitHub18> migen/new 4451bb2 Sebastien Bourdeauducq: genlib/fifo: remove Record support
<GitHub142> [misoc] sbourdeauducq pushed 2 new commits to new: http://git.io/vcngF
<GitHub142> misoc/new 1b8f313 Sebastien Bourdeauducq: lasmicon: do not depend on FIFO Record support
<GitHub142> misoc/new b3d5d16 Sebastien Bourdeauducq: interconnect/stream: remove param, do not depend on FIFO Record support
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#117 (new - 4451bb2 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
rohitksingh has quit [Ping timeout: 246 seconds]
<GitHub163> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vcnKO
<GitHub163> migen/new 0c1e1c9 Sebastien Bourdeauducq: test/fifo: do not use Record
rohitksingh has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#118 (new - 0c1e1c9 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 40.0.3/20150826023504]]
FabM has joined #m-labs
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
jaeckel has quit [Ping timeout: 260 seconds]
fengling__ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
<GitHub60> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vccJK
<GitHub60> migen/new 6c01f80 Sebastien Bourdeauducq: genlib/fifo: add missing imports
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#119 (new - 6c01f80 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
fengling__ has quit [Ping timeout: 245 seconds]
fengling__ has joined #m-labs
fengling has joined #m-labs
fengling__ has quit [Ping timeout: 245 seconds]
fengling has quit [Quit: WeeChat 1.2]
antgreen has quit [Ping timeout: 250 seconds]
<GitHub88> [misoc] sbourdeauducq pushed 2 new commits to new: http://git.io/vcc42
<GitHub88> misoc/new 617c6ec Sebastien Bourdeauducq: interconnect/stream: add multiplexer and demultiplexer
<GitHub88> misoc/new d21358f Sebastien Bourdeauducq: liteeth_mini: fix imports, replace Counter and FlipFlop
jaeckel has joined #m-labs
<sb0> _florent_, what's the point of Chunkerize/Unchunkerize? why not use Cast or just xxx.raw_bits().eq(yyy.raw_bits()) ?
jaeckel has quit [Remote host closed the connection]
jaeckel has joined #m-labs
<_florent_> When you have byte enables with your data in a stream:
<_florent_> Chunckerize: from payload data(dw=64)/be(dw=8) creates n chuncks of data(dw=64/n)/chunks(dw=8/n)
<sb0> all those special cases and adhoc solutions make me thing that the current dataflow abstractions do not work
<sb0> *think
<sb0> what is "be"?
<_florent_> but maybe what you suggested yesterday about params can also be applied here: use 2 endpoints
<sb0> does liteeth_mini require this little mess, and can it use the bare Pack/Unpack?
<_florent_> yes I think you need it
<_florent_> for converter
<sb0> cool. some more rewrite is needed then.
<sb0> meh
<sb0> be == byte enable?
<_florent_> yes
<_florent_> you just have to provide an equivalent to Converter
<sb0> brb
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Client Quit]
sb0 has joined #m-labs
sb0 has quit [Client Quit]
sb0 has joined #m-labs
<sb0> of course, after all those changes i did to liteeth, ethernet is 100% broken
<_florent_> what have you changed?
<sb0> I have copied the current modules chunkerize/unchunkerize modules into misoc.interconnect.stream for now (not committed)
<sb0> there was another commit before, but it only touched the imports
<_florent_> the changes in the first link seem fine
<sb0> where are the byte enables in (un)chunkerize/converter?
<sb0> I don't get it...
<_florent_> that was just an example
<_florent_> data and byte enables are defined in the description of your enpoint
<sb0> so chunkerize is like cast, but only applies to a part of the layout?
<sb0> ok
<sb0> and what do the chunkerize stuff make out of this?
<sb0> *does
<_florent_> when use with the Converter: eth_mac_description(8) to eth_mac_description(32) for example
<sb0> ok, so the converter does pack/unpack on each field of the layout, independently?
<_florent_> yes that's what I was trying to explain (without success)
<sb0> ok
<sb0> you are testing for the sum of the lengths of all fields, whereas you should compare the lengths of each pair of fields independently
<sb0> e.g. if you feed it from=(length 1, length 2) and to=(length 2, length 1) it will silently connect the fields one by one instead of erroring
<_florent_> right it's not detecting that and using witdh is probably not appropriate
rohitksingh has quit [Ping timeout: 255 seconds]
<sb0> blergh
<sb0> Pack/Unpack doesn't deal with EndpointDescription, but Chunkerize/Unchunkerize do
<sb0> _florent_, could you reimplement the Converter cleanly?
<sb0> make it part of liteeth (it's not very generic...) and monolithic - a Converter module that instantiates UpConverter or DownConverter would be good.
<sb0> those last two modules should essentially be like the current Pack/Unpack
<sb0> and not do any crazy stuff
rohitksingh has joined #m-labs
ylamarre has joined #m-labs
<sb0> flattening the hierarchy a bit (remove core/frontend), not using factory functions, and not having code in __init__.py would be nice as well ...
<sb0> if isinstance(sdram_controller_settings, str):
<sb0> self.sdram_controller_settings = eval(sdram_controller_settings)
<sb0> ...
<sb0> why is SDRAMCore accessing phy.settings and its caller accessing phy.module.geom_settings and phy.module.timing_settings before passing them to it?
<GitHub28> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vcCS3
<GitHub28> artiq/new-py2llvm 7a6fc39 whitequark: Make delay component of function type unifyable.
<GitHub28> artiq/new-py2llvm 651e6b1 whitequark: Remove build products from git.
<whitequark> ^ was a pretty nasty correctness bug
<sb0> and why does the PHY need this module attribute at all?
<sb0> it needs to know nothing about the DRAM geometry, goddammit
<sb0> _florent_, the "margin" parameter of the ns function in SDRAM is to account for a possible change of the command phase (when switching between reads and writes) in half-rate PHYs ...
<sb0> and more generally, when you find a "margin" in code I have written, there is a definitive reason for it
<sb0> what's the point of the class attributes in the classes that inherit from SDRAMModule, if you need to overload and pass their values to the constructor?
<sb0> also, why the discrepancy between NamedTuple and the dictionaries?
antgreen has joined #m-labs
bentley` has quit [Remote host closed the connection]
bentley` has joined #m-labs
antgreen has quit [Ping timeout: 256 seconds]
aeris has quit [Ping timeout: 256 seconds]
aeris has joined #m-labs
mumptai has joined #m-labs
ylamarre has quit [Ping timeout: 272 seconds]
ylamarre has joined #m-labs
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
siruf has quit [Quit: leaving]
siruf has joined #m-labs