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
mumptai has quit [Ping timeout: 255 seconds]
mumptai has joined #m-labs
HYDRAGON has joined #m-labs
HYDRAGON has quit [Ping timeout: 246 seconds]
<GitHub65> [artiq] jordens pushed 1 new commit to master: http://git.io/hPmx
<GitHub65> artiq/master 0578169 Robert Jordens: pdq2: driver and unittest...
<GitHub129> [artiq] jordens pushed 1 new commit to master: http://git.io/hPY4
<GitHub129> artiq/master 8cb77b0 Robert Jordens: pdq2: rename url parameter to device and require it
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#58 (master - 0578169 : Robert Jordens): The build passed.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#59 (master - 8cb77b0 : Robert Jordens): The build passed.
travis-ci has left #m-labs [#m-labs]
gaetan has joined #m-labs
gaetan has quit [Ping timeout: 246 seconds]
<GitHub38> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/hPwf
<GitHub38> migen/master 5f045b7 Robert Jordens: sim: keep track of unreferenced items...
<GitHub38> migen/master 14b1da4 Robert Jordens: test_actor: add unittests for SimActor...
<sb0> rjo, thanks!
HYDRAGON has joined #m-labs
HYDRAGON has quit [Quit: Page closed]
imrehg has joined #m-labs
imrehg has quit [Quit: Leaving]
<GitHub105> [artiq] whitequark opened pull request #13: Improve installation instructions (master...readme-fixes) http://git.io/hXNF
<whitequark> cool, github integration
<ysionneau> ah good idea to only build or1k target
<whitequark> llvmpy readme seems to suggest it wants a static build
<whitequark> i think that's a silly idea
<whitequark> at least if you're working on your fork of llvm, as we do
<ysionneau> afaik we don't use llvmpy anymore we just llvmlite
<ysionneau> which presents kind of the same interface
<whitequark> llvmlite i mean
<GitHub193> [misoc] enjoy-digital pushed 5 new commits to master: http://git.io/h17K
<GitHub193> misoc/master de2f1c3 Florent Kermarrec: sdram: create module.py to define SDRAM modules and use it on de0nano/ppro targets
<GitHub193> misoc/master 6e4b7c6 Florent Kermarrec: sdram: split sdram_timing in sdram_timing_settings/sdram_controller_settings...
<GitHub193> misoc/master fd2f8d4 Florent Kermarrec: sdram: define MT46V32M16 and use it on m1/mixxeo
<GitHub173> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/h1Fe
<GitHub173> misoc/master 1c0e306 Florent Kermarrec: targets/kc705: rename sdram_module to sdram_modules to reflect that we have 8 modules sharing the same characteristics
<GitHub167> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/h1Fp
<GitHub167> misoc/master 711540e Florent Kermarrec: targets/mlabs_video: rename sdram_module to sdram_modules to reflect that we have 2 modules sharing the same characteristics
_florent_ has joined #m-labs
<GitHub40> [migen] enjoy-digital pushed 4 new commits to master: http://git.io/h1hQ
<GitHub40> migen/master 3a38626 Florent Kermarrec: mibuild/platforms: add minispartan6 (from Matt O'Gorman)
<GitHub40> migen/master 78b4f31 Florent Kermarrec: mibuild/platforms/minispartan6: add device parameter (board can be populated with lx9 or lx25)
<GitHub40> migen/master 1a03c34 Florent Kermarrec: mibuild/platforms: review and fix small mistakes
<GitHub47> [misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hMJH
<GitHub47> misoc/master a560ba3 Florent Kermarrec: sdram/module: add AS4C16M16 for minispartan6
<GitHub47> misoc/master 45eb509 Florent Kermarrec: sdram/module: add speedgrate note for IS42S16160 and AS4C16M16
<GitHub1> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hMIn
<GitHub1> misoc/master 0f9b0c6 Florent Kermarrec: sdram/module: add MT47H128M8 DDR2 (used for a customer)
<sb0> rjo, what's the status of your pipistrello port? is that something Joe could use while we fix the kc705 bugs?
<GitHub40> [artiq] sbourdeauducq closed pull request #13: Improve installation instructions (master...readme-fixes) http://git.io/hXNF
<GitHub53> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/hMV0
<GitHub53> artiq/master f26486e whitequark: Improve installation instructions.
<GitHub53> artiq/master e4a71e6 Sébastien Bourdeauducq: Merge pull request #13 from whitequark/readme-fixes...
<whitequark> sb0: can you set github to print colored messages in this channel? it helps to separate people from bots
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#61 (master - e4a71e6 : Sébastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
mumptai has quit [Quit: Verlassend]
<GitHub70> [misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hMMp
<GitHub70> misoc/master c60d995 Florent Kermarrec: sdram/module: add tREFI uniformization to TODO
<GitHub70> misoc/master b75e4b2 Florent Kermarrec: software/bios/memtest: add data bus test (0xAAAAAAAA, 0x55555555) on a small portion of the test zone....
<GitHub22> [migen] enjoy-digital pushed 1 new commit to master: http://git.io/hMDf
<GitHub22> migen/master 7440ccd Florent Kermarrec: mibuild/xilinx/programmer: add iMPACT programmer (for sb: I need it in Windows for now since I was not able to get XC3SPROG working)
<whitequark> btw, why do we build both or1k-clang and or1k-gcc?
<whitequark> that seems... extremely redundant
<sb0> or1k-clang can't compile the misoc bios correctly right now
<whitequark> oh
<whitequark> (personally i would also set binutils on fire and use lld instead, but that's some more work)
<sb0> yeah
<sb0> I looked at doing things like that for lm32 a while ago, but it's a pita
<whitequark> lld recently gained elf and linkerscript support
<whitequark> so it should be mostly ready
<whitequark> eh, it's fine
<whitequark> i'm wondering why migen generates verilog and not rtl
<whitequark> rtl seems more straightforward
<whitequark> for simulation?
<sb0> what's "rtl"?
<whitequark> register transfer level
<sb0> yes, but what do you mean by that?
<whitequark> well... currently you take logic, convert it to verilog, feed it to a synthesis tool, which converts it to rtl, then feed it to PAR
<whitequark> why not cut out verilog?
<whitequark> you still need optimization and expansions on rtl level, which could be done by yosys or something
<whitequark> probably wouldn't change a design that works, but i'm wondering why is it done this way
<whitequark> though i like the idea of replacing more of the toolchain with a single FOSS tool, producing repeatable results even for different FPGA vendors
<whitequark> $ ./xsetup
<whitequark> ./bin/lin64/xsetup: line 21: 32454 Segmentation fault ${XLNX_DIR_NAME}/_xsetup "$@"
<whitequark> good job xilinx. good job.
<sb0> how exactly do you define "rtl"?
<whitequark> netlists
<GitHub67> [misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hMN0
<GitHub67> misoc/master c55199d Florent Kermarrec: misoclib/soc: add _integrated_ to cpu options to avoid confusion
<GitHub67> misoc/master 9bc71f3 Florent Kermarrec: rename sdram mapping to main_ram
<whitequark> i thought there is a common format?
<sb0> no, there isn't
<whitequark> oh.
<whitequark> ok, that explains.
<sb0> there's EDIF which is semi-standard, but the component of the netlist are FPGA-dependent
<sb0> *components
<sb0> it's basically a graph of instances of LUTx, FD, etc.
<sb0> (on Xilinx)
<sb0> if your migen design is only made of such instance, migen does support EDIF output
<whitequark> right. what do other vendors do? i thought the same
<sb0> the problem is converting the higher level logic description to those instances
<sb0> which is what yosys does (with the handicap of all the verilog corner cases)
<whitequark> *nod*
<whitequark> well, i mean, yosys uses netlists as an IR
<sb0> other vendors have different components in their netlists.
<whitequark> you could output yosys netlists with high-level logic blocks. the kind it would emit itself just after the frontend
<whitequark> and then let yosys lower it down to a vendor-specific netlist.
<whitequark> i think that's the optimal pipeline
<sb0> and there are different flavors of flip flops for example: with/without a reset port, can the FF reset to one instead of zero, with/without a clock-enable pin
<sb0> synthesizers need to know about such things
<sb0> carry chains are another rabbit hole
<sb0> yosys synthesis doesn't work very well. designs are larger and slower than with xst.
<whitequark> i see
<whitequark> that's a pity
<sb0> so for real-world projects, we do need to support xst
<sb0> additionally, we want to support lattice and altera fpgas, too
<sb0> and verilog is the common language that all synthesis tools will accept
<sb0> an interesting thing to do would be direct migen synthesis
<sb0> transform the fhdl to turn the logic into instances, then export to edif (and you can still export to verilog for debug)
mumptai has joined #m-labs
<whitequark> that looks like you would be replicating a good part of yosys
<whitequark> optimization
<sb0> yes
<whitequark> i would say improving yosys is a better idea then
<whitequark> especially seeing as python is poorly suited to the kind of problems you encounter while optimizing large netlists
<GitHub145> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDUh
<GitHub145> misoc/master 70469e1 Florent Kermarrec: sdram: simplify the way we pass settings to controller and rename ramcon_type to sdram_controller_type (more explicit)
<sb0> for speed/memory maybe, for the all the rest it's a lot better than C++ ...
<whitequark> dunno. i personally don't care whether it's python or c++. they both have annoyingly simplistic and inexpressive type systems
<whitequark> something with ADTs and parametric polymorphism would be an improvement :p
<sb0> _florent_, urgh, no
<_florent_> what?
<sb0> the lasmicon-specific ControllerSettings must be put with lasmicon
<sb0> problems with this patch are: 1) the controller settings are spread over many modules in the code 2) the grouping in the namedtuple is not used consistently 3) the type string is duplicated in two places (self.sdram_controller_type and self.sdram_controller_settings.type)
<sb0> and to make #1 worse, some settings are specific to one controller
<sb0> what about this:
<sb0> in minicon, define an empty MiniconSettings class/namedtuple
<sb0> in lasmicon, define a LasmiconSettings class/namedtuple containing those parameters you have right now
<sb0> then the user creates the correct *Settings class and passes it to SDRAMSoC
<sb0> you can import both MiniconSettings and LasmiconSettings in mem/sdram/__init__.py to simplify the imports for the user
<sb0> but their detailed definition must lie with each controller
<_florent_> OK I change that
<sb0> you can use isinstance() to determine which controller to use
<sb0> (on the *Settings)
<_florent_> yes and for the settings, why don't we create class with default parameters (since we use the default settings on all controller for now)
<sb0> yes, it's a good idea to have defaults in LasmiconSettings
<_florent_> OK
<sb0> I don't know if you can do it with namedtuple
<sb0> otherwise, def __init__(self, read_queue_size=8, ...)
<_florent_> yes I will create a clas
<_florent_> class
<_florent_> can I keep with_memtest and with_bandwidth as SDRAMSoC parameters?
<_florent_> to be able to change that in the make.py command line
<sb0> yes
<sb0> with_memtest doesn't go into the controllers, does it?
<sb0> it just adds one core to SDRAMSoC
<_florent_> sb0> you can use isinstance() to determine which controller to use : not sure if I want to keep the possibility to configure sdram_controller_type from the command line
<sb0> hmm, not sure how important that feature is
<sb0> otherwise you can always use eval()
<sb0> in fact, using eval() will solve the problem of with_bandwidth, which is also lasmicon-specific
<_florent_> I don't use it, I can remove that if you want
<sb0> i'd advocate keeping it, improving it so that arguments are sent through eval(), and putting with_bandwidth into LasmiconSettings
<_florent_> can you describe a bit your eval() method?
<sb0> it'll parse things like "LasmiconSettings(with_bandwidth=True)" from the command line, if you give it the right dicts
<_florent_> ah OK :)
<sb0> alternatively, if we want to keep simpler strings
<sb0> (like it's done for eg cpu_type)
<sb0> we can have a simple parser that would create the correct *settings based on strings like lasmicon:with_bandwidth,req_queue_size=4
<sb0> and if sdramsoc sees a string in sdram_controller_settings, it calls the parser
<_florent_> OK I'll add the parser after if needed
<sb0> but we might be overthinking things right now :)
<sb0> I'm not really changing sdram parameters from the command line...
<sb0> cpu yes
<sb0> all the other settings? almost never
<sb0> and where do we stop? if we can configure the sdram controller request queue size from the command line, why not the rtio output fifos depths on a per-channel basis?
<_florent_> agree
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Remote host closed the connection]
sb0 has joined #m-labs
<GitHub178> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDzP
<GitHub178> misoc/master 30c2521 Florent Kermarrec: sdram: pass sdram_controller_settings to SDRAMSoC
rjo_ has joined #m-labs
<rjo_> sb0: the pipistrello port works afaict. i did not test it against dds. but i don't see trouble there since the hardware is the same.
<rjo_> then again. eating cake dough before it's baked leaves a smaller cake and can give you salmonella...
<rjo_> that work would be better spent on more pressing issues.
<rjo_> less glamorous ones certainly.
<GitHub176> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/hDVE
<GitHub176> artiq/master 494c670 Florent Kermarrec: targets/artiq_ppro: use new sdram_controller_settings parameter
<GitHub88> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDzP
<GitHub88> misoc/master 30c2521 Florent Kermarrec: sdram: pass sdram_controller_settings to SDRAMSoC
<whitequark> nice
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#62 (master - 494c670 : Florent Kermarrec): The build passed.
travis-ci has left #m-labs [#m-labs]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<_florent_> rjo: in PLL_ADV I think there is a mistake, it should be p_CLKIN1_PERIOD=1/f0*1000*1000*1000
<_florent_> (I'm doing some tests on a scarabhardware board and ISE failed with 1/f0)
<rjo_> _florent_: pipistrello? ah yes. ns not s. make that 1e9/f0. why do people like 1000*1000*1000*1000?
<rjo_> remindes me of "kMcps" or
<rjo_> µµF
<rjo_> kilo-mega-cycles-per seconds == GHz or micro-microFarad == pF
<_florent_> you seem to like it too: f0 = 32*1000*1000
<_florent_> :)
<rjo_> i copy pasted that.
<rjo_> surprising that the pll works at all ;)
<_florent_> i copy pasted your 1000*1000 and added *1000 :)
<rjo_> and i think that 1/f0 was also copied from somewhere else. there might be other platforms with that same mistake.
<_florent_> I'm going to fix that, that's strange your ISE version doesn't complain with that
<rjo_> touché
<rjo_> it probably complains but since there are about 50 pages of ise-babble about mor1kx that one warning would have gotten lost.
<rjo_> yep ppro has the same issue.
<_florent_> not but mine stops compilation
<rjo_> ise 14.7 here
<GitHub101> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hD9W
<GitHub101> misoc/master cf17f06 Florent Kermarrec: targets: fix CLKIN1_PERIOD on ppro and pipistrello
<_florent_> 14.6 here
<rjo_> _florent_: 14.7 traces it back to the timespec and overrides it: https://travis-ci.org/nist-ionstorage/artiq/builds/49396694#L5134
<_florent_> ah OK I should update my version
<GitHub5> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/hDd3
<GitHub5> artiq/master 7e61f66 Sebastien Bourdeauducq: pdq2/mediator: get pdq devices from pdb
<GitHub5> artiq/master 1b7f71b Sebastien Bourdeauducq: controllers: consistent device/simulation specification