ChanServ changed the topic of #glasgow to: glasgow interface explorer · code https://github.com/GlasgowEmbedded/glasgow · logs https://freenode.irclog.whitequark.org/glasgow · discord https://1bitsquared.com/pages/chat · production https://www.crowdsupply.com/1bitsquared/glasgow · CrowdSupply campaign is LIVE!
egg|laptop|egg has joined #glasgow
GNUmoon has quit [*.net *.split]
DarthCloud has quit [*.net *.split]
nicoo has quit [*.net *.split]
DarthCloud has joined #glasgow
vup2 is now known as vup
nicoo has joined #glasgow
GNUmoon has joined #glasgow
modwizcode has quit [Quit: Later]
egg|laptop|egg has quit [Remote host closed the connection]
modwizcode has joined #glasgow
<cyborg_ar> The prize for the most cheesy commercial is HDS https://youtu.be/tW1S2tsxVHg
<cyborg_ar> Tho
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
GNUmoon has quit [Ping timeout: 268 seconds]
Yatekii has quit [Ping timeout: 246 seconds]
GNUmoon has joined #glasgow
bvernoux has joined #glasgow
Stormwind_mobile has joined #glasgow
_alice has quit [*.net *.split]
eddyb[legacy] has quit [*.net *.split]
eddyb[legacy] has joined #glasgow
_alice has joined #glasgow
_alice has quit [Ping timeout: 242 seconds]
eddyb has quit [Ping timeout: 268 seconds]
svenpeter has quit [Ping timeout: 244 seconds]
whitequark[m] has quit [Ping timeout: 244 seconds]
disasm[m] has quit [Ping timeout: 244 seconds]
jschievink has quit [Ping timeout: 244 seconds]
fridtjof[m] has quit [Ping timeout: 244 seconds]
randomplum has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 240 seconds]
promach3 has quit [Ping timeout: 240 seconds]
blazra has quit [Ping timeout: 260 seconds]
gillesmauve has quit [Ping timeout: 268 seconds]
GNUmoon2 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
svenpeter has joined #glasgow
emily has joined #glasgow
disasm[m] has joined #glasgow
gillesmauve has joined #glasgow
promach3 has joined #glasgow
_alice has joined #glasgow
fridtjof[m] has joined #glasgow
jschievink has joined #glasgow
blazra has joined #glasgow
eddyb has joined #glasgow
randomplum has joined #glasgow
whitequark[m] has joined #glasgow
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 256 seconds]
<d1b2> <brainstorm> Weird, I think my Glasgow rev C1 is dead somehow? Only PWR. FX2 and user leds are on (before ICE was on too) and I cannot factory reset it?: https://pastebin.com/APYMzHS9
<d1b2> <brainstorm> The lsusb is from OSX's brew install lsusb
<tnt> --factory only works once AFAIR
<tnt> (because it looks for un-initialized vid:pid but your device already has the glasgow ones 20b7:9db1 )
<d1b2> <brainstorm> I went/tried for factory because I was getting E: g.cli: device not found on any applet I tried to run :/
<d1b2> <brainstorm> ICE led should be on when connecting the USB?
<d1b2> <brainstorm> Can't remember now :/
<d1b2> <brainstorm> glasgow run selftest also fails with E: g.cli: device not found ... not looking good :/
<gruetzkopf> on a freshly plugged device, the ICE led is off
<d1b2> <Attie> @brainstorm are you on linux? can you run dmesg -w and report back as you plug it in?
<d1b2> <Attie> (use a pastebin / gist please)
<d1b2> <Attie> if FX2 and ICE are dim (compared to PWR), then you have no firmware, this is okay
<d1b2> <Attie> if FX2 is on, and ICE is off, then you have firmware, and this is also an okay state
<d1b2> <brainstorm> I'm on OSX and good news!: I rebooted and it was my host (computer), now the Glasgow is back to normal... ugh, my heart X"D
<d1b2> <Attie> ah, good 🙂
<d1b2> <brainstorm> Thanks everyone :)... those SPUSBDevice: IOServiceGetMatchingService did not return anything for location from lsusb were strange indeed 😒
<d1b2> <brainstorm> From system_profiler[96241:14161233] ... I should just get a linux laptop, OSX is being funny post-el Capitan
<rwhitby> I've just installed glasgow and dependencies on OSX, WSL2, Ubuntu VM and RPi4. OSX was by far the easiest due to @ktemkin brew tap. For all other platforms stuff had to be built from source (they all built fine, it was just an extra step). It's amusing seeing a Pi4 run yosys and nextpnr as part of running glasgow.
<agg> did you check out the yowasp-based versions?
<agg> avoids the need to build yosys or nextpnr or icestorm from source
<rwhitby> nope, didn't know about that
<agg> "pip install yowasp-yosys yowasp-nextpnr-ice40-5k"
Yatekii has joined #glasgow
<whitequark> -5k is for UltraPlus (revAB), -8k is for HX8K (revC)
<modwizcode> Wait so revC does have an 8K?
<whitequark> yes
<whitequark> ultraplus at the time when i designed revA was the slowest FPGA in production
<whitequark> the name is... misleading
<whitequark> at the current moment, the slowest FPGA in production is called "QuickLogic"
<modwizcode> their naming is very confusing
<whitequark> yes. welcome to silicon vendors
<modwizcode> I mean I was more surprised because I couldn't figure out (and still kind of don't know) what their "top tier" is called.
<whitequark> the reason it's called "UltraPlus" is because it has "Ultra" low power consumption (it very much does) and it has the usual fabric "Plus" some hard IP (it sure does)
<whitequark> well, ice40 does not compete on performance, it competes on cost and power consumption
<whitequark> so "ultra" being the "top tier" actually does make sense! it just requires the right context
<whitequark> it's not trying to replace xilinx. it's trying to be that thing that PWMs the RGB LED in your cellphone
<apo> next you're gonna tell us the quick name is logical as well
<whitequark> and manages power sequencing and maybe fiddles with the camera data a bit
<modwizcode> You make money quicker because it costs less!
<whitequark> apo: it's called "QuickLogic" because the company is making eFPGA IP blocks that can be "Quick"ly integrated into your ASIC to give it more configurable "Logic"
<apo> once again, apo successfully predicts the future.
<whitequark> see, you just have to be on the same drugs as their marketing people to understand it
<apo> :D
<modwizcode> Lattice is mostly known for their low power stuff was the impression I was given by the way people at work responded to me mentioning the name
<whitequark> Lattice chips can actually replace some Xilinx parts, specifically Spartan 3E loses easily to HX8K
<whitequark> by like, pretty much every metric
<modwizcode> Isn't the Spartan 3E ancient though?
<whitequark> Xilinx is pretty touchy about 3E too, probably because they have recovered all of the RND costs long ago and currently it's just free cash for them
<whitequark> yes, but they're still making it, and people are still making new 3E designs
<modwizcode> hmm.
<d1b2> <daveshah> They're touchy because it's easily within reach of low budget bitstream compatible clones
<whitequark> ahh
mndza has joined #glasgow
<mndza> hello! is anyone currently trying to eliminate the dependency on bitarray?
mndza has quit []
mndza has joined #glasgow
<electronic_eel> mndza: not that i'm aware of. but getting rid of bitarray would be a good step forward.
<mndza> i thought i might give it a go
<electronic_eel> i personally wouldn't have picked that one as a first step of helping developing glasgow, but that doesn't mean it is not a good idea or not welcome
<electronic_eel> i guess the problem will be to make sure that you don't break any existing functionality
<electronic_eel> maybe whitequark has some more tips for how to best do it
<d1b2> <Attie> @mndza I made a tiny start, but haven't managed to give it the attention I wanted to
<mndza> yes, i am aware i may not be able to do it, i was experimenting a bit with support.bits. i saw bitarray is used in very few places
<mndza> i reckon the most problematic use is for reversing bit order for a bitstream, as reading an entire bitstream to an int may be too much
jstein has joined #glasgow
<whitequark> electronic_eel: i've described how to replace bitarray on IRC earlier to, I think, Attie
<whitequark> i think it would be reasonable if mndza took the same steps
<whitequark> ah, so it was a bit more brief than what i thought
<whitequark> mndza: does that give you enough information?
<mndza> thank you whitequark :)
<mndza> one question though, do you expect to perform the bit reversal in xc6 with the bitarray?
<mndza> i already did some testing with an array() backend
<whitequark> you can reverse array elements and then every individual elements, right? that would be fairly efficient
<whitequark> *bits of every individual element
<whitequark> ah, hm, no, that only works for bitarrays of size that is a multiple of element bit width
<whitequark> basically, yes, i would like to have bit reversal because this is a common operation in some contexts
<whitequark> and it should work on bitarrays of any size
<mndza> yes, that should be the way to do it. i asked because i loved the simplicity of the int() backend
<whitequark> i understand that there are multiple annoying edge cases to handle but such is life
egg|laptop|egg has joined #glasgow
<whitequark> yep. sadly the int() backend doesn't scale
<whitequark> it works a lot better than i expected but FPGA bitstreams get massive
<whitequark> dozens of megabits
<whitequark> wait
<whitequark> xc6s doesn't do bitarray reversal, it does byte reversal, doesn't it?
<mndza> yes
<mndza> reverses the bits out of every byte i think
<whitequark> that's a lot easier than full bit reversal
<whitequark> you can do it with something like five bitwise operations
<mndza> that's actually why i asked: the rest of operations seem doable with an int() backend
<whitequark> no, we need an array backend regardless
<whitequark> for example, JED parsing code mutates individual bits a lot
<whitequark> that would work with an int() backend but produce massive amounts of garbage
<mndza> ok, i will try the array() route then, thank you for the pointers
<whitequark> iirc I measured it and it's not *quite* too inefficient to use, but it will be quite slow on low end devices like rpi
<whitequark> (pre-arm64 rpi)
<mndza> yeah i was not aware that the JED parsing code needed big bitarrays
<mndza> i will keep you posted :)
<whitequark> it's tens to hundreds of kilobits, generally
<whitequark> that adds up especially on the high side
ali-as has quit [Quit: Bye!]
GNUmoon has joined #glasgow
GNUmoon2 has quit [Ping timeout: 268 seconds]
diverger has quit [Ping timeout: 240 seconds]
egg|laptop|egg has quit [Remote host closed the connection]
G33KatWork has quit [Ping timeout: 256 seconds]
G33KatWork has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg_ has quit [Ping timeout: 264 seconds]