toshywoshy has quit [Read error: Connection reset by peer]
toshywoshy has joined #yosys
FabM has joined #yosys
<Sarayan>
Lofty: But the timings for a given corner are already 8 values, (rise/fall) -> (rise/fall) (min/max), so that's best and worst case isn't it?
ZipCPU|Laptop has joined #yosys
<lofty>
Sarayan: this is #yosys not #prjmistral :P
<Sarayan>
ah fuck
<Sarayan>
sorry
micko has joined #yosys
micko has quit [Client Quit]
Sarayan has quit [Quit: ssl test]
Sarayan has joined #yosys
chipdsgr has quit [Ping timeout: 272 seconds]
adjtm has quit [Quit: Leaving]
adjtm has joined #yosys
chipdsgr has joined #yosys
adjtm_ has joined #yosys
adjtm has quit [Ping timeout: 252 seconds]
jophish has quit [Quit: issued !quit command]
joe[m]1 is now known as jophish
jophish has quit [Quit: node-irc says goodbye]
jophish has joined #yosys
jophish has quit [Client Quit]
jophish has joined #yosys
jophish has quit [Client Quit]
jophish has joined #yosys
<jophish>
If I have a n bit number, initialized to 0 but I only ever set the low m < n bits of it, should I be at all concerned about having n bit comparators floating around?
<jophish>
I'm generating this code, so it's a little tricky (in this instance) to generate a m bit int
<mwk>
sounds inefficient, but as long as the register is initialized to a defined value, it's OK
<mwk>
also yosys may or may not be able to optimize it, depending on what exactly it looks like
<mwk>
actually if we're talking about eg. a 16-bit register that only ever has bits [7:0] assigned to, yosys is guaranteed to figure this out and optimize it
nak has quit [Ping timeout: 272 seconds]
<mwk>
(there's also a sat-based optimization that could detect this even if you do set the high bits but for some reason the value is guaranteed to be 0... it's not enabled by default though)
<jophish>
Yeah, I'm not happy about it, but there would be compromises in my source if I were to bound it tightly (still working on this though)
<mwk>
*shrug* it's okay, that's what we have optimizing compilers for
<mwk>
or synthesizers
<tnt>
If that helps sometimes, instead of making the size dynamic everywhere, I just make sure the assignement is masked with a constant. Like myreg <= xxxx & mask; and this makes it pretty damn explicit to the synthesis tool what bits are used ...
<jophish>
Hmm, looks as though this value's wideness leaks elsewhere into the code...
<jophish>
yeah, that's a good idea. I can try that
<jophish>
Is there an easy way of checking that there aren't any >=64 bit values left over after synthesis (not really sure that the question itself makes sense)
<jophish>
for anyone playing along at home, here's the gnarly source ds1
<mwk>
there is also another dff-chopping pass, wreduce, which triggers when the high bits are the same (ie. sign extension)
<mwk>
but you seem to be dealing with unsigned case here?
<jophish>
Yeah, in fact there's no numeracy happening at all, just setting to 0 or some other small value
<jophish>
it'
<mwk>
oh, it's an FSM or something?
<jophish>
it's an Int at the moment, but could be anything with enough states really
<jophish>
Yeah, so each of those "wait" lines introduces a new potential state
<mwk>
okay, then it will be chopped off by opt_dff
<mwk>
but only after it goes through the mux optimization, in fine mode
<jophish>
and each cycle, the program is executed up until the current waited upon "wait", When a wait happens the next cycle is allowed to pass it
<jophish>
right
<jophish>
one other nice thing to do would be to make the state here more structured instead of just an Int. That way hopefully each mux instead of having to examine the entire integer state could perhaps only look at a small portion
<jophish>
This comes at the expense of a wider state overall probably
<mwk>
one-hot encoding?
<jophish>
Yeah, I guess that's another extreme
<mwk>
I mean, that's usually a very reasonable idea, esp. when synthesizing for FPGA
<mwk>
FFs are cheap
<jophish>
yeah for sure
<jophish>
probably best of all is for me to stop worrying about this minutia, I can worry about it when I'm instantiating a bazillion of these state machines :)
<mwk>
... wish I could say something about yosys' fsm optimizations here, but uhhh, tbh they're not exactly in the best shape
<mwk>
ah well, they *are* on my list once I'm done with the memory stuff
<jophish>
Thank you for all the hard work!
freeemint has joined #yosys
somlo has quit [Remote host closed the connection]
cr19011 has joined #yosys
cr1901 has quit [Read error: Connection reset by peer]
_whitelogger has joined #yosys
ZipCPU|lapt0p has joined #yosys
somlo has joined #yosys
ZipCPU|Laptop has quit [Ping timeout: 268 seconds]
kristianpaul has quit [Remote host closed the connection]
krispaul has joined #yosys
krispaul has quit [Client Quit]
kristianpaul has joined #yosys
Sarayan has quit [*.net *.split]
Sarayan has joined #yosys
cr19011 is now known as cr1901
Stary has quit [Changing host]
Stary has joined #yosys
nak has joined #yosys
nak has quit [Quit: Bye]
nak has joined #yosys
nak has quit [Client Quit]
nak has joined #yosys
FabM has quit [Quit: Leaving]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
<tnt>
So what's the status of quicklogic nowadays in yosys ? Is master enough ?
<tnt>
(oops, I meant to ask #symbiflow)
<mwk>
no
<mwk>
the master contains the basics; there is no multiplier inference nor BRAM inference yet
<tnt>
Heh, I don't care much about inference tbh, I'm more of an instanciation guy.
<mwk>
well then, you can try master
<mwk>
but beware that the stuff there is... well, it's the result of a single PR that was meant as a basic piece of support that would then be followed up with more features and improvements, but that didn't exactly happen
<tnt>
:/ That's unfortunate, I had hoped in 6 month the toolchain status would have been a bit more streamlined.
<mwk>
my experience with symbiflow is not of streamlining anything
<mwk>
I got a bit optimistic when the base PR was finally in mergeable state (after a year or so), but it fizzled out by now
<mwk>
there's also BRAM inference laying around in a draft PR, but it kind of got paused over the question of whether the BRAMs are, in fact, 16- or 18-bit wide, and seems to be stuck in this phase
<lofty>
mwk / tnt: I have heard nothing back from Antmicro about that, and I can't do shit until I do
<lofty>
As for multiplier inference: you've got the choice of a working patch that is unlikely to be merged, and a non-working patch that might
<mwk>
oh right, it's the one that triggers the abc9 bug?
<lofty>
Yes.
<mwk>
perfect
freeemint has quit [Ping timeout: 244 seconds]
<tnt>
lofty: as stated, inferrence is not all that useful to me. I'm much more interested by how well it manages to map logic intelligently to the rather unique structure of the S3. A few RAM and a few mult, I can deal with by hand. Instanciating every cell, that's just painful.
<lofty>
tnt: I worked pretty hard on getting ABC9 working for QuickLogic, and from the corporate benchmarks I did a pretty good job
<lofty>
But you *need* to give it a good timing estimate; that's why the flow gives a warning if you don't specify a delay target
<tnt>
(not really sure how to read that graph tbh)
<lofty>
I'll rephrase the data then
<lofty>
0% is what the old QuickLogic/Antmicro flow gives
<lofty>
The new data is the stuff I worked on, but much of the sim lib hasn't made it upstream because that's a nightmare to merge
<tnt>
ok, I'm assuming this measures delay and not fmax then ?
<lofty>
This measures area
<lofty>
Area at equal delay
<tnt>
oh, ok.
<lofty>
(you can trade off area for further performance, but...I'm not sure I'd recommend that)
<lofty>
tnt: I think there is more to extract from QuickLogic, but ABC9 is a dead end for that, I think
<tnt>
Is that work in their latest release "1.3.1" ? the way I see it right now (because I obviously need pnr step too and that seems to be even more of a mess) my only option is basically treat this as a closed source toolchain and instal their pre-built stuff.
<mwk>
the problem with abc9 is that it still thinks in terms of LUTs
<mwk>
and yeah, I agree, we need better logic mapping tools
<mwk>
(that applies to most of the targets we have, but especially so for quicklogic)
<lofty>
Fortunately I have a new job working on that "better logic mapping tool".
<lofty>
> Average 11% improvement in the area utilization
<tnt>
Is that for QL or for lut arch as well ?
<lofty>
Can you be more specific with "that"?
<mwk>
I'd assume it refers to the 11% figure you just mentioned
<tnt>
both that better logic mapping tool and the benchmark figure.
<lofty>
The benchmark figure comes from the release notes of the 1.2.0 quicklogic toolchain
<lofty>
So as far as I can tell, it probably *is* in 1.3.1, but I'd have to download it to find out.