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
<mithro> sb0: easier to work in our own repository while things are changing quickly
fengling has joined #m-labs
<GitHub98> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vnwbT
<GitHub98> misoc/master 0309986 Sebastien Bourdeauducq: setup: convert to unix eols
<GitHub108> [misoc] sbourdeauducq pushed 1 new commit to new: http://git.io/vnwNq
<GitHub108> misoc/new 01be953 Sebastien Bourdeauducq: setup: cleanup
<GitHub187> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vnwNY
<GitHub187> migen/new 8935ca2 Sebastien Bourdeauducq: setup: remove unneeded import
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#107 (new - 8935ca2 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<sb0> rjo, any feedback on the new migen? you should be able to use it for the pdq gateware
early has quit [K-Lined]
early has joined #m-labs
<rjo> haven't had a close look. but i remember having questions.
<rjo> why is flen() not gone? can't we either len(Signal) or len(Constant)?
<rjo> what about the other suggestions i had last time?
<rjo> there was the inconsistency of using __all__ in a few places and sprinkling _ in others.
<rjo> and did something like migen.wrap() happen (makes a Signal or Constant out of whatever i give it)?
<sb0> right, we can remove flen()
<sb0> how would you make a Signal out of "whatever"?
<sb0> what would be a good policy for __all__ vs. _? can't really think of any...
<rjo> sb0: these 4 or five lines: https://github.com/m-labs/migen/blob/new/migen/fhdl/structure.py#L137 is pretty much what i would use all the time.
<rjo> sb0: for __all__/_ i would just be consistent. my personal preference is __all__ everywhere because i find the large amount of _ everywhere more irritating than a few namespace mangling lines at the top of the file.
<rjo> if i understand this right, in the new simulator you are doing yields for reads and writes. why is that better than sim.read()/sim.write() or dut_proxy.read()/write()? semantically to me the inly difference is the contro flow/stack. with the generators the simulator is in charge while otherwise the simulator is called back.
<sb0> rjo, there is no difference between calls and yields for reads and writes. but the yield comes useful when waiting for a clock cycle, and I'm simply using the same mechanism instead of having to pass a simulator context into the generators
<sb0> re. wrap. for the exception, there is one special case, https://github.com/m-labs/migen/blob/new/migen/fhdl/structure.py#L587
<sb0> others could be replaced with wrap, yes
<rjo> ack.
<sb0> note you can do multi clock domain now
<rjo> in the simulator, do you do the same delta-cycle stuff that iverilog does to execute a clock cycle?
<rjo> too lazy to look...
<sb0> something equivalent
<rjo> that is, if two different simulation routines execute on a clock cycle, are they guaranteed to execute once?
<sb0> sure
<rjo> can i do combinatorial loops?
<rjo> with "python" in the loop?
<sb0> or more exactly: their yields on the clock cycle are guaranteed to complete exactly one at the tick
<sb0> combinatorial loops yes, but not with python in the loop
<rjo> then you can not write combinatorial signals, right?
<rjo> not from python.
<sb0> simulation generators are always synchronous to a clock
<sb0> comb blocks work fine, even if you have some sort of loops in them
<sb0> (unlike what iverilog does, which was a problem with many designs)
<sb0> well. asynchronous generators may be implementable.
<rjo> sure. but any signal written to from a sim gen only changes on the clock.
<sb0> yes
<rjo> ok. if you implement asynchronous generators, you can do combinatorial loops with generators in them.
<rjo> they would need some kind of sensitivity list, right?
<sb0> yes
<sb0> I guess the generators could yield their sensitivity list.
<rjo> the polymorphic yield is a bit confusing...
<rjo> you would use it for reads (single signal), writes (pair) and "other lists" as sensitivities?
<sb0> read/writes are combined now. you yield a FHDL expression.
<rjo> ah.
<sb0> and use eq() for writes
<rjo> then i must have remembered an older implementation.
<sb0> the two forms are 1) FHDL expression 2) None to wait for the next clock tick
<sb0> yes, it was pairs before
<rjo> expressions as sensitivity lists sounds good. then you can sensitize on a > b.
<rjo> maybe "yield Wait(a > b, c[2])" and "yield Wait(ClockSignal('foo'))"? to make it explicit?
<rjo> or how would i wait for different clock signals in a single generator?
<sb0> events = yield Wait(a > b, c, Clock(), Clock("some_other"))
<rjo> but with the current "yield None" i can only wait for the default clock signal, right?
<cr1901_modern> sb0: Anything equivalent to the do_simulation or gen_simulation in the current simulator?
<sb0> yield None can be aliased to "yield Wait(Clock())"
<sb0> yes
<cr1901_modern> just make those methods and run_simulation will autodetect them?
<sb0> simulation methods are decoupled from Module now
<sb0> you only pass them to the simulator
<cr1901_modern> okay, that's what I thought. I'll think of something so my files aren't cluttered with do_sim() functions
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<rjo> sb0: is the proxy object gone?
<sb0> yes
<sb0> too many problems with it
<rjo> good.
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<sb0> f = open("/tmp/simserial", "w")
<sb0> f.write(os.ttyname(s))
<sb0> f.close()
<sb0> ....
<sb0> oooh and another factory function
<sb0> _florent_, would you mind maintaining the verilator stuff in a separate repository? I'm just going to make the misoc cores flexible enough that it can be done that way ...
<cr1901_modern> sb0: So, has your faith in other's coding habits decreased steadily over the years, or were there a few particularly horrific events that shaped your outlook?
<sb0> it's not just a coding habit, factory functions break inheritance, issubclass(), class.method, etc.
<sb0> and the other bit of code is non portable and non reentrant
<cr1901_modern> But if you follow GoF religiously, inheritance is bad!11
<sb0> GoF?
<cr1901_modern> Gang of Four Design Patterns
<acathla> religion is bad too
<cr1901_modern> acathla: Not being terribly serious, although I do like factories. sb0 as a point as well.
fengling has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<whitequark> inheritance is stupid to use so widely but everyone else in python isn't going to stop just because i don't like it
<whitequark> when in rome, etc
<sb0> "so widely"?
<sb0> actually, I'm not a huge fan of inheritance either...
<whitequark> there are a few useful patterns that are near impossible to replicate without inheritance
<sb0> but it has its uses and should not be broken
<sb0> yes
<whitequark> e.g. UI widgets and visitor
<whitequark> but for everything else you're better with ADTs
<whitequark> better off*
<whitequark> OCaml is a very interesting case study on this. the O in OCaml is "object oriented"; people usually assume this is some big thing but actually most OCaml code uses absolutely none object-oriented features
<whitequark> and apart from the two I mentioned, and excluding type system tricks, I don't think I've seen it used at all
<whitequark> while we're at it, I would like to take a moment to regret how objects and classes are understood as two parts of the same thing whereas in reality they are almost unrelated
<cr1901_modern> Classes are a contract that certain operations are available, and objects implement said contract?
<whitequark> no
<whitequark> object types are such a contract
<whitequark> it is perfectly reasonable to have object types without having classes at all
<cr1901_modern> fair enough... reminds me of a Lisp example where cons is implemented in multiple ways. The cons object will get the information you need when passed into cdr/car, but the way to get this information between implementations is vastly different.
<whitequark> no, not really, python just conflates classes and object types
fengling has joined #m-labs
<cr1901_modern> sb0: Have you tested using a clock domain not called "sys" yet in simulation? My simulation's entering an infinite loop if I do.
<cr1901_modern> whitequark: "no, not really?" Is my example in general poor, or is the "vastly different" part inaccurate?
<rohitksingh> Hello everyone! A rookie here. I'm just starting with misoc and noticed classes named "_CRG" inherited from "module" class, present inside 'target' files. What does it stand for? From its contents, I can see its mostly clock related...any pointers would be of help, thanks!
<sb0> whitequark, can we move libunwind under m-labs on github?
<sb0> rohitksingh, Clock and Reset Generator
<rohitksingh> sb0: hi! and thanks! :)
<sb0> whitequark, or are you merging your modifications upstream? should we use upstream then?
<whitequark> cr1901_modern: the difference between classes and object types is not an implementation detail
<whitequark> sb0: I am merging this upstream
<whitequark> http://reviews.llvm.org/D11897 is the last part
<cr1901_modern> Ack. I'll find something re: ADTs to read up on and see if I can't understand it (again).
<cr1901_modern> Also note to self: The new Simulator as a clocks input argument. Failure to fill that out appropriately causes bad things to happen.
<cr1901_modern> has*
<sb0> cr1901_modern, how did you crash it?
<cr1901_modern> Forgot to fill in the clocks input argument to Simulator with the clock domain name and period
<sb0> the default is a single sys clock.
<cr1901_modern> yes, and I have a module which can either be tied to the sys clock divided by some factor, or an external clock. So I made a whole new clock domain.
<cr1901_modern> Filled out the generator with {"rx" : test_rx(m)}, but let clocks take the default argument. So rx never elapsed :P
<sb0> ah. can you send a patch so that it does some sanity checking on that and throws eg a valuerror exception?
<sb0> should be clocks.keys == generators.keys
<cr1901_modern> Will do. I have a todo list of patches I need to send you, btw, so I'll get on those today.
<cr1901_modern> I feel bad that I keep breaking Migen these past few days lol
rohitksingh has quit [Ping timeout: 260 seconds]
antgreen` has quit [Ping timeout: 260 seconds]
<cr1901_modern> sb0: When creating an FSM, if using NextState within If statements no longer supported?
<cr1901_modern> erm, nevermind, cannot duplicate what I just saw o.0;
<cr1901_modern> (Can duplicate. According to structure.py, line 434, If statements require input arguments of the _Statement class, but NextState does not inherit from _Statement)
<cr1901_modern> Is this intentional?
<sb0> no
<cr1901_modern> Will it break anything to make NextState inherit from _Statement?
<GitHub139> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vn6qV
<GitHub139> migen/new 33f344b Sebastien Bourdeauducq: fsm: NextState and NextValue should derive from _Statement
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#108 (new - 33f344b : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
ylamarre has joined #m-labs
rohitksingh has joined #m-labs
<GitHub173> [misoc] sbourdeauducq pushed 1 new commit to new: http://git.io/vn6Nb
<GitHub173> misoc/new 8350916 Sebastien Bourdeauducq: reorganization WIP: flatten core structure (SDRAM still needs to be done)
rohitksingh has quit [Ping timeout: 264 seconds]
mumptai has joined #m-labs
rohitksingh has joined #m-labs
ylamarre1 has joined #m-labs
ylamarre has quit [Ping timeout: 252 seconds]
ylamarre1 is now known as ylamarre
ylamarre has quit [Quit: ylamarre]
antgreen` has joined #m-labs
antgreen` has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
mumptai has quit [Quit: Verlassend]