umarcor|2 has quit [Read error: Connection reset by peer]
gsuberland has quit [Remote host closed the connection]
<whitequark>
electronic_eel: actually, now i realize that using the 1:8 switch to have the ADC/DAC all strapped same is probably not possible
<whitequark>
because the ICE_MEM should sit somewhere
<whitequark>
it probably should be something like, strap them the exact same way as they are on revC, but do it twice
<whitequark>
this would also cut down on firmware size, which is nice if we're keeping one firmware for all devices, which we probably shoudl
craigo has joined #glasgow
minicom5 has joined #glasgow
minicom has quit [Quit: Ping timeout (120 seconds)]
Ekho has quit [Remote host closed the connection]
Ekho- has joined #glasgow
<electronic_eel>
the ATECC is on i2c too. So yeah, putting the ice-mem, atecc and 2 port adc/dac on one sub-bus, and the other two port adc/dac on another will work fine. leaving a few busses unpopulated won't hurt. and it's less complicated routing.
<electronic_eel>
but I'm not sure if we really want to keep one firmware for revC1, revC2 and revD. A few ifdefs won't hurt.
<electronic_eel>
but we can start with one firmware and introduce the ifdefs once we run out of memory on the fx2
analprolapse has quit [Ping timeout: 245 seconds]
analprolapse has joined #glasgow
m4ssi has joined #glasgow
<whitequark>
electronic_eel: a few ifdefs absolutely will hurt.
<whitequark>
you are not the one building and deploying software for every existing revision. I am. and I am not interested in supporting more than one firmware if at all possible.
<whitequark>
one is bad enough, frankly, three would be a total nightmare. four really, to include revAB.
<whitequark>
this is like your earlier suggestion of "just" including a microcontroller. no. there is no "just". there is an unjustified increase in complexity that does not buy anything but increases deploy headache.
<whitequark>
and if we run out of memory on the FX2, the right approach would be to fiddle with sdcc settings a bit, because there's really not a lot of code on the FX2 and it can be shrank by probably a factor of two or something. sdcc is really inefficient.
<whitequark>
electronic_eel: also we really should get rid of atecc, no one is interested in it, it seems
<whitequark>
after esden ships his boards we can't *introduce* it, so we should DNP it on revC1 and then remove it completely
<whitequark>
electronic_eel: ok, I guess my earlier response was harsher than necessary. still. the point stands. having exactly one firmware file is a very nice property that would simplify pretty much everything else that I would very much like to preserve.
<emily>
there's going to be divergence as soon as revE is a thing anyway right?
<whitequark>
yeah
<whitequark>
but that's covered under the "if at all possible" part
<whitequark>
it is precisely because the rise in complexity is unavoidable that I want to avoid it for so long
minicom5 is now known as minicom
craigo has quit [Read error: Connection reset by peer]
craigo_ has joined #glasgow
andres____ has joined #glasgow
andres____ has left #glasgow [#glasgow]
m4ssi has quit [Remote host closed the connection]
<electronic_eel>
whitequark: hmm, when the code behaves differently on different hardware (which it must), then it should be tested on the different hardware platforms if you are serious about it
<electronic_eel>
there is no big difference if the difference is done with ifs in the firmware or ifdefs by the preprocessor
<electronic_eel>
with the ifdefs you need some small buildsystem script additions, but that's about it
<whitequark>
electronic_eel: and everything that loads the firmware needs to know about it
<whitequark>
and everything that builds the firmware
<whitequark>
and everything that distributes the firmware and so on
<electronic_eel>
the main thing is the test on the different hardware platforms, and that doesn't change based on where the branching is done
<whitequark>
and then you have to detect it at runtime to decide which image to load
<electronic_eel>
yes, but don't we already do that for selecting the right gateware to build?
<whitequark>
then of course you can have different bugs in different firmware builds
<whitequark>
because the compiler miscompiles them differently
<whitequark>
you're precisely right that we still have to test it exhaustively. which is hard enough without adding even more complexity in terms of selecting the right firmware
<electronic_eel>
I'm not saying we should use build different versions right now, but I think it is not some really big thing we should avoid at all costs
<whitequark>
not at all costs, maybe, but yeah i do think it is such a big thing.
<whitequark>
i value simplicity in flow a lot
<whitequark>
i'm well aware that this isn't valued in the industry in general. i don't care. industry sucks
<mwk>
is... is the compiler miscompiling the firmware a common thing here?
<whitequark>
sdcc does that occasionally
<whitequark>
well
<whitequark>
not miscompiles exactly
<mwk>
wonderful
<whitequark>
the contracts of sdcc and of our 8051 variant don't *quite* match
<mwk>
oh?
<electronic_eel>
but why does it do that occasionally and not always?
<whitequark>
electronic_eel: i do not think that simplicity in flow should be defended with any arguments other than it being a goal in itself, sorry
<whitequark>
so i'm not really interested in this argument
<whitequark>
having multiple firmware versions is not currently my problem, and it will not be made my problem
<whitequark>
as for "why did it do that occasionally", i don't quite remember, the last time was a year ago or something
<whitequark>
but it might have depended on link order or function layout or some stuff like that
<electronic_eel>
ok, let's agree that we disagree a bit on how big an issue this is, keep building just one firmware, and quit this argument
<whitequark>
alright
<electronic_eel>
about the atecc - "no one is interested in it, it seems" - what kind of interest did you expect?
<whitequark>
from someone like esden who sells the boards
<electronic_eel>
the current users all built their glasgow themselves or got it from a friend, so no gain for them
<electronic_eel>
even the customers buying directly from esden/crowdsupply won't gain from it directly
<whitequark>
of course
<electronic_eel>
it is just buyers 2nd hand buyers and buyers from distributor that gain
<whitequark>
the other thing is that the infrastructure to program it is actually quite complicated and i'm not sure if i can or even should pull it off
<whitequark>
it could easily be weeks of work on its own
<electronic_eel>
so it will be some months / years till the people who really gain from it show up
<electronic_eel>
yeah, I looked at it and it seems all possible, but a chunk of work to do it correctly
<electronic_eel>
and it needs all be finished and working before esden begins manufacturing
<whitequark>
yeah, it seems a not very worthwhile way to spend time
<electronic_eel>
the first customers will appreciate something like multi-applet, interface to openocd,.. a lot more
<electronic_eel>
and when someone shows up who would gain from it, it is long too late to implement
<electronic_eel>
these market realities are the reason why you seldom see something like this in a product
<whitequark>
yep
<whitequark>
i say we ditch it
<electronic_eel>
doing something that is uncommon on the market would be the best reason for me to implement it
<esden>
Please excuse me if I am just stupid and miss the point of atecc. To my understanding it is a way to identify and make sure the source of the hardware. My experience with other hardware projects so far was rather positive regarding the honesty of the users and where they got the hardware. Also it will start becoming an issue when there are other sources of the hardware that end up putting the 1b2 logo on the board.
<electronic_eel>
but it is not strong enough to do all the work
<electronic_eel>
esden: yes, correct
<whitequark>
this is what I meant by "esden is not interested in it", electronic_eel
<electronic_eel>
esden: but there are other, more simple ways to identify the source
<electronic_eel>
whitequark: yes, I get it
<whitequark>
ack
<esden>
I do not intend to push the version of the design files that includes our company logo up stream. And I think it is more worthwhile to save the money on the part and invest your precious time whitequark in the software and features instead of the auth infrastructure.
<esden>
(lol now I want to see the diff of the topic... :P)
<whitequark>
one letter
<whitequark>
G->g
<esden>
haha ok :D
<electronic_eel>
esden: I've seen a more low tech approach to manufacturer auth: the manufacturer uses transparent nail polish with included glitter particles and puts a bit on the product near the serial number
<electronic_eel>
then the part is photographed and the photo made available online, sorted by s/n
<esden>
haha... that is a nice one! :D
<whitequark>
that's a lot like bunnie's bitmarks, except without the blockchain shit
<whitequark>
or alternatively: a PUF
<electronic_eel>
getting the glitter particles in the right position is really hard
<esden>
it is so random that it makes it unique, I like that
<esden>
I have those paint pens that could be loaded with nail polish like that
<esden>
the metron ones
<electronic_eel>
you'd have to let them dry a bit and use a photo rig
<electronic_eel>
drying needs to be done horizontally
<electronic_eel>
so needs a bit of space on your desk or some drying racks
<esden>
sure... I would also have to figure out a good way to add serial numbers to the boards
<daveshah>
whitequark: now kinda wonder if iCE40 [CB]RAM is usable as a PUF
<daveshah>
there is a way of reading it out, the vendor tools have that as an option
<whitequark>
BRAM too? nice
<whitequark>
not FF states i assume
<electronic_eel>
I'd print serial numbers on a sheet with stickers, add a barcode the sticker too
<daveshah>
whitequark: no, and afaik the only way to get a config interface is to reset the device anyway
<electronic_eel>
then put the sticker on the glasgow and scan it with a barcode scanner when putting it in the jig
<whitequark>
ah
<daveshah>
I'm not aware of any way to keep SPI "open"
<whitequark>
so here's for a change of topic
<whitequark>
anyone in this convo familiar with nmigen.build?
<whitequark>
or at least migen.build
<esden>
no sorry... :/ ... I did use the migen build target but that is it not familiar with the internals at all
<whitequark>
ok so migen has a concept of connectors
<esden>
right I do remember that
<esden>
it was useful in some of the examples IIRC
<whitequark>
in migen, you could not easily use SDR and DDR with i/o/io pins and so on
<whitequark>
you sort of could but it was so awkward glasgow grew its own abstraction layer
<whitequark>
which is now unnecessary
<esden>
ohh cool! I do remember fumbling through the IOB handling of migen before...
<esden>
on another note... what are your plans regarding user/api documentation of nmigen?
<whitequark>
there should be more of it
<esden>
I have people asking how to help with all things glasgow ... regarding what a beginner can do and help with documentation.
<whitequark>
the problem is my review bandwidth to a large extent
<esden>
should I send them here?
<whitequark>
I think by 2020 things should clear up a bit in nmigen-soc and so on and I should be able to spend more time writing docs
<whitequark>
or editing/reviewing
<whitequark>
but probably not right now
<esden>
whitequark: yeah I 100% understand the bandwidth vs. documentation issue. Believe me. :D
<electronic_eel>
esden: I don't think they need to know nmigen to be able to help
<whitequark>
there's just as much of an issue with applets
<electronic_eel>
I don't know any nmigen and still got a few commits in
<whitequark>
every new applet with gateware right now adds to things that have to be ported to nmigen later
<esden>
well I think I will send them in here, and let them ask you where they can be most useful/helpful. :D
<whitequark>
and APIs in Glasgow that are yet to be written
<whitequark>
and of course there are interdependencies
<whitequark>
for example, the glasgow.gateware.registers module should be replaced with nmigen-soc CSRs
<whitequark>
except they do not exist yet
<whitequark>
I *would* appreciate discussion of how the new pin assignment API should look like
<electronic_eel>
we could use a windows packaging expert to help getting all the dependencies working on win
<whitequark>
linux is more of a problem here, imo
<esden>
I will also have a lot of questions in hopefully near future. I have grandiose plans of doing livecoding streams on twitch and implement something like Commodore 1541 emulator/reader... and fumble through applet implementations for everyone to see and make fun of. :)
<electronic_eel>
?
<whitequark>
windows is largely just annoying, but there is roughly one way to do it
<whitequark>
take the portable python zip and stuff it full of our dependencies
<whitequark>
there's no issues with things like glibc versioning
<whitequark>
linux, i don't even know where to start
<electronic_eel>
... but instead with libusb driver assignments and so on
<esden>
on linux it could be a snap or some other flatpack too in theory... but I see the problem here, there are too many ways to do it...
<whitequark>
yes, exactly
<whitequark>
i've used all of these deployment methods to some extent
<whitequark>
and they all have serious issues
<esden>
yeah I hear you... :/
<electronic_eel>
hmm, I must have been really lucky. I just installed the packaged yosys and nextpnr rpms, ran the setup which pulled in the stuff from PyPi and were done
<whitequark>
yosys 0.9?
<electronic_eel>
ah, ok, there was the 0.9 missing one option
<whitequark>
yes, things like that accumulate
<whitequark>
i also think it's really important to finish the various codebase migration firs
<whitequark>
*first
<whitequark>
ideally before people start to write their applets en masse
<whitequark>
because that's going to be painful.
<electronic_eel>
we should create a proper way to make and publish applets that are outside of the master repo
<whitequark>
that too
<whitequark>
it's been planned for a long time
<esden>
streamlining API usage so that the applets don't diverge from the get go is a very good goal :D
<esden>
That is probably even more important than having mechanisms for publishing third party applets. Although that is important too.
<whitequark>
yes
<whitequark>
I mean, they are already diverging even in our repo
<esden>
You need more code monkeys to yak shave the codebase and help out it seems. :D
<esden>
in how far is it possible to run any of the glasgow stuff without having the glasgow hardware?
<electronic_eel>
esden: not only code monkeys, as you've just read the packaging part could also take some help
<electronic_eel>
packaging yosys and nextpnr can be done without any hardware at all
<esden>
fair enough yeah
<whitequark>
"code monkeys" would not help much if at all
<whitequark>
because what needs to be done is design
<esden>
hehe... you just need enough of them ;) ... J/K
<esden>
sounds good... if I find more people that are excited to put some time into the project I will send them your way, hopefully you can find some fun tasks for them :D
<whitequark>
as i've said, the limiting factor is my bandwidth
<whitequark>
so that would probably make things slower, unfortunately
<esden>
fair enough
<whitequark>
what i need is people who can participate in design discussions for APIs
<whitequark>
and also something for chronic pain
<electronic_eel>
some of the folks hanging out here for some time could take a look at fresh pull requests and help ironing out the biggest issues before you take a final look
<whitequark>
i could use some help porting gateware to nmien