azonenberg_work has quit [Ping timeout: 265 seconds]
<rqou> I'm not sure if greenpak has enough state bits to deal with a basic filesystem parser
<rqou> doing this with a microcontroller is easy
maaku has quit [Read error: Connection reset by peer]
maaku has joined ##openfpga
<diamondman> A little AVR could likely get that working easy
<diamondman> Give it a crystal and run it at like 16 MHZ... prob fast enough for decent speed
<rqou> yes, of course
<rqou> the point was to try to squeeze it into a greenpak
<dalias> rqou, fat is pretty trivial, but maybe not
<rqou> greenpak only has ~20 FFs
<dalias> raw partition would almost surely be possible but also less friendly
<diamondman> I was thinking of raw. Not bad. Just dd the hex file
<diamondman> though you may need to follow it with a size do it doe not read the whole rom
<rqou> making this work on the greenpak is going to require quite a bit of magic
<rqou> it only has 12 FFs
<rqou> not even necessarily enough to store the current sector number
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tecepe has joined ##openfpga
doomlord has joined ##openfpga
digshadow has joined ##openfpga
<cyrozap> diamondman: Hey, I hadn't heard of your project before, that's very interesting! Have you done any performance comparisons between it and OpenOCD?
talsit has left ##openfpga [##openfpga]
<cyrozap> dalias: "i would guess the mimas_v2 can also be programmed over the usb serial directly rather than just flashing it over that" <- The PIC microcontroller on the Mimas V2 is only programmed to do raw SPI R/W and serial UART, and it is not connected to the JTAG pins of te FPGA at all.
<dalias> ah ok
<dalias> there is a jtag interface tho
<cyrozap> dalias: "why do these boards always have such awful interfaces rather than something trivial to program like spi over usb-serial?" <- That's exactly what the Mimas V2 does, and it is terribly unreliable.
<dalias> but you need the right cable for it
<dalias> i don't see how it's "terribly unreliable"
<cyrozap> I've had very bad experiences with it :/
<dalias> were you perhaps running ubuntu with ModemMangler^H^H^H^Hager installed?
<cyrozap> Especially with that switch to change between "USB->SPI" and "USB->UART"
<dalias> it spams hayes AT commands to every serial device that gets connected :-)
<rqou> hey, some people actually need something like ModemManager
<cyrozap> dalias: No
<rqou> not just for dial up, but for 3G dongles
<cyrozap> dalias: I was just using the Python 3-based tool from Numato on my Arch Linux machine. No modem manager or other serial trickiness.
<dalias> the python tool works fine for me
<cyrozap> dalias: I've been meaning to write an alternate firmware for that device that would enable it to do simultaneous UART and SPI flashing (via USB CDC-ACM and HID, respectively), but that would involve having to actually write firmware for a PIC microcontroller (eww)
<rqou> eww indeed
<dalias> and the switch actually makes sense -- if you do use the board inside something that should be reasonably physically secure without opening the box, having the flash interface exposed on the usb port is not good :-)
<cyrozap> I think the issue I was having with the Python tool was that the switch would sometimes leave the UART to the FPGA in an unusable state (see my forum post here: https://community.numato.com/threads/mimas-v2-uart-doesnt-work-under-certain-circumstances.71/)
<cyrozap> Flashing usually went ok, but was extremely slow
<cyrozap> (compared to JTAG using my J-Link)
<dalias> btw one thing about the mimas_v2...
<azonenberg> cyrozap: lol, usb serial is a nightmare
<dalias> the factory firmware has the uart stuck at 19200 which is miserable to use
<azonenberg> This is one of the reasons why i can't wait to make myself a custom ethernet-jtag adapter
<rqou> wait, the baud rate from the USB interface is ignored?
<dalias> there's a replacement firmware that makes it fast but the update utility is windows-only afaik and doesn't have a way to revert
<dalias> rqou, not the usb-side
<dalias> it's like this
<rqou> afaik USB CDC allows specifying a baud rate
<rqou> azonenberg: what's wrong with USB CDC?
<rqou> other than it's designed for modems
<dalias> there's the usbserial interface on one side of the microcontroller
<dalias> and on the other side there's a fixed-baud uart connected to the fpga
<azonenberg> rqou: first off, the silicon is often unreliable when you're moving 100s of MB or GB through it nonstop
<azonenberg> i have had FTDI devices randomly drop writes
<azonenberg> under high load
<azonenberg> second, you have 480 Mbps under ideal conditions across all adapters plugged into one machine
<dalias> if the soft uart on the fpga doesn't match that speed, it won't communicate
<azonenberg> 240 Mbps in one direction
<rqou> but FTDI isn't actually CDC
<azonenberg> When you have a lot of boards being used simultaneously in a test farm etc, it adds up
<rqou> i was thinking a programmed microcontroller
<azonenberg> I'm talking usb serial at all, regardless of if it's CDC, FTDI, or something else
<azonenberg> the bandwidth limitation is a fundamental problem
<azonenberg> and nobody makes usb 3.x uart/jtag dongles that are cheap
<azonenberg> oh, and you need a cable server to hook it up to a LAN
<rqou> other than FTDI? :P
<azonenberg> i said usb3
<azonenberg> do they have a usb3 chip that does jtag?
<rqou> iirc FTDI had a usb3 chip
<azonenberg> somehow i doubt it
<azonenberg> its prob for fast parallel buses etc
<azonenberg> whereas, with 1000baseT...
<azonenberg> you just plug the board into the LAN
<azonenberg> hang eight devkits off the ribbon headers
<azonenberg> and you're done
<rqou> FT60x, and apparently fifo only
<rqou> not that MPSSE's stupid turnarounds can saturate usb3 anyways
<azonenberg> lol
<azonenberg> Yeah
<azonenberg> My plan is for the ethernet-jtag dongle to, eventually, implement some higher level commands
<rqou> especially on usb, turning around the bus takes forever
<azonenberg> so you can netcat a .bit to it
<rqou> (at least on usb2)
<azonenberg> But that was one of the other reasons i liked ethernet over usb
<azonenberg> Much lower latency
<azonenberg> i can ping my FPGA board in the garage in 39 us round trip
<azonenberg> that's <20us one way latency
<azonenberg> and that's through two switches
<rqou> speed of light time is ?
<rqou> oh nvm there are switches
<azonenberg> um... let's see, the fiber is 20-30m long (I don't need the distance but that's what i had sitting around)
<cyrozap> rqou: It's on his LAN, so probably inconsequential
<cyrozap> Light is pretty fast, imo
<azonenberg> Speed of light delay from me to the garage is on the order of 120 ns
<azonenberg> including the cat5 and optical links
<azonenberg> So most of the delay is likely buffering on the switches
<azonenberg> oh, and host-side latency in the linux kernel IP stack
<dalias> yeah
<dalias> i was gonna say
<rqou> wow your switches are fast
<azonenberg> the turnaround time FPGA-side is stupid low since all of the IP/ICMP is offloaded
<dalias> it's probably all kernel shittiness :)
<azonenberg> rqou: high end ciscos
<azonenberg> they're old, but nice
<azonenberg> I get more like 80us round trip times when the network has more load on it
<azonenberg> 40 on a good day
<rqou> i'm getting around 300 us pinging the management ip of a meraki box
<rqou> probably mostly bufferbloat though
<rqou> (no switch)
<azonenberg> Debian desktop -> ~4m cat5 -> cisco 2970G -> 30m multimode -> cisco 2970G -> ~2m cat5 -> atlys board
<azonenberg> the same switch in the garage has an AC701 attached via 1m of multimode
<azonenberg> i forget if i hooked up the baseT PHY on the atlys or if i only wired up the SFP
<azonenberg> on the ac701*
<rqou> i wonder what the round trip time is for FPGA <-> fiber <-> another FPGA
<azonenberg> Probably low, but i don't have two fpga-based boards with fiber
<azonenberg> even with baseT (so some DSP and conversion logic) its probably in the <1us range
<azonenberg> --- congress ping statistics ---
<azonenberg> rtt min/avg/max/mdev = 0.082/0.120/0.278/0.015 ms, ipg/ewma 0.134/0.122 ms
<azonenberg> 20000 packets transmitted, 20000 received, 0% packet loss, time 2681ms
<azonenberg> This is from my desktop to my file server in the garage over the same two switches
<azonenberg> while IRcing, streaming youtube, and some other light load
<rqou> 0% packet loss
<rqou> not happening in this apartment :P
<azonenberg> Lol
<azonenberg> I may not be using the latest and greatest
<azonenberg> the switches are probably EOL now
<azonenberg> but i'd prefer an old cisco to a modern linksys POS
<rqou> we've got a whole bunch of cat 5? that has been variously stepped on, overbent, taped to the wall, etc.
<cyrozap> azonenberg: Do you have an estimated cost for that device (Ethernet->JTAG)?
<azonenberg> cyrozap: I can fit a 2-port core, including the TCP offload engine, in an xc6slx45 iirc
<azonenberg> i havent tried more but i was planning on using a 7a100t so i'd have room to grow
<azonenberg> for an 8-port unit
m_w has quit [Quit: leaving]
<azonenberg> a single port could prob fit in a 7a50t or even a 35t
<azonenberg> I havent finished optimizing it (or implementing some features like pipelined scanning) either
<dalias> my wifi latency is ~460us round trip it seems
<dalias> odd because ping reports a much higher value
<azonenberg> thats not bad for wifi, but its hard to beat fiber or even copper LAN
<dalias> ~1.2
<azonenberg> and if you ping the AP itself you may be bottlenecking on the slow CPU
<azonenberg> a lot of wifi APs have a slow CPU then an ASIC switching packets
<rqou> i hate consumer APs
<dalias> the AP is hostapd on a real machine
<azonenberg> rqou: i hate consumer switches too
<azonenberg> and routers
<azonenberg> which is why my border router is an i3 running debian :p
<azonenberg> my parents border router is an ancient cisco 1U with an ADSL modem card
<dalias> latency would probably be lower if i used the pci intel card
<azonenberg> (I have a cable company CPE upstream of my router but it's just bridging)
<azonenberg> rqou: i cant wait till i can replace these ciscos, though
<rqou> before my housemate put in the meraki setup, I was using a celeron q1900 as the wifi AP
<dalias> but i use usb because i don't like antennas on local bus
<cyrozap> rqou: OpenWrt/Lede makes consumer routers tolerable.
<rqou> i used to do that
<rqou> then decided to just switch to x86
<azonenberg> they're nice switches but old, the fans are noisy, use quite a bit of power
<azonenberg> non-free OS
<azonenberg> EOLed so no security updates
<rqou> wait, which ISP allows you to use your own ADSL modem?
<azonenberg> and only four 1g SFP and 24 1g copper interfaces
<azonenberg> rqou: almost all of them
<rqou> not AT&T
<azonenberg> its just PPPoE, they cant tell
<azonenberg> you auth with a username and password
<azonenberg> (this is verizon at my parents place)
<rqou> AT&T requires their shitty 2wire box
<azonenberg> wuuut?
<rqou> or maybe that's VDSL
<azonenberg> i dont even think they can tell
<dalias> pretty sure you can swap something else
<dalias> but they can tell
<azonenberg> i'm using a WIC-1ADSL in a cisco
<cyrozap> rqou: U-Verse is VDSL2
<dalias> they can do all sorts of diagnostics on the adsl box
<azonenberg> its like 864 x 160 Kbps
<rqou> yeah, U-Verse requires the shitty 2wire box
<cyrozap> rqou: And IIRC, they do cert-based auth using it
<azonenberg> because they're so far from the DSLAM
<cyrozap> (I think)
<rqou> i managed to but it into "bridge mode"
<azonenberg> the cheap phone company one would go down every time there was a thunderstorm within 20+ miles
<azonenberg> this thing is rock solid
<azonenberg> rqou: anyway, my plan longer term is to build a 1U switch
<rqou> why hasn't someone just disassembled the uverse box, found an obligatory exploit, and figure out how to pull the cert out?
<dalias> :-)
<azonenberg> probably 16x 1g copper, 8x 1g SFP, 2x 10g SFP+
<cyrozap> rqou: Because AT&T owns it
<rqou> find one on ebay or something :P
<rqou> the standard way to get hardware you aren't "supposed" to have
<dalias> :-)
<azonenberg> i have the PHY/MAC logic done, the MAC table done
<azonenberg> still have to do the forwarding path
<azonenberg> its on hold waiting for me to finish the PCB
<azonenberg> which got kinda derailed over the summer with work
<azonenberg> First PCB will be 9x 1g backplane, 3x 1g SFP, 1x 10g SFP+ for my fpga cluster
<azonenberg> but i plan to run the same ip core on a 1U form factor in another board
<rqou> 13 ports?
<rqou> not a broadcom-esque 12/24/48? :P
<azonenberg> rqou: Specific requirements
<azonenberg> a 4HP x 3U eurocard cannot have more than four optics on the front panel, mechanically
<azonenberg> The backplane is a 10-slot system
<rqou> also, it's not so full of sfps that you need a fan just for the optics :P
<azonenberg> eight compute nodes, one management card, one switch card
<azonenberg> two of those plus a PSU in a 21-card 3Ux160mm eurocard rack
<azonenberg> So i need one 1000base-KX lane to each of the nine other cards
<azonenberg> a 10g uplink
<azonenberg> XAUI uses four GTPs, the 1g links use one GTP each so that's 13
<azonenberg> the xc7a200t-ffg1156 has 16
<azonenberg> and i had front panel space for three more SFPs, so...
<azonenberg> http://thanatos.virtual.drawersteak.com/unlisted/switch-108.png is the board as it stood when i stopped working on it
<azonenberg> one of the reasons i stopped is because the XC2C32A and discrete comparators etc in the top right are going to be replaced by a greenpak once i've officially stabilized this toolchain a bit more
<azonenberg> plus i was not in the mood to completely rip up the routing for that QDR-II+ SRAM, but it wasn't possible to get the buses length matched in that space without rotating the ram
<azonenberg> Also, the entire system will be fanless internally
<rqou> are you the one that caused kicad to gain length matching ability? :P
<rqou> or was cern already doing that?
<azonenberg> that was cern, although microvia support in push-and-shove (among other things) was my work
m_w has joined ##openfpga
<azonenberg> anyway the whole 21-card system will be pulling ~500W if i push things to the design limits
<azonenberg> So i plan on having the whole thing sit right on top of a 1U fan tray pushing ~300CFM of airflow
<rqou> heh, broadcom has individual switches that are probably 500W
<azonenberg> I'm budgeting i think 2.5A @ 12V for each of ten blade slots
<rqou> i saw one in the lab when I was interning there that had the cover open for probing the pcb
<azonenberg> so 300W per backplane
<azonenberg> Times two is 600W peak
<rqou> but obviously the fan doesn't work super well like that
<rqou> so someone had placed a random databook on top of the heatsink
<azonenberg> lol
<azonenberg> just as an air dam?
<rqou> yeah
<azonenberg> One of the other reasons i tabled the project, btw
<azonenberg> is that a new vivado version came out
<azonenberg> with support for some of the smaller ultrascale kintexes
<azonenberg> So i wanted to re-evaluate my power design
<azonenberg> and see if i wanted to up the current limits to handle them
<azonenberg> longer down the road, i want to make a backbone switch for my LAN based on one of those
<azonenberg> with sixteen 10g transceivers
<rqou> hope the transceivers don't overheat :P
<azonenberg> The switch would probably have ~14 10g optical interfaces
<rqou> my father had trouble with those way back in the day with the early gen 1g sfps
<azonenberg> then 2x 10g lanes to a second FPGA
<azonenberg> running a lot of 1g optics and maybe some copper ports
<rqou> apparently a number of early sfps exceeded the thermal limits
<azonenberg> lol oh joy
<rqou> of course this was around 10 years ago
<azonenberg> That was the backplane board as of when i tabled it
<azonenberg> i havent done the management card or compute blade yet
<azonenberg> The management card will be running the ethernet-jtag core (this is the primary intended use for it)
<azonenberg> as well as bridging UARTs and other stuff out to sockets
<azonenberg> so you can just telnet to the uart on a compute node
<azonenberg> As you can probably guess, the intention of the whole platform is basically a cloud computing environment for hardware-in-loop SoC prototyping
<rqou> broadcom labs have something like that
<azonenberg> you request an "artix7-large" instance and get handed the hostname of the management card for that backplane and the port range for your board
<rqou> some previous intern wrote a script to keep track of who was using which box
<azonenberg> you get libjtaghal-compatible low level JTAG
<azonenberg> a uart
<azonenberg> switching and metering of the 12V power rail
<azonenberg> access to i2c temp/voltage/current sensors on the compute node
<rqou> broadcom did it with a digi terminal server though
<azonenberg> a dedicated 1gbit ethernet pipe all the way from the compute node to the backbone switch
<azonenberg> a high speed ring bus between compute nodes on the same backplane for ganged computations (one GTP left and one right)
<azonenberg> And the plan is for everything to be automatically scheduled and prioritized
<azonenberg> If you request an interactive development run, you break in as soon as the first job running on one of those boards terminates
<azonenberg> if you request a nightly build, you get last priority
<azonenberg> other CI testing is in between
<azonenberg> different developers are automatically managed, as long as you only connect to the board the server told you to use you can't step on anybody else
<azonenberg> (I'm not planning to implement any security in that regard for now, this is meant for a collaborative lab rather than a hostile public cloud environment)
<azonenberg> whitequark: did you see the email from silego btw?
<azonenberg> i'm gonna ask him for some 46621 samples, and maybe a second dev board for CI purposes
<rqou> is the spi peripheral on greenpak really not dynamically configurable between serial->parallel and parallel->serial?
<azonenberg> Datasheet seems to imply that's the case
<azonenberg> i think it's one set of FFs
<azonenberg> basically meant for use as either an IO expander or ADC readout
<azonenberg> it may be able to read the ADC while writing to fabric, not sure
<azonenberg> greenpak5's i2c is far superior in this regard
<azonenberg> i intend to add pak5 support maybe a year out or so
<rqou> greenpak in general seems to be quite lacking in state bits
<azonenberg> once i have pak4 fully supported
<azonenberg> The primary intended use case is PMICs and such
<azonenberg> and light glue logic
<azonenberg> its not meant to be an FPGA
<azonenberg> althoguh i could see it replacing an attiny or pic10 in some applications
<rqou> is it possible to read the value of a counter directly? datasheet seems to imply no
<azonenberg> That's correct
<azonenberg> you can feed the parallel value from one or two counters to the DAC
<azonenberg> and i think the spi?
<azonenberg> other than that, only the overflow reg
<diamondman> cyrozap: you still around? I watched a movie :)
<cyrozap> diamondman: Yup. Currently watching your REcon talk.
<azonenberg> whitequark: also when i get the 46621 samples, i'm going to add support to gp4prog for a second voltage
<azonenberg> as vccio
<diamondman> cyrozap: Cool. I sounded super nervous through it... next one I give will be calmer.
<azonenberg> i think its just a siggen on pin... 12? or wherever vccio2 is
<rqou> dalias was suggesting using a greenpak to configure an fpga from a bitstream file on an sd card
<rqou> it seems it might just be possible, but will require some magic
<azonenberg> rqou: that sounds like it's pushing the limit
<azonenberg> if you dd'd it directly to the card, possibly doable, possibly
<azonenberg> i would be inclined to use a coolrunner instead
<rqou> a file seems probably not doable, but a series of sectors maybe
<diamondman> azonenberg: Take it to the limit (music)
<azonenberg> much more state bits
<azonenberg> and higher clock rate capability
<rqou> i personally would have used a microcontroller
<azonenberg> or one of the new pic32mm's
<azonenberg> that might be the better option
<azonenberg> 4x4mm 20-QFN
<azonenberg> 32-bit MIPS @ 25 MHz
<azonenberg> 4 kB RAM, 16 kB flash
<azonenberg> and $1ish
<rqou> you don't like ARM?
<azonenberg> i've always had a soft spot for MIPS
<diamondman> cyrozap: I have not been able to do direct tests with open OCD since all the ways I see on how to program it are just SVF replays and I have not done much with that part yet. However, I can disable the optimizer of my code which will produce a similar command sequence to how openocd would program a chip if it knew how. All my tests are on XC2C256 chips for now, but I can get some metrics on them. I
<diamondman> am expecting some spartan 3 and 6 support within a week, and then I can do more hardcore benchmarking against digilent Adept's software and Xilinx's iMPACT tool.
<rqou> impact is such an annoying tool
<rqou> is it still not possible to easily extend with with more adapter support?
<diamondman> rqou: It really is. So bad in fact, It sparked a pashion in e to build better tools that has been burning for about 3 years now....
<diamondman> rqou: impact? Add additional adapters? Very unlikely that is even supported.
<diamondman> And if it is, the api is likely undocumented
<rqou> it's been done ~twice by reverse engineering the tcp interface
<azonenberg> they license it to a few folks like digilent
<azonenberg> and yes, the tcp interface is the way to go if you want to do it yourself
<cyrozap> diamondman: OpenOCD can also directly program devices using *.bit files, not just SVF. Also, while I acknowledge that OpenOCD has a significant amount of technical debt, we are making progress on it.
<azonenberg> just clone xvcd
<azonenberg> i considered doing that using libjtaghal
<azonenberg> but realized that my own tools were far more effective
<rqou> does impact still need jungo drivers (at least on windows)?
<diamondman> rqou: Yes
<rqou> on linux?
<diamondman> rqou: but impact is technically deprecated despite being needed for some devices
<rqou> what's the replacement? whatever is in vivado?
<diamondman> linux.... they support libusb drivers since like version 12
<diamondman> but they are not super great
<diamondman> yeah vivado, which is like all in one java blob
<rqou> i recall a long time ago someone got so tired of impact's drivers on linux that he used ld_preload to force it to use libusb
<rqou> along with some reverse engineering of course
<azonenberg> there is an official libusb driver now i think
<azonenberg> its sucky
<azonenberg> the device often stops functioning
<azonenberg> so badly that you have to reboot the host OS to make it work
<rqou> why is this so hard?
<azonenberg> reloading the driver, impact, or unplugging the device doesnt work
<diamondman> rqou: That was me
<diamondman> my recon talks about me using LD_PRELOAD to get it working
<diamondman> and even then it worked 1/5 times or so because of internal race conditions
<rqou> oh you did that
<diamondman> the reason it had to be preloaded in the first place is they manually inserted the file path to the libusb so
<diamondman> but that path was the centos version from like cent5
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou> no, there was a prior hack that emulated the jungo driver interface using libusb
<diamondman> modern systems canged those links to be ldlinks which are like shortcut files for the linker
<rqou> is this yours?
<diamondman> but they were manually opening the path with dllload or something and that failed because ofc it did
<diamondman> the ldpreload sometimes fixd it but you had to keep restarting it until it worked
<azonenberg> diamondman: lol
<diamondman> rqou: No I did not make this. But I was complaining on some similar channels to this about 3-4 years ago about it
<azonenberg> i never figured out why it wasnt working reliably for me
<azonenberg> but i know that sometimes it would just stop responding
<azonenberg> the led went out
<azonenberg> and it just didnt work
<rqou> btw lattice diamond currently also has fun bugs with usb
<azonenberg> and this was with the unmodified stock xilinx tools
<diamondman> rqou: So it seems I was hasty in assuming I was the only one who did that XP
<diamondman> azonenberg: yes.
<rqou> if you install lattice diamond in a container that doesn't properly hide /sys/bus/usb it will hang forever
<rqou> and it seems to have a statically linked libusb too
<diamondman> azonenberg: I tried installing the proprietary kernal drivers once... and ended up reinstalling that system (I was a noob so I could have probably recovered)
<rqou> basically if /sys/bus/usb has stuff but /dev/bus/usb doesn't have stuff lattice diamond hangs
<azonenberg> diamondman: this isnt the kernel drivers
<azonenberg> this is the modern ise libusb driver
<diamondman> cyrozap: I like what openocd has acomplished. It handles the stated task of providing a debugging interface beautifully (besides the CLI). I actually originally started my work here to produce something that could completely replace openOCD's coontroller interface layer. That way all the chip drivers you guys have can just work.
<diamondman> azonenberg: I know. I was just commenting on the time I tried that :)
<diamondman> azonenberg: then the libusb option becamse available (or I became aware of it) and I took the ld_preload path
<rqou> imagine how much more insane windows would be if it had ld_preload
<rqou> :P
<diamondman> rqou: Well, you can still inject dlls with native win32 api calls
<rqou> now imagine if there was an official way to do it
<rqou> yeah, I know you can CreateRemoteThread inject a dll
<diamondman> Pretty common behavior to get certain behavior with oem utilities that aim to have some custom mark all over your computer
<diamondman> rqou: So do you just mean... an easier way to do it?
<rqou> yeah, i meant an easier way to do it
<rqou> although tbh windows did have a "hijack this exe with a totally different exe" feature
<rqou> but it was removed in iirc vista
<rqou> even process explorer (now a microsoft tool) used it
<diamondman> meta processes (spooky noise)
<rqou> not a meta process
<rqou> much more ugly than that
<rqou> there was a way to register "when this program launches, actually launch it using this other program as a debugger"
<rqou> where the other program could be anything
<rqou> so process explorer hooked task manager with it
<rqou> and viruses obviously hooked everything with it
<diamondman> cyrozap: yeah that sounds like a playground lol
<diamondman> I do not remember that feature
<diamondman> woah, that thing about a playground was not aimed at cyrozap
<rqou> it's called "image file execution options"
<rqou> and apparently it still exists
<rqou> but now the debugger can't be anything; it has to be on the systemwide PATH
<diamondman> rqou: That helps a bit...
<azonenberg> Welp
<azonenberg> Back to coding
<azonenberg> Gonna try and clean up some of the logic for shared functionality
amclain has quit [Quit: Leaving]
m_w has quit [Quit: leaving]
carl0s has joined ##openfpga
<whitequark> azonenberg: yep just read the mail
<azonenberg> I think as soon as those samples come in
<azonenberg> i'll implement minimal 46140 support
<azonenberg> as well as full (well, to the extent that we support the feature in question on the 46620) support for the 46621
<azonenberg> that's basically just a 46620 minus one IOB
<azonenberg> so 99.9% of the code is the same
<azonenberg> just have to change Greenpak4Device::CreateDevice() as well as add a second case anywhere we check the device ID
<azonenberg> Basic 46140 support (not using any of the shared resources, just the single-use-only LUTs and IOBs) should be pretty quick
<azonenberg> Some of the shared resources will need more work
<azonenberg> for example, there is only one shreg vs two, but it has 3 taps
<cr1901_modern> 46140 is a cute device
<azonenberg> the ADC, DAC, DCMP/PWM, SPI are not implemented on either device yet
<azonenberg> the oscillator etc should port pretty painlessly
<azonenberg> I want to buckle down and get at least basic functionality for the entire GP4 family by end of year
<azonenberg> whitequark: can you help me out with full support on the gp4prog side? adding support for trimming etc on the 46621 and 46140 as needed
<azonenberg> I can send you some of my 46621 samples
<azonenberg> or give them to you when you're in town
<azonenberg> We can fine tune the PAR and hard IP extraction capabilities down the road, but in the short term I want to get basic digital support for the entire gp4 family
<azonenberg> then next priority is getting 100% support for every function with manual primitive instantiation
<whitequark> azonenberg: yep sure
<azonenberg> whitequark: also highish priority since i have samples inbound
<azonenberg> can you add support to gp4prog for a second vdd?
<azonenberg> so you can control vcco for the 46621
<whitequark> I have a flight today/tomorrow
<azonenberg> I believe there is also a requirement that vdd2 be lower than core vdd as well
<azonenberg> And i dont mean like right now
<azonenberg> but, next time you get a chance to work on the project
<whitequark> but if you file an issue and then assign it to me i'll do it
<azonenberg> that should be your focus
<azonenberg> Ok
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
LoveMHz has joined ##openfpga
talsit has joined ##openfpga
<azonenberg> sooo apparently something we did in the past broke the pre-divider on the ring oscillator
* azonenberg investigates
<azonenberg> oh, lol
<azonenberg> now this is interesting
<azonenberg> I guess we have another thing to add to the linter, lol
<azonenberg> apparently yosys won't catch setting a parameter the module in question doesn't have
<azonenberg> i changed PRE_DIV to HARDIP_DIV
<azonenberg> never changed it in the test case
<azonenberg> and yosys happily synthesizes it :p
<azonenberg> i only caught it when i re-ran the Blinky test on the dev board in front of me
<azonenberg> and one of the leds wasnt acting right
<azonenberg> aaand this is why we need HiL testing
<whitequark> yes, this is quite annoying about yosys
<whitequark> maybe we should request that from clifford?
<azonenberg> his policy right now seems to be to not add error checking :P
<azonenberg> if we write a checker he will probably merge it
<azonenberg> Soo i am trying to figure out why one of my test cases is generating an empty bitstream...
<azonenberg> Anyway, i think we should finish making the taxonomy
<azonenberg> of bugs
<azonenberg> Then discuss which ones are best done in yosys and which in a standalone tool
<azonenberg> for those best done standalone, figure out if any existing tool will do it
<whitequark> azonenberg: btw
<whitequark> did you know there is a possibility to stream github issue events to irc?
<whitequark> hilariously it's undocumented and not exposed in the GUI
<whitequark> but it's there
<azonenberg> lol
<rqou> wtf
<azonenberg> i might try it soon then
<rqou> it's architecturally sensible, but
<rqou> why not just expose it?
<whitequark> no idea
<whitequark> maybe they just/... forgot
<openfpga-github> [openfpga] azonenberg pushed 6 new commits to master: https://git.io/vPFKO
<openfpga-github> openfpga/master a466fb9 Andrew Zonenberg: greenpak4: Implemented Greenpak4PairedEntity. Fixes #25.
<openfpga-github> openfpga/master dfd3710 Andrew Zonenberg: tests: fixed typo'd parameter name
<openfpga-github> openfpga/master 3c94fab Andrew Zonenberg: greenpak4: Initial version of Greenpak4PairedEntity
<whitequark> wow neat
<azonenberg> whitequark: that was the main core feature we needed to support the 46140
<azonenberg> the PAR algorithm may need some tweaking to efficiently handle placement where resources can conflict
<azonenberg> but it should at the very least be functional with poor QoR
<azonenberg> I think at this point i am going to table new features on the 46620 for a few days
<azonenberg> grab my 46140 zif socket from the garage tomorrow
<azonenberg> and try to get at least a basic blinky working there
<azonenberg> i'm not gonna worry about adding all of the fancy stuff yet
<azonenberg> just IOBs, dedicated (non-oversubscribed) LUTs and FFs, and oscillators to start
<whitequark> hrm
<azonenberg> then prob the comparators and vrefs
<whitequark> does the DAC accept input from a counter yet?
<azonenberg> No, that requires implementing the DCMP block
<whitequark> ok
<azonenberg> And that is going to be ugly
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from ebe64fa to 58e3635: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 58e3635 Travis CI User: Update documentation
<azonenberg> tl;dr there's lots of shared input muxing
<azonenberg> i need to sit down and spend some uninterrupted time working on it
<whitequark> this is the full set of hooks you can set
<whitequark> for gh irc
<azonenberg> that, the SPI, and some clocking on the counters are all on hold pending the same core issue
<travis-ci> azonenberg/openfpga#134 (master - f73fe46 : Andrew Zonenberg): The build passed.
<azonenberg> basically, i have to figure out how best to handle shared signals like clocks etc
<azonenberg> for example, if you want to clock a counter from a fabric signal (vs an osc)
<azonenberg> you can do it
<azonenberg> But that uses the one "fabric counter clock" net on one half of the device
<azonenberg> So if you use two different fabric clocks in counters, they have to be in opposite halves of the device
<azonenberg> oh, and i have to do all of this in such a way that it won't break the 46140 since that's a single-matrix device
<azonenberg> the DAC/DCMP have the same core issue
<azonenberg> it's solvable, but i have to figure out the best way
<azonenberg> Decidedly nontrivial
<whitequark> oh
<whitequark> okay
<azonenberg> and at this point, essentially all of the remaining hard IP depends on this in one way or another
<azonenberg> the SPI for example blows away all of the clock and DCMP outputs in one matrix when enabled
<azonenberg> and i have no way to explain that to the router yet
<azonenberg> There's a few little things i can do, like enabling the fractional Vdd and off-chip inputs to the comparator Vref blocks
<azonenberg> and implementing the latch mode on the DFFs
<whitequark> yeah but for 46620 to become useful for me i need either DAC or ADC...
<azonenberg> Yeah, i know
<whitequark> i have the boards even already
<azonenberg> if you want to code it up yourself, feel free :)
<whitequark> sadly i have like two jobs
<azonenberg> That's why i figured it might be a good idea to table the 46620 for a short time and bring the 46140 and 46621 to the same level of maturity i'm at
<whitequark> well, you have at least a month while i'm away
<azonenberg> as that way i can say "we support the entire greenpak4 family"
<whitequark> *nod*
<azonenberg> it's way better in my book to have basic digital logic functional on the entire product line
<azonenberg> as well as device flashing etc
<azonenberg> than to have slightly better support but only for one device
<whitequark> i think flashing should already work
<rqou> did you obtain/reverse engineer the programming sequence?
<whitequark> long ago
<rqou> iirc there's a Vpp involved?
<whitequark> the board does that all by itself
<azonenberg> rqou: We have the programming spec for the 46620 from silego
<whitequark> azonenberg: I didn't even use that at all
<azonenberg> in addition, we RE'd the USB commands for the official devkit
<whitequark> it's unnecessary if you use the UDB
<azonenberg> Yeah
<whitequark> there's actually some things missing
<whitequark> ADC trimming precisely
<azonenberg> whitequark: and, i know for a fact that socket testing and osc cal
<azonenberg> and that
<whitequark> because... no ADC
<whitequark> azonenberg: I reimplemented the socket testing and osc cal bitstreams in yosys
<whitequark> and included those in gp4prog
<azonenberg> yes but socket testing and osc cal is not implemented for anything but the 46620 right now
<whitequark> oh
<whitequark> yeah
<azonenberg> as we can't compile for anything else
<whitequark> that's about ten minutes work
<azonenberg> Ten minutes work once we get device support for GPIOs
<azonenberg> and the osc
<whitequark> yeah
<azonenberg> Which is why that's my first target on the 46140
<azonenberg> so i can then program the device and do hardware verification
<azonenberg> Anyway, might be a week or so but it's moving along
<azonenberg> Also, i am tentatively being moved to a different project at work next month
<azonenberg> So I may not be in your area after all
<whitequark> just put the chips in a sealed bag, in a letter and mail them ;p
<azonenberg> lol
<whitequark> no one's gonna lose or steal my mail in HK
<azonenberg> oh you mean the 46621 samples?
<whitequark> yeah
<whitequark> or more lke 140
<azonenberg> they're not valuable enough for me to be super concerned
<azonenberg> You should have got 46140s in the UDB
<whitequark> well it'd be silly if they got lost
<whitequark> oh
<whitequark> oh right
<azonenberg> I requested 46621s from silego
<azonenberg> those fit the same zif as the 46620
<azonenberg> just need another power rail
<azonenberg> So i can send you some of THOSE when they come in
<azonenberg> But i wont include 140s unless you never got any
<whitequark> I did
<azonenberg> (but then you prob never got the stqfn-14 socket either)
<azonenberg> ah ok
<whitequark> I forgot bout those
<whitequark> I actually tested 140 discovery
<whitequark> in gp4prog with them
<azonenberg> yeah, i saw that
<azonenberg> i'll try to bang up 46621 discovery when my samples arrive
<whitequark> how?
<azonenberg> So, the bitstream is essentially the same
<whitequark> by disabling half of the pins and detecting that?
<azonenberg> basically, yes
<whitequark> mhm
<azonenberg> I was thinking of actually using the loopback bitstream
<whitequark> does silego tool detect 21 anyway?
<azonenberg> but modified to make the vdd2 pin as an input
<azonenberg> or something
<azonenberg> basically if i see what looks like a 46620
<azonenberg> push a bitstream to sram and check which voltage level i get back
<azonenberg> i dont know if there's any way to do it w/o disturbing the existing bitstream in ram
<whitequark> what do you mean?
<azonenberg> So here's the idea i have in mind
<azonenberg> Create a bitstream for 46620/21 (same die we think)
<azonenberg> that floats the vdd2 pin
<azonenberg> and drives a pin in the low voltage bank high
<azonenberg> Set vdd=3.3, vdd2 = 1.8
<azonenberg> read that pin
<azonenberg> 0 = fault
<azonenberg> 1.8 = 46621
<azonenberg> 3.3 = 46620
<azonenberg> If you have a better idea i'd love to hear
<rqou> there's no "ID" readback in the programming sequence?
<azonenberg> rqou: lol i wish
<azonenberg> they ID the chips by running a "dump firmware" command on each attempted part
<azonenberg> then looking at whether what comes back is sane
<rqou> greenpak feels like a giant grab bag of random features
<azonenberg> yes, it is
<azonenberg> but it's a) cheap, b) the company is not hostile to f/oss, and c) there is no existing HDL toolchain to get in our way
<azonenberg> Which is a combination i don't expect to find anywhere else soon
<azonenberg> My impression is that the bulk of silego's business is making "ASICs" for OEMs
<whitequark> they make real ASICs too
<rqou> the 22V10 doesn't count? :P
<whitequark> I think they kept doing that and then they made GP1 at some point
<azonenberg> and it was cheaper to make a PLD with all of the features they needed, and program it to the client's requirements
<azonenberg> then to keep spinning new asics
<azonenberg> And they happen to sell the chips on the side to small run users too
<azonenberg> but its not the point
<rqou> btw I love the gigantic "All Devices Discontinued!" label on the lattice 22V10 datasheet
<azonenberg> lol
<azonenberg> and well, it doesnt count b/c its obsolete :p
<azonenberg> i am talking about a modern part you can buy now, in a smallish SMT package
<azonenberg> aaanyway its 1am again
<azonenberg> i was supposed to be getting to sleep early for once
<rqou> i probably should too so that I can get back to being awake during daylight :P
Bike has quit [Quit: leaving]
talsit has left ##openfpga [##openfpga]
carl0s has quit [Quit: Leaving]
DocScrutinizer05 has quit [Read error: Connection reset by peer]
DocScrutinizer05 has joined ##openfpga
_whitelogger has joined ##openfpga
<openfpga-github> [openfpga] whitequark pushed 1 new commit to master: https://git.io/vPF91
<openfpga-github> openfpga/master 19d6478 whitequark: gp4prog: add provisional support for SLG46621V....
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 58e3635 to 1b30649: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 1b30649 Travis CI User: Update documentation
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ylm has joined ##openfpga
<azonenberg> lol
<azonenberg> So two days ago
<azonenberg> Silego finally removed the "preliminary" marking from the slg46620 datasheet
<azonenberg> (in rev 100)
<azonenberg> digshadow: btw did you get the chips i sent you?
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPFxk
<openfpga-github> openfpga/master ec17d94 Andrew Zonenberg: greenpak4: Code cleanup in preparation for multiple device support
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 1b30649 to 75f2d56: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 75f2d56 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#136 (master - ec17d94 : Andrew Zonenberg): The build passed.
doomlord has joined ##openfpga
<digshadow> azonenberg: last night when I checked mail I didn't see them
<digshadow> did you check the tracking?
digshadow has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
Bike has joined ##openfpga
ylm has quit [Ping timeout: 250 seconds]
<azonenberg> Delivered on the 20th
<azonenberg> One of your roomies grab it maybe?
carl0s has joined ##openfpga
<digshadow> azonenberg: found it
<azonenberg> digshadow: :)
<azonenberg> When do you think you'll get to imaging the 46620?
<azonenberg> top metal on that is my #1 priority of the stuff i sent
<azonenberg> already decapped
<digshadow> azonenberg: what would help
<digshadow> is to get a priority list of what you want done
<digshadow> and a justification for it
<digshadow> i'll be doing some decap stuff in a few hours
<digshadow> so asap would be preferred
<digshadow> for anything you actually care about
<azonenberg> digshadow: see PM
<digshadow> got it
<rqou> do you happen to have a decap of the NES MMC5?
<rqou> I'm curious about how apparently nobody ever really figured out its scanline counter
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
carl0s has quit [Quit: Leaving]