05:16 <sf-slack> <kgugala> @mkurc I believe you have a quickfeather board on your desk

07:03 <sf-slack> <mkurc> I do. I'll check the bitstream

07:22 <sf-slack> <mkurc> @olof.kindgren Bad news :( The bitstream seems not to be working. The LED remains off all the time.

07:23 <sf-slack> <kgugala> @olof.kindgren you can use fasm2bels to decompile the bitstream

07:24 <sf-slack> <kgugala> and get structural verilog

07:24 <sf-slack> <olof.kindgren> @mkurc Thanks for checking. It was a shot in the dark. I will do some more detailed analysis once I get a cable

07:24 <sf-slack> <kgugala> you can run simulations with it

07:24 <sf-slack> <kgugala> (this is quite useful in debugging)

07:25 <sf-slack> <kgugala> BTW we have a similar tool fo 7 series FPGAs

07:25 <sf-slack> <olof.kindgren> @kgugala That's handy, but I'm trying too many things at once. First step should really be to see I got correct pin for the LED, reset polarity and that the clock is runnkng

07:27 <sf-slack> <olof.kindgren> Once I have that working it could make sense to do post-p&r simulations if things are still not working

07:27 <sf-slack> <kgugala> mhm

07:27 <sf-slack> <kgugala> also it probably makes sense to add fasm2bels support to edalize

07:27 <sf-slack> <kgugala> :)

07:30 <sf-slack> <olof.kindgren> @kgugala Yes. netlist/gatelevel simulations is one of the reasons I'm looking at building a next-generation Edalize (called Edalize Slight Return for now)

07:30 <sf-slack> <olof.kindgren> https://github.com/olofk/edalize/wiki/Edalize-(Slight-return)

07:31 <sf-slack> <kgugala> Return of the sims

07:31 <sf-slack> <kgugala> ;)

07:31 <sf-slack> <olof.kindgren> Does anyone know a particular brand of these SWD cables that are both supported by OpenOCD and has the right connector?

07:36 <sf-slack> <mkurc> @olof.kindgren Regarding the PB-SDIOMUX error: You are using the binary toolchain provided by QuickLogic right? Can you tell which version? (release). I recall an issue with those SDIOMUX pins and I'd like to double-check if it is not a lingering bug there.

07:37 <sf-slack> <olof.kindgren> Should be 1.2 Will double check

07:37 <sf-slack> <olof.kindgren> Yes. Installed from `Symbiflow_v1.2.0.gz.run`

07:38 <sf-slack> <mkurc> Ok, thx.

07:38 <sf-slack> <olof.kindgren> Related to that, can you verify which pin number I should use in the pcf for the red LED on the quickfeather board?

07:40 <sf-slack> <kgugala> @olof.kindgren regarding the cables - I think we should soon open source Antmicro's adapter - the latest revision supports SWD and can be used with QF (I also tested the current revision with some other boards e.g. OrangeCrab and it works fine)

07:41 <sf-slack> <olof.kindgren> That would be cool. Wouldn't help me in this particular case though since I guess I would still need to build one :)

07:45 <sf-slack> <mkurc> So Quickfeather uses the chip in PU64 package. You may refer to IO pins either by number or by "alias" (eg. IO_20). The RGB led uses IO_22, IO_21 and IO_18.

07:49 <sf-slack> <olof.kindgren> @mkurc Cool. So yesterday I tried `22` which didn't work and then `34`. Do you mean that `IO_22` is an alias for `34`?

07:49 <sf-slack> <mkurc> Yes it is

07:49 <sf-slack> <olof.kindgren> Hey, I just found a video which describes how to use a TinyFPGA (hopefully BX) to program the board. Might try that later

07:49 <sf-slack> <olof.kindgren> @mkurc Cool. Thanks. Then I got the pinout correct at least

07:50 <sf-slack> <mkurc> great :)

07:50 <sf-slack> <olof.kindgren> I hate cables. Why can't we just have everything in the cloud instead?

17:38 <_whitenotifier-f> [fpga-tool-perf] mithro opened issue #249: Add a LUNA USB 3.0 design as test case - https://git.io/JTsZm

20:25 <mithro> kgugala: You should be able to use to the USB bootloader to program the QuickLogic device, right?

20:28 <sf-slack> <kgugala> @mithro yes, you should. The device should come preprogramed with the USB - UART bitstream. This should allow you loading bitstream using firmware running on the CPU

20:28 <sf-slack> <kgugala> I never used this