whitequark[m] changed the topic of #nmigen to: nMigen hardware description language · code https://github.com/nmigen · logs https://freenode.irclog.whitequark.org/nmigen
<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> so....
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<Degi> Was something posted in the last 4 mins?
<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
<_whitenotifier-3> [YoWASP/yosys] whitequark 55bab8e - Update dependencies.
emeb has left #nmigen [#nmigen]
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
roamingr1 has joined #nmigen
revolve has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
Bertl_oO is now known as Bertl_zZ
revolve has joined #nmigen
roamingr1 has quit [Ping timeout: 240 seconds]
Guest139081 is now known as JJJollyjim
jjeanthom has joined #nmigen
mwk has quit [Ping timeout: 260 seconds]
jjeanthom has quit [Ping timeout: 260 seconds]
chipmuenk has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
samlittlewood has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
pftbest has quit [Read error: Connection reset by peer]
pftbest_ has joined #nmigen
richbridger has joined #nmigen
mwk has joined #nmigen
Bertl_zZ is now known as Bertl
roamingr1 has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
<FL4SHK> feature request: something like a VHDL `function`
<FL4SHK> I don't have a lot of requests for nMigen btw
<FL4SHK> it's nearly perfect
<FL4SHK> any way to use GHDL's yosys plugin combined with nMigen to instantiate a VHDL entity?
<FL4SHK> because I might choose to write some modules in VHDL, some in nMigen :)
<FL4SHK> (really it'd be my extended VHDL thing)
<whitequark[m]> hm
<whitequark[m]> are you using platforms?
<FL4SHK> What is that?
<FL4SHK> I think I know what you're talking about
<whitequark[m]> nmigen platforms
<FL4SHK> Is that used by nMigen boards?
<whitequark[m]> yes
<FL4SHK> yeah, I've used it when I used nMigen boards
<whitequark[m]> because the answer to your question differs depending on whether you let nmigen drive the flow, or the other way around
<FL4SHK> so since both HDLs are Python-based
<FL4SHK> it might be possible to share some source code...
<whitequark[m]> share how?
<FL4SHK> I believe I'd drive with nMigen
<FL4SHK> well, anything like integer constants or Python lists
<whitequark[m]> oh, yeah
<FL4SHK> those could be shared
<whitequark[m]> if you drive with nmigen, you'll discover that platforms using yosys currently don't support vhdl at all
<whitequark[m]> if you synthesize with vivado or something like that, then you already have vhdl support
<FL4SHK> GHDL's yosys plugin could synth for me
<FL4SHK> I've tested it
<FL4SHK> it's apparently experimental
<FL4SHK> but I'd like to use it
<FL4SHK> I could just synth with GHDL + yosys, but instantiate the synthesized Verilog module from nMigen
<whitequark[m]> yes
<whitequark[m]> or you could add support for using GHDL with Yosys to nMigen platforms :p
<FL4SHK> I can do that
<FL4SHK> I think it'd be fun to use multiple HDLs in one project
<whitequark[m]> yeah
<whitequark[m]> there's also the RPC frontend
<FL4SHK> What is that?
<whitequark[m]> which lets you instantiate nMigen modules, even parametric, from VHDL or Verilog
<FL4SHK> ooh, even parametric
<FL4SHK> though nMigen modules' generics are generally class constructor arguments, right?
<whitequark[m]> yeah
<FL4SHK> that's the same advantage one will have with my thing
<FL4SHK> in my thing
<FL4SHK> signals are scoped to VHDL AST nodes
<FL4SHK> so you do
<FL4SHK> myarch.d.a = Signal(UnsignedR(7, 0))
<FL4SHK> probably shortened by a preceding `d = myarch.d`
<FL4SHK> such that you can do `d.a = ...`
<FL4SHK> since this is really just a way to create a VHDL AST with Python
<FL4SHK> I did decide upon `mysignal.eq()` for assignment
<FL4SHK> but since this is VHDL, I didn't know of any way to do clock domain stuff
<FL4SHK> and you still need processes
<FL4SHK> upside: it's VHDL 2008 that I support
<FL4SHK> downside: you don't get a lot of VHDL 2008 from GHDL
pftbest_ has quit [Remote host closed the connection]
<FL4SHK> upside: type generics can be done Python-side
pftbest has joined #nmigen
<FL4SHK> downside: I don't know how to allow custom lowering functions
<FL4SHK> any ideas on that last one?
<whitequark[m]> what are they?
<FL4SHK> like, let's say I want to add AST nodes locally, i.e. not part of the VHDL generator
<FL4SHK> AST node classes*
<FL4SHK> It may be necessary to add AST node classes to the VHDL generator in all cases
<FL4SHK> something like `ValueCastable` might be what I'm looking for
<FL4SHK> it might be enough to just accept pull requests
pftbest has quit [Ping timeout: 260 seconds]
pftbest has joined #nmigen
FFY00_ has quit [Read error: Connection reset by peer]
FFY00_ has joined #nmigen
bvernoux has joined #nmigen
jjeanthom has joined #nmigen
Bertl is now known as Bertl_oO
duck25 has joined #nmigen
Evidlo has quit [Ping timeout: 276 seconds]
JJJollyjim has quit [Ping timeout: 276 seconds]
emily has quit [Ping timeout: 276 seconds]
duck2 has quit [Ping timeout: 276 seconds]
Evidlo has joined #nmigen
JJJollyjim has joined #nmigen
emily has joined #nmigen
bvernoux1 has joined #nmigen
cr1901_modern1 has joined #nmigen
bvernoux has quit [Ping timeout: 252 seconds]
cr1901_modern has quit [Ping timeout: 252 seconds]
chipmuenk has quit [Quit: chipmuenk]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
jjeanthom has quit [Ping timeout: 252 seconds]
bvernoux1 has quit [Read error: Connection reset by peer]
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
lf has quit [Ping timeout: 250 seconds]
lf has joined #nmigen
Yatekii has quit [Ping timeout: 245 seconds]