carl0s has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
m_w has quit [Quit: leaving]
carl0s has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou> before I go and duplicate effort, is there an existing cross-platform (preferably Python) tool for flashing the HX8K breakout dev board (FT2232-based)?
<azonenberg> There are plenty of tools for talking to ft232/2232 based JTAG adapters
<azonenberg> I dont know if any implement the ice programming protocol
<azonenberg> but if you can get a SVF then openocd should workl
<azonenberg> work*
<rqou> most of the ft2232 programmer things need some "fiddly config bits" for the "extra pins" like reset, etc.
<rqou> i specifically don't want to depend on something like openocd
<rqou> I guess I'll just write yet another one
<rqou> blargh, there isn't even a unified interface to talk to libftdi on linux and ftd2xx on windows
<rqou> why is programming hard? :P
<azonenberg> Lol
<azonenberg> I would suggest using libftd2xx on all platforms
<rqou> but then you have to screw around with windows drivers
<azonenberg> You can use it natively on linux too
<azonenberg> It's more reliable than the open source drivers in my experience
<azonenberg> there are still bugs but i think they are silicon bugs
<rqou> why is something like libftdi so complicated anyways? it basically just "moves data around" and does some framing stuff
<azonenberg> Because the silicon is a pain in the butt
<azonenberg> look at the die photos on siliconpr0n
<azonenberg> the ft232h is die rev A13
<azonenberg> it took them thirteen respins to get the chip working
<azonenberg> and they probably just gave up on fixing the remaining bugs :p
<cyrozap> rqou: Uh, does iceprog not work?
<rqou> maybe it does?
<rqou> I haven't tried it yet
<rqou> does it work on windows?
<cyrozap> It's Python, so maybe?
<cyrozap> Oh, wait, iceprog is C
<rqou> yeah, and it seems to need libftdi
<rqou> so windows is :(
<cyrozap> Uh, libftdi supports Windows
<cyrozap> It uses libusb
<rqou> yes, it does "support" windows, but like you said it needs libusb
<rqou> not the native ftdi driver
<cyrozap> Correct
<rqou> that's annoying
<rqou> also, can you bind one interface of the ft2232 to libusb and the other interface to the native driver?
<cyrozap> No, you have to use either one or the other. What's wrong with libusb?
<rqou> a) you need to install it manually (rather than via windows update) and b) you lose the ability to use the second half of the ft2232 for uart mode
<cyrozap> Ah, I see.
<rqou> in general, windows seems to really like to make usb hard
<rqou> cyrozap: iceprog works
<rqou> and I don't really care sufficiently to bother with windows right at this moment :P
amclain has quit [Quit: Leaving]
cosmobird has joined ##openfpga
doomlord has joined ##openfpga
<azonenberg> fwiw libftd2xx *does* allow you to access each half of the device with one in MPSSE and one in UART mode
<azonenberg> But, you have to access the uart via the API and not the kernel uart driver
<azonenberg> You could probably write a service that hosts the device and exposes a telnet console on a socket
<rqou> I don't feel like shaving yaks today :P
<azonenberg> But there are a lot of very hairy yaks in your front yard...
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…]
Bike has quit [Quit: elemen]
doomlord has joined ##openfpga
<rqou> yosys build failure on my machine: http://paste.debian.net/hidden/0e967c69/
<rqou> problem with my setup or problem with yosys?
<cr1901_modern> "(3:07:19 AM) azonenberg: But, you have to access the uart via the API and not the kernel uart driver" Is this Linux-specific? On Windows, I can use one port with libusb and keep the other as a VCP just fine
<cr1901_modern> azonenberg: Did you see my link: https://gist.github.com/cr1901/43d38516c9b9ea2c819d24f10bea0cdc
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
digshadow has quit [Ping timeout: 244 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Bike has joined ##openfpga
amclain has joined ##openfpga
digshadow has joined ##openfpga
m_w has joined ##openfpga
doomlord has joined ##openfpga
dalias has joined ##openfpga
<dalias> tangentially related topic:
<dalias> is there any research on feasibility of diy single-unit chip fab?
<dalias> given the wavelength of blu-ray lasers and the information density of discs, it seems plausible that the tech could be repurposed to do something comparable to a 600nm process
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rqou> tl'dr: it's quite possible
<rqou> regarding hacking blu-ray drives (unfortunately probably abandoned): https://github.com/scanlime/coastermelt
<dalias> it seems a blu-ray writer would already have all the right precision controls for the laser at a reasonable resolution
<rqou> depends on what you mean by "reasonable"
<rqou> normally blu-ray writers follow a track pattern that is already embedded on the blank disk
<rqou> they're usually not precise enough to generate this track by itself
<dalias> right
<dalias> but if you could provide a pattern for them to follow while burning onto the mask on silicon...
<rqou> it's probably feasible
doomlord has joined ##openfpga
<rqou> hmm, yosys is failing to build on debian sid using clang because of possibly a clang bug: https://llvm.org/bugs/show_bug.cgi?id=24770
<rqou> it builds fine using gcc
<rqou> debian sid's clang is pretty old though for some reason: Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
<dalias> uhg clang that old is unusably broken
<dalias> i wouldn't try to use earlier than 3.8
<rqou> why does clang change so rapidly that debian's version is "unusable"?
<cr1901_modern> dalias: Prob not to fab a j-core :P. The cheapest I've heard of it being done is through MOSIS
<dalias> cr1901_modern, what specifically were you answering?
<dalias> (whether there's research? whether it's practical? or something else)
<cr1901_modern> dalias: Whether it's practical
<dalias> i'm talking about an individual-unit approach to production
<cr1901_modern> dalias: No chance in hell for doing something complicated like a CPU core, AFAIK. azonenberg has a long-term project to make a fab at home, but even then he only expects to do simple TTL logic.
<cr1901_modern> azonenberg: Feel free to correct me if I'm wrong :P ^
<dalias> because you expect too high error rate?
<rqou> i know that in my semiconductor fabrication course, we basically didn't expect anything with more than a few transistors to work
<rqou> this was because the gate threshold voltages weren't consistent enough
<cr1901_modern> When I was in uni, microfab was taught one year; we don't have a lab or professor dedicated to it
<rqou> we have a dedicated teaching cleanroom
<rqou> apparently it cost "only" around ~$1 million :P
<rqou> on top of the teaching cleanroom we also have a "real" cleanroom donated by Marvell
cosmobird has quit [Remote host closed the connection]
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
carl0s has joined ##openfpga