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 :-)
<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>
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
<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
<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.