redstarcomrade has quit [Read error: Connection reset by peer]
andymandias_ has quit [Ping timeout: 248 seconds]
andymandias has joined #glasgow
<Actually64Dragon>
On the prior comment about using a 3d printer for a sort of grid array... The Saturn 2 resin printer I have can probably hit the detail levels needed, if you ever want to pursue that project, I'm game. I think the simplest approach would probably be to do 0.8mm pogo pins arrayed to the BGA and then just resin print a base to secure the chip against. There are some fun ways to try and metal coat resin prints, and I'm
<Actually64Dragon>
not opposed, but all of that would basically be to defer the problem of connection to a breakout, and for higher speed systems, introduces microwave propagation and leakage concerns.
andymandias has quit [Ping timeout: 260 seconds]
andymandias has joined #glasgow
<Actually64Dragon>
As for a quick access strategy, you might try taking a printout and tracing wires out from where you need them with a tape or glue, then ball a bit of solder on the end of each one and/or use some solder paste. If you have one of those conductive ink pens, you could also give something like that a try, as well, though not getting into unwanted pins may be hard, there, and I'd be concerned about the quality of conductor.
Actually64Dragon has quit [Ping timeout: 252 seconds]
andymandias has quit [Ping timeout: 245 seconds]
andymandias has joined #glasgow
Actually64Dragon has joined #glasgow
purdeaandrei[m] has quit [Quit: Idle timeout reached: 172800s]
Actually64Dragon has quit [Ping timeout: 264 seconds]
andymandias has quit [Ping timeout: 252 seconds]
andymandias has joined #glasgow
bvernoux has joined #glasgow
smkz has quit [Ping timeout: 276 seconds]
smkz has joined #glasgow
GNUmoon has quit [Ping timeout: 260 seconds]
GNUmoon has joined #glasgow
FFY00 has joined #glasgow
FFY00_ has quit [Read error: Connection reset by peer]
bvernoux has quit [Quit: Leaving]
tec has quit [Quit: Ping timeout (120 seconds)]
tec has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<purdeaandrei[m]>
I wonder if there's a way to just do a Simulatable DDR Buffer that won't have glitches, that doesn't realy on current Amaranth implementation that might change in the future
<purdeaandrei[m]>
maybe i can add a second clock domain, ticking at twice the speed, a few picoseconds delayed from the sync domain, and have that be a requirement for tests using DDR buffers
<vegard_e[m]>
it's based on a non-final draft of RFC 36, and was written before RFC 55 and RFC 69, so it's a bit outdated now, but maybe still useful for inspiration
<purdeaandrei[m]>
mwkmwkmwk (@_discord_729063422678794270:catircservices.org)'s xor trick seems to be working fine!
<purdeaandrei[m]>
Now I'm wondering about something else:
<purdeaandrei[m]>
Verilog has the stratified event queue, and it uses it to ensure that synchronous logic always samples a "past" value, and never samples from the future. (without it the nondeterminism of what order processes run in could cause problems)
<purdeaandrei[m]>
updates to non-blocking assignments always happen after all active events are processed
<purdeaandrei[m]>
In Amaranth for normal synthesizable logic I'm sure there is some similar mechanism, and it would be fairly easy to implement given how control domains are designed
<purdeaandrei[m]>
you see SCK has a MODE3 and a MODE0 option
<purdeaandrei[m]>
it implies that the first falling edge has no effect
<purdeaandrei[m]>
so nothing to race
<vegard_e[m]>
unless you're working with a MODE1 or MODE2 target 🙂
<purdeaandrei[m]>
I don't think we support mode1/mode2 at the moment
<purdeaandrei[m]>
see this comment from whitequark (@_discord_182174208896401419:catircservices.org)
<whitequark[m]>
I don't think the QSPI controller need to support mode1/2
<whitequark[m]>
the SPI controller, maybe
<vegard_e[m]>
does the QSPI controller even need to support mode 3?
<purdeaandrei[m]>
So my worry is: is this nondeterministic? or is there some feature in amaranth that makes .sample() deterministic in this case?
<vegard_e[m]>
anyway, if the actual hardware ignores an initial falling edge, shouldn't the testbench too?
<vegard_e[m]>
and if it does, it shouldn't matter whether it's seen before or after the cs assertion
<whitequark[m]>
I think it doesn't; it starts driving the first bit on CS# low
<whitequark[m]>
oh sorry I misunderstood
<whitequark[m]>
ignore that
<purdeaandrei[m]>
Okay so two questions then:
<purdeaandrei[m]>
1) for my own eduction: is my intuition correct that ctx.negedge(generated_clock).sample(generated_cs) is nondeterministic?
<purdeaandrei[m]>
2) should I make the testbench not depend on Mode 3?
<purdeaandrei[m]>
s/eduction/education/
<whitequark[m]>
purdeaandrei (@_discord_693328004947902465:catircservices.org) the Amaranth simulator is deterministic: given the same inputs and the same set of processes you will always get the same simulation results, even if processes run in a different order
<whitequark[m]>
if `generated_clock` and `generated_cs` change "simultaneously" then the new value will be sampled. else one of them happens before the other
<mwkmwkmwk[m]>
... wasn't it old value?
<whitequark[m]>
hm
<whitequark[m]>
yes, sorry
Wanda[cis] has quit [Quit: Idle timeout reached: 172800s]
<purdeaandrei[m]>
so one of them happens before the other does not include delta cycles, it must be a non-zero timestep ?
<purdeaandrei[m]>
* a non-zero-length timestep
<whitequark[m]>
zero length steps (delta cycles) and non-zero-length steps are treated exactly the same wrt event ordering
<whitequark[m]>
the only difference is how it's displayed, and (soon) what the current time reported to simulation is
<purdeaandrei[m]>
hmm, why does it see the old value? If I understand right both `generated_clock` and `generated_cs` are updated during the same signal-update-half of the delta cycle, then the process waiting negedge() is unblocked, wouldn't .sample() result in the new value of generated_cs?
<purdeaandrei[m]>
Or does it always store the previous values for the current delta cycle, and processes always read the previous value?
<whitequark[m]>
it's done to make it straightforwardly possible for processes to pretend to be flops
<purdeaandrei[m]>
well, for interacting with normal flops, even if the process were to see the new value, after the signal updates, it would still work okay, because the other flop's value update hasn't executed yet
<purdeaandrei[m]>
but this is the special case of the output of one flop driving the clock of another flop
<purdeaandrei[m]>
So this is a difference between VHDL and Amaranth, right?
<purdeaandrei[m]>
And I see it getting the new value:
<whitequark[m]>
so there are two things at play here
<whitequark[m]>
the first one is how Amaranth preserves determinism in a concurrent simulation, which as far as I know should match VHDL closely (although Amaranth doesn't guarantee that certain constructs introduce or do not introduce a delta cycle_)
<whitequark[m]>
s/cycle_/cycle/
<whitequark[m]>
the second one is how the simualtor interface specifically is constructed, which isn't based on VHDL or Verilog and is our original work
<whitequark[m]>
I think mwkmwkmwk (@_discord_729063422678794270:catircservices.org) should be able to tell you why we designed it the way we did
<purdeaandrei[m]>
I'm confused about what the actual implementation is supposed to do. I just tried this in amaranth:
<purdeaandrei[m]>
and in both cases the new value is sampled
<purdeaandrei[m]>
(like VHDL)
<purdeaandrei[m]>
so both the sample flipflop which is using the 'gclk' control domain
<purdeaandrei[m]>
and also the testbench that is using .posedge().sample()
<purdeaandrei[m]>
(but it seemed like the same construct in the QSPI test behaved differently?)
<purdeaandrei[m]>
rather than the why I'm still a little confused about the actual what it's supposed to do
<purdeaandrei[m]>
yepp, so in the QSPI test it does what you said, it samples the old value, but in my simplified test pastebin above it samples the new value
<purdeaandrei[m]>
I'm sure I'm missing something simple, but I don't see where the difference comes from
<vegard_e[m]>
sample captures the value at the trigger point, before any other logic or processes are allowed to act on the trigger and potentially change it
<vegard_e[m]>
but in your test case `generated_cs` is not set in response to `generated_clk`, so that doesn't apply
<vegard_e[m]>
what happens is that the DUT is triggered by the clock edge, sets both `generated_cs` and `generated_clk` high, then the testbench is triggered by the change in `generated_clk` and samples `generated_cs` that's already high