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
kristianpaul has quit [Quit: leaving]
<sb0__> ....
<cr1901_modern> Is that bad?
* cr1901_modern is a sockets API user, not implementer
kristianpaul has joined #m-labs
<cr1901_modern> Well I guess it is, if sb0's only response is "...." :P
<sb0__> the consequence for the user is TCP keepalive doesn't work from a vbox guest
<cr1901_modern> Should a person really be using keepalive in the first place? The person who taught me sockets told me to basically assume "sockets can and will break", don't try to spend time trying to salvage a connection. Save state, make a new connection, continue where you left off
<sb0__> how do you know when the socket is broken without keepalive?
<sb0__> tcp has lousy error detection mechanisms
<cr1901_modern> select timeout :P
<sb0__> what?
<cr1901_modern> Okay, I wasn't being totally serious, but each program I've written using sockets, there was always a heartbeat from the server side
<sb0__> expecting some data periodically from the remote end is exactly what tcp keepalive does, and would do in a cleaner way if implementations weren't idiotic
<cr1901_modern> Oh... then I'm an idiot then
sb0__ has quit [Quit: Page closed]
sb0 has joined #m-labs
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
sb0 has quit [Ping timeout: 264 seconds]
sb0 has joined #m-labs
<mithro> We just opened the crowd funding campaign for the Numato Opsis - https://www.crowdsupply.com/numato-lab/opsis - Feel free to poke me if you see any factual errors on the page
attie has quit [Ping timeout: 244 seconds]
attie has joined #m-labs
<sb0> mithro, we did have pretty complete M1 boxes, not just "early developer kits"
<mithro> sb0: Wikipedia is lying to me then :P
<sb0> we did sell a few of the devices exactly as on this video: https://vimeo.com/30842451
<sb0> mixxeo is ddr1, not ddr2
<sb0> and doesn't have VHDCI or GbE (only 100M)
<mithro> sb0: oh - I see what has happened the columns have been swapped with the Digilent Atlys one
<sb0> anyone knows a 7-series board that has SFP and a high speec (>= 2.4Gsps) DAC?
<sb0> *speed
<mithro> anyway I should be sleeping
<larsc> sb0: probably not what you are looking for, but ZC706+DAQ2
<sb0> DAQ2?
<sb0> is that FMC?
<larsc> yes
<sb0> so this doesn't need a zynq, does it? i can put it on eg a kc705
<larsc> yes
<sb0> does the AD9144 work correctly?
<larsc> I hope
<larsc> It works to the point that I haven't seen any issues
<larsc> the thing to be aware of is that the data link is jesd204b
<larsc> means you either need to create your own phy for that or pay extra money to xilinx
<sb0> i'm pretty sure the xilinx core is garbage as usual so i'd rather get a proper phy developed
<larsc> yeah, shouldn't be too hard
<larsc> the gtx takes care of most of the complicated stuff
<larsc> is basically just providing the right control signals to it and implement descrambling + synchronization
<sb0> hmm
<sb0> 4 channels * 16 bit * 2.8GSPS = 180Gbps
<sb0> divided by the 8 transceiver lanes, that makes 22.4Gbps/lane
<sb0> so you need one of those FPGAs with the beefy transceivers, I guess?
<larsc> 12.5 is the limit
<larsc> with 10b8b overhead
<sb0> ah. so you can only use two channels at the max sample rate.
<larsc> the ad9144 has a NCO
<sb0> http://www.digikey.com/product-detail/en/AD9144-FMC-EBZ/AD9144-FMC-EBZ-ND/4915052 is considerably cheaper and doesn't have the ADC I don't need
<larsc> will probably work as well
<larsc> but I've never worked with it
<sb0> oh, it has an interpolation mode
<sb0> mh. looks complicated.
<larsc> you can bypass all of that if you want to
<larsc> but yes, it's an rf dac, so you can supply a lower rate datastream and it can modulate it onto a reference frequency
<sb0> the dac5670 looks less finicky
<larsc> wrong company though ;)
<sb0> would be nice if there were fpgas with integrated no-frills high-speed DACs
<sb0> i'd rather spend my time developing dsp algorithms than deciphering the scriptures of the proprietary chip du jour to figure out why writing to register X breaks 3% of the time
<larsc> don't we all?
terpstra has joined #m-labs
<terpstra> sebastien, you here?
<terpstra> (no idea what your irc name is)
<sb0> hi terpstra
<sb0> yes
<sb0> welcome back! long time no see.
<terpstra> sb0, hey, it's wesley from gsi
<terpstra> yeah, indeed
<terpstra> i was just curious about your graphics core
<terpstra> you can output hdmi 720p60 ?
<sb0> which graphics core?
<sb0> the framebuffer one? yes.
<terpstra> for your DJ video mixing box
<terpstra> are you doing that using a serdes phy on the xilinx, pulling the framebuffer from sdram?
<sb0> yes, mixxeo does 2x 720p60 in + 1x 720p60 out
<sb0> with mixing
<sb0> yes
<sb0> there's a receiver as well
<terpstra> interesting. i might steal some code from you for my own purposes, if that's ok with you :)
<sb0> sure, it's open source
<sb0> what are you up to?
<terpstra> also fyi, in case you are interested, i've been working on an out-of-order soft-cpu that can run risc-v/lm32/nios instructions... in case you want more speed :)
<sb0> oh yes, definitely
<terpstra> still working on the control system here
<terpstra> it's not ready yet, but in a month or so i hope to be booting linux :)
<sb0> and you need hdmi code for the control system?
<terpstra> no, for my cpu =)
<terpstra> i want to be able to hook it up to a monitor
<terpstra> the cpu is my private side project
<sb0> as a matter of fact, artiq (which you might have seen) will probably use some of that hdmi code, in fact
<terpstra> interesting
<terpstra> i think you are the only game in town for an open hardware hdmi framebuffer. :)
<sb0> for transmitting data to remote fpgas over fiber optics.
<sb0> is some of the cpu code public already?
<terpstra> yes
<sb0> a faster cpu is definitely something that artiq could use
<terpstra> but it's not finished yet
<terpstra> it lacks a branch predictor (which matters a lot as the pipeline is 10 cycles deep) and load-after-store alias detection
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<terpstra> atm it hits 150MHz for a 3-way execute CPU on cyclone V and 125MHz for 5-way execute
<terpstra> but i expect that to drop once i include an MMU
<terpstra> i'll let you know when it's usable as a drop-in replacement for the lm32, though
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<terpstra> BTW, do you have a document somewhere for the PTE format you used in the MMU for the LM32?
<sb0> sounds great!
<terpstra> i plan to support Sv32 and Sv39 risc-v PTE formats
<terpstra> but i know you have some custom solution
<sb0> hmm, if it's not in the repository, I think not
<sb0> how fast do you expect this cpu to be compared to the original lm32?
<sb0> both without mmu
<terpstra> so i expect it will run a bit slower MHz-wise
<terpstra> i'm not sure what an lm32 on cyclone V hits, but i guess 175MHz ?
<terpstra> on the IPC front, though, it will be a lot faster
<sb0> we're running the cpu at 125MHz on kintex7 right now due to sdram and vivado issues
<terpstra> on tight loops it can execute full throughput .. so 4 ops/cycle
<sb0> nice!
<terpstra> also LM32 has no branch prediction, i believe you pay 5 cycles to issue a taken branch / jump
<sb0> how many luts?
<terpstra> uhm, let me open my text file (it depends on the parameters you pick)
<terpstra> so, keep in mind these numbers do not include a complete L1d or branch predictory
<sb0> L1d?
<terpstra> so for a 3-way CPU which considers 14 instructions at a time => 4.1k LEs
<sb0> L1 data cache?
<terpstra> L1 data cache
<sb0> what's a LE again?
<terpstra> logic element
<terpstra> altera terminology
<sb0> are those the same on all alteras? what does it contain?
<terpstra> it's the standard core element on all modern altera chips, yes
<terpstra> you could say it contains 2 LUTs, but not really
<sb0> it's old though
<terpstra> one LE is either 1x 6:1 LUT or 2x 4:1 LUTs
<terpstra> and a half used LE still counts as a full LE
<sb0> okay
<sb0> for 4-wide issue?
<ysionneau> 16:53 < terpstra> BTW, do you have a document somewhere for the PTE format you used in the MMU for the LM32? < https://github.com/m-labs/lm32/blob/master/doc/mmu.rst
<sb0> that sounds excellent.
<terpstra> well, it will be bigger
<terpstra> and i said that was only for 3-way 12 cycle look ahead
<terpstra> if you go up to 4 execute, 4 issue, 28 look ahead, it goes up to 8.7k
<sb0> still very reasonable
<terpstra> you can pretty much trade-off performance/area
<terpstra> ysionneau, thank you for the link!
<terpstra> ysionneau, so it's only one level deep? and does not refill the TLB itself?
<sb0> yeah it's software refill
<terpstra> hmm. that's quite different from the risc-v approach
<sb0> not optimized for perf, unlike yours
<terpstra> so there is no PTE format b/c it's done by software
<ysionneau> yep
<terpstra> i need to think how hard it would be to support that
<ysionneau> but you could say that the TLBVADDR "format" is kind of a PTE format
<ysionneau> you are encouraged to use the same format in your OS page table to get optimal perfs
<terpstra> i'm not sure if it makes sense to support this sort of MMU when i already plan on doing Sv32
<terpstra> are you guys actually running linux with this MMU?
<sb0> no
<terpstra> do you use the MMU for your current project at all? :)
<cr1901_modern> ysionneau is porting NetBSD
<terpstra> ah
<cr1901_modern> that uses the MMU by virtue that Net doesn't run without one :P
<terpstra> sure
<sb0> gotta go to a meeting, ttyl
sb0 has quit [Quit: Leaving]
<ysionneau> so far the port is unfinished though
<terpstra> the risc-v guys have a working linux port
<ysionneau> kernel boots up to mounting rootfs and runs a *very* basic /sbin/init containing just a few open() and a write() to stdout
<terpstra> which is the main reason i want to support their PTE format
<ysionneau> so your cpu will support several ISA?
<terpstra> yeah, it's just one file that does the decode
<ysionneau> ok so you select the ISA at synthesis time I guess
<terpstra> just fill in your instruction set here
<terpstra> yes!
<terpstra> not dynamically
<terpstra> the CPUs have to be fairly similar
<cr1901_modern> I can't believe someone did an OOE unit by themselves. Hobbyists never cease to amaze me
<cr1901_modern> and keep me motivated to improve
<terpstra> so LM32, risc-v, and nios are all similar enough that i can support them all
<ysionneau> very good :)
<ysionneau> you seem to have done a tremendous job!
<terpstra> but say, sparc, would not be possible (register windows)
<terpstra> arm with its weird rotate instructions would also not work
<terpstra> any variable length instruction set, also not possible atm
<ysionneau> don't you fear the branch prediction logic will decrease your max frequency?
<terpstra> no
<terpstra> i intend to use IT-TAGE but applied to cache lines instead of instructions
<terpstra> all that requires is reading 2-4 memory blocks, comparing a small (8-9 bit) tag, and then selecting the chosen way
<terpstra> i think it's actually easier, because in an FPGA our memories are fast compared to core logic, unlike in an ASIC
<terpstra> IT-TAGE in an ASIC needs to be pipelined, but i am willing to bet it is not necessary on an FPGA
* ysionneau does not know IT-TAGE
<ysionneau> but you seem to have thought this through already :)
<terpstra> "A case for (partially) TAgged Geometric history length branch prediction"
<terpstra> it's a branch predictor with similar miss rates to haswell
<terpstra> but it's shockingly simple
<ysionneau> wow
<terpstra> the circuit is Figure 1 in that paper
<terpstra> actually, figure 5 is closer to what i want to do
<terpstra> my intention is to do branch prediction BEFORE decode, because icache+decode are 2-3 cycles late
<terpstra> i'm betting you can do an IT-TAGE next-line branch predictor in an FPGA;)
<ysionneau> I'll have a look :)
<cr1901_modern> re: OPA, essentially anything that's a MIPS32 clone can be supported?
<terpstra> cr1901_modern, i would rather say yes/no on a case-by-case basis :)
<terpstra> mips has branch delay slots, for example. i can't do those.
<terpstra> i mean, maybe you could modify it to work, but out-of-the-box it has to be pretty similar to the lm32/risc-v
<terpstra> (besides, the only interesting instruction sets are those that a free to use)
early has quit [Ping timeout: 244 seconds]
early has joined #m-labs
<cr1901_modern> terpstra: Yes, I agree. I was just thinking of one of NEC's old V-series ISAs
<terpstra> i don't know that one
<cr1901_modern> terpstra: http://www.planetvb.com/content/downloads/documents/U10082EJ1V0UM00.pdf It reads like a MIPS clone, except with hardware interlocking
<cr1901_modern> and nifty bit-string instructions
<mithro> terpstra: I've been trying to breath some more life into misoc for video processing - _florent_ has been working on http://hdmi2usb.tv/firmware-misoc/ for me and we just launched a crowd funding campaign for our board https://www.crowdsupply.com/numato-lab/opsis which has 2 x 720p@60 input and 2 x 720p@60 output (plus GTP tranceivers on DisplayPort
<mithro> connectors).
<cr1901_modern> mithro: I'm sure you've been asked this plenty of times, but what's the point of having a PCIe connector if no existing card can attach to it without frying it?
<mithro> Actually, we won't fry anything
<cr1901_modern> well, that's good, but no existing card will work, correct? :P
<mithro> Yes
<mithro> It's for expansion boards well develop.
<mithro> Then PCI express connector is cheap and supports high speed signals
<mithro> S/well/we will/
<mithro> cr1901_modern: I really need to write up some better information about what I'm trying to do there.
<mithro> Bblr
<cr1901_modern> I was just yanking your chain anyway, don't worry :)
<terpstra> at gsi we have a PCIe female plug on a board ... but actually it's male :P
<terpstra> so you have to stick a double-ended PCIe male-male cable into it and your computer
<terpstra> (thunderbolt is apparently too big a pain to get connectors for)
sb0_ has joined #m-labs
<sb0_> mithro: can you correct the part about the m1 only available as developer kit?
sb0_ has quit [Client Quit]
sj_mackenzie has joined #m-labs
sj_mackenzie has quit [Remote host closed the connection]
sj_mackenzie has joined #m-labs
MastaTabs has joined #m-labs
<MastaTabs> hi there
<mithro> Hrm, I thought we had - will get that fixed.
<terpstra> anyway, i'll be back when it can fully replace the lm32. ciao.
terpstra has quit [Quit: Leaving]
<MastaTabs> I've just been trying misoc on my minispartan6 with the lx25, compiled/translated it myself and made the needed changes for the lx25 version
<MastaTabs> runs the bios so far, still a problem with the 'payload' but thats not to much a hassle right now
<MastaTabs> was trying to get the framebuffer to work but found that it seems to need 32bit wide memory, am I right ?
attie_ has joined #m-labs
hozer1 has joined #m-labs
nicksydney has quit [Read error: Connection reset by peer]
nicksydney has joined #m-labs
hozer has quit [Ping timeout: 244 seconds]
attie has quit [Ping timeout: 244 seconds]
<mithro> MastaTabs: _florent_ has a MiSoC repo for the miniSpartan6+ - dunno were he go to...
<MastaTabs> know the address ?
<MastaTabs> think I got it
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Disconnected by services]
cr1901_modern1 is now known as cr1901_modern
hozer1 has quit [Ping timeout: 250 seconds]
hozer has joined #m-labs
<GitHub84> [artiq] fallen pushed 1 new commit to master: http://git.io/vGxe3
<GitHub84> artiq/master 7dfd11e Yann Sionneau: pxi6733: try to fix ping method
MastaTabs has quit [Quit: Verlassend]
sb0 has joined #m-labs
<sb0> mithro, is the project based in bangalore?
<GitHub71> [artiq] raghavendrasrinivas opened pull request #127: dds: expose amplitude register, add runtime hooks (master...dds_amplitude) http://git.io/vGxqh
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#459 (master - 7dfd11e : Yann Sionneau): The build passed.
travis-ci has left #m-labs [#m-labs]
<sb0> ysionneau, logger.debug!
<sb0> ah, yes, bangalore
<sb0> mithro, btw, the milkymist one isn't a mixer
<sb0> and those devices worked (barring a few bugs and design issues)
<mithro> sb0: the guys doing the hardware manufacturing are in Bangalore
<mithro> (Numato Lab)
<mithro> sb0: but you can't buy them anymore, right?
<sb0> not from me
<sb0> the hardware and processing part of the mixxeo also works, what doesn't is the mechantronics stuff with is a real pain and would probably require an expensive board respin, among many other extremely annoying problems
<sb0> *mechatronics
<mithro> sb0: That is based on the firmware at github.com/m-labs/mixxeo-soc ?
<sb0> yes
<sb0> you can take that, load it into a mixxeo, connect a few pot and do crossfade/add/blackout
<sb0> at 720p60
<sb0> oh, the resolution is also a pain, it's limited by the slowtan6 serdes and people are complaining
<mithro> Yeah - if you were doing the board now, an Artix-7 which can do 1080p would be a better option
<sb0> so that + the mechatronics problems which are as expensive as they are petty make it not such a great idea to pursue ...
<GitHub176> [artiq] fallen pushed 1 new commit to master: http://git.io/vGxsR
<GitHub176> artiq/master 63d4907 Yann Sionneau: pxi6733: replace print by logger.debug
<sb0> there are external hdmi chips that can do higher resolutions...
<sb0> non-FPGA vendors can get high speed silicon right, it seems
<mithro> sb0: yeah - I assume you have "abandoned" the mixxeo unless someone else wants to pick up the work?
<sb0> yeah, basically
<sb0> or if someone wants to buy a lot of them
<sb0> and well, 1080... there was someone asking about 4k in the channel the other day
<sb0> it never ends
<sb0> and fpga vendors suck at making fast chips
<sb0> compare GDDR5 with what you can do with a fpga ...
<sb0> well there's HMC, but the price is ridiculous
<mithro> Yeah
<mithro> sb0: My primary use case is the conference video capture / streaming - the main reason I'm interested in the mixxeo type stuff is in the hope of finding people to share development resources with
<mithro> sb0: With FOSS projects like maybe 1% of people end up contributing, so the more people I can get interested in the project - the more likely we'll get another contributor.
<mithro> sb0: After getting _florent_ to rewrite our crappy VHDL/Verilog firmware mix in misoc/migen I have no idea why we didn't just use your stuff earlier
<mithro> sb0: so, I'd really like to get people contributing / working on improving misoc stuff around video again