sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<GitHub-m-labs> [artiq] drewrisinger opened issue #1221: No ARTIQ 4 Manual Link on m-labs website https://github.com/m-labs/artiq/issues/1221
<GitHub-m-labs> [artiq] drewrisinger opened issue #1222: Rust manual paths broken https://github.com/m-labs/artiq/issues/1222
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±7] https://git.io/fhv1l
<_whitenotifier-6> [m-labs/nmigen] whitequark f7fec80 - ir: allow non-Signals in Instance ports.
<_whitenotifier-6> [m-labs/nmigen] whitequark 221f108 - back.rtlil: fix translation of Cat.
<_whitenotifier-6> [m-labs/nmigen] whitequark 6672ab2 - back.rtlil: explicitly pad constants with zeroes.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470800049?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Failure. 78.31% (-0.37%) compared to 8cc900c - https://codecov.io/gh/m-labs/nmigen/commit/6672ab2e3fd78d539c0efe1f13f301d5ce0aee3e
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing 8cc900c...6672ab2 - https://codecov.io/gh/m-labs/nmigen/commit/6672ab2e3fd78d539c0efe1f13f301d5ce0aee3e
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+2/-0/±5] https://git.io/fhv1d
<_whitenotifier-6> [m-labs/nmigen] whitequark 6d9a6b5 - hdl.mem: implement memories.
<_whitenotifier-6> [m-labs/nmigen] whitequark 2b4a851 - back.rtlil: implement memories.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470802855?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Failure. 77.25% (-1.07%) compared to 6672ab2 - https://codecov.io/gh/m-labs/nmigen/commit/2b4a8510ca3653e796b0a6f8ac0d7868cfdf9a9b
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing 6672ab2...2b4a851 - https://codecov.io/gh/m-labs/nmigen/commit/2b4a8510ca3653e796b0a6f8ac0d7868cfdf9a9b
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/e80d80f13323536840dcb1b1806d378ae1026648
<GitHub-m-labs> artiq/master e80d80f Sebastien Bourdeauducq: manual: move to correct directory for building rust crates. Closes #1222
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-4: https://github.com/m-labs/artiq/commit/a53065ffc870d848973dbf663a381fd1d6a11132
<GitHub-m-labs> artiq/release-4 a53065f Sebastien Bourdeauducq: manual: move to correct directory for building rust crates. Closes #1222
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/af1f87833a080dad4d126426129416854db71f81
<GitHub-m-labs> artiq/release-3 af1f878 Sebastien Bourdeauducq: manual: move to correct directory for building rust crates. Closes #1222
<GitHub-m-labs> [artiq] sbourdeauducq closed issue #1221: No ARTIQ 4 Manual Link on m-labs website https://github.com/m-labs/artiq/issues/1221
<sb0> byte == deserialized word (10-bit, 20-bit, ...)?
<whitequark> sb0: byte == word
<whitequark> inconsistent use of terms
<sb0> cr1901_modern: yes, the xilinx stuff does only barrel-shifting. there are features to shift the clock instead, but they are complex and broken.
<sb0> the hack I'm using is to reset this crap until the comma is aligned
<sb0> you get a random clock phase at each reset
<whitequark> with ecp5 you just get a bitslip input you can strobe
<whitequark> doesn't really get simpler than that
<whitequark> i have only used the barrel shifting mode with pcie though, since it's the only mode supported with native pcie mode for some reason
<sb0> someone wrote a paper on how determining the clock/comma phase, then using a MMCM to compensate, but it's quite a mess
<sb0> "for some reason" - sounds like xilinx :)
<whitequark> i think it's related to the custom pcie features like receiver detectin
<whitequark> not sure though
<whitequark> anyway, i never had to do comma alignment manually in the first place
<whitequark> with ecp5 you put the commas (normal and inverted) into the serdes as parameters
<whitequark> and it automatically aligns to them and locks
<whitequark> that actually works well
<whitequark> sb0: oh, i know why it does barrel shifting in pcie mode, actually
<whitequark> the UG says that it can align to commas in some low time interval, like 4 symbol times
<whitequark> you cannot do that with bitslip
<whitequark> so i think what it does is it simultaneously matches commas in several different alignments
<whitequark> probably not all 10
<whitequark> but maybe 5 or 4
<whitequark> and then reconfigures the barrel shifter after each symbol
<whitequark> instead of doing bitslip 10 times
<sb0> yeah well, that's not very hard to do and you can do it in fabric
<whitequark> i know why they did it in the serdes
<sb0> I implemented it for HDMI (with barrel shift)
<whitequark> when you use 5 Gbps mode of SERDES, it only works with 1:2 gearing, because the fabric is not fast enough for 500 Msps rate
<whitequark> actually it isn't really fast enough for 250 Msps rate either, you really want to use a PSCLKDIV primitive to do a 1:4 total gearing
<whitequark> and then process it at 125 Msps
<whitequark> with a very small gearbox in 250 MHz domain
<whitequark> so, if you were doing bitslip in fabric, you'd probably have to do it post gearboxes, and if you do that, i think you blow timing constraints of some protocols it supports
<sb0> what's the latency of those things?
<sb0> with xilinx it's very high, 100-300ns, for some reason
<whitequark> there is not enough info in UG for me to give you a precise number
<whitequark> I can measure it for you though
<whitequark> what methodology should i use?
<whitequark> send a stream of 0 symbols, put a pulse in it, compare transmitted pulse time to received pulse time?
<sb0> yes, with 8b10b disabled
<sb0> or well, you can keep it enabled
<sb0> just connect transceiver TX with RX, send something, and measure latency inside the fpga
<sb0> they don't document the latency?
<whitequark> maybe I can't read
<whitequark> but they are definitely better at making bug-free IP than at documenting it
<whitequark> remember when i said about several departments that dont talk to each other?
<whitequark> sb0: oh, found the table
<whitequark> they do document latenc
<whitequark> sb0: what specific configuration are you interested in
<whitequark> speed, encoding, preemphasis/deemphasis
<whitequark> equalization
<whitequark> do you want CTC or not
<sb0> no CTC
<sb0> 3gbps
<whitequark> sb0: interestingly, other than the FPGA bridge (which you can bypass), all latencies they give are exact
<sb0> 8b10b (does this take more than a few cycles?)
<whitequark> 8b10b takes exactly 2 symbol clocks
<bb-m-labs> build #2158 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2158
<whitequark> ok, with 3 Gbps, you need at least 1:2 gearbox in SERDES
<whitequark> or in fabric I guess, 300 MHz might be okay
<whitequark> assuming you go for a fabric gearbox...
<whitequark> sb0: transmit latency will be 34.433 ns
<whitequark> er, sorry, I miscounted
<whitequark> transmit 28.345ns, receive 37.519ns
<whitequark> this is with pre-emphasis off, equalization off
<whitequark> and with SERDES word aligner enabled
<whitequark> without SERDES word aligner enabled, receive latency is 24.186ns
<whitequark> sb0: anyway, i can make you a demo design based on ecp5-5g versa board if you want
<whitequark> that's like half a hour of work
<bb-m-labs> build #2159 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2159
<sb0> ah, that's much better than xilinx
<sb0> I don't need a demo design, don't even have a lattice board
<bb-m-labs> build #973 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/973
<bb-m-labs> build #2772 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2772
rohitksingh_work has joined #m-labs
hartytp has joined #m-labs
<hartytp> sb0: "why does it need rtm drtio?"
<hartytp> I'd like to do the sync from the kernels, which means accessing DAC SPI from kernels, so DRTIO seems nicer than serwb
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fhvyB
<_whitenotifier-6> [m-labs/nmigen] whitequark b0bd7bf - hdl.ir: correctly handle named output and inout ports.
<hartytp> also, I'd prefer to hook the sysref gen up to the RTM fpga
<whitequark> ok, nmigen has working memories in verilog...
<hartytp> means we don't have to worry about lack of pins on the AMC<->RTM connector
<hartytp> if you think that RTM DRTIO is going to be an issue then we can do things differently
<whitequark> now i need to add memory in simulation
<hartytp> "we can probably move to kernels, the reason it's done in rust was the potential dependency of drtio on the clock tree"
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470823885?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 77.75% (+0.5%) compared to 2b4a851 - https://codecov.io/gh/m-labs/nmigen/commit/b0bd7bfaca2a549358b740d6325780b51fb7f26c
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 77.25%) - https://codecov.io/gh/m-labs/nmigen/commit/b0bd7bfaca2a549358b740d6325780b51fb7f26c
<hartytp> ack. that made sense then, but now kernels seem like a nicer way of doing things. I'm happy to handle the port
<whitequark> sb0: attie: is it intended that re does nothing for transparent read ports?
<whitequark> i.e. re only has meaning for synchronous, non-transparent read ports, and not for anything else?
<bb-m-labs> build #2160 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2160
<hartytp> sb0: also, if I configure the new PLL via a kernel then we can re-use it as a Mirny driver, which seems nice and avoids duplication of work
<hartytp> whitequark: btw, I've been following progress on nmigen, it looks really cool! nice work
<whitequark> thanks
<whitequark> hopefully artiq will run on nmigen (in compat mode) before end of year
<whitequark> not much remains to be done, really
<whitequark> it's remarkable how each time i begrudgingly write a test to get coverage like 0.5% up, i find a bug
hartytp has quit [Ping timeout: 256 seconds]
<bb-m-labs> build #2161 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2161
<bb-m-labs> build #974 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/974
<bb-m-labs> build #2773 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2773
<attie> whitequark: what does "transparent" mean for a port?
<cr1901_modern> the address currently being written on a given clk is available on the read port
<whitequark> attie: WRITE_FIRST ~ transparent
<whitequark> xilinx even uses them alternately
<cr1901_modern> yosys only uses transparent in its cell lib if memory serves
<sb0> the only potential issue I see with RTM DRTIO is the size of the satman firmware that has to fit in BRAM
<sb0> the rest should work fine
<attie> sounds more like a footgun to me, tbh
<attie> when I use an re it's usually because I want the read output to be stable until the next re
<whitequark> attie: well, migen has that footgun right now
<whitequark> it ignores re even if you specify it
<attie> it wouldn't be the only one...
<whitequark> interestingly, so does yosys
<whitequark> $memrd cells will ignore re unless they're configured as non-transparent
<whitequark> anyway, in nmigen i will make it a hard error
<attie> I mean, I guess you're assumed to think about what mode it's in first
<whitequark> re will be hardwired to a constant 1 unless it will be used
<attie> although I can think of contexts where I might want to keep the read address stable and see changes in content reflected
<attie> is it possible to make the difference between those two somehow explicit?
<whitequark> hm
<whitequark> attie: which two?
<attie> latch address vs. latch output
<attie> I'm still not entirely clear, what exactly does it do if you put has_re=True on a WRITE_FIRST port?
<whitequark> migen latches address, nmigen doesn't latch anything
<whitequark> nmigen doesn't have has_re.
<attie> ok, so it is what I was thinking of.
<attie> there's a use case for both modes, latch address and latch output.
<attie> but it should be a bit clearer which one you're getting, it being a combination of has_re and mode is very cryptic
<whitequark> yosys doesn't currently support latch address directly afaict
<attie> I guess if you use async_read you can manually implement the address register.
<whitequark> well to me it seems like while re is low, output should never change
<whitequark> so while latch address mode is useful, it should not be controlled by re
<attie> conceptually, absolutely those are two different things and they shouldn't both be called re.
<bb-m-labs> build #2162 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2162
<attie> but they use the same signal in xilinx bram so you have to make the output look like that eventually.
<whitequark> strictly speaking, xilinx synthesizer has to fold unnecessary registers in
<attie> although I guess it doesn't matter if it's a different signal, as long as they're not both present simultaneously?
<attie> actually idk what vivado does if you put two, isn't that the optional output register
<attie> hmm actually latch address mode is only useful if you are writing on another port and waiting to see those changes. and unless you are in read first mode, that's undefined behavior.
<attie> no wait, unless *the other port* is in read first mode
<attie> this whole component is a footgun.
<bb-m-labs> build #975 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/975
<bb-m-labs> build #2774 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2774
<whitequark> indeed
<attie> maybe just wrapping it into something that disallows all the more complicated options is fine...
<attie> would it be possible to have a lower-level "expert mode" module that has all the options, and a higher level one that offers the most sensible options sans footgun?
<whitequark> attie: i think a set of warnings (on by default) would be useful
<whitequark> can you look at uh
<whitequark> give me a moment to push
<attie> btw PR #90 was exactly that footgun, and the bug was in migen for years before anyone noticed
<whitequark> yeah...
<whitequark> and my ghetto solution (making re a constant) would have caught the bug
<attie> for extra fun there was also a bug in the sim implementation that hid this bug
<sb0> hartytp: so all SPI would be RTIO/realtime then?
<sb0> then it's exactly the same driver as mirny
<sb0> btw when will you test the PLL chip for phase determinism? that would be a big problem if it doesn't work
<sb0> rewriting into kernels will add some more development time before the board does anything, though, and joe will likely be unhappy with that. and it seems joe still hasn't learned from what happens when he pushes unrealistic deadlines
<sb0> actually, if we do that then we can strip the non-RT SPI support from the DRTIO firmware on the RTM side, and gain some memory
<sb0> all satman would do then is basically program the si5324 and answer aux ping, moninj, and a few minor things
<sb0> we can strip routing management since it's always a leaf node
<whitequark> attie: sb0: do asynchronous memory write ports ever make sense?
<whitequark> how would that even work?
<whitequark> technically, yosys implements them, though i don't think it actually does anything meaningful with the cells
<whitequark> write_verilog definitely emits invalid verilog for asynchronous write ports
<whitequark> oh, nevermind, I've realized
<whitequark> asynchronous write ports use enable as a strobe
<whitequark> it definitely never makes sense to instantiate it in an nmigen design
<whitequark> but the semantics of a $memwr cell like that is at least defined
<whitequark> wow, there are *so many* errors migen isn't checking when using memories
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 3 commits to master [+1/-0/±6] https://git.io/fhvHB
<_whitenotifier-6> [m-labs/nmigen] whitequark 8d58cbf - back.rtlil: more consistent prefixing for subfragment port wires.
<_whitenotifier-6> [m-labs/nmigen] whitequark a061bfa - hdl.mem: tie rdport.en high for asynchronous or transparent ports.
<_whitenotifier-6> [m-labs/nmigen] whitequark c49211c - hdl.mem: add tests for all error conditions.
<whitequark> attie: okay, can you go over the code i just pushed and see if you can find any combinations that are definitely undefined?
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470845762?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.27% (+1.51%) compared to b0bd7bf - https://codecov.io/gh/m-labs/nmigen/commit/c49211c76ab18762039918c41384435ac793943a
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 77.75%) - https://codecov.io/gh/m-labs/nmigen/commit/c49211c76ab18762039918c41384435ac793943a
<attie> whitequark: I think only combinations of two ports are undefined, no? if you have a transparent write port, a read from the same address is undefined.
<attie> you have only write or read ports now, no ports that can do both?
<whitequark> attie: hmm
<whitequark> but you can request several ports from the same memory
<whitequark> I'm confused as to how "transparent" is a feature of combinations of two ports
<whitequark> "transparent" means that if a write (somehow) touches a memory location, it is immediately reflected at the output of this read port
<attie> yeah, but your write port doesn't even have a read data signal any more
<attie> so where would that even be reflected?
<whitequark> on a different read port of the same memory
<whitequark> that (dynamically) reads the same address
<attie> yeah, except no because that's not how xilinx bram works
<attie> it literally cannot offer that feature, and gives you undefined instead
<attie> (IIRC in practice comes out to value changes next cycle)
<attie> xilinx bram is transparent *only* on the same port you are writing from
<whitequark> hm
<whitequark> so how does their synthesizer know when to assemble read and write ports into a single bram port?
<whitequark> does it look at the address syntactically?
<attie> yeah one address signal = one port i think
<cr1901_modern> pretty sure any pipelined softcore relies on a write being immediately available to read on a second port... and well, I've seen plenty of soft cores work on Xilinx
<whitequark> (drive them to the same address)
<whitequark> is you request a read port and a write port with the same address
<whitequark> attie: right so the way you get a read/write port in nmigen
<whitequark> since this *can* represent xilinx (with caveats) but the opposite cannot represent e.g. ice40
<attie> cr1901_modern: well, once you start pipelining you have to detect hazards anyway. so you can wait one clock cycle longer.
<cr1901_modern> attie: Fair, wasn't meant to derail, just I could've sworn I've relied on the exact behavior to work that Xilinx claims doesn't work. Hmmm...
<attie> cr1901_modern: did you check that the component did end up in bram and not in dram?
<attie> the *same* verilog description will infer to either, and merrily change behavior, merely based on size and the mood of the synthesizer that day.
<cr1901_modern> attie: Will check tomorrow/when I'm a bit more focused. Tbh, I don't remember where the reg file goes on Xilinx devices
<cr1901_modern> (same thing of course works on ice40, where only BRAM is present)
<attie> unless you have an extremely large reg file, likely to be dram.
<whitequark> 06:34 < attie> the *same* verilog description will infer to either, and merrily change behavior, merely based on size and the mood of the
<whitequark> wtf
<whitequark> is this ise or vivado?
<attie> vivado
<attie> that's what PR #105 is about and why I run my own fork of migen atm
<whitequark> ugh
<attie> because I have a SyncFIFO, and depending on its depth and width, sometimes it works and sometimes it doesn't
<whitequark> incredible
<whitequark> i hate this
<whitequark> i hate this passionately
<whitequark> why do we even *use* xilinx
<attie> personally, I do because someone gave me free FPGAs
<cr1901_modern> attie: Is PR #105 your PR?
<attie> yes, I'm nakengelhardt on github
<_whitenotifier-6> [nmigen] whitequark opened issue #12: Implement a sanitizer for memory port combinations - https://git.io/fhvQl
<whitequark> attie: ok so
<whitequark> i've opened #12
<whitequark> do you think you can write in the most painfully verbose way the exact requirements xilinx has for its bram and dram
<whitequark> because i can implement the sanitizer but i find the requiremnts extremely confusing
<whitequark> there will probably also have to be a "mode" parameter for Memory, to select between bram and dram and possibly dff
<cr1901_modern> attie: Btw, since you wrote mist https://twitter.com/cr1901/status/1064996800988438528 (everything in this tweet is out of date now that nmigen targets RTLIL, btw)
<cr1901_modern> s/targets RTLIL/devel is underway/
<attie> honestly, I've come to the conclusion that 'portable' verilog is a lie, and you need to manually instantiate xilinx BRAM to have any behavior guarantees.
<whitequark> or at least stuff it full of attributes
<whitequark> which is my plan here
<attie> yeah that would work
<attie> could also extend in the future to ultraram, which is only inferred with the attribute
<attie> (haven't used it at all yet, no idea what new and exciting pitfalls await there :)
<cr1901_modern> That's what attributes are for, no? :)
<whitequark> no
<whitequark> attributes are not to keep the synthesizer from illegally converting valid behavioral verilog to completely different gateware
<cr1901_modern> I meant using attributes in the context of representing inherently non-portable HDL in a unified manner
<cr1901_modern> If you can't reliably get xilinx BRAM to behave in the context of nmigen, using attributes is, well IMO, a good solution
<cr1901_modern> which vivado output file would have the "this signal X mapped to Y primitive" information?
<attie> At one point last year I tried to experiment with what verilog descriptions would synthesize into what BRAM settings, but I could not because *there was not enough other crap* in my design and so it never mapped to BRAM at all
<whitequark> daveshah: question, TN1250 says that RE is only available for 256x16 BRAM configuration
<whitequark> however, all the other primitives still have RE
<whitequark> what is the reality like
<cr1901_modern> attie: http://ix.io/1wul Gonna go ahead and guess Xilinx has been using dist ram all this time
<_whitenotifier-6> [nmigen] whitequark commented on issue #12: Implement a sanitizer for memory port combinations - https://git.io/fhv73
<attie> yep, that one has the behavior you'd expect (writes are immediately visible on the read port).
<attie> hope you don't have a generic somewhere to change the size of the register file, or it might suddenly give you stale data without notice :)
<cr1901_modern> nope, for lm32 it's set
<attie> I think it's fairly rare to run into these problems because the usual use cases map to the appropriate sizes
<cr1901_modern> I did some experiments w/ ice40 lm32 early this year; transparent reads are implemented using $memrd bypass circuitry that compare the write address to the current read address and enable a mux if they match.
<attie> yeah, I guess they added that to the hard logic in xilinx bram but didn't add the cross-check to the other port.
<cr1901_modern> IIRC, yosys does this at the RTLIL stage though (so the other backends might have the same impl w/ $memrd bypass as well)
<cr1901_modern> I've never used the xilinx backend of yosys to check tho
<attie> since they could be both write addresses and then you are personally responsible for ensuring no conflict anyway.
<cr1901_modern> one write port, two read ports- write conflict isn't possible in this case (unless 2am me is more tired than usual)
<sb0> whitequark: afaict intel isn't better and there are no alternatives to xilinx and intel for large and less-slow FPGAs
<whitequark> ok
<attie> yeah, if each of the ports only has one direction then there are fewer problematic cases and interactions.
<sb0> might have used ECP5 on kasli though, if the speed is acceptable
<cr1901_modern> sb0: pretty sure you've said intel is even worse. Like their high speed transceivers are completely unusable
<cr1901_modern> does this ring a bell/like something you've said?
<whitequark> it's not that they are unusable
<whitequark> it's that they kill themselves if you stop the clock
<whitequark> which is a hilarious silicon bug if you aren't trying to use that silicon
<attie> ahaha that was also my discovery :D
<attie> november last year was a fun month!
<whitequark> i mean transceivers are fun in every family
<sb0> yeah, other than that they just seem roughly as crappy as the xilinx transceiver
<whitequark> ah.
<whitequark> fun fact: ECP5 was likely going to be all 5G, but they fucked up
<whitequark> with transceivers
<whitequark> so they have to heavily bin them and *then* they overvolt them by 100 mV to actually get them to work at 5G
<attie> They do give you a big critical warning about it though so at least I didn't fry my hosts' brand-new cards before they even got to use them.
<sb0> I guess we can put a ECP5 on the sayma rtm too
<whitequark> and the entire ECP4 series got cancelled because they couldn't get transceivers to behave at all
<whitequark> sb0: this doesn't apply to operating at 3G btw
<whitequark> you can use the cheaper non-5G parts at normal Vcore
<whitequark> Vtr* even
<whitequark> ECP4 was also going to get much larger fabric
<whitequark> as it is, ECP3 has FPGAs with more LUTs than the largest ECP5 in existence
<whitequark> which is pretty weird
<sb0> what about speed?
<sb0> this is usally the FPGA metric that sucks the most
<whitequark> ECP5 has a smaller node so it's generally faster than ECP3
<whitequark> do you want any specific numbers I can find?
<sb0> how fast does misoc run on it?
<whitequark> I haven't run misoc on it
<whitequark> but I can try
<sb0> also, artiq rtio
<whitequark> oh something interesting wrt RTIO on ECP5
<whitequark> many ECP5 pins (I think half of them? this part is a bit confusing) have an integrated gearbox
<whitequark> so you can select 1:2, 1:4 or 1:7
<whitequark> is this useful for RTIO maybe?
<sb0> is it like a small SERDES?
<sb0> Xilinx has this too, no?
<whitequark> essentially
<sb0> isn't that used for the SDRAM?
<sb0> and 1:2 is a DDR register, right?
<whitequark> yes and yes
<whitequark> well, they group them all together
<sb0> yeah we use this for the TTL PHY on Xilinx to get 1ns I/O resolution
<whitequark> ah ok
<whitequark> ECP5 clocking for this feature is very complicated and obnoxious
<whitequark> I am not sure if it really is so complicated, or it is just because it is made for MIPI and SDRAM
<whitequark> which are by themselves complicated and obnoxious
<sb0> SDRAM is relatively reasonable given the constraints
<whitequark> you can also align the data to clock edge or between clock transitions
<sb0> it's basically designed like that to be cheap
<whitequark> without having to mess with PLLs
<whitequark> ah I see
<sb0> low pin count, high bandwidth, high SDRAM chip yields
<sb0> the problem is most SDRAM PHYs are fucked, but this is the case for most commercial IPs that have CDCs or asynchronous parts, especially when it's from xilinx
<sb0> and SDRAM has a lot of async stuff
<sb0> in misoc we're doing a bit of a hack for reading (not using DQS), and there's another hack I want to try to clean that up
<sb0> the main issue is DQS is not free-toggling, so some data gets stuck unless you have some async logic that isn't implementable on xilinx fabric
<whitequark> hm this is definitely complicated and obnoxious
<sb0> what I want to do is have the controller issue 1 dummy-read after each legitimate read (just repeat the last read command) to make the SDRAM chips toggle DQS and pump data out of the FPGA I/O cell and into the elastic buffer
<whitequark> as a matter of fact
<whitequark> i should study how SDRAM works
<sb0> then everything is implementable cleanly and without any xilinx hard-IP bullshit
<sb0> well, yes, but it's done like that because DQS is bidirectional
<sb0> doing it otherwise requires more pins, and SDRAM is optimized for rock-bottom cost
<sb0> those pins have to be routed on every DIMM, connector, motherboard etc.
<sb0> also if it's a free-running clock, you can't mux it. with the current design you can connect DQS pins of several DRAM ranks on a bus, and use chip select
<whitequark> so why is DQS a thing? don't you already have a clock?
<whitequark> or is that clock used only as reference and DQS for actually transferring data?
<sb0> yes, but the skew isn't known and can vary from chip to chip and with PVT
<whitequark> ok
<sb0> with DQS all data transfers are source-synchronous
<whitequark> i see, your workaround makes sense
<sb0> we need some sort of FIFO that can write on both clock edges
<sb0> this isn't doable on xilinx fabric
<sb0> so we need IDDR + regular FIFO, which needs some cycles to flush the pipeline
<whitequark> what if you use two FIFOs?
<sb0> maybe, but matching the delays (since this will be coming straight from the I/O pin at >1Gb/s) will be very tricky
<whitequark> hmm okay
<sb0> also, more routing delays inside the FPGA = more absolute VT drift
<sb0> the "repeat last read command" hack seems much more reliable and easier, and also should have a negligible impact on performance
<whitequark> i mean you only need that before going to a different state, right?
<whitequark> back to back reads should be fine
<sb0> the main issue with it is the additional cycle it would take for read-to-write turnaround
<sb0> absolutely, it's a pipeline
<whitequark> yeah, it definitely sounds much more reliable
<daveshah> whitequark: I'm pretty sure the RE/WE pins on the ice40 are subtly broken in various ways and both Yosys and icecube use RCLKE/WCLKE
<whitequark> wtf
<whitequark> ok good old fpga bugs
<daveshah> I think tying WCLKE high and using WE instead breaks initialised BRAM
<whitequark> thanks
<whitequark> this is definitely what i see in techmap files
<daveshah> ad DQS BTW, the ECP5 has a hard FIFO on all the left and right IO pins for DQS CDC
<whitequark> daveshah: any idea if iCECube infers transparent ports?
<daveshah> whitequark: no, not sure
<whitequark> their example goes like:
<whitequark> always @(posedge clk)
<whitequark> begin
<whitequark> if (write_en)
<whitequark> mem[(addr)] <= din;
<whitequark> dout = mem[addr]; // Output reend
<whitequark> ... did they really mix <= and = here?
<whitequark> what semantics is this *supposed* to have?
<whitequark> I *think* this is read-before-write?
<daveshah> Mixed <= and = is the sort of thing that breaks stuff
<daveshah> But yes, that is read before write
<whitequark> this is depressing
<whitequark> can FPGA companies please refrain from ever writing any verilog
<whitequark> they do not appear capable of doing it
<whitequark> daveshah: why do they even have RCLKE/WCLKE?
<daveshah> idek
<whitequark> is it for power saving?
<daveshah> yes
<daveshah> except they seem to be the only read or write enable icecube uses
<whitequark> ... why do they even have RE and WE then?..
<daveshah> That's the bigger mystery
<whitequark> maybe they had a macro from the fab or something
<whitequark> I have no better ideas
<daveshah> If you look at the SPRAM, you can actually find out which macro they used
<whitequark> ha, really?
<daveshah> The user guide inexplicably gives you a mapping from Verilog port names to RAM macro port names
<whitequark> like physically look or at the interface?
<daveshah> Without even telling you what half the power control ports do
<whitequark> lol yeah it does
<daveshah> So you have to Google those port names and find the macro
<whitequark> it refers to "RAM datasheet"
<daveshah> Or look at the sim model in Radiant which also came from the memory compiler
<daveshah> It's from Virage btw
<daveshah> who now seem to be Synopsys Designware
<whitequark> so
<whitequark> daveshah: do you think you can add info about ECP5 RAM similar to https://github.com/m-labs/nmigen/issues/12#issuecomment-449280778 ?
<sb0> whitequark: hey maybe the new laser PDH locker can use Lattice
<whitequark> PDH locker?
<sb0> pound-drever-hall
<whitequark> what does the FPGA need to do?
<whitequark> so this is ECP5 territory
<whitequark> okay
<whitequark> >
<whitequark> Is setting up PDH locks really something you want/need to do with ARTIQ, or is this better done as a simple "standalone" board of some sort (e.g. an Arduino shield) where you write some quick and dirty GUI and then set-and-forget?
<whitequark> arduino shield...
<whitequark> really?
<sb0> probably even less than ECP5, maybe even MCU
<whitequark> ah, then put iCE40 there
<sb0> though a nice FPGA potentially allows fancier locks, but the NIST folks know a lot more than I do...
<whitequark> I should see how fast picorv32 can get on UP5K
<whitequark> remember those numbers you said are shit? well I looked closer and we've actually improved the toolchain quite a bit since then
<whitequark> there was a lot of low-hanging fruit in yosys and of course arachne was not timing-driven
<sb0> I have very little experience with lasers, chiefly because doing it with trashed equipment from eBay (which is the only thing I can afford) is a pain and time sink
<whitequark> well I know iCE40 practically inside out at this point
<sb0> it's much worse than vacuum where parts are more repairable (give them a good cleanup), cheaper, and more generally available
<whitequark> it's easy to design for, easy to write HDL for, and generally not a pain
<whitequark> there are a few stupid gotchas with pin assignment, mainly
<whitequark> the way they do clocks and PLLs is just not very good and requires forethought at PCB design phase
<whitequark> each PLL is assigned to an IO buffer and if you feed a PLL to a GB then it eats the I part of IO (?!)
<whitequark> this is of course only mentioned in the footnotes and there is no table anywhere that says which PLL goes where
<_whitenotifier-6> [nmigen] nakengelhardt commented on issue #12: Implement a sanitizer for memory port combinations - https://git.io/fhvFk
<whitequark> you have to look at bondouts and such
<whitequark> again the department htat made silicon did not talk to the one making documentation
<attie> ok, I've added what I think I know about the xilinx BRAM behavior.
<whitequark> thanks!
<whitequark> >sometimes it will find a read register somewhere even if you intended to write an asynchronous read port
<whitequark> ...
<whitequark> sb0: what do you think about running *only* $mem cells through Yosys Xilinx techmapping in nMigen?
<whitequark> because this kind of shit is just absurd
<whitequark> are they even trying?
<attie> that one isn't really a "bad xilinx" though
<attie> it's just that if your address didn't have to go through many combinatorial stages, the resulting verilog looks the same
<whitequark> syntactically or semantically?
<attie> both
<whitequark> hm ok
<attie> I mean, if you got the address from some module that has an output register
<attie> and then feed it to your asynchronous read port
<attie> and migen puts the whole thing in a single file
<whitequark> ah I think I see
<whitequark> so what does Yosys do here...
<attie> how would it know that the register was meant to be associated with *this* bit of code rather than *that* bit of code
<_whitenotifier-6> [nmigen] daveshah1 commented on issue #12: Implement a sanitizer for memory port combinations - https://git.io/fhvFg
<whitequark> hm, Yosys always infers 7-Series BRAMs in READ_FIRST moed.
<daveshah> whitequark: a small picorv32 design can do about 26MHz with nextpnr
<whitequark> daveshah: iirc when I last tried it was about 13 MHz with arachne
<whitequark> but it was mor1kx
<whitequark> I should try misoc again
<daveshah> That was on up5k
<whitequark> oh it was on hx8k
<daveshah> Probably 60MHz on hx8k is doable
<whitequark> sb0: ^ that's far more reasonable than arachne numbers
<whitequark> though picorv32 is still weirdly slow
<whitequark> I should definitely try mor1kx again
<daveshah> I think nextpnr is at least 30% better than arachne on picorv32
<daveshah> Plus there have been the recent improvements to Yosys by you and tnt
<whitequark> attie: do I understand it right that READ_FIRST/WRITE_FIRST/NO_CHANGE is primarily to determine what happens with data out of the writing port?
<whitequark> effectively that configures some sort of mux and register of the read port, right?
<whitequark> in READ_FIRST it just does a read, in WRITE_FIRST it muxes data in to data out, in NO_CHANGE, WE gates the clock to that register
<whitequark> this probably makes more sense if you're looking at the bitstream...
<daveshah> At least on ECP5 it's very uninformative - just one random bit for either READBEFOREWRITE or WRITETHROUGH modes
<daveshah> Which I think behave quite similarly
<whitequark> hm, I think I get it
<whitequark> >one port is writing AND it is in READ_FIRST mode, in which case the other port will read the old data. (Note that it is the setting of the write port that defines the behavior of the read port. Setting of the read port is irrelevant.)
<whitequark> this part is just what it would do anyway, isn't it
<whitequark> like, you are configuring the read behavior through the write port because the read mux/register is fed by the WE signal
<whitequark> of the write port
<whitequark> daveshah: does this make sense to you?
<whitequark> it feels like a really sloppy abstraction to me, barely covering the underlying macro
<whitequark> which is why it's so weird
<daveshah> Interestingly the ECP5 also has a NORMAL mode where the read port is undefined while writing
<whitequark> what bit does that set?
<whitequark> or
<daveshah> No bits
<daveshah> It's the default
<whitequark> does that just remove a false path between DIN and DOUT?
<whitequark> ah
<whitequark> so you have two bits for READBEFOREWRITE and WRITETHROUGH
<whitequark> interesting
<daveshah> Yes
<whitequark> I wonder what the former bit does
<daveshah> I'm not fully sure how they behave when dealing with both ports
<whitequark> yeah I'm coming to conclusion that we need some sort of testbench
<whitequark> to validate whether we actually instantiated memory in a sane way
<daveshah> I wonder if they have to have explicit bypass logic even for the READBEFOREWRITE case
<whitequark> this is very obnoxious
<daveshah> I dare say no one has mentioned Intel yet either
<daveshah> God knows what cursed shit they do
<attie> I didn't really think about the underlying hardware yet.
<attie> But to sum up my feeling about xilinx bram handling, "I can see how you got here but maybe you should reevaluate your life choices."
<whitequark> yeah i definitely concur
<whitequark> i sort of understand it now but it's still a nightmare
<attie> oh since I just had to scroll through another hundred of this delightful message, Xilinx's official advice on this: "It is suggested to confirm via simulation that an address collision never occurs and if so it is suggested to try and avoid this situation."
<whitequark> wonderful.
<whitequark> yeah there's definitely a huge sim/synth mismatch in migen wrt RE
<whitequark> actually, this doesn't even make any sense
<whitequark> WRITE_FIRST merely latches address
<whitequark> so in case of address conflict MemoryToArray is just wrong
<whitequark> but it's wrong in a yet another way, different from Xilinx
<whitequark> this is a horrible mess
<whitequark> i think MemoryToArray is just mostly completely wrong
<whitequark> this needs to be simulated in a completely different way
<attie> I thought I made it match with what BRAM is doing at least. What else is wrong?
<whitequark> it might match the Xilinx behavior, I don't understand it that well
<whitequark> but it's wrong in general
<whitequark> well
<whitequark> ohhhh I see
<whitequark> WRITE_FIRST effectively implements an async read port
<whitequark> except the address is latched
<whitequark> this is horrible but it should be correct
<whitequark> ah, no, it's not exactly correct
<whitequark> attie: so, let's say you have a WRITE_FIRST port with has_re=True
<whitequark> now let's say you set re low
<attie> mm yeah that case might be badly handled
<whitequark> this is the general problem with the address latching trick
<whitequark> I thought it was more broken than it is, but it's still broken
<whitequark> can't exactly blame you
<attie> it's not "address latching trick" so much as "this is the xilinx macro for write first"
<whitequark> attie: what I do in nMigen simulator is I abuse one of the simulator implementation details to do actual forwarding
<whitequark> abuse in the sense that this is an implementation detail no nMigen consumer may rely on
<whitequark> but it will work correctly with any number and any kind of ports
<whitequark> even multiple write ports
<whitequark> let me write the tests for it and push so you can see
<attie> but the re signal is not conforming to the xilinx macros, so I'm not sure exactly how the xilinx tools interpret it
<whitequark> yes, this thing also bothers me about Migen's Memory primitive
<whitequark> it's tailored to Xilinx enough to make it badly fit other FPGAs, but at the same time not enough that you won't get UB
<whitequark> like half of the possible combinations give you nonsensical behavior on Xilinx
<whitequark> honestly, the more i look at it, the more unhappy i am about it
<whitequark> and xilinx FPGAs
<whitequark> and Verilog
<whitequark> really, fuck all of this shit, who thought synthesis from Verilog was a good idea in the first place
<attie> that's a permanent way of life if you work in this area :D
<whitequark> well ice40 does not give me this kind of pain, and ecp5 also seems to behave sanely
<attie> we practically have weekly bitching sessions about "why are our tools so terrible"
<whitequark> "weekly" implies this ever stops
<attie> well in a 20 person office you have to shut up sometimes or the people from other departments will be cross.
<whitequark> lol
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhffT
<_whitenotifier-6> [m-labs/nmigen] whitequark a40e2ca - back.pysim: fix an issue with too few funclet slots.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470913575?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. Absolute coverage decreased by -0.01% but relative coverage increased by +20.72% compared to c49211c - https://codecov.io/gh/m-labs/nmigen/commit/a40e2cac4bb5d082d2c2c754a43cce5c8563b061
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.27%) - https://codecov.io/gh/m-labs/nmigen/commit/a40e2cac4bb5d082d2c2c754a43cce5c8563b061
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark> attie: can you take a look at my simulation models and tests?
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fhfIy
<_whitenotifier-6> [m-labs/nmigen] whitequark fbb5eab - hdl.mem: add simulation model for memory.
<whitequark> basically, in nmigen, there is no MemoryToArray; it directly emits $memrd and $memwr cells for Yosys while providing a behavioral model for the simulator. the simulator actually doesn't understand memory at all.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470944339?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.67% (+0.41%) compared to a40e2ca - https://codecov.io/gh/m-labs/nmigen/commit/fbb5eab18353ef872ed62861138b37bb970d622d
<_whitenotifier-6> [nmigen] Success. 96.77% of diff hit (target 79.25%) - https://codecov.io/gh/m-labs/nmigen/commit/fbb5eab18353ef872ed62861138b37bb970d622d
<whitequark> and I model transparent ports by combining an async port with a latch that prevents any changes while clock is high
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fhfIN
<_whitenotifier-6> [m-labs/nmigen] whitequark e58d9ec - hdl.mem: add simulation model for memory.
<whitequark> the *only* case where you could observe mismatch is if you gate a clock to some submodule while it is low and start changing the address and look at the outout
<whitequark> but this is sufficiently pathological that it's not worth fixing I think
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470945317?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.67% (+0.41%) compared to a40e2ca - https://codecov.io/gh/m-labs/nmigen/commit/e58d9ec74d1bbb17b3214514cea72d97b9d41955
<_whitenotifier-6> [nmigen] Success. 96.77% of diff hit (target 79.25%) - https://codecov.io/gh/m-labs/nmigen/commit/e58d9ec74d1bbb17b3214514cea72d97b9d41955
<attie> whitequark: I have to go now, can you remind me again when you next see me around?
<whitequark> sure
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±4] https://git.io/fhfqP
<_whitenotifier-6> [m-labs/nmigen] whitequark af7db88 - hdl.mem: use different naming for array signals.
<_whitenotifier-6> [m-labs/nmigen] whitequark 7ae7683 - back.pysim: give numeric names to unnamed subfragments in VCD.
<_whitenotifier-6> [m-labs/nmigen] whitequark 48d13e4 - back.pysim: handle out of bounds ArrayProxy indexes.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470959501?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.67% (+<.01%) compared to e58d9ec - https://codecov.io/gh/m-labs/nmigen/commit/48d13e47ec085bb8921bf7bff77803a17cab3fe1
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.67%) - https://codecov.io/gh/m-labs/nmigen/commit/48d13e47ec085bb8921bf7bff77803a17cab3fe1
<whitequark> sb0: all of glasgow gateware tests pass with nmigen.
<whitequark> ok, almost all, one test uses FIFO, which isn't shimmed yet...
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±4] https://git.io/fhfOF
<_whitenotifier-6> [m-labs/nmigen] whitequark fa2af27 - hdl.mem: ensure transparent read port model has correct latency.
<_whitenotifier-6> [m-labs/nmigen] whitequark 568d3c5 - compat: provide Memory shim.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470976473?utm_source=github_status&utm_medium=notification
hartytp has joined #m-labs
<hartytp> white quark: "hopefully artiq will run on nmigen (in compat mode) before end of year " cool!
<hartytp> sb0: "the only potential issue I see with RTM DRTIO is the size of the satman firmware that has to fit in BRAM " shall we stick a bigger Artix on the RTM?
<hartytp> we can always go back to a smaller one in a future design revision once we've finished debugging
<hartytp> but right now I need something that works and FPGAs are cheaper than code optimization
<hartytp> "hartytp: so all SPI would be RTIO/realtime then? "
<hartytp> "then it's exactly the same driver as mirny "
<hartytp> yes and yes
<hartytp> seems like a much nicer way of doing things so long as RTM DRTIO works
<hartytp> if it doesn't then we can fall back to doing things in fw
<hartytp> but that feels like a hack
<hartytp> "btw when will you test the PLL chip for phase determinism? that would be a big problem if it doesn't work "
<hartytp> soon. The eval board is waiting for me in Ox, but I'm in the US now for Christmas
<hartytp> will test it in first week of Jan
<hartytp> but, even if it doesn't work, it's still a better choice than the HMC830. We'd just need to add some extra logic to measure the phase and reset until it gives us what we want
<hartytp> "rewriting into kernels will add some more development time before the board does anything, though, and joe will likely be unhappy with that. and it seems joe still hasn't learned from what happens when he pushes unrealistic deadlines "
<hartytp> not necessarily
<hartytp> my plan would be that I do the port to kernels in a branch
<hartytp> you can focus on getting the existing system working without synchronisation (which no one needs straight away anyway)
<hartytp> and I'll get the kernel port working in parallel. Also a good time to clean up some of the code which is getting to be a bit of a mess
<hartytp> "actually, if we do that then we can strip the non-RT SPI support from the DRTIO firmware on the RTM side, and gain some memory "
<hartytp> that sounds like a good plan! Let's just make the RTM a minimal satman
<hartytp> "whitequark: hey maybe the new laser PDH locker can use Lattice "
<hartytp> why would that card need an FPGA? I'd assumed it would be a simple micro controller to just configure some SPI settings and do some non-realtime ADC readout for diagnostics
<hartytp> the PDH modulation/demodulation would usually be on a separate card to the servo. the servo might want an FPGA if you really want to push BW to the few MHz level (max you can get out of a diode)
<hartytp> but that would be on a different board, or could just use stabilizer if you are happy with BW in the hundreds of kHz range (which one usually is)
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+2/-0/±1] https://git.io/fhfGg
<_whitenotifier-6> [m-labs/nmigen] whitequark fc7da1b - hdl.ir: do not flatten instances or collect ports from their statements.
<_whitenotifier-6> [m-labs/nmigen] whitequark 00ef7a7 - compat: provide verilog.convert shim.
hartytp has quit [Ping timeout: 256 seconds]
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/470992071?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Failure. 78.7% (-0.98%) compared to 48d13e4 - https://codecov.io/gh/m-labs/nmigen/commit/00ef7a78d38f542c39488df918e42013bbc65c56
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing 48d13e4...00ef7a7 - https://codecov.io/gh/m-labs/nmigen/commit/00ef7a78d38f542c39488df918e42013bbc65c56
d_n|a has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
key2 has joined #m-labs
rohitksingh has joined #m-labs
<sb0> hartytp: the 15t is the same silicon as the 50t :)
<sb0> but we can put devices that say 50t on the package and the idcode if that's safer...
<sb0> 26MHz or even 60 is much slower than xilinx. and I don't know why everyone uses picorv32, it's a pretty bad CPU
<sb0> whitequark: synthesizing the memory cells is a good idea. i was considering doing it within migen, but it's even better if we can reuse the yosys code
hartytp has joined #m-labs
<sb0> note that SyncFIFOBuffered uses an external register to turn the RAM read from async into sync
<sb0> so it will need rewriting
<hartytp> sb0: you mean that we can probably tell vivid we have a 50T and flash that onto a 15T and it will probably work?
<sb0> iirc that's the only significant place where this trick is used
<hartytp> s /vivid /vivado
<sb0> hartytp: no, it will fail idcode check. so that and the bitstream CRC need to be edited after synthesis.
<hartytp> so, question is how many Sayma boards we'll make in the next few years and the cost of FPGAs versus cost of paying someone to hack bitstreams
<hartytp> my guess is the FPGAs are cheaper ;)
<sb0> oh it's a trivial hack. i've been wondering if it should be enabled in migen by default.
<sb0> that and smashing other obnoxious vivado features such as webtalk
<hartytp> well, ultimately I'll leave FPGA-related decisions up to you and rjo
<hartytp> my only comment is that Sayma working quickly is quite valuable to me, so if we're going to rely on doing this then it had better work with minimal fuss
<sb0> yeah, maybe we can stuff 50t on the protos and use 15t later...
<sb0> if that needs to be done in a hurry then i'd say go for 50t
<sb0> they're pin compatible
hartytp has quit [Ping timeout: 256 seconds]
<sb0> but then those protos will have a small compatibility issue
hartytp has joined #m-labs
<hartytp> sb0: ack
<hartytp> the real question is how many Sayma boards are ever going to be produced
<hartytp> if they become widely used then there will be plenty of incentive to improve things
<hartytp> but, right now, we have a really expensive RF card produced in small quantities and we're worrying about like $30 worth of additional FPGA costs. Unless the batch size increases that FPGA cost is nothing compared to even relatively trivial gateware work
<hartytp> anyway, as I said, your call.
<hartytp> if we need to, TS/Creotech also offer FPGA replacement pretty cheaply (we've had some dead Kaslis fixed that way).
<sb0> so the 15T has ~100kbytes of BRAM
<sb0> (usable)
<sb0> and the 50T has 300
<sb0> without any optimization and with switching support, satman is at 88K of code
<sb0> you need some memory on top of that for bss and stack
<sb0> if we really want to spend the absolute minimum amount of time on this, then the 50t is a safer choice
<hartytp> let's assume Sayma is >$500 per channel (so $4k for the AMC + RTM), which would be really good going for an RF card like this and is almost certainly an underestimate of actual costs
<hartytp> so adding $40 for the RTM is a 1% increase on the cost.
<hartytp> obviously it's a slippery slope if one takes that attitude everywhere, but in this case it seems like a no brainer to me
<hartytp> ultimately, the thing that is most likely to kill Sayma as a project is lots of small issues causing delays until everyone gets fed up and gives up
<hartytp> anywhere where we can inject a small amount of cash to reduce time/risks seems worth doing to me
<sb0> oh but hacking xilinx fpgas is fun
<sb0> unlike e.g. microtca supplies not working
<hartytp> haha
<hartytp> well, up to you
<sb0> let's go for 50t, we can populate the other one later, and we have sayma v1 to test
<hartytp> really nothing more I can add to this other than to reiterate that currently my plans for Sayma rely on DRTIO so I need it to work fairly fast
<hartytp> :)
hartytp has quit [Ping timeout: 256 seconds]
<cr1901_modern> sb0: The idea behind picorv32 is that it can in most designs it can be run as a control CPU without requiring a separate clock domain between your speed-sensitive logic and the CPU. It runs at like 700MHz on Virtex devices.
<cr1901_modern> But of course to meet that goal, everything is registered, and CPI is > 1. The fact that it is small is a nice side effect.
m4ssi has quit [Remote host closed the connection]
<key2> whitequark: we managed to port minerva to nMigen
<key2> but that crashes yosys
<key2> (have not tested it yet tho, just generated)
<key2> so we generate the rtlil, and use yosys to do opt before generating the verilog
<GitHub-m-labs> [artiq] drewrisinger opened issue #1223: Docs: wrong path for https://github.com/m-labs/artiq/issues/1223
<GitHub-m-labs> [artiq] drewrisinger opened issue #1224: Docs: artiq_flash has no -m option https://github.com/m-labs/artiq/issues/1224
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1224: Yes, send a PR. https://github.com/m-labs/artiq/issues/1224#issuecomment-449455028
rohitksingh has quit [Ping timeout: 250 seconds]
key2_ has joined #m-labs
key2 has quit [Quit: Page closed]
key2_ is now known as key2
rohitksingh has joined #m-labs
nurelin_ has quit [Ping timeout: 245 seconds]
nurelin_ has joined #m-labs
rohitksingh has quit [Remote host closed the connection]
<whitequark> key2: ah nice
<whitequark> 15:56 < sb0> note that SyncFIFOBuffered uses an external register to turn the RAM read from async into sync
<whitequark> Yosys synthesis is smart enough to fold that into memory cells.
<whitequark> 15:54 < sb0> 26MHz or even 60 is much slower than xilinx. and I don't know why everyone uses picorv32, it's a pretty bad CPU
<whitequark> iCE40 is the slowest FPGA series currently on market
<whitequark> it's optimized for power consumption not fabric speed
mumptai has joined #m-labs
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fhfp0
<_whitenotifier-6> [m-labs/nmigen] whitequark 913339c - hdl.ir: fix port propagation between siblings.
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhfpz
<_whitenotifier-6> [m-labs/nmigen] whitequark a4183eb - hdl.mem: use more informative signal naming for ports.