<galibert[m]>
I managed to get data last night. Something is clear, glasgow is quite cool, and adding the streams was Very Good
<galibert[m]>
it essentially just worked once I stopped doing stupid things (like thinking Cat was lsb-first)
<whitequark[cis]>
very nice
<galibert[m]>
It probably could be crankier in places, like having "You didn't define voltages, kiss your inputs goodbye" rather than just "I couldn't setup the pulls" :-)
<galibert[m]>
applet v2 is really nce when you want to do "bench-specific" applets where you just want to do glasgow run <mumble> and where having ports or voltages on the command line is not helpful
<whitequark[cis]>
amaranth has no idea about complex high-level concepts like "dynamically adjustable port voltage"
<whitequark[cis]>
this is entirely down to glasgow since glasgow is what controls all of the stuff you can do in amaranth code (in particular relating to pins)
<galibert[m]>
I was thing more about "ok, elaboration is done, now give me the list of all io.Buffer"
<galibert[m]>
s/thing/thinking/
<whitequark[cis]>
that is not how this feature should be approached
<galibert[m]>
Ah?
<whitequark[cis]>
you shouldn't be inspecting the netlist to reconstruct information you already had, without ever storing it anywhere
<galibert[m]>
Being able to write ports = assembly.add_port_group(clk="A5", lr="A4", data="A3") is really, really nice
<whitequark[cis]>
just put the pin name in a list.
<whitequark[cis]>
assembly currently doesn't put every used pin in a list. it should do that. it involves zero netlist introspection and one list.append
<whitequark[cis]>
re: applet v2 / being able to use fixed pin names: yup, it was designed with the idea of enabling this exact workflow in mind (among others)
<galibert[m]>
I would have thought knowing the buffer type/mode associated with the pin was useful?
<galibert[m]>
assembly doesn't see the m.submodules.clk_buffer = clkb = io.Buffer("i", self._ports.clk)
<galibert[m]>
Oh, I don't think the frequency of sync is documented anywhere? It feels like 25MHz, but I;m not certain
<whitequark[cis]>
that still requires no netlist introspection (by design), because all buffer instantiations go through platform.get_io_buffer, which glasgow already overrides to transparently add OE control
<galibert[m]>
Ah nice
<galibert[m]>
Didn't know there was that useful hook
<whitequark[cis]>
it looks like we've left it undocumented
<whitequark[cis]>
that is a mistake
<whitequark[cis]>
re: sync, it varies from revision to revision so you shouldn't rely on it
<whitequark[cis]>
assembly.sys_clk_period gives you the period
<whitequark[cis]>
revA/B use 30 MHz, revC uses 48 MHz
<galibert[m]>
Yeah, I just wanted to know if it was enough to handle the 5Mhz I-don't-believe-it's-not-i2s clock as a signal or if I needed to have two clock sides and cdc
<whitequark[cis]>
but I am leaving option open to add a way to use a PLL with any unsuspecting applet
<whitequark[cis]>
* but I am leaving the option open to add a way to use a PLL with any unsuspecting applet
<galibert[m]>
48? I severely miscounter then
<galibert[m]>
s/miscounter/miscounted/
<whitequark[cis]>
yeah that would seem the case
<whitequark[cis]>
25 is not something that the FX2 can possibly generate
<galibert[m]>
I probably measured half the frequency, I mean I did it with a stopwatch and a blinking led
<whitequark[cis]>
do you... not have an oscilloscope?
<galibert[m]>
I wouldn't have known where to put it
<galibert[m]>
Also, no, I have a LA that can pretend to be a scope (a saleae)
<whitequark[cis]>
e.g. the testpoint labelled "CLKREF"
<whitequark[cis]>
or just the LED (since you know the division factor)
<whitequark[cis]>
surely the saleae can measure 1 Hz signals :D
<galibert[m]>
I keep my glasgow closed, and also I was thinking you had a pll anyway. External and internal clocks in fpga are barely connected
<whitequark[cis]>
i avoid using PLLs since there are only two in an ice40 device (sometimes 1 or 0 but this one has 2) and so using them means an applet cannot use it for its own reasons
<galibert[m]>
Ah, I didn't know it was such a rare resource
<whitequark[cis]>
they also come with weird placement restrictions i don't entirely recall
<whitequark[cis]>
basically the output of a PLL is fed through an input buffer for some random pin
<whitequark[cis]>
if you use a PLL you can't use that pin as an input
<galibert[m]>
that's special
<whitequark[cis]>
I know right
<whitequark[cis]>
I didn't expect this to be at all
<whitequark[cis]>
on revA/B this was catastrophic, on revC we adjusted the pin assignment so you aren't actually losing pins
<galibert[m]>
in any case, 48MHz is good. It means handling the clk as a data signal through a pair of f/f and schmitt-triggering it into an enable is perfectly sane
<galibert[m]>
which translates into m.d.sync += [clk1.eq( clkb.i), clk2.eq (clk1)] ; m.d.comb += clkp.eq(clk2 & ~clk1)
<galibert[m]>
Rather easy
<whitequark[cis]>
probably want one more FF stage to avoid metastability issues
<galibert[m]>
ok, I'll add one
<galibert[m]>
In summary, congrats with the current state of Glasgow, it's very nice
<whitequark[cis]>
thank you
<whitequark[cis]>
i solved something like half of the major design issues, i think
<galibert[m]>
That's rather good
<galibert[m]>
I could use your recommendation. The glasgow part allows be to record the audio the synth produces as digital. So what I want to do is a python script that starts the recording, sends some midi frames to trigger sound generation, wait a little, send some more stuff to stop the audio, then stop the recording. Is there a sane way to do that or should I just run glasgow in a subprocess?
<whitequark[cis]>
this is a tangent to the conversation at hand, but i quite dislike the use of the term "sane" to mean "good" or "correct". all it does is to reinforce the stigma on mental health on a day to day basis. anyway. back to the topic
<whitequark[cis]>
how do you send midi frames?
<whitequark[cis]>
if it's the linux midi api, you can probably use that from python directly, like from your applet
<galibert[m]>
Using mido
<whitequark[cis]>
mido?
<whitequark[cis]>
oh it's a python library, i see
<galibert[m]>
yeah
<whitequark[cis]>
i'd use the library from the applet
<whitequark[cis]>
(also, unless you actually block, you don't have to care about the async stuff; it's only when a call takes more than a few milliseconds that you have to think about it)
<galibert[m]>
I have a number of time.sleep() in the midi side because the midi interface has no rate control and the mu can't handle more than one packet at a time
<whitequark[cis]>
await asyncio.sleep(seconds)
<galibert[m]>
that sounds useful
<whitequark[cis]>
async programming and asyncio can be very finicky but it sounds like you don't need much of it here
<galibert[m]>
I hope mido won't mess things up there
<galibert[m]>
Dunno how it looks inside
<whitequark[cis]>
if the calls return more or less instantly, it's going to be fine
<whitequark[cis]>
if they do, use run_in_executor (but beware thread safety issues)
redstarcomrade has quit [Read error: Connection reset by peer]
napstx[m] has joined #glasgow
<napstx[m]>
Hello, I recenetly bought a Glasgow Interface Explorer and I need some help getting it to do what I need. I effectivly need the ability to controll to applets from the same script. I will put some psudocode of what I would like do to below:
<whitequark[cis]>
oh, sorry, there were two messages
<napstx[m]>
Sorry, send my message before I finished so edited it
<whitequark[cis]>
ok, so right now the script mode does not work combined with multi-applet support, it's a work in progress
<whitequark[cis]>
i'm not able to right now, but i'll give you a code example in a few hours that shows how to do what you want by instantiating the applets directl
<whitequark[cis]>
s/directl/directly/
<whitequark[cis]>
feel free to remind me if i forgey
<whitequark[cis]>
s/forgey/forget/
<napstx[m]>
Thank you so much, I will await your reply
<whitequark[cis]>
in short, you can use the Assembly API to instantiate applet interfaces in any Python script. this would actually serve as a good example we should add
Foxyloxy_ has joined #glasgow
coderobe9 has joined #glasgow
ali_as2 has joined #glasgow
dos1 has joined #glasgow
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
jfsimon has quit [Max SendQ exceeded]
ali_as has quit [*.net *.split]
coderobe has quit [*.net *.split]
dos has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
coderobe9 is now known as coderobe
ali_as2 is now known as ali_as
dos1 is now known as dos
jfsimon has joined #glasgow
jfsimon has quit [Quit: Leaving]
jfsimon has joined #glasgow
naruitech_36862[ has joined #glasgow
<naruitech_36862[>
Could someone kindly provide me the package "usbtransport", which I could find in my clone folder with the latest version? Really appreciate it!
<whitequark[cis]>
"usbtransport" has never been a part of Glasgow software as far as I know
<whitequark[cis]>
where are you getting these package names?
<itsmk>
A coworker tried to use it for some Jira task: "It's like it's using some old version!"
<whitequark[cis]>
it's not even "plausible but wrong", it's straight up "completely wrong" but if you know nothing about glasgow you might be excused for thinking the result is in some way legitimate
<whitequark[cis]>
reading and internalizing any of that output has the effect of poisoning what you do know about glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
owoday[m]1 has quit [Quit: Idle timeout reached: 172800s]