<whitequark[cis]>
i don't like the degree of reliability i'm getting but i also have no "gold standard" to measure against because i literally have no tools which can do sustained 65 MHz SPI flash capture except for thunderscope (which i still need to update to the latest firmware..)
<whitequark[cis]>
oh, i have an idea: instead of resetting the entire SCK domain on CS# reset without synchronization between async reset and clock, i could do the following: place the shift register into a reset-less domain, use async CS# assertion as reset, synchronize deassertion to SCK, then start the bit counter at 2 instead of 0
<whitequark[cis]>
I realized that many of the issues I'm observing could be stemming from bad reset deassertion to first byte relationship, as opposed to bad reset assertion to last byte relationship; the former corrupts data much more easily
<whitequark[cis]>
oh, i think i got it to work much better! i needed an SB_GB
<whitequark[cis]>
or actually it looks like i got lucky once
<whitequark[cis]>
i think this might've been a bad idea and i should just use a PLL and a gearbox after all
<whitequark[cis]>
oh, nope. none of these things. it was just EMI
<whitequark[cis]>
okay, two conclusions
<whitequark[cis]>
first: doing it with a PLL at any respectable rate is a royal pain. for some reason nextpnr seems to place and route (specifically both) the CDC FIFO suboptimally and as a result you can't hit more than 90 MHz. this will actually be a problem for other applets without question, and I don't know to solve that, which brings me to the second point
<whitequark[cis]>
second: I think the clocked-by-SCK approach is probably fine? I can reliably get a correct bitstream read out by this ECP5 at 2.5 MHz then switching to 65 MHz, and it's about 256K of data, so not PRBS31-sized but also most issues (even rare ones) tend to show themselves at least once at this point
<whitequark[cis]>
it's probably worth looking into the idea I had with the reset synchronizer, but it doesn't seem like it would make a massive difference in practice
duskwuff[m] has quit [Quit: Idle timeout reached: 172800s]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
jn_ has joined #glasgow
jn_ has quit [Changing host]
jn_ has joined #glasgow
jn has quit [Ping timeout: 276 seconds]
GNUmoon has quit [Remote host closed the connection]
ALTracer[m] has quit [Quit: Idle timeout reached: 172800s]
<_whitenotifier-5>
[glasgow] whitequark closed pull request #750: target.hardware: bugfix, pull up/down where not set for Port B when Port A and B was set - https://github.com/GlasgowEmbedded/glasgow/pull/750
GNUmoon has quit [Remote host closed the connection]
f_|DSR has joined #glasgow
GNUmoon has joined #glasgow
_whitelogger has joined #glasgow
balrog has quit [Ping timeout: 244 seconds]
<asjackson>
for testing with v2 applets, do i use a single simulation assembly, and pass that to two separate (gpib) interfaces?
balrog has joined #glasgow
tomkeddie[m] has quit [Quit: Idle timeout reached: 172800s]
<asjackson>
with the new assembly api im not sure how to unset a pull up/down resistor, when you do assembly.use_pulls({...}), it doesn't clear the existing pulls config i think?
<whitequark[cis]>
<asjackson> "with the new assembly api im not..." <- assy.use_pulls({pin="float"}); await assy.configure_ports()
<whitequark[cis]>
re testing: yes
<asjackson>
ahh, lets see, thanks!
<asjackson>
alright i am confused and stuck about several things :'(
<asjackson>
when i try to run the simulation it says AttributeError: 'str' object has no attribute 'invert' - from simulation/assembly.py", line 172, in use_pulls
<asjackson>
and also my applet doesnt seem to work with real hardware now so ive either done something wrong, or inverting has changed (i was doing `io.Buffer("io", ~self.ports.dio`)
<whitequark[cis]>
inversion hasn't changed
<asjackson>
ok i'll crack out the logic analyzer soon to see why it's not doing stuff
<whitequark[cis]>
the simulation related error is an oversight in the glasgow framework, if you upload your current state i should be able to fix it
<asjackson>
ok i got it working with hardware again. i think i need flush now? and also i'd mixed up my pull up resistors for talk/listen
<whitequark[cis]>
yeah, you need to flush explicitly before reading
<asjackson>
also if we need to call `configure_ports` to apply the pull up config, we should probably have a way to stop it printing `I: g.hardware.assembly: port A voltage set to 5.0 V` every time :D
<whitequark[cis]>
mm probably yeah
<asjackson>
happy its working again though. converting was a bit confusing, but i think the v2 api will be much easier to get started with
<asjackson>
i think the only thing which irks me a tiny tiny bit is the use of `recv`. i'm dyslexic and it takes me longer to figure out how to spell recv than it would receive haha
<asjackson>
there's probably just as many dyslexic people who'd argue the opposite though so, hard to win that one
<whitequark[cis]>
i used send and recv because there is a very old tradition of using these names specifically in Unix
<whitequark[cis]>
but i might just go back to write/read, i'm not sure yet
<whitequark[cis]>
it's all a part of making pipes function more like sockets
<whitequark[cis]>
this should fix your simulation woes
<asjackson>
🎉
<asjackson>
thanks!
<asjackson>
i'll rebase from that to test
<asjackson>
ok yeah it seems to run, but gets stuck for some reason. maybe because talking sets the pulls one way and listening sets them back to float 🤔
<asjackson>
is it possible to define two assemblies and connect them together?
<whitequark[cis]>
so, one thing you have to keep in mind is that right now, pulls don't do anything in simulation
<whitequark[cis]>
for most applets this is immaterial
<whitequark[cis]>
i'll have to implement it, but not this very moment
<asjackson>
ahh i see
<_whitenotifier-5>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-819-3fdca6151a7952c4c6a122f4405e254a70c161bc - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
so... what i'm gathering is that in addition to spi-analyzer applet i'll need a qspi-analyzer applet
<whitequark[cis]>
okay, i think the SPI analyzer is working quite well by now
<whitequark[cis]>
i've tried using it on a 17 MHz SCK BIOS ROM and a 51 MHz SCK and both seem to read correctly
<asjackson>
until your spi-analyzer i hadn't considered that it was possible to drive the logic with an external clock, but that opens up some cool possibilities for the analyzer applet 👀
<whitequark[cis]>
it is, but it's much more difficult to design things that work well in that way
<_whitenotifier-5>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-817-d4aeab9b83623b6d799c71011038218db70f54a0 - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
in short, FPGA logic (any digital logic) has requirements for how the asynchronous signals like clock and reset can be related to other signals, and if you violate those, the result is indeterminate. could be anything. could be things that violate the laws of logic even
<whitequark[cis]>
the SPI analyzer is basically not practical to implement in any other way
<whitequark[cis]>
Jonimus: the SPI analyzer has been merged! should be totally sufficient for your needs
<asjackson>
it's probably more me not knowing python but i to get two components to talk to eachother i need to run them both at the same time... i tried `x = iface0.talk(...), await iface1.listen(...), await x` and also `asyncio.gather(...)` (the latter gave a fun error about simulation needs to be running 🤯)
<whitequark[cis]>
oh, no, this is an amaranth/glasgow-specific thing
<whitequark[cis]>
you cannot use asyncio in simulation because the simulation uses simulation-gender async functions, not asyncio-gender async functions (the gender of a function cannot be determined by merely looking at it, you have to Know)
<whitequark[cis]>
you can add parallel processes to the simulation using assembly.add_testbench
<asjackson>
like teal gender
<asjackson>
real*
<whitequark[cis]>
yes :p
<asjackson>
ah i see, ok i will try, thanks!
<whitequark[cis]>
and, naturally, you can only call other async functions of the same gender (or some higher-order functions that are genderfluid! for example, your Interface, provided you don't use asyncio in it, is compatible with both simulation-gender and asyncio-gender)
<asjackson>
that's fun
<whitequark[cis]>
but yeah, to understand what you can do in the function you pass to add_testbench, refer to Amaranth simulator docs
<whitequark[cis]>
also, if you are curious, you can look into the implementation of add_*_pipe in SimulationAssembly
<whitequark[cis]>
it's short and somewhat readable and it could help you understand how this all works
<asjackson>
i'll take a look :3
<jn_>
(in conclusion, async functions are gay)
<whitequark[cis]>
100%
<asjackson>
lol
<asjackson>
it still says runtime features can be used only while simulation is running 😭