clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
emeb_mac has quit [Ping timeout: 246 seconds]
togo has quit [Quit: Leaving]
gruetzkopf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
gruetzkopf has joined #yosys
_whitelogger has joined #yosys
proteusguy has quit [Ping timeout: 250 seconds]
emeb_mac has joined #yosys
PyroPeter has quit [Ping timeout: 258 seconds]
_whitelogger has joined #yosys
PyroPeter has joined #yosys
_whitelogger has joined #yosys
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 246 seconds]
_whitelogger has joined #yosys
_whitelogger has joined #yosys
_whitelogger has joined #yosys
proteusguy has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #yosys
futarisIRCcloud has joined #yosys
emeb_mac has quit [Ping timeout: 240 seconds]
gsi__ is now known as gsi_
_whitelogger has joined #yosys
<janrinze> ZipCPU: ah, right. we do have a life outside the matrix don't we ;-)
<daveshah> You can't escape the matrix
m4ssi has joined #yosys
<janrinze> :D
<janrinze> daveshah: I just noticed some commits in ABC that may be of interest to Yosys. Specificaly something got reverted. Not sure how much the impact is but i wonder what Clifford's policy is on keeping up to date with ABC.
<daveshah> janrinze: good spot
<daveshah> In general things are kept relatively up to date
<daveshah> In this case it seems to be related to the word-level stuff in ABC, which Yosys doesn't use afail
<daveshah> *afaik
<janrinze> Okay, currently Yosys is at ABC 2ddc57d. I'm building with latest commit now and will run a few tests. Probably no difference like you said.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<janrinze> forgot to add -j8 .. ah well, it will finish sometime soon.
<janrinze> Nice, the json produced is identical. So no impact at all.
<janrinze> daveshah: did we get any examples for SB_I2C and SB_SPI? I would like to try them as a substitute but try to avoid long debug sessions :D
<janrinze> daveshah: also, I probably did not google enough but is there a symbol defined to identify the FPGA we are building for? Using `ifdef to make some blocks conditional to the type of FPGA would allow me to consolidate my sources.
futarisIRCcloud has joined #yosys
<tnt> janrinze: I don't have any 'minimal example', but I have code on github using sb_spi ...
<janrinze> tnt: i'd like to take a peek at that
<tpb> Title: ice40-playground/top.v at master · smunaut/ice40-playground · GitHub (at github.com)
<tpb> Title: ice40-playground/boot.S at master · smunaut/ice40-playground · GitHub (at github.com)
<tnt> Basically it's a riscv (picorv32) with a small RAM4K boot zone that's initialized and loads the main app from flash into the larger SPRAM memory (because you can't initialize SPRAM).
<janrinze> tnt: I see you did the bidirectional pin construct same as i have. There was some talk about getting that automatically supported.
<tnt> I never trust auto-magic IO for anything else than pure input/pure output with no register. anything else I do myself.
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined #yosys
_whitelogger has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
<janrinze> tnt: have you had any luck at adding a SB_PLL to the output of SB_HFOSC? SB_PLL_CORE throws ERROR: PLL 'pllout.uut' couldn't be placed anywhere, no suitable BEL found. and SB_PLL_PAD obviously does not apply since it's not a pad.
maikmerten has joined #yosys
<tnt> janrinze: I have never tried tbh ...
<tnt> janrinze: you can try to switch the HFOSC output to be FABRIC rather than global, that might help.
<tnt> janrinze: do you have a ready made test case ?
<janrinze> tnt: not yet
<janrinze> tnt: I've got duties outside the matrix.. perhaps this evening. for now i'll use an external wire to hook up the 12 MHz.
lutsabound has joined #yosys
_whitelogger has joined #yosys
maikmerten has quit [Remote host closed the connection]
emeb has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
sxpert has quit [Ping timeout: 250 seconds]
sxpert has joined #yosys
janrinze has quit [Remote host closed the connection]
endre_ has joined #yosys
emeb has quit [Quit: Leaving.]
<endre_> Hi, I have tried out yosys and nextpnr-ecp5 for the 1st time. I haven't got any experience with ECP5. Is it normal that for a 32 bit adder the following delay is reported?: "Info: Max delay <async> -> <async>: 23.84 ns"
<endre_> Isn't it a little bit slow?
emeb_mac has joined #yosys
<daveshah> That includes delay to/from the IO pins too
<daveshah> For something with 96 pins, they will be quite spread out
<daveshah> Put the adder between two registers and see what the max frequency is, that will be more realistic
<endre_> daveshah: thanks for the tip
endre_ has quit [Quit: Page closed]
maikmerten has joined #yosys
analognoise has joined #yosys
emeb_mac has quit [Ping timeout: 250 seconds]
analognoise has quit [Read error: Connection reset by peer]
analognoise has joined #yosys
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined #yosys
janrinze has joined #yosys
rohitksingh has joined #yosys
m4ssi has quit [Remote host closed the connection]
parport0 has quit [Ping timeout: 244 seconds]
parport0 has joined #yosys
<janrinze> daveshah: is there a simple way to show usage the statistics? I see them when nextpnr runs but it would be nice to retrieve them from either an .asc or .bin
<daveshah> You can use icebox_stat
<daveshah> on the asc
lutsabound has quit [Quit: Connection closed for inactivity]
<daveshah> You can also do 'yosys -p stat design.json' if you want post-synth statistics
lutsabound has joined #yosys
<janrinze> Ah, icebox_stat has not much info on the up5k DSP etc.
<tnt> interestingly icebox_state doesn't match nextpnr output :/
<daveshah> Route throughs probably
<tnt> for RAM ?
<daveshah> No, just in general
<tnt> I meant, they differ on the number of RAM used.
<janrinze> the yosys command works. Somehow only absolute values, no info on how much it is of the available resources.
<tnt> well yeah, yosys has no idea which model you're targetting.
<daveshah> Is the RAM difference up or down?
<tnt> up, icebox_stat reports 24 used. In reality there is 18 RAM4K used (and 4 SPRAMs)
<janrinze> icebox_stat is very slow here.. The SPRAMs are not in the list and indeed it reports 6 SBRAM instead of 4 for my design.
<janrinze> tnt: both results are around 50% more for BRAM.
<daveshah> Yeah, looks like the way icebox_stat counts BRAM is broken
<daveshah> It attempts to normalise y using seg[1] - (seg[1] % 2)
<janrinze> Also amount of CARRYs is a little less than what yosys reports.
<daveshah> But actually BRAMs start at an odd y
<daveshah> icebox_stat counts used cout wires, Yosys reports number of SB_CARRY primitives
maikmerten has quit [Remote host closed the connection]
futarisIRCcloud has joined #yosys
SpaceCoaster has quit [Ping timeout: 250 seconds]
sxpert has quit [Ping timeout: 264 seconds]
sxpert has joined #yosys
danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
danieljabailey has joined #yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys