futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Exec1N has joined #glasgow
<_whitenotifier-f>
[libfx2] artizirk commented on pull request #4: Add standalone url field to fx2 setup.py - https://git.io/JfPR7
ExeciN has quit [Disconnected by services]
Exec1N is now known as ExeciN
<_whitenotifier-f>
[libfx2] artizirk commented on pull request #4: Add standalone url field to fx2 setup.py - https://git.io/JfP0j
<d1b2>
<tnt> Anyone know what the clkref frequency is from memory ?
<d1b2>
<edbordin> crystal is 24 MHz if that's what you're after
<d1b2>
<tnt> No, the CLKREF pin from the FX2 to the FPGA.
<d1b2>
<edbordin> nvm, back to lurking for me
futarisIRCcloud has joined #glasgow
<d1b2>
<gimbas> just thought of a possible applet, cause i needed it just now xd pulse generator, pwm generator
<d1b2>
<gimbas> maybe it exists already and i don't know about it?
<d1b2>
<gimbas> either way my glasgow isn't even assembled yet xd
<whitequark>
tnt: 48 MHz
<tnt>
whitequark: tx. Unfortunately I've confirmed the HX PLL are different from the UP5k ones. Previous gen I guess.
<whitequark>
oh
<whitequark>
do you still only have revB?
<tnt>
No no, I have both revB and revC glasgow. But I was testing the divide-by-5 mode of the PLL for TMDS 10:1 but that only works on the UP5k, the HX doesn't have that.
<whitequark>
huh
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 256 seconds]
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 260 seconds]
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
tomtastic_ has joined #glasgow
tomtastic has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
englishm has quit [Excess Flood]
englishm has joined #glasgow
tomtastic_ is now known as tomtastic
rappet has quit [Quit: -]
rappet has joined #glasgow
bvernoux has joined #glasgow
ExeciN has quit [Quit: so long king Bowser]
Stormwind_mobile has quit [Ping timeout: 246 seconds]
Stormwind_mobile has joined #glasgow
<electronic_eel>
esden: whitequark: what do you think about changing the adc to INA233 for revC2?
<whitequark>
didn't we discuss it before?
<whitequark>
I *think* I agreed to it?
<electronic_eel>
yes, and as niklas was doing the edinburgh design, we wanted to test it there
<whitequark>
ahh
<electronic_eel>
but it seems this design was never finished, so we didn't get results
<whitequark>
mh ok
<whitequark>
also now I remember that I owe you some I2C stuff...
<electronic_eel>
so now I think the question is if esden wants to do it
<whitequark>
been working mostly on nmigen in the meantime since that's what puts food on my table, quite literally
<electronic_eel>
yeah, the interface to the internal i2c
<whitequark>
I should find some time to implement that + an ELA
<electronic_eel>
that will be needed when we want to make the test jig board work
<electronic_eel>
wasn't someone else working on the ELA?
<electronic_eel>
awygle?
<whitequark>
I suggested that I do it since I wrote all of the existing code for --trace and it should be very easy for me to adapt it
<awygle>
whitequark told me to stop :-P
<whitequark>
it's probably like a hour of work
<whitequark>
well, it's not that I wanted you to stop
<awygle>
I am joking
<whitequark>
right ok
<awygle>
I do still want to write a Glasgow applet, and ideally document the process, but if wq is willing to do the ELA I have other higher value things to do in the short term
<electronic_eel>
whitequark: another question - back when we talked about the self test (which still has to be fixed for revC), I said that we'll need the internal pullups of the ice40
<whitequark>
the problem with documenting the process is that the process is bad
<whitequark>
*everything* about applets is in flux
<electronic_eel>
and you said that nmigen currently has no way of accessing those
<electronic_eel>
is this still the case?
<whitequark>
they're halfway migrated to nmigen, they're halfway using nmigen's platform layer...
<whitequark>
electronic_eel: uhm, not quite
<electronic_eel>
maybe I remember it wrong
<whitequark>
it's not an nmigen problem
<whitequark>
IIRC it's a glasgow-using-nmigen problem
<whitequark>
I don't recall the discussion, think you can find it in the logs?
<whitequark>
or let's just rehash it
<electronic_eel>
oh, so nmigen can use them, but glasgow is still using the omigen compat layer?
<whitequark>
no
<whitequark>
there's no compat layer for the platform stuff
<whitequark>
on ice40, you can set IOSTANDARD, PULLUP, and so on as parameters on SB_IO
<whitequark>
in nmigen, you normally provide these in the platform, in the resources list
<whitequark>
unfortunately this doesn't really cover meta use cases like glasgow, which add them at runtime
<whitequark>
or rather, the way glasgow uses resources isn't appropriate for its meta use case
<electronic_eel>
runtime as in python running nmigen elaborate or runtime as in logic switching in the fpga?
<whitequark>
neither
<whitequark>
nmigen.build is mildly biased towards fully static FPGA pinouts since most boards work that way
<whitequark>
it provides a connector functionality for PMODs etc
<whitequark>
glasgow right now pretends to be a fully static board with two 8-pin IO resources
<whitequark>
this isn't how applets actually work and it hurts glasgow in more ways than one
<whitequark>
what *ought* to happen is that there would be no resources defined upfront, only connectors corresponding to ports
<whitequark>
(in fact we can literally rename the FPGA pins to A0..A7 B0..B7)
<whitequark>
and then each applet would create a resource with the pins it needs
<whitequark>
so it'd be like on-demand construction of board definitions
<whitequark>
in that case it's very easy to say if we want pullups, or DDR, or whatever
<whitequark>
right now glasgow has it hacked together in a fairly obtuse way
rappet has quit [Ping timeout: 272 seconds]
<whitequark>
anyway
<whitequark>
forget all that
<whitequark>
should we maybe just enable the pullups permanently on every design?
<whitequark>
it's usually not very good to have floating digital inputs
<whitequark>
then that would be a 2-line patch for the existing code
rappet has joined #glasgow
<electronic_eel>
so for the selftest, we would have stuff like pullups & input everywhere and on pin is output low, read back all input pin status
<electronic_eel>
that would work with pullups enabled always
<whitequark>
shall I enable the inputs now?
<electronic_eel>
inputs? do you mean pullups?
<whitequark>
er, yes
<electronic_eel>
if it is just a 2-line patch, maybe put it in a branch and let me play a bit with it?
<whitequark>
is there a reason we shouldn't just have pullups on ice40 side always enabeld
<whitequark>
?
<electronic_eel>
what happens with unused pins that go to the levelshifters currently?
<electronic_eel>
and especially the dir lines to the level shifters?
<electronic_eel>
I think the dir should be set to low, to set the level shifter to input
<electronic_eel>
then the pin to the ice40 is driven by the level shifter
balrog has quit [Ping timeout: 260 seconds]
<whitequark>
electronic_eel: right now all unused pins are tied low
<tnt>
That's new ? Because it was the case and got "fixed" but that was back in rev B.
<electronic_eel>
ok, so they are actively driven low. additional pullups would just be some µa flowing
<whitequark>
sorry, I misspoke
<tnt>
It's annoying that unused pins are driven (or even pulled) because if you're switching from one applet to another using different pins, you're messing with the DUT.
<whitequark>
unused OEs are driven low
<whitequark>
so the pins are hiz
<tnt>
ok
<electronic_eel>
yes, that is how I think it makes sense
<whitequark>
see target/hardware.py
<electronic_eel>
so then I don't see an issue with always enabling the pullups on the pins to the level shifters
<electronic_eel>
we may not enable pullups on the sync though
<whitequark>
right
<electronic_eel>
haven't thought about the pins to the lvds port, there pullups would probably make sense
<whitequark>
wait, I think we can enable the PU on revC1's sync
<electronic_eel>
you mean because the pulldown resistor is strong enough?
<whitequark>
revC1's sync has an LVC1T45 on it, right?
<electronic_eel>
yes
<whitequark>
so on ice40's side we can enable the pullup on io while oe isn't enabled, right?
<whitequark>
or am I forgetting something
<electronic_eel>
on the io yes, the dir pin is the interesting part
<electronic_eel>
there is R10, a 1K pulldown on the dir line
<whitequark>
I wasn't thinking about enabling pullups on DIR pin
<electronic_eel>
ok
<whitequark>
is there any case where it's useful?
<electronic_eel>
selftest
<whitequark>
shorts?
<electronic_eel>
yeah, but for the sync it is hard, because we have nothing else internally that can read the status back
<electronic_eel>
for the regular pins we have the pullup/pulldown-i2c-expanders
<whitequark>
the problem with pullups on OE pins is that currently that won't do anything
<electronic_eel>
but the test jig board has a line for sync
<whitequark>
because their direction is strictly output
<electronic_eel>
hmm, there is no currently no gateware for syncing to another glasgow?
<whitequark>
nop
<whitequark>
and i don't even really know how to do it reliably
<electronic_eel>
I thought I remember you posting something with 2 glasgows or something?
<whitequark>
i don't think so
<electronic_eel>
or do I misremeber?
<electronic_eel>
maybe some dirty hack
<whitequark>
hm
<whitequark>
i don't remember making one, but then my memory is pretty holey
<electronic_eel>
for testing purposes we'd just need a simple input, I think that shouldn't be too hard
balrog has joined #glasgow
balrog has quit [Ping timeout: 246 seconds]
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JfPhj
<whitequark>
okay, now selftest always fails with:
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JfPjB
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark da6aa8a - README: remove forum link.
<electronic_eel>
spring cleaning ;)
<d1b2>
<esden> I don't know when the the forum got created.
<d1b2>
<esden> It really depends on the user type which tool they prefer to get support through.
<d1b2>
<esden> but having discord for icebreaker indeed makes the forum very sparsely frequented
<whitequark>
the main problem with the current forum script is that it doesn't email me on a new topic and can't be made to
<whitequark>
and... i would prefer people to go to github issues over fussing with a different script
<d1b2>
<esden> discourse forum that I installed works very well from notification and ease of administration perspective
<whitequark>
i absolutely am not going to maintain a discourse installation
<d1b2>
<esden> I am actually thinking of expanding it to be an overarching forum for 1bitsquared products/projects in general
<whitequark>
i took one look at the requirements and it's an IT nightmare
<whitequark>
i guess we could use 1b2's discourse instance
<electronic_eel>
that would be another idea, if there is really demand for it
<d1b2>
<esden> right I just installed their docker thing... and it "maintains itself"
<d1b2>
<esden> I just need to press the "update button" from time to time 🙂
<electronic_eel>
hmm, I have my doubts about this kind of maintaining
<d1b2>
<esden> @whitequark sure you are welcome to use my instance...
<whitequark>
let's say i'm not very happy about it either
<ktemkin>
there are some uniquely wonderful things about forums, too -- where else can you find a google result of yourself asking the same question five years earlier?
<d1b2>
<esden> I need to move the icebreaker forum and expand it
<whitequark>
but as long as the forum is someone else's problem i'm ok having it
<d1b2>
<esden> it feels wasteful to use the forum just for one project somehow
<whitequark>
ktemkin: ha!
<d1b2>
<esden> there is not enough traffic to justify multiple forums
<d1b2>
<esden> @Kate Temkin hahaha! 😄
<d1b2>
<esden> INDEED....
<whitequark>
i'm somewhat surprised how well the discord bridge works
<whitequark>
but that's all good; i think i'm a lost cause in that i can't reliably stay logged into discord
<ktemkin>
esden: you stole qyriad's setup, right?
<electronic_eel>
@esden does atting highlight my message in your discord?
<d1b2>
<esden> @Kate Temkin I even asked @Qyriad for advise and she gave me lot's of good scripts and pointers. 😄
<ktemkin>
if so, if you want, I can just ask her to put your discord bridges on our server
<d1b2>
<esden> eloctronic_eel it does ... but because you don't have an account here @ ing you is bit annoying. 😄
<whitequark>
yeah, not having tab-completion is the most annoying part of the bridge
<whitequark>
and it's not that annoying
<whitequark>
matrix does work better in this aspect
<ktemkin>
there was a nicer-looking project I considered when looking at bridges originally
<d1b2>
<esden> @Kate Temkin I almost asked @Qyriad but I fealt that it would be rude to put additional admin burden on her. ... right <@!199166349715570688> ? it would be rude ... 😄
<ktemkin>
it ran an IRC _server_ for the discord instead of a bridge
<whitequark>
"... right <@!199166349715570688> ?" heh
<electronic_eel>
matrix works quite nicely, we are using it at work. but I have some usability grief with the riot webclient.
<whitequark>
wait, let me see how it actually works discord-side
<d1b2>
<Qyriad> @esden if you already have the configuration…configured, then it's almost no work at all
<d1b2>
<Kate Temkin> I think the configuration is the same as ours
<d1b2>
<Qyriad> Well, just about
<d1b2>
<Qyriad> Well, just about
<d1b2>
<esden> @Qyriad that is true. But setting it up just took about a day of cussing, so not that bad. I decided to put it on it's own linode server. So in the future I can put other bridge like things on there too.
<d1b2>
<esden> I did not want to contaminate my dedicated rented server with the node stuff...
<d1b2>
<TiltMeSenpai> probably want single quotes around that url, there's exclamation points in it. Thanks for the download link though
simukis__ has quit [Quit: No Ping reply in 180 seconds.]
simukis_ has joined #glasgow
simukis_ has quit [Quit: No Ping reply in 180 seconds.]
simukis_ has joined #glasgow
<d1b2>
<esden> @whitequark I am downloading it and will put a mirror on my server.
simukis_ has quit [Quit: No Ping reply in 180 seconds.]
simukis_ has joined #glasgow
<whitequark>
cool!
<d1b2>
<esden> 55% ... wish me luck that it managed to download all 12.51GB
<Ultrasauce>
well that's making chromium unhappy in all sorts of interesting ways. thanks for sharing
balrog has quit [Ping timeout: 256 seconds]
<d1b2>
<TiltMeSenpai> yeah I think the webapp tries to jam the entire file in ram when you download something
<d1b2>
<esden> It is 100% ridiculous....
<d1b2>
<esden> I am at 70% 🤞
<d1b2>
<esden> they are trying hard to make you install their desktop client I guess?
<d1b2>
<gimbas> yep, they do be like that
<hl>
I don't recommend trying to download large files using their web client, I've had OOMs from trying that (maybe it works better in chrome though), use megadl
balrog has joined #glasgow
<d1b2>
<TiltMeSenpai> oh hi it's done
<sorear>
a few years ago I don't think there was a web JS api to stream data other than browser-managed downloads directly to disk