00:19 <rqou> offtopic: what's the "big deal" with this BeagleWire board? why's it being hyped everywhere?

00:25 <awygle> because the beaglebone people have money?

00:27 <awygle> it is cool that it + beaglebone is a "complete open source solution" (you know, to first order, if you ignore the chips)

00:27 <rqou> erm, so is just plugging an icestick into the usb port? :P

00:28 <awygle> i don't think an icestick is OSHW

00:56 <mithro> digshadow: https://github.com/timvideos/conda-hdmi2usb-packages/tree/master/openocd

00:56 <rqou> eww openocd

00:57 <digshadow> mithro: I was wondering more if there was a memory you could read

00:57 <digshadow> to identify if its basys3, etc

01:01 <kc8apf> digshadow: I don't know anything on basys3 that would tell you electronically. USB ID on programming interface is shared with a bunch of boards. JTAG ID is tied to FPGA. No other JTAG devices on chain.

01:30 <digshadow> kc8apf: tim and I just played with it briefly. He found the adept gui shows the board (in a youtube video)

01:30 <digshadow> we weren't able to get it to detect on my system, but I may have too old of a version installed

01:30 <digshadow> the ftdi has a memory attached including things like device serial number

01:32 <mithro> Dunno how it does it

01:32 <mithro> https://www.irccloud.com/pastebin/4w42LJkY/

01:32 <mithro> But it can definitely tell the difference between the arty and Basys somehow...

01:35 <mithro> https://www.irccloud.com/pastebin/jbzZSzFq/

02:17 <kmehall> rqou: one unique feature of the beaglewire is that the ice40 is connected the GPMC bus on the beaglebone

02:17 <rqou> ah, ok

02:17 <kmehall> so you can make memory-mapped peripherals in the FPGA, probably with better bandwidth/latency than USB or icoboard's bitbang thing

03:24 <mithro> kmehall: It's the only ice40 device I've seen with sdram rather than sram too

07:54 <ZipCPU|Laptop> digshadow: Use the ftdi tool and dump the ftdi's EEPROM. It will have the word "Basys3" within it.

08:00 <digshadow> ZipCPU_: got it thanks

08:11 <kc8apf> digshadow: if it's in that eeprom, I wonder if they pack it into a usb descriptor. lsusb with enough -v's might cause it to show

08:13 <azonenberg> kc8apf, digshadow: if you have an up-to-date usb.ids you should see the digilent vid/pid show up as something like "digilent integrated jtag" or something

08:14 <azonenberg> or wait, this is the ftdi

08:14 <azonenberg> not the pic based one

08:15 <kc8apf> Finally tried out ReflowR tonight. Seems to follow the temp profile quite well and is very simple to use. It's also designed in almost exactly the most dangerous ways possible: unfused mains connection, large prominent surface that rapidly reaches 200+C, rough cut aluminum (really needs deburring), remotely controllable over wifi with an unencrypted, unauthenticated API

08:15 <kc8apf> I'm really struggling to think of ways to make a reflow hot plate more dangerous

08:16 <kc8apf> azonenberg: fdti-based ones have a similar description. digshadow is looking for the actual board it is designed into.

08:17 <azonenberg> yeah i know

08:17 <azonenberg> what i mean is, the old ones had no such information that i know of

08:17 <kc8apf> ah

08:17 <azonenberg> i know they had a shared vid/pid for multiple boards b/c i was the one that put it in the usb.ids database :p

08:17 <azonenberg> and i had two boards with the same vid/pid

08:23 <digshadow> azonenberg: the main question was if one could ease setup by auto-detecting the dev board connected to your computer (ie and create a blank project with constraints, the fpga selected, etc). Sounds like its possible and mithro does something similar today for some migen/litex stuff

08:28 <azonenberg> kc8apf: y u no oven?

08:29 <azonenberg> oven is totally the way to go

08:29 <azonenberg> hot plates are useless for 2-side smt and... i cant remember the last time i did a 1-side board

08:36 <cr1901_modern> Still it's enough to do greenpak stuff at least (n.b. I prob wouldn't buy this)

08:38 <azonenberg> yeah but if a $50 unmodified walmart toaster oven will do the trick

08:38 <azonenberg> i dont see the point in using a fancy hot plate

08:38 <azonenberg> if you want good temp control put a controller on an oven

13:21 <qu1j0t3> kc8apf: nice description!

14:05 <tinyfpga> digshadow: some FPGA boards may have unique USB VID:PID values for that specific board. The string you see in the EEPROM is likely in the USB String Descriptor, this would be available with a USB library

14:07 <tinyfpga> digshadow, mithro, kc8apf: the updated TinyFPGA Bootloader includes FPGA type, board name, and SPI Flash memory map in a special location in the SPI flash. The tinyprog script knows how to extract this information. It’s stored as JSON so it’s pretty straightforward. https://github.com/tinyfpga/TinyFPGA-Bootloader/blob/master/README.md

14:08 <tinyfpga> the board could

14:09 <tinyfpga> ...even be configured to store the constraints files and other information needed by the toolchain to build a project

17:46 <kc8apf> tinyfpga: unfortunately, it's not the device description string. That just contains "Digilent USB Device"

17:47 <kc8apf> I'm not seeing Basys3 show up as a string anywhere in lsusb output.

18:18 <kc8apf> libftdi has methods for accessing the EEPROM user area. So, easy-ish to access in a native app. Would need to reimplement for something like WebUSB.

18:48 <daveshah> mithro: I have now submitted https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/308, and the corresponding PR in the arch defs

18:51 <mithro> kc8apf: I think we just need to ltrace the dadutil library to figure out where they are getting the strings from -- I think it's using libusb to read something but it could just be something to do with the serial number

18:51 <mithro> tinyfpga: How goes the bootloader port to other ICs?

18:52 <awygle> whitequark: ping?

18:54 <kc8apf> mithro: fair enough. libftdi builds on libusb so we don't have to completely reinvent the wheel

19:34 <mithro> daveshah: Great work on vpr stuff

19:35 <mithro> daveshah: I would say https://github.com/mithro/vtr-verilog-to-routing/issues/5 and/or https://github.com/mithro/vtr-verilog-to-routing/issues/4 are probably the next most important issues

19:47 <daveshah> mithro: Cheers! Unfortunately next week is looking a bit busy but I'll see what I can do on those issues