kraiskil has quit [Read error: Connection reset by peer]
citypw has joined #symbiflow
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #symbiflow
citypw has quit [Ping timeout: 240 seconds]
_whitelogger has joined #symbiflow
OmniMancer has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala__ has joined #symbiflow
kgugala has quit [Ping timeout: 256 seconds]
andrewb1999 has quit [Ping timeout: 260 seconds]
kgugala_ has quit [Ping timeout: 260 seconds]
citypw has joined #symbiflow
<sf-slack>
<olof.kindgren> @kgugala Do you mean that it is supported already now, but not tested, or do you mean that we could theoretically do that if we add support for it in the quickfeather software?
<sf-slack>
<kgugala> @olof.kindgren all the components are in place and I'm pretty sure QL people tested that, I'm saying I haven't
<sf-slack>
<olof.kindgren> oh, really. That would save me a lot of trouble. Who should I talk to about this?
citypw has quit [Remote host closed the connection]
<sf-slack>
<olof.kindgren> @kgugala We talked about changing the default package type in symbiflow for the quicklogic device. I think it's a bad idea to change it to the one on quickfeather. Found a forum post that tells this package is not generally available and was only produced in limited quantities fo rthe quickfeather
<sf-slack>
<olof.kindgren> So outside of quickfeather, the majority of devices will use other packages
kgugala has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala__ has quit [Ping timeout: 256 seconds]
kgugala has quit [Ping timeout: 264 seconds]
<sf-slack>
<kgugala> oh, yeah. They mentioned that the fab they use EOLed the current package
<sf-slack>
<kgugala> you're right - let's stay with the one we have as the default one
epony has quit [Remote host closed the connection]
epony has joined #symbiflow
QDX45 has quit [Remote host closed the connection]
QDX45 has joined #symbiflow
kgugala has joined #symbiflow
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 264 seconds]
<sf-slack>
<tpagarani> @olof.kindgren Yes QuickFeather comes pre-programmed with the bootloader that allows you to flash new image using TinyFPGA progammer. You can follow the instructions at https://github.com/QuickLogic-Corp/qorc-sdk/
<sf-slack>
<olof.kindgren> @tpagarani Fantastic! I'll take a look
OmniMancer has quit [Quit: Leaving.]
andrewb1999 has joined #symbiflow
citypw has quit [Ping timeout: 240 seconds]
andrewb1999 has quit [Ping timeout: 264 seconds]
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 256 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
xtro has joined #symbiflow
xtro has quit [Client Quit]
adjtm has joined #symbiflow
az0re has quit [Quit: Leaving]
<sf-slack>
<olof.kindgren> @tpagarani FYI, the instructions for installing the ARM toolchain via a PPA don't work. At least not on ubuntu 20.04
QDX45 has quit [Remote host closed the connection]
<sf-slack>
<timo.callahan> @olof.kindgren, I went through this just last night. I found the .deb for 18.04. I also had to find a .deb for libisl15 for 18.04. But it now seems to work. If you want to go down this path (you may well not), let me know and I'll try to find the URLs or can even send you the .debs.
<sf-slack>
<timo.callahan> (That is I manually installed the 18.04 debs on my 20.04 laptop)
<sf-slack>
<olof.kindgren> @timo.callahan Getting the tar ball worked fine so I'd suggest just drop the ppa method
<sf-slack>
<olof.kindgren> Maybe it's just me, but I don't like choices :)
<sf-slack>
<timo.callahan> :)
<sf-slack>
<olof.kindgren> Alright. So I just built and programmed one of the qork_sdk examples through the USB bootloader
<sf-slack>
<olof.kindgren> I have also built bit files before with my own designs
<sf-slack>
<olof.kindgren> Now the question is, how do I convert my bitfiles into something flashable in the easiest way? There's quite a bit of infrastructure in these examples, so I'm not sure where to start looking
<sf-slack>
<olof.kindgren> e.g. do I need to compile some boilerplate C to load the FPGA from the CPU?
<sf-slack>
<olof.kindgren> Hmm.. so looking deeper at this it seems the bin is just an objcopy'd elf and the FPGA image is embedded as data in the elf
<sf-slack>
<olof.kindgren> So if I want to do this manually, I'll get symbiflow to output a .h for me, #include that in a small C main, compile and objcopy ?
<sf-slack>
<kgugala> the serial loader can program the CPU part only, but CPU can later program FPGA
<sf-slack>
<kgugala> so the USB2Serial does what you described
<sf-slack>
<kgugala> you basically load a CPU program which later programs the FPGA
<sf-slack>
<olof.kindgren> Is the FPGA image always the same size? Was thinking if I could write a small hack that automatically merges the required C code with the FPGA data so I don't need an ARM toolchain for this
<sf-slack>
<kgugala> yes, the toolchain should be the same size
<sf-slack>
<kgugala> so dding bitstream into the app should work
<sf-slack>
<olof.kindgren> cool
<sf-slack>
<olof.kindgren> Is any header added or removed between the h data and the .bit file?
<sf-slack>
<olof.kindgren> It's even a zephyr app :)
<sf-slack>
<kgugala> so basically it sets a few registers, enables FPGA clocks and writes the bitstream
<sf-slack>
<kgugala> yep you can program FPGA from zephyr
james_lan has joined #symbiflow
<sf-slack>
<olof.kindgren> Hmm.. Right. You might want to set up some more stuff, like clock frequencies and so. In that case you can't just use a single hardcoded elf
<sf-slack>
<olof.kindgren> Ok, so for now I'll do it the intended way. But how do I get symbiflow to give me a h file?
<sf-slack>
<kgugala> you may read the configs from constant offset in the binary
<sf-slack>
<kgugala> and update this along with the bitstrema
<sf-slack>
<olof.kindgren> True
<sf-slack>
<olof.kindgren> I think it could be quite useful for people like me who are primarily interested in the FPGA side and kind of don't want to pretend there's an ARM inside as well :)
<sf-slack>
<kgugala> :)
<sf-slack>
<mgielda> you mean an NVIDIA
<sf-slack>
<mgielda> lets get used to the new naming scheme
<sf-slack>
<olof.kindgren> True. I always called them silicon heaters anyway so I don't have to update my naming scheme :)
<sf-slack>
<mgielda> heaters gonna heat
<sf-slack>
<olof.kindgren> :)
<sf-slack>
<olof.kindgren> ok, I'm far too tired for this, but I'm getting closer now
<sf-slack>
<olof.kindgren> But if I get one of those swd cables I can program the fpga part directly from a bit file, right?
<sf-slack>
<kgugala> yep
<sf-slack>
<olof.kindgren> Sounds like I should get one of those anyway.
<sf-slack>
<kgugala> it will also give you debug access to the CPU
<sf-slack>
<kgugala> so it's useful
<sf-slack>
<olof.kindgren> I'm getting the weirdest error when I try to run write_bitheader manually. ```$ write_bitheader corescore_qf.bit corescore_qf.h Traceback (most recent call last): File "/mnt/gentoo/opt/symbiflow/install/bin/python/bitstream_to_header.py", line 30, in <module> with open(args.infile, 'rb') as bitstream: FileNotFoundError: [Errno 2] No such file or directory: '.bit'```
<sf-slack>
<olof.kindgren> Yes, corescore_qf.bit exists in current directory
<sf-slack>
<olof.kindgren> oh... write_bitheader does some weird stuff before calling bitstream_to_header.py
<sf-slack>
<olof.kindgren> How is it supposed to be used?
<sf-slack>
<olof.kindgren> Oh well. That's for another day to find out
<sf-slack>
<olof.kindgren> Wait a minute... isn't there a much simpler solution. We could add something like xmodem support in the factory image. Then we can just send a new FPGA image and run load_fpga when it's done
<sf-slack>
<olof.kindgren> At least for volatile FPGA images that would be pretty nice
<sf-slack>
<olof.kindgren> Or zmodem which is a bit more modern. Latest update is from 1986. Happen to know that since I read it on a flight a couple of years ago :)