[Ristovski] has quit [Remote host closed the connection]
[Ristovski] has joined #yosys
[Ristovski] is now known as Ristovski
strongsa1ophone has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #yosys
Degi_ is now known as Degi
oldtopman has joined #yosys
oldtopman has quit [Remote host closed the connection]
citypw has joined #yosys
emeb has quit [Quit: Leaving.]
citypw has quit [Quit: Leaving]
citypw has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
citypw_ has joined #yosys
citypw_ has quit [Remote host closed the connection]
sth0R__ has joined #yosys
citypw has quit [Client Quit]
sth0R__ has quit [Remote host closed the connection]
citypw has joined #yosys
_whitelogger has joined #yosys
_whitelogger has joined #yosys
emeb_mac has quit [Quit: Leaving.]
oldtopman has joined #yosys
_whitelogger has joined #yosys
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
turq has quit [Ping timeout: 260 seconds]
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
Cerpin has quit [Quit: leaving]
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
emeb has joined #yosys
Cerpin has joined #yosys
Cerpin has quit [Quit: leaving]
citypw has quit [Ping timeout: 240 seconds]
_whitelogger has joined #yosys
Cerpin has joined #yosys
<grazfather>
Is there a channel I could ask verilator questions, or is this best
<mwk>
there's always ##openfpga, which is somewhat bigger
<grazfather>
ty
adjtm has quit [Ping timeout: 250 seconds]
adjtm has joined #yosys
<tnt>
Is there an attribute I can put on a net to avoid yosys using DFFE for it ? And if not, would anyone mind if I added that ? :p
<mwk>
that sounds... oddly specific?
<tnt>
Well actually it comes up quite often ... that and set/reset.
<tnt>
Like ... the same function can be packed in the lut4 with no overhead but yosys goes and create an enable which (1) needs to be generated (2) creates a distinct control group that can't be packed with any other FF since control groups are shared.
<mwk>
hrm, yeah
<mwk>
I suppose it's sort of the same problem I was trying to partially solve with xilinx_dffopt
<tnt>
I can sort of work around it genrating the signal combinatorially, using (*keep*) on that and then registering the kept signal That works.
<tnt>
Now I need to find a way to make it realize that x == 15 ? x : x+1 with x bein 4 bits fits better _without_ using a carry chain.
<mwk>
for dff2dffe there is an -unmap-mince option which undoes the mapping if the control set is not common enough
<mwk>
but eh
<mwk>
it's... kind of shit in several ways
<tnt>
mwk: I know, I added the 'mince' thing :p
<mwk>
oh, heh
<tnt>
not great, but it helps
peeps[zen] has joined #yosys
peepsalot has quit [Ping timeout: 265 seconds]
<daveshah>
ZipCPU: CCU2C are the ECP5 carry chain
<ZipCPU>
Can anyone explain what CCU2 is for the ECP5, and why someone might want to turn off Yosys' support for CCU2? I'm trying to get a Yosys script up and running for the ULX3
<ZipCPU>
daveshah: You are quick! ;)
<daveshah>
any noccu2 you see will be from the bad old days before nextpnr supported them
<ZipCPU>
Why would you want to turn carry chain support off then?
<ZipCPU>
Ahh ... okay
<ZipCPU>
Is that the same with -nomux and -nodram ?
<daveshah>
There might be some micro-benchmarks where turning them off gives better performance, but I doubt many real designs would benefit from this (-abc9 would probably fix most of those anyway)
<daveshah>
Yes
<ZipCPU>
So ... I can skip those options as well then ... cool, that makes things easier
<ZipCPU>
Thanks!
<daveshah>
nomux (or its new alias nowidelut) is sometimes needed if area (or tool runtime) is more important than Fmax
<ZipCPU>
I thought wide muxes slowed down FMax ?
<daveshah>
For ECP5 wide LUTs improve Fmax
<ZipCPU>
Ok. How about the -nodram option?
<daveshah>
That will also be from the bad old days, that disables distributed RAM
<ZipCPU>
Ahh ... and here I thought it would've disabled dynamic RAM
<whitequark>
we renamed it to -nolutram because of this
<ZipCPU>
Distributed RAM is definitely something I'd want
<daveshah>
That's why it's called lutram in yosys now
<daveshah>
yes
<whitequark>
not sure where -nodram still survives
<whitequark>
I think only as a compat option? it shouldn't be mentioned anywhere
<daveshah>
I think it was kept as an alias like nomux
<ZipCPU>
It's in the "passthru" example in the ulx3s-examples repo
<daveshah>
Yeah, that's using a very old set of options
<ZipCPU>
I'm a little surprised that the NextPNR setup for the ULX3S is a --45k option. I thought the ULX3S used an 85k chip?
<ZipCPU>
Is there a factor of two somewhere in the naming conventions?
<daveshah>
There are 12k, 25k, 45k and 85k versions in existence
<daveshah>
all the ECP5 chips in that package are more or less pin compatible
<ZipCPU>
Of the ULX3S?
<daveshah>
yeah
<ZipCPU>
Hmm ... okay. How would I tell which version I had?
<daveshah>
what does the chip say
<ZirconiumX>
Read the SKU on the chip
<ZipCPU>
One moment ... let me go look
<ZirconiumX>
There'll be a 12, 25, 45 or 85 on it
<ZipCPU>
It says LFE5U-85F
<ZipCPU>
So that'd be the 85K option?
<daveshah>
Yep
<ZipCPU>
Awesome! Thanks again
<daveshah>
--85k --package CABGA381
<ZipCPU>
Ok, that's important ... I couldn't find the --package option in any of the examples I looked at so far
<daveshah>
nextpnr should default to CABGA381 without --package, but relying on that is deprecated now
<ZipCPU>
Which I suppose it probably should be
<daveshah>
Indeed
<ZipCPU>
Is there a --speed option I should be looking for as well?
<ZipCPU>
I'm not sure how I'd determine what value would be "right" for that, but my last ECP5 project uses it
<daveshah>
--speed 6
<daveshah>
It defaults to that anyway, as it is the slowest speed grade it is a fairly safe default
<ZipCPU>
Ok, the chip says 6BC381C on it, so perhaps 6 sounds like a good number
<ZipCPU>
(Not that I know if the two are related ...)
<daveshah>
yeah, all the ULX3S are speed grade 6, unfortunately
<ZipCPU>
Will I run into a problem with that?
<ZipCPU>
I suppose it'd slow me down somewhat
<daveshah>
No, but it's not as fast as it could be
fflam has joined #yosys
lambda has quit [Ping timeout: 246 seconds]
mirage335 has quit [Ping timeout: 246 seconds]
mirage335 has joined #yosys
fflam has quit [Quit: WeeChat 2.7.1]
fevv8[m] has quit [Ping timeout: 246 seconds]
fevv8[m] has joined #yosys
lambda has joined #yosys
peeps[zen] is now known as peepsalot
madushan1000[m] has quit [Ping timeout: 246 seconds]