ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting September 14th
<sorear> Lofty: not sure if you're talking about alpha or ia64 but either way I'd have to look at the manuals
<Lofty> IA64.
<FL4SHK> I'm not at all familiar with rocket-chip
<sorear> in general, nobody loves integer divide
<FL4SHK> I've noticed
<FL4SHK> there's not really a good reason for that from what I can tell
<Lofty> ...I got divide and multiply mixed up, I do apologise
<FL4SHK> I'll be supporting vector integer divides, with AVX does *not* do
jaseg has joined #nmigen
<FL4SHK> I need to study numerical analysis
<FL4SHK> I think it'd be feasible to simply do Newton-raphson with fixed point and end up with the correct result
<FL4SHK> don't know how to find the maximum number of iterations to perform Newton-raphson for?
<FL4SHK> it sounds like an on-paper math problem, which should be fun
<sorear> well you can do error bounding easily enough
<sorear> I'm a little confused about how this works for divides, which have 2 arguments, but given that this is a super common implementation strategy I have some confidence it's possible to meet 754's correct rounding requirement
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
hitomi2508 has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 246 seconds]
jjeanthom has joined #nmigen
jaseg has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 240 seconds]
jjeanthom has quit [Ping timeout: 240 seconds]
jjeanthom has joined #nmigen
jjeanthom has quit [Read error: Connection reset by peer]
<lkcl> FL4SHK: have a look at the jondawson fpu. it's a FSM, trading "long completion time" for "LUTs needed"
<lkcl> FL4SHK: we didn't implement NR, however my understanding is that you implement them as a FSM and keep on iterating until the error is below the acceptable threshold.
<lkcl> that means needing to have internal mantissa large enough to hold the intermediate results so that you _can_ detect that
<lkcl> then, yes, sorear, the rounding is computed from what's left (the remaining bits that didn't go into the output result)
<lkcl> like this for example:
<lkcl> having massive intermediary registers that are 2x or 3x the output result mantissa is pretty "normal"
<lkcl> for a 64-bit divider because the mantissa is 54 bits all the intermediate registers are 108 bits wide
emeb has joined #nmigen
jeanthom has joined #nmigen
hitomi2508 has quit [Quit: Nettalk6 - www.ntalk.de]
<d1b2> <EmilJ> vup: what's your preferred method of getting your bitstream to the board?
<vup> @EmilJ: re the FIFO making the timing worse: that is really weird, the encoder is the TMDS encoder so it could be possible this will not produce valid TMDS
<d1b2> <EmilJ> dangit
<vup> whatever is the most convenient for getting the bitstream to the board for you, for boards with a zynq + ethernet I use ssh to copy it over and load it using the kernel
<d1b2> <EmilJ> could you build camera.py and check for oserdes timing?
<d1b2> <EmilJ> hmm, what kernel functionality provides bistream download
<vup> if you use the xilinx kernel you can echo the bitstream into "/dev/xdevcfg"
<d1b2> <EmilJ> like, cat thing.bit > /dev/xdevcfg?
<vup> yes
<d1b2> <EmilJ> should I expect a system reset?
<vup> no
<d1b2> <EmilJ> yay
<vup> if you use mainline, you need to copy the bitstream to "/lib/firmware", potentially stripping the header using for example this script: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/b43f280f929f365a164b1f3f5f055547e15d5179/src/soc/platforms/zynq/to_raw_bitstream.py#L14 and then `echo "name_of_the_bitstream.bin" > /sys/class/fpga_manager/fpga0/firmware`
<d1b2> <TiltMeSenpai> out of curiosity, are there plans to support the quicklogic chips in nmigen and/or is there interest in this?
<d1b2> <TiltMeSenpai> I just got mine like a couple days ago and I'm wondering what I'm actually going to do with it
yosys-questions has joined #nmigen
<d1b2> <EmilJ> vup: /sys/class/fpga_manager/fpga0/firmware: Permission denied oh no (even with sudo)
<vup> what is your exact command?
<d1b2> <EmilJ> echo "hdmi_test_PynqZ2.bin" > /sys/class/fpga_manager/fpga0/firmware
<d1b2> <EmilJ> xilinx@pynq:~$ file /sys/class/fpga_manager/fpga0/firmware /sys/class/fpga_manager/fpga0/firmware: ERROR: cannot read `/sys/class/fpga_manager/fpga0/firmware' (Input/output error)
<d1b2> <EmilJ> what the heck
<vup> hmm, does dmesg say anything?
<d1b2> <EmilJ> failed to open journal: is a directory
<d1b2> <EmilJ> xilinx@pynq:~$ file /sys/class/fpga_manager/fpga0/firmware /sys/class/fpga_manager/fpga0/firmware: ERROR: cannot read /sys/class/fpga_manager/fpga0/firmware' (Input/output error) `
<d1b2> <EmilJ> woops
<d1b2> <EmilJ> Direct firmware load for hdmi_test_PynqZ2.bin failed with error -2 meant to send this
<d1b2> <EmilJ> interestingly enough, the bit2bin file has the same byte count as the bit file as well as the bin file generated by the build automagically
<vup> I think you need flip_data=True for bit2bin
<vup> we should make that the default
<d1b2> <EmilJ> well, I have been running a modded version of program_bitstream_ssh.py
<d1b2> <EmilJ> which has flip_data=True
<d1b2> <EmilJ> py bitstream_name = "{}.bit".format(name) bin_bitstream = bit2bin(build_products.get(bitstream_name), flip_data=True) with open(name + ".raw.bin", "wb") as f: f.write(bin_bitstream)
<vup> hmm shouldn't it be `hdmi_test_PynqZ2.raw.bin` then?
<vup> -2 would be no such file or directory
<d1b2> <EmilJ> I have renamed it, after copying it to /lib/firmware
<vup> and you are sure `/lib/firmware/hdmi_test_PynqZ2.bin` exists?
<d1b2> <EmilJ> yes
<d1b2> <EmilJ> `xilinx@pynq:~$ ls /lib/firmware | grep hdmi hdmi_test_PynqZ2.bin
<d1b2> <EmilJ> should file hdmi_test_PynqZ2.bin return something more specific than "data"?
<d1b2> <EmilJ> sudo echo "base.bin" > /sys/class/fpga_manager/fpga0/firmware returns zero, and I see the "Done" LED turn off for ~100ms on the board when I do that
<d1b2> <EmilJ> so it's not like I can't write to the firmware thingy
<d1b2> <EmilJ> I'll just do the thing I did last time, where I ran the python thingy
<vup> don't think file knows about the xilinx bitstream format, atleast with its header stripped
<vup> so data seems appropriate
<d1b2> <EmilJ> hey, that didn't crash, neat
yosys-questions has quit [Remote host closed the connection]
XgF has quit [Remote host closed the connection]
XgF has joined #nmigen
<Degi> A signal being high for 1 clock cycle is enough to make a FSM transition, right?
<Degi> Somehow my FSM doesn't do that, despite the signal being 1 for one cycle... When I set it to "1" instead of the signal, it proceeds to the next state, so the FSM itself seems to work
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<Degi> Actually nevermind, something else is broken.
_whitelogger has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
<_whitenotifier-f> [nmigen] whitequark commented on issue #439: fsm_state changes mid cycle - https://git.io/JUXEf
emeb has left #nmigen [#nmigen]
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 2 commits to cxxsim [+3/-0/±5] https://git.io/JUXEC
<_whitenotifier-f> [nmigen/nmigen] whitequark b01b371 - [WIP] sim: add cxxsim engine.
<_whitenotifier-f> [nmigen/nmigen] whitequark 070036f - sim._cxxrtl: fix setters of multichunk values (#439).
<_whitenotifier-f> [nmigen] whitequark commented on issue #439: fsm_state changes mid cycle - https://git.io/JUXE8