<whitequark>
(other than locally on my machine I mean)
<d1b2>
<Attie> am i missing something?... where is U30.G4 in the schematic? (tied to VIO_AUX)
<d1b2>
<Attie> it doesn't appear to be a change from C1 -> C2, but I can't see it
thasti has quit [Remote host closed the connection]
thasti has joined #glasgow
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #glasgow
samlittlewood_ has joined #glasgow
samlittlewood has quit [Ping timeout: 264 seconds]
samlittlewood_ is now known as samlittlewood
<electronic_eel>
Attie: the R6 / R50 footprints are there to allow the user to bypass or tweak the dropper resistors. this might be needed if for some application the drop of the ldo and the resistors combined is too high. but when you do this, the ldo could become unstable under overload conditions, so it is just for users that know what they are doing. but the empty footprints cost nothing, so they were added to allow for some easier hacking if wanted/needed
<d1b2>
<Attie> @electronic_eel yep, i thought so, thanks
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood_ has joined #glasgow
<electronic_eel>
Attie: re G4 on the ice40: i just looked up the pinout sheet from lattice. it is vccio_3 in the BG121 package we are using
<electronic_eel>
vccio_3 is for the lvds port, so it is tied to vio_aux
<d1b2>
<Attie> i suspected something like that - but it's completely missing from the schematic?
<electronic_eel>
it is probably hidden in the schematics, as it is always the same signal as the other pins for vccio_3. the schematics just show E4 for it
<d1b2>
<Attie> oh, hmm...
<electronic_eel>
you can probably enable show hidden signals and then you'll see it
<d1b2>
<Attie> yes, okay... ew (that's a grey G4 on top of the E4)
<electronic_eel>
or go into the symbol editor and look at the details
<electronic_eel>
yeah, that is what i meant
<d1b2>
<Attie> not a fan of that tbh, but oh well
<electronic_eel>
it is hidden to reduce cluttering the schematics with stuff that doesn't really matter, since you must always connect these to the same rail
<d1b2>
<Attie> yeah, i appreciate that, but i'm still not a fan - two pins on the top vs one?
<electronic_eel>
just look at the pinout table, there are tons of power pins that go to the same rail. if you always had these shown in the schematics, the schematics would be full of them, and take the view away from the interesting stuff
<d1b2>
<Attie> granted
<d1b2>
<Attie> happy to put that down as a "you vs me" / personal preference thing
<electronic_eel>
here with the ice40 you could get away with showing them. but consider a bigger fpga with 700 something pins. so the kicad lib maintainers decided to do it that way, and they used the same principle for all fpgas
<d1b2>
<TiltMeSenpai> could you throw a pin without a pin number as the "visible" one, and have all the pins with actual pin numbers hidden under it?
<d1b2>
<Attie> interesting (i've not really used KiCAD properly before looking at Glasgow - gave it a good chance ~3-4 years ago)
<d1b2>
<Attie> i'd hope for some kind of marker - "there are more pins here" or similar, but nvm
<d1b2>
<TiltMeSenpai> I can see how having a pin number, then having even more hidden pins under it is kinda ehhh
<electronic_eel>
TiltMeSenpai: yeah, it would be better to not show a pin no at all in this case. let's hope the kicad devs improve this with the schematic editor rewrite for version 6
<d1b2>
<Attie> i'm more used to a full page dedicated to powering a part, then other pages dealing with RAM, and other interfaces, etc...
<d1b2>
<Attie> - one of my style comments would be, we have ~infinte space, why is this so squished?... imo it can make things a little tricky to follow
<electronic_eel>
hmm, but you have to draw all these gnd connections when you use the part. that costs time and takes schematics space. and i don't really see a benefit in it, since in 99.9% you want to connect all these pins to the same rail
<d1b2>
<Attie> I've had a fairly good rummage through, and (aside from stylistic comments, which I'll keep to myself from now unless queried), my only real comment would be the slots in the pours. not likely a real issue for this layout though.
<d1b2>
<Attie> @electronic_eel - yeah, i can see that side too
<d1b2>
<Attie> ... otherwise, looks good! well done 🙂
<electronic_eel>
re slots: yeah, there are some that could be optimized away a bit. the ones you were showing, and also a bigger one in the 3v3 layer, where the right side is cut by the 5v trace
uovo has quit [Ping timeout: 256 seconds]
<electronic_eel>
but i think glasgow is not really high speed enough that this will become an issue
<electronic_eel>
but thanks for taking a good look at the schematics and board!
<whitequark>
ok it will never finish on dumbo-2
<whitequark>
do i know anyone here with a windows machine and 64-bit python?
<whitequark>
a bare metal windows machine that is, not a vm
samlittlewood_ has quit [Ping timeout: 260 seconds]
samlittlewood has joined #glasgow
cr1901_modern has joined #glasgow
<Lofty>
whitequark: I have a windows machine and can drop Python on it
egg has joined #glasgow
<Lofty>
Python 3.9.0 (tags/v3.9.0:9cf6752, Oct 5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] on win32
<d1b2>
<Attie> @whitequark I can do python on windows too of you need a second
<whitequark>
this will establish the performance of the new cache
<whitequark>
i'm interested in whether the warm startup latency became lower on bare metal or not
<Lofty>
My Python is sparkling new and things are not set up properly :P
<whitequark>
wait, what?
<Lofty>
There's no pip
<whitequark>
ohhhh
<Lofty>
Well, you have to `py -m pip`
<whitequark>
that's cursed
<whitequark>
oh
<Lofty>
And then it doesn't go into the system path
<whitequark>
you got the windows store one right
<Lofty>
No, the python.org executable installer
<whitequark>
huh
<d1b2>
<TiltMeSenpai> oh boy, the windows store one doesn't look like it sets up paths right :/
<d1b2>
<TiltMeSenpai> yowasp-yosys does a command not found thing after installing
<Lofty>
Yeah, same for the py.org installer
<Lofty>
So, yowasp-yosys has been installed ~somewhere~ and I don't know where
<Lofty>
Ah, found it
<d1b2>
<TiltMeSenpai> wait, what? by default, it looks like the windows store install sticks itself in a hidden folder that you can't access by default, even as admin
<Lofty>
TiltMeSenpair: %LOCALAPPDATA%\Programs\Python\Python39\Scripts needs to be in your system path
<d1b2>
<TiltMeSenpai> that's... very cursed...
<d1b2>
<TiltMeSenpai> unless you're windows store, in which case %LOCALAPPDATA%\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0, which is obvious and intuitive
<Lofty>
The windows store version is in I think %LOCALAPPDATA%\Packages\
<tnt>
I'm not really sure in what state I left it, I know I could never get it to do anything useful (on a FR2433 chip)
<whitequark>
tnt: thx, that will come in handy!
<cr1901_modern>
According to the JTAG manual... SBW requires some flash writing code to be sent to the chip (presumably in RAM?). Is that stored on the FET, and will a user be expected to provide such an image for Glasgow?
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #glasgow
<whitequark>
cr1901_modern: that should be built into the applet
<whitequark>
it's the same thing you do with MIPS, STM32, ...
<cr1901_modern>
ahhh
<whitequark>
actually i wonder if you really need the code