<whitequark>
not just another FPGA board! a very, very expensive FPGA board
<marcus_c>
But one with flexible level shifters and power supplies. This is the main selling point.
<whitequark>
I would say that the main selling point is the end-to-end integration from software to hardware that lets one forget there is a complex and obscure FPGA toolchain in the middle
<marcus_c>
Well, that's not what sold it to me at least. :-)
<whitequark>
or a 8051 from the mid-2000s for that matter
<whitequark>
sure, but the other components reduce the effort that gets you to a working, communicating design to the point where entirely new classes of application are available
<marcus_c>
It's probably not too difficult to define a LiteX platform for it, if you want to hide the toolchain but still get down and dirty. :-D
<whitequark>
I mean, there is an Amaranth platform for it already
<marcus_c>
There you go then.
<whitequark>
... how do you think Glasgow software works?
<marcus_c>
LUTs?
<whitequark>
what?
<marcus_c>
The hardware components of the FPGA, which everything gets translated down to regardless of how many or few abstraction layers you put on top.
<whitequark>
that's irrelevant, I'm talking about the host software stack
<marcus_c>
I don't know anything about that - still haven't got my glasgows so I haven't looked at any sw yet, but I'll probably make my own anyway.
<whitequark>
the whole point of the project is that it is a set of nicely interacting abstractions that compose to give you a seamless experience of using it and developing for it
<whitequark>
you... are going to throw out what I consider the most useful part of the project after paying this much for hardware? that's an interesting approach
<whitequark>
(as an aside, third party software is explicitly unsupported)
<marcus_c>
Well, I'll make that decision afterr I look at it and decide whether or not _I_ consider it useful for my intended application.
<marcus_c>
I can mention that when dasKeyboard made their 5Q keyboard _they_ thought that their cloud software was the most useful part of it all. I thought otherwise and made my own firmware for it. (Also unsupported.)
<whitequark>
mm, I wonder if we should add a section in the README or something for the people who consider buying the board as yet another FPGA devboard
ar-jan has quit [Ping timeout: 246 seconds]
<whitequark>
though the Crowdsupply page should have already been pretty detailed on what makes it interesting (and worth the cost)
<whitequark>
so I'm not sure
ar-jan has joined #glasgow
<marcus_c>
I would assume that if someone picks the Glasgow as an FPGA devboard over the (cheaper) alternatives, they already have a pretty clear idea about what they want to use the board for and how to achieve it.
<whitequark>
I'm not so sure anymore
<whitequark>
but there's probably no point thinking too much about this case
redstarcomrade has quit [Quit: Connection closed for inactivity]
bvernoux has quit [Quit: Leaving]
bvernoux has joined #glasgow
mats1 has quit [Ping timeout: 268 seconds]
uartist5 has joined #glasgow
mats1 has joined #glasgow
uartist has quit [Ping timeout: 252 seconds]
uartist5 is now known as uartist
pie_ has quit []
pie_ has joined #glasgow
<swiftgeek>
whitequark: but would it be really that much effort to add some instructions for using it with icestorm? I don't have board on hand (yet) so it's hard to tell
<swiftgeek>
like as long as it gets blinky example working, i'm kinda happy
<swiftgeek>
that's like 95% of fpga boards already (taking number out of ass)
<whitequark>
it's not entirely straightforward because there is a board management 8051 that you need to talk to
<swiftgeek>
i just want bitstream upload really
<whitequark>
without some additional steps you won't be able to use the I/O
<whitequark>
other than the two pads connected directly to the FPGA
<swiftgeek>
do you mean direction pins? that is still connected directly to fpga so i don't see a problem there, just something to keep in mind
<swiftgeek>
and VIO is external, though setting internal reference to common 3.3V for such educational purposes would be nice
<whitequark>
VIO does not directly affect internal reference
<whitequark>
you can do all this with the Python API (it's like two lines if you have an async event loop), just like... I feel like people are treating any open-source hardware with an FPGA on it as "FPGA devboard" and while this is fine I'm not sure I want to *participate* in it, speaking as the Glasgow maintainer?
<swiftgeek>
but is maintaining hello blink example that much more effort?
<whitequark>
the way I see it, there is a scope of the project (which is already enormous) and if I do not resist expanding it, it will expand endlessly
<swiftgeek>
would make it way more valuable though when making a decision to buy the board (IMO)
<whitequark>
every individual thing to maintain is maybe not "that much more effort", but they compound
<swiftgeek>
that's why i'm mentioning keeping it hard limited to single hello blink example
<swiftgeek>
no host communication, just bitstream upload, with clear warning that such use is not supported by glasgow project but it /can/ be used like that with enough effort
<whitequark>
I feel like anyone who is willing to spend enough effort to do something unsupported, can figure out how to upload bitstreams by reading the code
<whitequark>
the function is called "download_bitstream", i think. it might even be documented? though we don't currently publish API docs
<swiftgeek>
you are overestimating how smart some people are, it's a matter of time :D
<marcus_c>
swiftgeek: There is no need for 1bitsquared to maintain a blink example. Anyone could do it. This is what makes open source awesome.
<swiftgeek>
for some it will be trivial, but for me it will be easily weeks/months ;D
<swiftgeek>
like it would be easier for me to start with 8051 fw from scratch probably xD
<whitequark>
Glasgow is not a project headed by 1bitsquared
<whitequark>
they make the hardware, since
<whitequark>
*since I considered, correctly, that it would be too difficult for me to do so
<marcus_c>
Ok, substitute with "project maintainer" or whatever.
<Wonka>
they also make the ICEbreaker which is an actual devboard...
<d1b2>
<Rogan> In which case, perhaps you should rather start with a dev board that is properly supported, and has documentation for your abilities and use cases?
<whitequark>
they are a very valuable partner making the project actually accessible to people, but they do not have the manpower to maintain software
<marcus_c>
The point is that anyone can scratch their own itch.
<marcus_c>
I mean, in the "being allowed" sense. Asking for help if you lack the skills is perfectly ok.
<whitequark>
I understand the frustration, it's just that in the past I did not regard expansion of scope the way it should be, and burned out hard
<swiftgeek>
yes i can take everything there is and spend time reversing it pointlessly, or I can try convincing somebody to be kind and use their existing knowledge to make a quick and dirty example
<whitequark>
oh, I can just tell you how to do it
<swiftgeek>
just because something is open doesn't mean it will be trivial for somebody to figure it out
<whitequark>
I don't want to maintain it
<whitequark>
I do not want people to expect that they can use Glasgow hardware as a generic FPGA devboard, ask me generic FPGA or Verilog questions in the context of this project, etc
<swiftgeek>
that's why a disclaimer on top is great
<whitequark>
no one reads or follows those
<d1b2>
<Rogan> if it exists, and has their name on it, they'll get questions about it
<swiftgeek>
i would fully support that decision when clear example is given, then maybe maintainer could be found for separate or not repo that would host more examples, but that would be up to that person
<swiftgeek>
but blinky example would make it easier to make that happen
<whitequark>
I do not want that to happen
<swiftgeek>
and that's what I can't understand
<swiftgeek>
I want anything to be used in as many ways as possible, even if I don't want any part of that
<swiftgeek>
like not even near that
<d1b2>
<Rogan> I think the part you are not understanding is the burn out.
<d1b2>
<Rogan> When someone has lost all interest and ability to perform, due to being at breaking point for far too long
<d1b2>
<Rogan> they have to set boundaries, in order to function.
<whitequark>
I made Glasgow open source because (technical reasons aside--you can't really make closed-source Python applications) I consider intellectual property an outdated, socially corrosive principle
<swiftgeek>
I prefer to not function, so I guess I'm making bad decisions there :P
<whitequark>
that's why it's under 0-clause BSD specifically
<whitequark>
everyone should be able to understand the tools they are using unimpeded by legal or technical obstacles
<swiftgeek>
at the same time glasgow would inherently be a name and some kind of community
<swiftgeek>
making that an obstacle doesn't sound right with me
<whitequark>
however, many people understand open source as "you, the maintainer, have an implied obligation to make it useful for my specific case"
<whitequark>
here, "useful for an FPGA developer board for someone without a lot of experience with one"
<d1b2>
<Rogan> This precise thing that you are doing is what @whitequark is trying to avoid. People pressuring for MORE, demanding more of their time.
<whitequark>
I reject that, primarily because I spent many years accepting it and it led me to quitting most of the projects I started or brought to public view
<swiftgeek>
well not exactly, I have assumption that it already pushes bitstream somehow
<whitequark>
you don't go to a display panel vendor and ask them how to use the embedded 8051 as a general purpose CPU, do you?
<swiftgeek>
hello blink example, is the most easy way i could think to ask for direction for somebody with knowledge how it works
<swiftgeek>
whitequark: i absolutely do and have strange results
<swiftgeek>
sadly they are not great in the end and hardware is aging and therefore every single project like that ends up being unique snowflake
<whitequark>
... were you the person who emailed me about a weird 8051 you found somewhere
<d1b2>
<Rogan> Do you accept when the vendor says no, we will not provide that information? Or do you keep harassing them in the hope that they will give in and send you what you want?
<swiftgeek>
i keep finding 8051 everywhere lol
<whitequark>
Rogan: I would not consider this "harassment", that's far too harsh of a description
<whitequark>
however it is pushing boundaries, in a way far too common in open source
<swiftgeek>
d1b2: I don't accept it, I move forward anyway
<d1b2>
<Rogan> not giving up in the face of "I don't want to do that"? Looks like it to me
<swiftgeek>
but I don't think of such vendor greatly in those cases
<whitequark>
at one point, I actually had some doubts whether I want anyone to mass-produce the hardware. of course, being OSHW, it's not like I had effective mechanisms to prevent it
<swiftgeek>
like I really don't like certain chip vendor for saying they won't support non-chinese xD
<d1b2>
<Rogan> Will accept this description, though
<swiftgeek>
(I asked for specific pdf file even if it was in chinese)
<whitequark>
I eventually decided to take the gamble on it being a good idea, to large extent because I have a lot of respect for Piotr
<whitequark>
it probably bears saying that I have, and as far as I know will, earn $0 from Glasgow hardware sales
<swiftgeek>
oh, didn't knew that
<d1b2>
<Rogan> I appreciate that you did allow 1b2 to make this hardware, because it means I can get my hands on one. Thank you!
<swiftgeek>
that's like 10 more reasons for me to change glasgow so it handles stuff below 1.8 down to at least 0.9V
<d1b2>
<Rogan> I am looking forward to learning about FPGA development, within the constraints of this project, using the framework that you have invested a massive amount of effort into designing and implementing.
<swiftgeek>
i can barely think of any 5V use case, and over half are below 1.4V
<whitequark>
that's something that is already planned, actually
<whitequark>
it should be a matter of swapping the level shifters. though the new ones will need to go through the same testing as the old ones
<whitequark>
one thing about hardware modifications is that they cannot be called "Glasgow" without prior agreement with the project
<swiftgeek>
but can they be called glasgow derivative ?
<whitequark>
"derived from" or "based on" is fine since that is just a fact
<swiftgeek>
then that's fine with me
<swiftgeek>
i have seen trademarks refusing such thing
<whitequark>
anything that is clearly distinct works
<whitequark>
it's a fine line to walk
<whitequark>
go too far and you alienate the people who are most interested in the project and would invest the most effort
<whitequark>
go too close and you end up doing support for hardware you did not even see
<whitequark>
which is not something I am willing to do at all
<whitequark>
I think most of the people requesting features do not understand the incomprehensibly wide scope the project already has
<swiftgeek>
but it definitely has to upload bistream somehow :P
<whitequark>
it does
<Wonka>
14:56:45 <@whitequark> the function is called "download_bitstream", i think. it might even be documented? though we don't currently publish API docs
<whitequark>
I need to run rn but I can show you how to do it once I'm back, if no one else does that
<Wonka>
should be findable
<whitequark>
in the meantime that is
<swiftgeek>
i wonder if i could hook up fx2lp to ice40hx8k to simulate having glasgow since fx2 usually stays somewhat compatible
<swiftgeek>
(for sole purpose of testing bitstream upload)
<swiftgeek>
yeah all that object oriented complexity is so over my head but i see some hex codes on top of hardware.py so it really looks like something talking to FX2 xD
<swiftgeek>
Wonka: nah i'm more about not finding my around codebase
<swiftgeek>
so seeing those i guess vendor requests and whatnot makes me feel like i'm in right place, though still have no clue if i actually look back on python code xD
<swiftgeek>
so I gave up and moved on to C side
<swiftgeek>
thankfully no python on FX2 side, so there is a chance I will spot something relevant there
<swiftgeek>
and first surprising thing to me is that PB5/D5/IOB_105_SDO is not touched on FX2 side, so the entire load looks much easier i guess
<whitequark>
the request to load FPGA bitstream is 11h, with wIndex being the number of 1k-sized chunks
<whitequark>
the load is completed by sending a request 18h, with 16 arbitrary bytes (you can just use zeroes) as data
<swiftgeek>
I hope this doesn't mean I need to write my own tool for bitstream upload :D
<swiftgeek>
but wouldn't be that bad really
<whitequark>
I'm not sure why would you be asking otherwise?..
<whitequark>
about C code, that is
<swiftgeek>
ah because python is so high level it makes it really hard for me to grasp anything, so I moved on to side I could grasp :P
<whitequark>
the code is something like `from glasgow.device.hardware import GlasgowHardwareDevice; import asyncio; asyncio.run(GlasgowHardwareDevice().download_bitstream(open("bitstream.bit", "b").read()))`
<swiftgeek>
thx
<whitequark>
it probably makes more sense to open an asyncio shell (`$ python3 -m asyncio`) and then ditch `asyncio.run()`, in case you'll also be manipulating IO voltages and stuff
<whitequark>
then it becomes something like `from glasgow.device.hardware import GlasgowHardwareDevice; GlasgowHardwareDevice().download_bitstream(open("bitstream.bit", "b").read())`
<swiftgeek>
wait this is still 56pin, so I guess I have the same IC just in different package, thought it was the bigger one
<whitequark>
wait, if you have an FX2 devboard and an FPGA devboard, why do you need to use Glasgow as an FPGA devboard?..
<whitequark>
I
<whitequark>
*I
<whitequark>
*I'm so confused
<swiftgeek>
glasgow is small portable and has level shifter
<swiftgeek>
and infinitely more unsupported potential from FX2, than FTDI not actually hooked up