<agg>
40MHz is definitely way too low, even this LFE5U-45F-6 is >100MHz
<agg>
I bet the 5g part having faster brams is just the 5g part running at 1v2 instead of 1v1
<agg>
(not an educated opinion, just a guess)
<Degi>
I wanna try out in the future, if the non 5G parts can do that too if powered at 1.2 V... Or if it goes even faster at 1.3 V. Also I wonder what the actual IO speed is, I didn't go above 800 MHz because that's about the limit of the PLL but I wonder if it goes a bit higher.
<lkcl>
agg, ah thank you. appreciated pointing that out. could be
<agg>
I think they might just be the same die, but binned to meet timing and run at a higher voltage
<d1b2>
<dub_dub_11> (and apparently later in a product lifecycle, "binned to meet timing" can mean "binned to meet market demand" so the cheaper parts are identical anyway 😄 )
<d1b2>
<dub_dub_11> it's just if the manufacturer tests it
<Degi>
Yes, somebody else told me that too, that the -6, -7 and -8 might be identical and maaaybe even between different models the die might be the same (though that's a big maybe)
<agg>
I'm pretty sure the LFE5U parts are the same as LFE5UM, with the SERDES bonded out even
<agg>
just no guarantee they work
<Degi>
Gotta try that out...
<agg>
yea
<agg>
I mean I'm buying LFE5UM parts and soldering them to boards designed for LFE5U with all the serdes pins grounded because I don't need them but all the non-serdes are out of stock
<agg>
i'm trying to synth a quick 6-speed design in diamond but it keeps optimising out my bram x_x
<Degi>
Oh, I posted
<Degi>
<Degi> Maybe its true and they have good yield on UM parts and produce less U ones?
<Degi>
<Degi> (As in most of the produced SERDES's work)
<Degi>
<Degi> Oh, really?
<Degi>
afterwards, my ZNC was offline for a sec sry
<agg>
ah
<Degi>
Hm, even if you add large amounts of RAM?
<agg>
I think it's just The Situation
<agg>
and so I can't buy the U parts but normally could
<agg>
I think the problem was it saw through my foolish initialisation for a rom and removed it
<agg>
adding a fake write port did it
<Degi>
Neat
<agg>
ok, it reckons 375MHz for IO -> register -> BRAM -> register -> IO
<agg>
(16x1024 BRAM)
<Degi>
Neat
<Degi>
What does it say for -5G?
<agg>
nextpnr says 145MHz though so
<Degi>
Interesting
<agg>
this platform i have for quick testing has io pads from the 256 package and there are no 5G parts in that package, boo
<Degi>
Oh, does it have no SERDES?
<agg>
the BG256 package has no SERDES pins, only available with U parts
<Degi>
Yeah, that'd explain the lack of -5G
<agg>
I can change the speed to 8 instead of 6 though, let's see what difference that makes
<agg>
still 375MHz is pretty quick, wonder why it's like 2x nextpnr's
<agg>
(I know npnr's is deliberately quite conservative and maybe the bram timing isn't as fine-tuned?)
<Degi>
Hm, maybe diamond had an update or NextPnR is pretty conservative?
<agg>
395MHz for -8
<agg>
(192MHz for npnr on -8)
<Degi>
Oh
<Degi>
It'd be nice if it was a bit less conservative...
<Degi>
But yeah that explains why the 20 bit counter kinda worked most of the way at 800 Mhz despite NextPnR having like less than half that as a result
<agg>
I'd much rather it be conservative than optimistic, lol
<agg>
I dunno what settings diamond is being given by nmigen either, the speed will depend on the temperature grade (commercial/industrial) and the operating temperature you tell it to consider
<Degi>
Oh, it even considers the temperature...
<Degi>
How about clock jitter and voltage ripple? xD
<agg>
checking the diamond log, this was indeed told commercial, which I believe will get better numbers than industrial
<Degi>
Now which settings was it fuzzed with...
<_whitenotifier-3>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JONCz