clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
rohitksingh_ has quit [Ping timeout: 256 seconds]
<awygle> yeah me either, all i know is everybody hates abc :p
<ZirconiumX> ...eh?
<ZirconiumX> I found something odd
<ZirconiumX> So, ABC has a bunch of unhelpfully named commands
<ZirconiumX> &if, &jf, &kf, &lf
<ZirconiumX> Which seem to do LUT mapping
<ZirconiumX> But I don't know any more than that because it doesn't have any help.
<ZirconiumX> Anyway, I took a random benchmark and tried experimenting
<ZirconiumX> (axilxbar)
<ZirconiumX> Default ABC9 is 7265 SB_LUT4s
<ZirconiumX> Hacking the ABC9 script to use &lf brings that number to 6268
<ZirconiumX> Which is a pretty major drop.
<awygle> interesting. are they equivalent results? lol
<ZirconiumX> I have enough faith in ABC to presume so
<awygle> is there a yosys benchmark collection? seems like that would be a prerequisit for your statistical analysis work
<ZirconiumX> Yes
<awygle> oh good
<ZirconiumX> But I don't currently have a framework for running it on more than one test at a time ^.^;;
<ZirconiumX> More python :P
<awygle> heh
vidbina has quit [Ping timeout: 240 seconds]
<dh73> Yosys ABC scripts are not fully optimised. You can get better results by changing the scripts or saving the previous results and do a second or more runs over those results.
<dh73> We got good results with this one
<awygle> is this what AI people mean when they talk about interpretability
<dh73> read_verilog axilxbar.v; scratchpad -copy abc9.script.flow3 abc9.script; synth[...]
<ZirconiumX> "have you tried running it again?" - the script
<dh73> :P
rohitksingh has joined #yosys
<ZirconiumX> Hmm, while &lf is much smaller, it's worse in Fmax.
<ZirconiumX> Can't have your cake and eat it too
develonepi3 has quit [Quit: Leaving]
<ZirconiumX> dh73: and it actually works, too. thanks, I hate it.
<ZirconiumX> Like, that's an average 6 MHz over the default
<ZirconiumX> And smaller.
<ZirconiumX> tnt: turns out the solution to your problems is to just keep running ABC again until it works /s
citypw has joined #yosys
emeb_mac has joined #yosys
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 256 seconds]
dh73 has quit [Ping timeout: 256 seconds]
dh73 has joined #yosys
dh73 has quit [Quit: Leaving.]
<tnt> ZirconiumX: I had tried abc2 (to run it twice) and that didn't change thing. abc9 on the ice40 is just broken.
<tnt> Now that I have added other logic (unrelated to those two signals, but using the same intermediate signals), it produces something different ... still not what I'd like and too long a path, but it's way less obvious what it's doing now.
rohitksingh has joined #yosys
strongsaxophone has joined #yosys
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
emeb_mac has quit [Quit: Leaving.]
dys has quit [Ping timeout: 265 seconds]
strongsaxophone has quit [Ping timeout: 265 seconds]
m4ssi has joined #yosys
strongsaxophone has joined #yosys
_whitelogger has joined #yosys
az0re has quit [Ping timeout: 240 seconds]
strubi has joined #yosys
tmiw has quit [Ping timeout: 265 seconds]
tmiw has joined #yosys
tux3 has quit [Read error: Connection reset by peer]
dormito has quit [Ping timeout: 265 seconds]
strongsaxophone has quit [Ping timeout: 268 seconds]
dormito has joined #yosys
rohitksingh has quit [Ping timeout: 240 seconds]
strubi has quit [Ping timeout: 268 seconds]
twnqx has joined #yosys
strongsaxophone has joined #yosys
strongsaxophone has quit [Ping timeout: 265 seconds]
strongsaxophone has joined #yosys
twnqx has quit [Ping timeout: 272 seconds]
strongsaxophone has quit [Ping timeout: 240 seconds]
dormito|2 has joined #yosys
dormito is now known as Guest89933
Guest89933 has quit [Killed (tolkien.freenode.net (Nickname regained by services))]
dormito|2 is now known as dormito
dh73 has joined #yosys
awordnot has quit [Ping timeout: 258 seconds]
awordnot has joined #yosys
awordnot has quit [Ping timeout: 268 seconds]
awordnot has joined #yosys
<tnt> Is there a way to have "default" port value if an input port is not connected ? I tried something like `assign (weak0, weak1) port_in = 0;` but yosys doesn't seem to like it.
<thardin> you mean like a pull-up?
<mwk> tnt: do you mean a top-level module port?
<mwk> if not, there's no way in yosys AFAIK
<tnt> mwk: no, internal modules.
<tnt> thardin: sort of except it's resolved at build-time, not runtime. When instanciating the module if that port is left unconnected, it takes that value instead of xxxx
Degi has joined #yosys
<Degi> I'm getting a nextpnr_ecp5::assertion_failure (from nextpnr.h_362) when I try to do something with an ECLKSYNCB
<tnt> Degi: and your treillis/database and nextpnr are all up-to-date ?
cr1901_modern has quit [Ping timeout: 258 seconds]
<Degi> Yes they seem to be, at least pacaur says that it is up to date (using the nextpnr-git and trellis-git package which directly reference the git repo)
<Degi> though I found out that CLKDIVF also causes that
<tnt> I'm not sure how https://aur.archlinux.org/packages/trellis-git/ represent reality, but the last updated date on that page is far from current, it's like 6 months old.
<Degi> Basically it contains a single file which downloads trellis from github and then compiles it, so it should be up to date
<tnt> and you did that recently ? And rebuilt nextpnr after any trellis update ?
<Degi> Hm maybe I should try that and generally updating my computer...
<daveshah> My gut feeling is that something that's supposed to be a string isn't
<tnt> ah the famous lattice numbers as string "0b1010101" thing.
<daveshah> There should be a better error but it may have been lost during the JSON format change
<daveshah> The CLKDIVF division factor is a number like "2.0" in a string iirc
<Degi> Oh
<Degi> Now it works
<Degi> Thanks!
<tnt> IS yossys supposed to trim modules (in this case SPRAM) that I instantiate manually ?!?
<daveshah> Yes, unless they are marked keep
<tnt> and what criteria does it use ? I don't see anything in the output related to that instance at all.
<daveshah> Some modules that you would not want trimmed (like WARMBOOT) are marked keep
<daveshah> If it is not marked keep as a module and has no used outputs then it is trimmed
<daveshah> Any module that "does something" even if no outputs are used should be marked keep in the library so this doesn't happen
<tnt> ok, "no output" at least that gives me a hint as to waht's wrong. Thanks !
<Degi> Hm is DLLDELD not yet implemented?
emeb has joined #yosys
<tnt> Arf :+ vs +:
cr1901_modern has joined #yosys
vidbina has joined #yosys
<tnt> Ohhh, yosys implemented a 4:1 mux in a way I had never thought of before using only 2 LUT4s in 2 layers. (instead of the "tree" structure of 2 * 2:1 + 2:1 that would use 3 LUT4s).
vidbina has quit [Read error: Connection reset by peer]
<Degi> Huh, the log says that DLLDELD exists (but 0 used) but something is giving me a "not part of the design" error
<tnt> Looks like DLLDELD isn't defined in yosys
<Degi> Hm yeah, I'll try updating it
<tnt> No, even in master it doesn't seem to be.
<tnt> where did you see that DLLDELD exists ?
<tnt> AFAICT there is no support for it in either yosys or nextpnr yet.
<daveshah> From memory DLLDELD is in Trellis but nothing else yet
<Degi> Oh
<Degi> Nextpnr says in the log that 0 DLLDELs are used, so I guess nextpnr supports it at least?
<daveshah> No it doesn't, it just picks it up from the Trellis db
<tnt> It knows it exists from the trellis database
<daveshah> I can add support for it on Friday if you need it
<Degi> Hm the reference implementation for the DDR aligned interface uses it, though I guess I could try using ddr centered, though that'd need a tx centered
<daveshah> Ah right I hadn't seen that before, I usually just use delay blocks and hope for the best
<Degi> Ah yes I guess I could do that too
<Degi> Hm how do I make a 1 ns delay block?
<tnt> DELAYG blocks
<daveshah> With a value of about 25 (its circa 40ps per tap iirc)
<tnt> Degi: note that depending on you interface, the clock signal might already be delayed compared to the data.
<tnt> It takes more time for the clock to go from the pin through the buffer, through the cock network and to the IO FFs than for the data signals to go from the pad to the IO FFs.
<Degi> In this case it shouldn't be, but for later usage yes
<tnt> about 2ns
<Degi> Hm oh
<Degi> I couldtry if thats enough
<tnt> *clock ...
<daveshah> Unfortunately nextpnr and trellis don't have full IO timing support yet
<daveshah> This is on the TODO list but a bit of a limitation for this kind of stuff
<tnt> There is this weird zone. Between the slow interfaces where you can just use the opposite edge because they're slow enough. And there is super high speed stuff that needs runtime read training. And then there is in between where you do static io timing. That last one is definitely not ideal right now, always have to run some diamond / icecube to check.
<Degi> Hm it says that DelayG must be connected to a top level input or output, the input is connected directly to a differential pair
<tnt> for diff pair you would only use the _p signal and just specify the iostandard in the constraints.
<daveshah> Also, you mustn't have any non delayed users of the signal either
<Degi> Currently I'm doing it in nmigen so I basically have platform.add_resources([Resource("clkin", 0, DiffPairs("J_33:14", "J_33:13", dir="i"), Attrs(IO_TYPE="LVDS", DIFFRESISTOR="100"))])
X-Scale` has joined #yosys
<tnt> Err ... you'd have to check the RTIL generated by nmigen to see wtf it's doing and how to fix it.
<tnt> you might have to use dir="*"
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<tnt> sorry, dir="-"
<Degi> Oh I was using the pin somewhere else, nvm
<Degi> Cool it works
<Degi> Does the refclk for the ODDRX2F need to be double the sclk frequency?
<tnt> ECLK = 2 * SCLK
<tnt> That's a 4:1 serdes, not a simple DDR.
<Degi> Hm yes and since its routed over the edge clock, nextpnr doesn't complain about the frequency
<Degi> Huh twisted pair arduino cables seem to have some crosstalk between clock and data at 1.2 Gbits
citypw has quit [Ping timeout: 256 seconds]
tux3 has joined #yosys
rohitksingh has joined #yosys
<daveshah> Interestingly, this semi-internal document suggests regular ddr modes have a higher max frequency in practice than x4
<daveshah> p27
<daveshah> Regular DDR worked on 100% of devices at 1300Mbps
<daveshah> (spec 800Mbps)
<daveshah> The 4:1 had 50% of devices failing at 1000Mbps
<Degi> Hm yes DDR over arduino jumper wires seems to sporadically work at 1500 Mbps
<Degi> Oh wtf I selected the wrong pins and wondered why it wasnt working. Apparently 720 Mbps works sporadically wirelessly
<daveshah> lol
awordnot has quit [Read error: Connection reset by peer]
phire has quit [Ping timeout: 255 seconds]
awordnot has joined #yosys
phire has joined #yosys
<ZirconiumX> Oh, hey phire
twnqx has joined #yosys
<awygle> lol hey phire. small world.
m4ssi has quit [Remote host closed the connection]
_whitelogger has joined #yosys
lambda has joined #yosys
dh73 has quit [Ping timeout: 258 seconds]
<pepijndevos> lolwat... wireless DDR?
dh73 has joined #yosys
<tnt> ac coupling
awordnot has quit [Ping timeout: 272 seconds]
awordnot has joined #yosys
rohitksingh has quit [Ping timeout: 255 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
dormito has quit [Ping timeout: 268 seconds]
dormito has joined #yosys
az0re has joined #yosys
emeb_mac has joined #yosys
dormito has quit [Ping timeout: 258 seconds]
dys has joined #yosys
Stary has quit [Ping timeout: 272 seconds]
dormito has joined #yosys
Stary has joined #yosys
az0re has quit [Ping timeout: 240 seconds]
futarisIRCcloud has quit [Read error: Connection reset by peer]
ktemkin has quit [Remote host closed the connection]
daveshah has quit [Remote host closed the connection]
ric96 has quit [Remote host closed the connection]
emeb_mac has quit [Quit: Leaving.]
ric96 has joined #yosys
ktemkin has joined #yosys
daveshah has joined #yosys
benreynwar has quit [Remote host closed the connection]
flammit has quit [Remote host closed the connection]
lukego has quit [Remote host closed the connection]
litghost has quit [Remote host closed the connection]
futarisIRCcloud has joined #yosys
benreynwar has joined #yosys
flammit has joined #yosys
lukego has joined #yosys
<corecode> tnt: now if you would do a stream about using formal, that would be great
litghost has joined #yosys
<phire> oh yeah. I've been ideling in this channel for years
_florent_ has quit [Remote host closed the connection]
sorear has quit [Remote host closed the connection]
svenn has quit [Remote host closed the connection]
_florent_ has joined #yosys
sorear has joined #yosys
svenn has joined #yosys
tecepe has quit [Remote host closed the connection]
emilazy has quit [Remote host closed the connection]
rjeli has quit [Remote host closed the connection]
mithro has quit [Remote host closed the connection]
marex-cloud has quit [Remote host closed the connection]
bubble_buster has quit [Remote host closed the connection]
tmichalak has quit [Ping timeout: 240 seconds]
bubble_buster has joined #yosys
mithro has joined #yosys
rjeli has joined #yosys
tecepe has joined #yosys
emilazy has joined #yosys
tannewt has quit [Remote host closed the connection]
esden has quit [Remote host closed the connection]
elms has quit [Remote host closed the connection]
ovf has quit [Remote host closed the connection]
esden has joined #yosys
ovf has joined #yosys
elms has joined #yosys
tannewt has joined #yosys
<tnt> corecode: you have to ask matt venn for that :) My formal knowledge is minimal at best and when I tried I kind of hit the limits of the oss version :/ (and yeah I know I can get a "hobby" license for the closed parser but that's just not the same)
m4ssi has joined #yosys
<corecode> yea
<corecode> maybe somebody can pick it up
<corecode> the cache seems small enough to be able to understand the reasons on why to test something
m4ssi has quit [Remote host closed the connection]