samlittlewood has quit [Ping timeout: 272 seconds]
samlittlewood has joined #glasgow
samlittlewood has quit [Ping timeout: 252 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
samlittlewood has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
egg|anbo|egg__ has quit [Remote host closed the connection]
<d1b2>
<esden> Thanks @sorear 🙂 I just got today and yesterday the first 3 parts from Arrow. I am planning a new status update post fairly soon. I should be able to provide new info about how things are going. Still not there, but items are trickling in. 🙂
<sorear>
excited to hear that
oeuf has joined #glasgow
uovo has joined #glasgow
oeuf has quit [Ping timeout: 256 seconds]
oeuf has joined #glasgow
mal has quit [Quit: mal]
bvernoux has joined #glasgow
mal has joined #glasgow
bvernoux has quit [Quit: Leaving]
samlittlewood_ has joined #glasgow
samlittlewood has quit [Ping timeout: 265 seconds]
samlittlewood_ is now known as samlittlewood
egg|anbo|egg has joined #glasgow
samlittlewood has quit [Ping timeout: 268 seconds]
samlittlewood has joined #glasgow
<d1b2>
<Grazfather> Thank you
<d1b2>
<Grazfather> I'm looking forward to it as well
bvernoux has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
uovo has quit [Ping timeout: 256 seconds]
egg|anbo|egg has quit [Remote host closed the connection]
oeuf has quit [Ping timeout: 268 seconds]
oeuf has joined #glasgow
uovo has joined #glasgow
uovo has quit [Ping timeout: 265 seconds]
oeuf has quit [Ping timeout: 265 seconds]
rcombs has quit [Remote host closed the connection]
rcombs has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
<d1b2>
<tnt> Meh, IO timings for the clk_if as output aren't looking great ... but then again, we're also violating some timings currently. ( Previous analysis was done on UP5k data and clk_if=30 MHz, numbers are different for HX8k and clk_if=48MHz ).
oeuf has joined #glasgow
uovo has joined #glasgow
oeuf has quit [Ping timeout: 272 seconds]
uovo has quit [Ping timeout: 272 seconds]
<d1b2>
<tnt> SLRD to clock setup time: 12.7 ns and Clock to SLRD hold time: 3.7 ns ... seriously ... on a 20.83 ns period, this thing wants the data to be present and valid for a 16.4 ns window WTF.
<whitequark>
interesting
<whitequark>
maybe worth talking to Cypress support?
<d1b2>
<tnt> Not sure what I'd expect them to say ?
oeuf has joined #glasgow
uovo has joined #glasgow
<d1b2>
<tnt> Actually ... we're messing it up right now wit the internally sources clock too. I somehow completely missed the fact that signal has a huge setup time compared to the others. 18.7 ns. At 30 MHz in the up5k we had ample margins. But here now ... not really, we only offer ~ 15.5 ns of setup time, missing the target by 3 ns.
egg|anbo|egg has joined #glasgow
<whitequark>
hmm
<whitequark>
what are our options?
uovo has quit [Ping timeout: 272 seconds]
uovo has joined #glasgow
<d1b2>
<tnt> With the internally sourced if_clk ... nothing we can do really. Pretty much all timings are "fixed", the only options we have is which edge to input/output on. And neither works out. If the if_clk came in onto the other pin, we could potentially use the PLL phase shift to move things around a bit. But (1) need to make sure it doesn't screw the other side ( FX2 -> ICE40 direction ), and (2) that's a pretty major hardware change anyway to make
<d1b2>
this late .... so I wouldn't really consider that an option.
<whitequark>
hm
<whitequark>
what is the exact path of if_clk in the design you're currently looking at?
<d1b2>
<tnt> So with internally sourced if_clk (i.e. what's currently running right now): - It takes 2.6 ns for the clk to go from the pad through the SB_GB_IO and land at the clk input of the IO flip flops. ( Clock delay ) - From there, it take 2.8 ns after the clock edge at the IO FF for the actual data to show up on the pad ( Clock-to-Out ). - With a 20.83 ns period ( 48 MHz ), that means the setup time before the next if_clk edge at the pad is 15.43 ns
<d1b2>
<tnt> (This is HX8k typical timing. Best/Worst variation is actually pretty small on it, less than ~ 500 ps)
<d1b2>
<tnt> With an externally source if_clk, what I was planning is the classic thing of you output and inverted clock using DDR register so your rising edge ends up right in the middle of your data eye, giving you a half period setup time and half period hold time ( minus a tiny incertitude right in the middle transisition ). This would give ~ 10.4 ns setup time for that signal, but SLRD wants 12.7 ns.
<d1b2>
<tnt> So what I can technically do with an externally sourced if_clk is not use the main clock (that's clocking all the internal logic) to generate that signal, but instead use a phase shifted version of it.
<d1b2>
<tnt> That however screws with my plans since the whole reason I started looking into all of this is for the hyperram extension stuff and I wanted to use that PLL because of all the hyperram associated complexities and I can't use it for both.
<d1b2>
<tnt> (I mean, I also didn't mention the obvious but you can run the interface at lower clock speed ... )
<whitequark>
then we would take a severe perf hit
<d1b2>
<tnt> yes, that's why I only mentioned it for completeness-sake.
<d1b2>
<tnt> CLKOUT and IFCLK don't have a defined phase relation do they ?
<whitequark>
iirc no
<d1b2>
<tnt> blessed be whoever put CLKOUT and IFCLK on test pads.
<whitequark>
hi
egg|anbo|egg has quit [Remote host closed the connection]
uovo has quit [Ping timeout: 272 seconds]
<whitequark>
they were there since revA... waiting for this exact moment :p
uovo has joined #glasgow
<d1b2>
<tnt> So, they are in sync in practice (within what I can measure with a 4 Gsps scope).
<whitequark>
as in, 0°?
<d1b2>
<tnt> yes, they overlap on the scope.
<d1b2>
<tnt> (and before anyone asks, I did deskew between probes beforehand by probing the same signal with both probes first)
<whitequark>
good enough for me
egg|anbo|egg has joined #glasgow
bvernoux has quit [Quit: Leaving]
egg|anbo|egg has quit [Remote host closed the connection]
<d1b2>
<esden> They are both rated at 200MHz, so I would guess some of the timing is different.
<d1b2>
<zyp> yes, they default to 7 cycles of initial latency rather than 6
<d1b2>
<zyp> at least the W956 does 🙂
<d1b2>
<esden> Ok good to know. Though in this particular case I am curious how they relate to the setup and hold times that tnt is fighting with.
<d1b2>
<tnt> @esden Huh, setup & hold time we were talking about are to the FX2
<d1b2>
<esden> ahh! Ok sorry I misunderstood that.
<d1b2>
<tnt> The hyperram chips themselves require dynamic training, if you look at the "sure to be valid window" purely from a static timing, it's non-existent.
<d1b2>
<esden> Ok, got it. 🙂
<d1b2>
<tnt> @zyp You can still configure it for latency=6 thought right ? (at lower fmax)
<d1b2>
<zyp> no, I'm just saying why I haven't tried reducing it
<d1b2>
<tnt> Looks like I've actually been unintentionally overclocking them when doing tests here since I was setting the latency to 3 and running the chips at 144 MHz ...
<d1b2>
<zyp> I'm also hoping I could get it up to 200 MHz, I've had it working at 180 MHz, but the rest of the design doesn't meet timing beyond that
<d1b2>
<tnt> Heh, I'm on an ice40. I'm happy with 144 😅
<d1b2>
<tnt> I don't have fancy pll or idelay/odelay to work with.
<d1b2>
<zyp> what sort of gearing is that using?
<d1b2>
<tnt> The "control" part is running at 72 MHz.
<d1b2>
<tnt> @esden Why are you going with the 200 MHz parts btw ? wouldn't they be more expensive ?
<d1b2>
<zyp> for me they were actually cheaper than the cypress parts I had on the BOM before
<d1b2>
<esden> Yeah they are cheaper than Cypress parts, or other Winbond parts.
<d1b2>
<tnt> Oh ok.
<d1b2>
<esden> ISSI also makes hyperram parts but they are also more expensive.
<d1b2>
<tnt> I wonder if when you're stuck in 2x latency mode, does the fmax still apply.
<d1b2>
<tnt> Yeah, I just received some 256 Mbits ISSI parts 😄
<d1b2>
<tnt> You can make a 1 Gbit quad pmod with that.
<d1b2>
<esden> I did not pull a trigger on ordering the winbond parts yet, so if we find out that they have a problem that causes us to loose performance or makes things difficult we should figure it out sooner than later. 😄
<d1b2>
<esden> @tnt lol that is quite a chonker 😛
<d1b2>
<zyp> so far they've been behaving well for me
<d1b2>
<esden> @zyp glad to hear that 🙂
Tom_ has joined #glasgow
<d1b2>
<tnt> @esden Don't be in a hurry to order, this is going to take a while ...
<d1b2>
<zyp> but better order while they are still available 🙂
Tom has quit [Ping timeout: 268 seconds]
<d1b2>
<esden> @tnt do you need me to send you parts/boards?
<d1b2>
<esden> Now that we know that the circuit works in principle (we should still test the second chip but I expect it to work) I want to order the thin pcb RamPak prototypes soon.
<d1b2>
<tnt> @esden I tested both chips here, works fine.
<d1b2>
<tnt> I had some instability but ... just retested and that was due to me setting latency to 3 which is only rated to 83 MHz and running them at 144 MHz 😅 Properly setting the latency yields reliable successful memtest even with higher resistor than should be there.
<d1b2>
<tnt> But the road to getting that into a shape that's remotely upstreamable and usable as part of the framework is long and it's not a super high priority for me because I don't really need it, so I'll only work a few hours a week on that.
<d1b2>
<esden> @tnt Yeah no worries, and no rush. That means I can order the new thinner PCB prototypes. This will add some time anyways.We can then see what applications there might be for having the additional memory on board. I think the original motivation was for a framebuffer, for LED panels and other displays. I bet there are other applications too. As always I can then send some prototype hardware to the people in the community, so that we can work
<d1b2>
together on getting this capability implemented and tested. It should not be just on your shoulders... 😉