clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
lansiir is now known as oldtopman
Stary has quit [Ping timeout: 240 seconds]
Degi has quit [Ping timeout: 264 seconds]
az0re has quit [Quit: Leaving]
Xark has quit [Ping timeout: 265 seconds]
_whitelogger has joined #yosys
az0re has quit [Ping timeout: 240 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
_whitelogger has joined #yosys
az0re has joined #yosys
elGamal has quit [Ping timeout: 256 seconds]
elGamal has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
jakobwenzel1 has joined #yosys
daniellimws has joined #yosys
jakobwenzel1 has quit [Remote host closed the connection]
jakobwenzel1 has joined #yosys
<corecode> how do you cast constants to a specific width? like assign foo = WIDTH'(4);
<whitequark> in verilog or SV?
<ravenexp> I use "localparam [WIDTH-1:0] a = 4;"
<corecode> in open source yosys
<tnt> 4'd4
<tnt> oh wait, nm
<tnt> I think I just do assign foo = 4;
<corecode> ok, the example might be not so useful
<corecode> say assign foo = {some_val, WIDTH'(0)};
<corecode> meh, 0 is also not so good, because you could use a repeat
<corecode> i hope you understand what i mean
daniellimws has left #yosys ["Leaving..."]
<tnt> is some_val a signal ?
<corecode> yea
<corecode> but it's about constants that need to be sized to a param width
<tnt> that just doesn't exist
<tnt> so you need to work around it ...
<corecode> :)
<corecode> okay
<corecode> it's a sv thing
<corecode> but yea
<tnt> Is it even in SV ?
<corecode> i was asked in another channel
<corecode> allegedly
<corecode> icarus suppors it
<tnt> Ah yeah indeed. But yosys definitely doesn't even with the -sv switch. I didn't know that.
<tnt> For the case you posted above I usually work around it by assigning parts of 'foo' independently. Like assign foo[WIDTH-1:0] = 1234; assign foo[TOTAL_WIDTH-1:WIDTH] = some_val;
<corecode> yea the sv bnf shows that a ' cast can be a simple_type, which in turn can be a ps_parameter_identifier
<tnt> I find that using SV features is hit and miss :/ I really only like to use what works in all of yosys/iverilog/verilator ... that means basically not much.
<corecode> yea
<corecode> thanks
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
peeps[zen] has joined #yosys
peepsalot has quit [Ping timeout: 264 seconds]
peepsalot has joined #yosys
peeps[zen] has quit [Ping timeout: 240 seconds]
klotz has joined #yosys
Stary has quit [Read error: Connection reset by peer]
futarisIRCcloud has joined #yosys
Stary has joined #yosys
<daveshah> mwk: can you mark IOBUFDS IOB as `(* iopad_external_pin *)`? I don't have ISE set up so can't rerun cells_xtra.py and don't want stuff to get out of sync if I manually change
Stary has quit [Ping timeout: 246 seconds]
citypw has quit [Ping timeout: 250 seconds]
<mwk> ... huh? I seem to recall I already merged that fix
<mwk> moment
<mwk> ahhh, that was IOBUFDSE3
<mwk> actually, I'll just merge it into master immediately
<mwk> obvious fix is obvious
<mwk> done
klotz has quit [Quit: klotz]
<daveshah> mwk: thanks
<daveshah> lambda: can you see if this fixes your litedram issue?
m4ssi has joined #yosys
<lambda> daveshah: will check
jakobwenzel1 has quit [Quit: jakobwenzel1]
Nazara has quit [Ping timeout: 265 seconds]
Nazara has joined #yosys
emeb has joined #yosys
<lambda> daveshah: nope, still getting the same error with 9b982e929. do you need the new netlist?
<daveshah> Yes please
m4ssi has quit [Remote host closed the connection]
<daveshah> lambda: the problem is that ddr3_dq and ddr3_dqs need to be inout not output
<daveshah> manually fixing it in the JSON gets past packing at least
<daveshah> of course it should fail more gracefully than it does, I will take a look when I have a moment
<daveshah> I can't get past placement as there seem to be too many PLLs
<lambda> daveshah: huh, that's gotta be a ghdlsynth bug then - they're declared inout throughout the entire design. I'll look into that
s_frit has quit [Ping timeout: 250 seconds]
<daveshah> It's also possible it's a Yosys issue in deminout
s_frit has joined #yosys
m4ssi has joined #yosys
<lambda> regarding too many PLLs: litedram uses two (though I think that might be possible to trim down to one), and my design uses another one, while xc7a35t should have 5 total, right?
<daveshah> It's possible x-ray doesn't support all of them, or didn't when I wrote the export tool
<lambda> I think nextpnr has shown both 2 and 5 in the past, might be misremembering though
s_frit has quit [Ping timeout: 256 seconds]
s_frit has joined #yosys
s_frit has quit [Ping timeout: 264 seconds]
s_frit has joined #yosys
m4ssi has quit [Remote host closed the connection]
ross_s has joined #yosys
<lambda> daveshah: the inout thing seems to be on ghdlsynth, 'write_verilog' already shows inouts as outputs.
s_frit has quit [Ping timeout: 240 seconds]
s_frit has joined #yosys
s_frit_ has joined #yosys
s_frit has quit [Ping timeout: 250 seconds]
s_frit_ has quit [Ping timeout: 250 seconds]
s_frit has joined #yosys
enigma has joined #yosys
enigma has quit [Ping timeout: 240 seconds]
s_frit has quit [Ping timeout: 264 seconds]
s_frit has joined #yosys
s_frit_ has joined #yosys
s_frit has quit [Ping timeout: 264 seconds]
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
adjtm has joined #yosys
adjtm_ has quit [Ping timeout: 246 seconds]
<tnt> ZirconiumX: maybe we should move here :p
<tnt> Quick test on my small soc shows 2000 -> 2500 LCs with flow map and seems slower as well (although there is really very few failing path)
<ZirconiumX> I said it was experimental, not better :P
<ZirconiumX> But I'll paste it here too: https://github.com/YosysHQ/yosys/issues/1792
<ZirconiumX> I'll be honest, I'm not entirely sure we have good enough debugging tools for this, but maybe we can find something
<daveshah> I think seeing how sensitive performance is to magic numbers (wire delays, box delays, etc) would be a good start
<ZirconiumX> Can nextpnr print the average routing delay for a network?
<ZirconiumX> I realise that wire delay is as much a fudge factor as anything, but we can try sensible things first
<tnt> Mmm, apparently -dffe_min_ce_use 4 is what's causing my assertion error when also using -abc9
<ZirconiumX> File a bug :P
<daveshah> ZirconiumX: I don't think it really correlates at all to the real world wire delay
<daveshah> ime something that is basically "minimum routing delay without using dedicated cascade" is roughly what it represents
<daveshah> rather than average
<daveshah> Because abc9 just adds wire delay to LUT delay, and the minimum routing delay to use a LUT is also what should be added to LUT delay
<ZirconiumX> I'm not entirely sure how you'd try to optimise this kind of thing. It seems like a probably noisy black-box function
<daveshah> Simulated annealing :p
<ZirconiumX> I suppose that would work.
<daveshah> But seriously, probably just trial and error of the few key parameters
dys has quit [Ping timeout: 250 seconds]
<daveshah> working out what actually makes a difference would be a good first step
<ZirconiumX> We'll probably want a fairly beefy benchmark for this then
<ZirconiumX> VexRiscV almost fits...
<tnt> I'm re-running my riscv vex vs picorv builds with/without abc9 ...
<ZirconiumX> picosoc it is then
<daveshah> tnt: https://github.com/YosysHQ/yosys/pull/1794 should fix the abc9+mince issue
<ZirconiumX> I forgot the sed invocation I used to extract Fmax from nextpnr output...
<tnt> daveshah: oh, wow, that was fast :)
<tnt> ZirconiumX: I have a script that does min/max/avg on a bunch of nextpnr logs.
<tnt> gimme a sec
emeb_mac has joined #yosys
<ZirconiumX> Ah, thank you!
<tnt> daveshah: that does indeed fix it btw, tx :)
<tnt> Results with abc9 actually don't look bad on that particular SoC. Nothing mind-blowingly better either.
klotz has joined #yosys
<tnt> I think some of my past results might have been due to missing '-device u'
<tnt> Huh
<tnt> ERROR: Module 'SB_SPRAM256KA' contains specify cell '$specify$2054' where DST '$dummywireforinterface\CLK' is not a module input.
<tnt> Ah yeah, I see.
<ZirconiumX> Another bug :P
<tnt> yup, submitted a PR already
<tnt> Ah, seems on my USB SoC abc9 performs quite a bit worse, from 28M to 25M average.
strongsaxophone has joined #yosys
<ZirconiumX> ...Do we know if ABC9 accepts floating-point arguments for wire delay?
<ZirconiumX> Or if they just get parsed as ints
<ZirconiumX> Looks like ints.
strongsaxophone has quit [Remote host closed the connection]
<ZirconiumX> daveshah: There's quite a lot of play in the wire delay parameter actually, it seems
<ZirconiumX> Like, 3.5MHz
klotz has quit [Quit: klotz]
jakobwenzel1 has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
jakobwenzel1 is now known as jakobwenzel
futarisIRCcloud has quit [Ping timeout: 246 seconds]
<awygle> this "mcy" thing seems pretty cool
futarisIRCcloud has joined #yosys
<ZirconiumX> Mutation Cover with Yosys
<awygle> Is that what it stands for?
<ZirconiumX> Yep
Moe_Icenowy has joined #yosys
MoeIcenowy has quit [Ping timeout: 246 seconds]
Moe_Icenowy is now known as MoeIcenowy