cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cyrozap has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<purdeaandrei[m]>
So I'm a bit lost.
<purdeaandrei[m]>
I'm trying to write a DDR divisor=0 QSPI test, that is not sensitive to the glitchy implementation of the simulatable DDRBuffer. Initially I wanted to treat the existing SDR test as a black box, and transform it without necessarily understanding what it does. I started by implementing `glitch_resistant_posedge/negedge()`, which I would just text-replace existing negedges like this:
<purdeaandrei[m]>
I succeeded in creating that, but then I realized that it's not enough
<purdeaandrei[m]>
because the data signals can be glitchy too, and if I'm unlucky about when I'm sampling then I might sample the wrong io values.
<purdeaandrei[m]>
So next idea: same as above, plus I should sample the `io` values some time before the `sck` clock edge I'm awaiting (to maintain the previous semantics of the test)
<purdeaandrei[m]>
This turns out to be impossible, or very ugly
<purdeaandrei[m]>
When I tried to create a delayed version of the io signals, I tried ctx.changed(), in conjunction with saving the samples tagged with ctx._engine.now and when I decide now is the right time to return from my coroutine, I can look up the perfect sample to return.
<purdeaandrei[m]>
However I got this exception: ```TypeError: Object (slice (sig io__oe) 0:1) is not an Amaranth signal```
<purdeaandrei[m]>
Which is fair enough, I guess, `.sample()` normally takes expressions not signals. To be honest I'd expect amaranth to be able to handle a slice of a signal, but still the problem is my solution is not as generic as I'd like even if it was able to
<purdeaandrei[m]>
* Which is fair enough, I guess, `.sample()` normally takes expressions not signals. To be honest I'd expect amaranth to be able to handle a slice of a signal, but still the problem is my solution is not as generic as I'd like even if amaranth was able to handle slices in `.changed()`
<purdeaandrei[m]>
So now the only way I can imagine creating a delayed version of a signal is for example by waking up a testbench every picosecond
<purdeaandrei[m]>
which would be terribly inefficient
<purdeaandrei[m]>
So now I'm thinking I have only two options:
<purdeaandrei[m]>
1) rework the testbench to sample only signals
<purdeaandrei[m]>
-or- 2) change the semantics of the testbench, and sample some delay after the rising edge. This will work with the current QSPI implementation, because the controller always sends data on the falling edge, and the testbench looks at values on the rising edge. But this changes the semantics of the testcase: a different implementation that sends nibbles on the rising edge, that respects the hold time of the QSPI target would fail
<purdeaandrei[m]>
this test.
<purdeaandrei[m]>
-or- 3) change the semantics of the testbench, and sample some delay after the falling edge.
<purdeaandrei[m]>
Anyone have any other ideas?
Eli2 has quit [Ping timeout: 246 seconds]
<purdeaandrei[m]>
option 1 is impossible? how to I even get to the original sliced signal?
Eli2 has joined #glasgow
axiesmoothie[m] has joined #glasgow
<axiesmoothie[m]>
got the glasgow from 1bitsquared now aye ty
redstarcomrade has joined #glasgow
<axiesmoothie[m]>
there's no shorting risk with the case whatsoever right? shouldnt be scared of turning it on after mounting the case?
<whitequark[m]>
the case is non conductive
<axiesmoothie[m]>
there's a coating?
<whitequark[m]>
you can confirm it with a multimeter
<whitequark[m]>
yes, the black color comes from anodization
<axiesmoothie[m]>
I see, thats very neat
<whitequark[m]>
it covers the aluminium case with a layer of sapphire. it's cheap and durable
<axiesmoothie[m]>
It didnt use to be anodized when there was a blog post about shorts?
<whitequark[m]>
it did; we eventually determined it was likely not the case, though iirc Esden added some stickers for safety anyway
<axiesmoothie[m]>
Ah okay I understand
<whitequark[m]>
we take any reliability issues seriously, which is why the blog posts sometimes mention unlikely or one off observations
<whitequark[m]>
as far as I know nobody has ever destroyed their glasgow or any equipment due to issues on our end, so far at least
<whitequark[m]>
the device that I thought was shorting is still functional, I think it just had some bad solder joints or a PCB microcrack...
<axiesmoothie[m]>
When I initially got the glasgow I was messing with some city escooters but this project isnt even relevant anymore I think so I'll have to find a new one aha
<axiesmoothie[m]>
I determined that I needed a device to easily interface with any storage chip I encounter without paying for those manufacturing flashers that seem to cost thousands of dollars
<whitequark[m]>
yeah me too :3
<axiesmoothie[m]>
I understand well I'm glad I can turn it on worry-free, just wouldnt want to damage it as it's such a rare device aha
<whitequark[m]>
it should be fine in the case yeah
<whitequark[m]>
and in general it's been super resilient, you'd have to really try to damage it
<whitequark[m]>
12V on the pins would do it for example, but shorting the pins to ground and driving high will not
redstarcomrade has quit [Read error: Connection reset by peer]
SophiaNya has quit [Remote host closed the connection]
SophiaNya has joined #glasgow
dne has quit [Remote host closed the connection]
dne has joined #glasgow
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
Eli2 has quit [Quit: Ex-Chat]
<axiesmoothie[m]>
So for sure Glasgow will never be able to read UFS chips as the minimum data rate is too high correct? Thankfully from my experience as UFS is more on the expensive side it isnt used in embedded devices
<whitequark[m]>
not revC
<whitequark[m]>
revE should be able to do it, when we design and ship it (years from now)
<axiesmoothie[m]>
is that because you'll have a more beefy fpga in there?
<whitequark[m]>
yeah
Eli2 has joined #glasgow
Actually64Dragon has joined #glasgow
<tpw_rules>
oh no, it uses a mipi thing?
<whitequark[cis]>
yep
<tpw_rules>
according to wikipedia 10KHz is supported somehow, if you give up your kidney for the specs presumably (and the UFS chip implements it right)
cr1901 has quit [Remote host closed the connection]