sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<travis-ci> jhwgh1968/smoltcp#4 (fuzz_injector - 225ebe6 : jhwgh1968): The build passed.
<mtrbot-ml> [mattermost] <sb10q> @astro this is the first test that attempts to access the board
<mtrbot-ml> [mattermost] <sb10q> probably still an issue with networking.
<mtrbot-ml> [mattermost] <sb10q> @astro how is the no-hardware test able to access the network to ssh into the VM?
<mtrbot-ml> [mattermost] <sb10q> isn't that one sandboxed?
jevinskie has joined #m-labs
proteusguy has quit [Ping timeout: 245 seconds]
_whitelogger has joined #m-labs
sb0 has joined #m-labs
kristianpaul has quit [Quit: WeeChat 1.9.1]
rohitksingh_work has joined #m-labs
<lkcl> ehn? que??
<lkcl> connect \EN { { \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en \wrport_mem_w_en } }
<lkcl> moo?
<lkcl> that's from running mem.py example to output rtlil
<lkcl> why is it connecting the Memory write-enable eight times?
<lkcl> moo? :)
proteusguy has joined #m-labs
<sb0> whitequark: nmigen still produces many signals whose name is just a number, e.g. with minerva
<sb0> jfng1: are you the minerva author?
<whitequark> sb0: i still haven't fixed that
<sb0> whitequark: also, what do you think about an option to shorten the paths of python sources that appear in comments?
<whitequark> sb0: that's not unreasonable but i don't know how
<whitequark> given that if you import from nmigen.lib it will be a completely different root
<whitequark> maybe even somewhere in /usr
<whitequark> maybe it would be better to use python module paths, actually
<whitequark> i'm not sure how to get them though
<sb0> ah yeah, and the python import system isn't exactly easy to deal with
<whitequark> i think i can do it, open an issue so i don't forget
<whitequark> the easiest way is to grab __name__ or __module__ or something from the outer scope
<sb0> there are some issues though
<sb0> what about relative imports?
<whitequark> they get expanded internally
<whitequark> hmm, so i know one major issue with it
<sb0> or code that is fed using exec()
<sb0> or similar
<whitequark> that doens't work with paths either
<whitequark> it uses some stub
<sb0> yeah sure, but that's a corner case to keep in mind
<whitequark> the major issue is if we use python paths then the result becomes useless for external tooling
<sb0> another idea is to implement various ad-hoc cases, e.g. replace the python site packages path with <site-packages>
<_whitenotifier-9> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/fj3qQ
<_whitenotifier-9> [m-labs/nmigen] whitequark 585514e - hdl.ir: rework named port handling for Instances.
<whitequark> sb0: that has the same problem as going for python module paths, really
<whitequark> what are you solving exactly? unreadable verilog?
<key2> sb0: yes jfng1 jfng1 wrote minerva
<mtrbot-ml> [mattermost] <sb10q> yes, unreadable verilog
<whitequark> what about just exporting verilog with no attributes?
<whitequark> write_verilog -noattr
<whitequark> of course you don't want that for syntheiss
<key2> ha that's usually what i do when i want to be able to read the code
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/522946678?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] Success. Absolute coverage decreased by -0.02% but relative coverage increased by +14.23% compared to aed2062 - https://codecov.io/gh/m-labs/nmigen/commit/585514e6ed6619cfc5bb582ff6a4c1d509154567
<_whitenotifier-9> [nmigen] Success. 100% of diff hit (target 85.76%) - https://codecov.io/gh/m-labs/nmigen/commit/585514e6ed6619cfc5bb582ff6a4c1d509154567
<whitequark> or you could do `attrmap -remove src`
<_whitenotifier-9> [nmigen] peteut commented on commit 287a0531b325c752a94d12ce6169a1de66c9569a - https://git.io/fj3mI
<_whitenotifier-9> [nmigen] whitequark commented on commit 287a0531b325c752a94d12ce6169a1de66c9569a - https://git.io/fj3mq
<_whitenotifier-9> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fj3mm
<_whitenotifier-9> [m-labs/nmigen] whitequark 93d15ab - compat.fhdl.specials: fix TSTriple.
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/522953619?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] Success. 85.73% remains the same compared to 585514e - https://codecov.io/gh/m-labs/nmigen/commit/93d15abcf1ac5f23a1761641862bb4360338305a
<_whitenotifier-9> [nmigen] Failure. 0% of diff hit (target 85.73%) - https://codecov.io/gh/m-labs/nmigen/commit/93d15abcf1ac5f23a1761641862bb4360338305a
<_whitenotifier-9> [nmigen] peteut opened pull request #60: compat.fhdl.specials: fix Tristate. - https://git.io/fj3m2
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/522960634?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] codecov[bot] commented on pull request #60: compat.fhdl.specials: fix Tristate. - https://git.io/fj3mV
<_whitenotifier-9> [nmigen] Success. 85.73% remains the same compared to 93d15ab - https://codecov.io/gh/m-labs/nmigen/compare/93d15abcf1ac5f23a1761641862bb4360338305a...6989364dd02e62bfceecde0407cb1ba8e158c572
<_whitenotifier-9> [nmigen] whitequark closed pull request #60: compat.fhdl.specials: fix Tristate. - https://git.io/fj3m2
<_whitenotifier-9> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fj3mw
<_whitenotifier-9> [m-labs/nmigen] peteut 371dc8b - compat.fhdl.specials: fix Tristate.
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/522961249?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] Success. 85.73% remains the same compared to 93d15ab - https://codecov.io/gh/m-labs/nmigen/commit/371dc8bebe0f1ed75a1dcb4289a7bb2aa939a89d
<_whitenotifier-9> [nmigen] Failure. 0% of diff hit (target 85.73%) - https://codecov.io/gh/m-labs/nmigen/commit/371dc8bebe0f1ed75a1dcb4289a7bb2aa939a89d
ZirconiumX has joined #m-labs
<_whitenotifier-9> [nmigen] peteut commented on commit 371dc8bebe0f1ed75a1dcb4289a7bb2aa939a89d - https://git.io/fj3mA
<_whitenotifier-9> [nmigen] peteut opened pull request #61: compat.fhdl.specials: fix Tristate, TSTriple: - https://git.io/fj3Yl
<_whitenotifier-9> [nmigen] whitequark closed pull request #61: compat.fhdl.specials: fix Tristate, TSTriple: - https://git.io/fj3Yl
<_whitenotifier-9> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fj3Y8
<_whitenotifier-9> [m-labs/nmigen] peteut c8e92c0 - compat.fhdl.specials: fix Tristate, TSTriple.
<_whitenotifier-9> [nmigen] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/m-labs/nmigen/builds/522977034?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/522977169?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [nmigen] Success. 85.73% (+<.01%) compared to 371dc8b - https://codecov.io/gh/m-labs/nmigen/commit/c8e92c0612ed5c9903b1c58e321307819d358b4f
<_whitenotifier-9> [nmigen] Success. 100% of diff hit (target 85.73%) - https://codecov.io/gh/m-labs/nmigen/commit/c8e92c0612ed5c9903b1c58e321307819d358b4f
proteusguy has quit [Remote host closed the connection]
_whitelogger has joined #m-labs
<mtrbot-ml> [mattermost] <astro> @sb10q: the no-hardware test does not access the board. it uses ssh over localhost which is fine in a sandbox.
<mtrbot-ml> [mattermost] <sb10q> ah ok, I thought all network access including localhost was blocked
<mtrbot-ml> [mattermost] <sb10q> which would make sense, since nix runs builds in parallel, and there could be port number conflicts ...
<mtrbot-ml> [mattermost] <astro> I assume the sandbox is just a separate network namespace - which has nothing except its own loopback interface
mauz555 has joined #m-labs
<sb0> are high-speed transceivers well supported with the open source tools on lattice fpgas?
<whitequark> i've had essentially zero issues with them
<whitequark> ran in a bunch of different modes, all works according to the docs
<whitequark> which are shit
<whitequark> hm, i think the only actual issue i may have is preemphasis/deemphasis, which i never quite figured out
<whitequark> it's not documented well
<sb0> ok, I just want to receive raw samples from a SFP
<sb0> no data encoding etc.
<whitequark> that's quite trivial
<sb0> it's for using the SFP as a high-speed photodiodes basically
<whitequark> you can grab my code from yumewatari
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0> what's yumewatari?
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0> hmm 5gpbps...
<whitequark> sb0: my pcie phy
<whitequark> unfinished, pending nmigen
<sb0> no SFP on devboard?
<whitequark> only gbe
<whitequark> there are SMAs though for the other SERDES
<sb0> yeah but I don't want to make an adapter
<lkcl> whitequark: i've done python module import-walking a number of times.
<lkcl> i'll try to recall how it's done.
<lkcl> imputil
<whitequark> sb0: the other board *only* has a shitton of SMAs
<whitequark> and it's completely useless
<lkcl> sb0: "replace the python site packages path with <site-packages>" - ringing alarm bells at that
<whitequark> sb0: maybe it's possible to halfass the connector? rip apart the SMA pigtail and solder it right onto the module
<sb0> yeah, sure, but it's messy and fragile
<sb0> and you need to power the module etc.
<sb0> I don't get that other devkit indeed. and it has 2.54mm prototyping areas?
<sb0> no sdram
<lkcl> whitequark: i believe imputil will be a good place to start. damn it was only 8 months ago i did some *really* extensive python-module introspection... trouble was, the project was such hell, i was treated so badly that i've mentally erased the incident.
<lkcl> you can i believe get at object.__module__
<sb0> so you can add DIP chips?
<lkcl> it's hidden
<lkcl> ah, no, here you go:
<lkcl> >>> x = 5
<lkcl> >>> x.__class__.__module__
<lkcl> '__builtin__'
<sb0> lkcl: iirc that only gives you the top-level name of the module and not its path
<lkcl> sb0: that's what imputil is for
<lkcl> i've had to deal with this extensively, three times in 20 years of working with python
<lkcl> it'll just take me a while to drag it out of my long-term chemical memory
<whitequark> sb0: it doesn't even have a crystal
<whitequark> completely pointless stupid devkit
<whitequark> lattice has devkits like that, there's the "UPduino" with what we call a "scenic route ground trace"
<lkcl> >>> x = Signal()
<whitequark> routed by some kid in sri lanka or something
<lkcl> >>> x.__class__.__module__
<lkcl> 'nmigen.hdl.ast'
<whitequark> completely nonfunctional pll
<sb0> you can add a CMOS oscillator like in 80s-era computers on the protoyping area :)
<whitequark> lol
<whitequark> i think you can make an inverter inside the FPGA and run the xtal like that
<sb0> though I'm not sure if they're even available in 3.3V
<whitequark> i never tried it
<whitequark> i should, always been curious
<sb0> there are some old CPLD appnotes that say you can do that
<whitequark> i know for a fact that xtal driver chips are just four inverters
<whitequark> 1 inverter to actually oscillate, 3 more to clean up the output
<whitequark> to get rail to rail waveform
<sb0> 4 inverters don't invert, no?
<whitequark> one inverter connected across xtal
<sb0> ah ok
<whitequark> other three in a chain connected to output of 1st one
<whitequark> sometimes you get two if the vendor is a cheapass
<whitequark> the versa devkit is weird too
<whitequark> it has the ecp5 and also it has an ispclock chip
<whitequark> which is completely unnecessary
<lkcl> sb0, whitequark: path = os.path.abspath(a_module.__file__)
<sb0> ispclock... somehow this reminds me of systemace by xilinx
<lkcl> that's if you have the module
<whitequark> all it does is it forces you to use an awful windows tool if you want a different clock freq, and also fucks up the jtag scan chain
<whitequark> if it is in the chain then the ecp5 will not flash correctly
<whitequark> even if you BYPASS it
<whitequark> they added some jumpers on the board.
<sb0> ah. so it is worse than the systemace.
<sb0> at least the systemace doesn't have JTAG bugs
<whitequark> i have absolutely no idea why, i looked at it and it should work. but it doesn't.
<whitequark> the expansion connector on the versa is also stupid
<lkcl> so the full "thing" you want is: os.path.abspath(sys.modules[an_instance.__class__.__module__].__file__)
<sb0> okay, so what's a good ecp5 board?
<whitequark> versa is the best off the shelf one i think
<sb0> I really just need a SFP on it and some sane way to configure and communicate with the FPGA
<sb0> maybe some GPIOs
<whitequark> never seen any ecp5 board with an sfp
<sb0> or SATA?
<whitequark> or SATA.
<whitequark> sb0: wait
<whitequark> there might be one
<sb0> "MikroProjeckt did not provide availability nor pricing information for the board, but I’ve been told the sample price is $1,800 + shipping"
<key2> sb0: you looking for a board with SFP ?
<sb0> yes
<key2> ecp5 only ?
<sb0> I need a high speed photodiode for messing around with lasers
<sb0> no, but that would be a good project to try out the open source ecp5 toolchain
<sb0> i have many xilinx boards that i can use instead...
<key2> ah
<key2> cuz i bought this one which is quite cheap :)
<key2> but kintex
<key2> the board costs more than the FPGA itself :)
<key2> i mean less sorryu
<whitequark> huh that's ridiculously cheap
<key2> i got a couple
<key2> can go up to 10gnb
<key2> gb
kristianpaul has joined #m-labs
<lkcl> key2: zowee
<key2> ??
<lkcl> just agreeing: that's ridiculously cheap
<lkcl> how many LUTs on the 420T?
<key2> i have it here
<lkcl> the ecp5 however is entirely libre toolchain supported
<lkcl> only thing being it maxes out at 85k LUTs
<lkcl> 7K420T 65,150(2) 41,400 23,750 260,600 5,938 2,969 521,200
<lkcl> WOW
<lkcl> 260k 6-input LUTs
<lkcl> 5938 Kb DRAM
<lkcl> 521k flip-flops
<lkcl> what the hell is the Zynq ZC706 USD $2500 for??? :)
<lkcl> whitequark, sb0: you got all that voodoo magic? os.path.abspath(sys.modules[an_instance.__class__.__module__].__file__)
<whitequark> that's not actually applicable
<lkcl> that'll give the full absolute path of the module that any given object instance comes from
<lkcl> what's needed instead?
<whitequark> there is no need to do that anywhere in nmigen
<lkcl> if you can be more specific about what's needed, i can help find it
<whitequark> i already get filenames from stacktraces just fine
<lkcl> this stuff is pretty obscure
<lkcl> ok, so what's needed?
<whitequark> it's probably fine as-is if there is an option to remove src attrs from verilog
* lkcl scrolls back a bit
<lkcl> ok - then i won't worry about it. ping me if ever it turns out to be necessary
<sb0> key2: is the FPGA actually working properly?
<sb0> at this price it could be chips that failed tests and got officially discarded...
<lkcl> sb0: aliexpress hold money in escrow, they don't give it out to the seller for at least a month
<sb0> in the best case, it's could be chips that someone bought in large quantity for some project and got a big discount for, then some of them got diverted
<lkcl> so if you register a complaint, they definitely don't get the money.
<sb0> lkcl: subtle failures inside the FPGA may be hard to detect.
<lkcl> basically, you have a month in which to test the board comprehensively
<lkcl> sb0: ack
<lkcl> it may just be "china pricing". that's extremely common, it's just not published
<lkcl> freescale have COMPLETELY DIFFERENT pricing structures for the iMX6 than for the rest of the world
<sb0> "don't worry I wrote 9.9USD on the packing box" :))
<lkcl> and they only answer enquiries by word-of-mouth, from people *in* china.
<lkcl> lol
<lkcl> that's pretty normal, too :)
<sb0> I wish it were
<sb0> when I was living in europe I was wasting a lot of time on customs crap and that pissed me off royally
<whitequark> you lived in *germany*
<key2> sb: it does wirk
<key2> work
<_whitenotifier-9> [nmigen] whitequark created branch back.verilog_strip_src - https://git.io/fhUU5
<_whitenotifier-9> [m-labs/nmigen] whitequark pushed 1 commit to back.verilog_strip_src [+0/-0/±1] https://git.io/fj3GI
<_whitenotifier-9> [m-labs/nmigen] whitequark 9b26c31 - back.verilog: allow stripping the src attribute, for cleaner output.
<whitequark> sb0: needs yosys #950
<sb0> alright, thanks!
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale has joined #m-labs
jevinskie has quit [Quit: Textual IRC Client: www.textualapp.com]
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/523050296?utm_source=github_status&utm_medium=notification
proteusguy has joined #m-labs
<lkcl> key2: the seller probably works at a factory where it *cough* fell off the back of an all-electric lorry
<sb0> rjo: are the "PTB drivers" mentioned in the ARTIQ doc (default network ports) published?
<key2> lkcl: no i figured it
<key2> they got a huge amount of extra kintex for their project. so they decided to make those
<sb0> rjo: ok
<sb0> should we mention/link them in the artiq manual since they seem very specific to in-house hardware?
<sb0> we already have the nist kc705 on the other hand...
<rjo> sb0: imo mentioning is fine (just for port allocation, and name/few word short description/url). i would do a minimum to keep this maintanable.
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit []
<_whitenotifier-9> [nmigen] jfng synchronize pull request #59: build: add DSL for defining platform resources. - https://git.io/fjOq5
<bb-m-labs> build #2515 of artiq-board is complete: Success [build successful] Build details are at https://buildbot.m-labs.hk/builders/artiq-board/builds/2515
<bb-m-labs> build #2999 of artiq is complete: Success [build successful] Build details are at https://buildbot.m-labs.hk/builders/artiq/builds/2999
<_whitenotifier-9> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/523107464?utm_source=github_status&utm_medium=notification
mauz555 has joined #m-labs
mauz555 has quit []
mumptai has joined #m-labs
mumptai has quit [Quit: Verlassend]
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 244 seconds]
X-Scale` is now known as X-Scale
mauz555 has joined #m-labs
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 246 seconds]
kristianpaul has quit [Ping timeout: 246 seconds]
bb-m-labs has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
bb-m-labs has joined #m-labs
kristianpaul has joined #m-labs
elmarco_ has joined #m-labs
vup2_ has joined #m-labs
elmarco has quit [Ping timeout: 250 seconds]
tpw_rules has quit [Ping timeout: 250 seconds]
nurelin_ has quit [Ping timeout: 250 seconds]
kaaliakahn has quit [Ping timeout: 250 seconds]
vup2 has quit [Ping timeout: 250 seconds]
qinfengling has quit [Ping timeout: 250 seconds]
tpw_rules has joined #m-labs
mauz555 has quit []
kaaliakahn has joined #m-labs
qinfengling has joined #m-labs
nurelin_ has joined #m-labs
<_whitenotifier-9> [nmigen] Wren6991 commented on issue #41: Invalid Verilog generated for .bool() of zero-width slice - https://git.io/fj3BD
futarisIRCcloud has joined #m-labs