Sunday, 2019-02-24

*** tpb has joined #yosys00:00
corecodei guess i just found out why these fpgas are "slow"00:07
*** cr1901_modern has joined #yosys00:17
corecodeAssertion failure: switches_locked[chip_info->pip_data[pip.index].switch_index] == WireId()00:41
corecodecan't read its own asc?00:41
*** gsi__ has joined #yosys01:54
*** gsi_ has quit IRC01:57
*** emeb_mac has joined #yosys02:29
*** danieljabailey has joined #yosys02:33
*** kuldeep has quit IRC02:41
*** kuldeep has joined #yosys02:41
*** leviathanch has joined #yosys02:53
*** proteusguy has quit IRC03:13
*** citypw has quit IRC03:13
*** citypw has joined #yosys03:26
*** gsi__ is now known as gsi_03:59
*** pie__ has joined #yosys05:02
*** pie___ has quit IRC05:06
*** _whitelogger has quit IRC05:19
*** _whitelogger has joined #yosys05:21
*** FL4SHK has quit IRC06:05
*** FL4SHK has joined #yosys06:22
*** emeb_mac has quit IRC06:56
*** indy has joined #yosys07:32
*** voxadam_ has quit IRC07:35
*** voxadam_ has joined #yosys07:36
*** xerpi has joined #yosys07:59
*** dys has quit IRC08:14
*** xerpi_ has joined #yosys08:16
*** xerpi has quit IRC08:19
*** FL4SHK has quit IRC08:56
*** xerpi_ has quit IRC09:06
*** xerpi_ has joined #yosys09:06
*** FL4SHK has joined #yosys09:11
*** proteusguy has joined #yosys09:30
*** rohitksingh has joined #yosys09:35
*** rohitksingh has quit IRC09:47
*** rohitksingh has joined #yosys09:59
*** leviathanch has quit IRC10:12
*** Laksen has joined #yosys10:24
*** xerpi__ has joined #yosys10:27
*** xerpi_ has quit IRC10:29
*** kuldeep has quit IRC10:50
*** kuldeep has joined #yosys10:50
*** xerpi__ has quit IRC10:51
*** xerpi__ has joined #yosys10:52
*** proteusguy has quit IRC11:04
*** rohitksingh has quit IRC11:04
*** xerpi__ has quit IRC11:25
*** leviathanch has joined #yosys11:35
*** dys has joined #yosys11:43
*** somlo has quit IRC12:09
*** somlo has joined #yosys12:11
corecodeis there interest in supporting .*?12:49
daveshahYes, definitely12:50
corecodei'll look into that12:51
tnt.* ?13:02
corecodeassigns same-named ports to nets13:03
*** lutsabound has joined #yosys13:03
corecodeZipCPU: Warning: Driver-driver conflict for \reset between cell $procdff$565.Q and constant 1'0 in top_u4k: Resolved using constant.13:07
corecodei think your POR suggestion produces this13:07
tntcorecode: is the code somewhere ?13:10
tntcorecode: and wrt to the assert above yeah ... nextpnr can't load the asc it writes :/13:10
lutsaboundcorecode: a negative logic reset would work13:40
lutsaboundThe ice40s can't handle nonzero initial values13:42
daveshahthey can13:50
daveshahYosys automatically wraps the offending one-initialised FFs in inverters to make it zero-initialised13:50
corecodeokay, something[tm] doesn't work14:05
corecodeso i guess it is time to simulate what icebox_vlog produces14:06
corecodewhere do i get simulation models for SB_RAM40_4K etc?14:06
tpbTitle: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at
daveshahBRAM initialisation might be worth checking14:11
daveshahthere is a test for that14:11
*** jayaura has joined #yosys14:27
jayauraHi, I tried synth for a riscv verilog file generated by SpinalHDL, but getting errors which I do not understand:
tpbTitle: yosys error - (at
jayaurathe source file is
tpbTitle: [VeriLog] VexRiscv.v SpinalHDL generated - (at
jayauraCould someone tell me whether this error is fixable ?14:34
tpbTitle: Fix WREDUCE on FF not fixing ARST_VALUE parameter. by litghost · Pull Request #824 · YosysHQ/yosys · GitHub (at
jayauradaveshah: thanks for the quick response. I'll try rebuilding14:37
jayauraoh wait, was that for me?14:37
jayauradaveshah: thanks that patch fixes the error!14:38
daveshahit was a recent regression14:38
jayauraI see!14:38
*** proteusguy has joined #yosys14:52
*** emeb has joined #yosys15:27
*** voxadam_ has quit IRC15:34
*** voxadam_ has joined #yosys15:34
*** citypw has quit IRC15:49
*** lutsabound has quit IRC15:53
*** develonepi3 has quit IRC15:53
*** rohitksingh has joined #yosys16:09
*** ouznext has joined #yosys16:19
ouznexthi. my project passed building (synthesizing) last week just file (, it was using yosys at commit e45f62b0c56717a23099425f078d1e56212aa632. Today my same code is failing to synthesize with error: "hrmcpu.v:146: ERROR: Identifier `\program0.PROGRAM' is implicitly declared and `default_nettype is set to none.". Today it's at Yosys commit  c521f4632f1c82b48a5538c832980668044e8fd9 .16:23
tpbTitle: Travis CI - Test and Deploy Your Code with Confidence (at
ouznextIs it possible there is some regression between commit e45f62b0c56717a23099425f078d1e56212aa632 and c521f4632f1c82b48a5538c832980668044e8fd9 of yosys, regarding parameters? Offending line in my code according to yosys is:, defparam program0.PROGRAM = PROGRAM;16:25
tpbTitle: hrm-cpu/hrmcpu.v at master · adumont/hrm-cpu · GitHub (at
corecodemaybe the default nettype changed16:27
corecodegood idea16:27
corecodeyou should explicitly declare all your nets16:27
daveshahBut this is a parameter not a net16:28
daveshahbisecting now16:28
*** rohitksingh has quit IRC16:29
ouznextI am using `default_nettype none , but code hasn't changed since  Feb 10. Was sinthesizing fine 7 days ago with that.16:29
corecodeoh parameter16:29
daveshahOffending commit seems to be 23148ffae14318bb34cb311eb13494e25ebf459316:30
corecodedo you already have a testing setup16:31
corecodei guess yosys compiles faster than nextprn16:31
ouznext@daveshah I can try to build yosys at the previous commit, run my tests, then build yosys at that commit and test again. I 'll come back and tell you results. Thanks16:35
daveshahThe problem commit is definitely 23148ffae14318bb34cb311eb13494e25ebf459316:36
daveshahI've created
tpbTitle: [regression] defparam failing with default_nettype none · Issue #826 · YosysHQ/yosys · GitHub (at
tntouznext: you can try the #() syntax in the mean time, it might work.16:41
ouznext@daveshah: confirmed, synthesis goes well with [email protected] (previous commit), then fails with [email protected]16:48
*** develonepi3 has joined #yosys16:50
corecodewhat do i need to do to use SB_HFOSC in a design?16:56
corecodeto simulate it16:56
corecodevlog exposes the pin16:57
*** kuldeep has quit IRC17:09
*** kuldeep has joined #yosys17:10
*** rohitksingh has joined #yosys17:16
*** rohitksingh has quit IRC17:20
corecodeis it possible that i have to tell iverilog to initialize flops?17:31
tntwell if you don't have a reset they will start as 'x'.17:49
tntyou can just assert the reset line of your core at the beginning of execution.17:49
corecodeyea, i had a bug in my POR generator17:49
*** xa0 has quit IRC17:51
*** xa0 has joined #yosys17:53
*** rohitksingh has joined #yosys18:08
corecodeso there is a difference between my top simulation and the chip top simulation18:34
tnt? Usually you have a testbench that wires things up.18:35
corecodeyes i do18:35
corecodeand after nextpnr i dump a verilog of the synthesis and simulate tis18:35
corecodemeaning that either yosys and iverilog interpret my design differently18:37
corecodeor somewhere in the yosys/nextpnr chain something changes the design18:38
tntah well, it's not too surprising, if you have anything else than '0' or '1', the post-pnr simulation will probably be different.18:40
corecodewell, most of it is X18:40
tntsome hw block also lack simulation models.18:41
corecodegiven that i assert a global reset, i'd expect at least the first instruction pointer to be asserted right18:42
corecodebut not so18:42
*** ouznext has quit IRC18:43
tntis the clock properly running ?18:45
corecodenow, is it a simulation error or a synthesis error, or my code error18:53
corecodewell the design is doing something18:57
corecodesome LEDs are on18:57
corecodebut they don't toggle18:58
corecodeso the simulation still does something else18:58
*** maikmerten has joined #yosys18:59
tntdo you have your code somewhere ?18:59
corecodeso with a 1:20 chance the design will run correctly on the fpga19:03
corecodeso there is clearly a race condition somewhere19:03
corecodemight by my high spi speed19:03
corecodebut why doesn't it simulate?19:04
tpbTitle: forth-cpu/rtl at master · corecode/forth-cpu · GitHub (at
*** leviathanch has quit IRC19:22
*** rohitksingh has quit IRC19:28
tntcorecode: I don't have the U4k support, could you put the synth result verilog ?19:34
tpbTitle: forth-cpu-u4k_chip.v · GitHub (at
*** proteusguy has quit IRC19:46
tntyour SCK seems a bit fast compared to the clock btw.19:47
tntThe result from ip_comb is undefined, so some of the inputs must be missing resets.19:56
corecodeyes that was deliberate20:02
corecodeyea, my is ip_comb undefined20:02
corecodebecause it can run on the fpga20:04
tntWell 'x' don't exit on the fpga :p20:05
corecodemust be something about what is fetched from ram20:05
tntIt's doesn't even fetch anything from RAM.20:05
corecodehow do you know?20:06
tntWell, I looked at the simulation trace ... address is always underfined.20:07
corecodei think it's a cycle20:08
corecodeit fetches data using an undefined address20:08
corecodeand then dispatches the next instruction pointer generation based on the undefined result20:09
corecodea fix point, basically :)20:09
tntinstruction pointer is always undefined ...20:10
corecodeno, IP is defined while in reset20:10
tntbut not iaddr20:10
corecodebecause that's the address to fetch in this cycle to execute next20:11
corecodeso it is IP+120:11
corecodei did not really know how to implement this elegantly20:11
tntsome of the control signals to actually make it ip+1 are obviously not reset properly.20:13
corecodei have the feeling i should add some pipelining - the core is a bit too slow for my liking20:13
corecodetnt: yea, they come from RAM20:13
corecodei guess the question is, what do i execute in the first cycle after reset, when there is no instruction word fetched yet20:14
*** kuldeep has quit IRC20:14
*** kuldeep has joined #yosys20:15
*** lutsabound has joined #yosys20:15
tntcorecode: well, the RAM wouldn't be in reset so it should fetch the first instruction if your logic ensured that iaddr == IP if reset is asserted.20:24
corecodethe problem is that i am fetching from ip_result20:25
tntyou could combinatorially force iaddr to 0 during reset.20:26
corecodein ip_comb?20:26
tntfor instance20:27
corecodeso why don't i get this problem when i simulate the design, not the synthesis result20:28
tntnot sure ... but the 'x' won't behave the same in the original verilog and in the synth result just because the order of operation isn't preserved.20:31
corecodei tried to avoid another LUT in the imem fetch path20:32
corecodebut okay20:32
corecodelet's keep this for now20:32
corecodethat fixed it20:34
tntThe reset process and initial pipeline fill is tricky ... I also had trouble with it when I first made my cpu.20:34
corecodehow did you solve it?20:34
tntBy adding resets on every FF that influence the fetch address.20:35
tntbut I don't have any direct combinatorial dependency between the RAM output and the next address because I have a pipeline.20:37
tntThe downside of the pipeline is the added jump latency of course.20:37
tntWhat's the fmax on the U4k btw ?20:40
corecodeunless you have a pre-decode, maybe?20:40
corecodeon this design?20:40
tntNo idea how the fabric is compared to the up5k.20:40
corecodesame timing as the up5k20:40
corecodesays 29MHz20:40
corecodehowever, synopsys estimated >40MHz20:41
*** kuldeep has quit IRC20:41
corecodebut the icecube2 placer is buggy20:41
corecodeand can't place my design20:41
tntOh ok. Yeah, I built it here with up5k target at 31 MHz.20:41
tntThe synopsys 'estimates' are meaningless ... I had variation up to +- 50% of synth estimate vs actual placed timing with icecube depending on the design.20:42
tntWhat's the issue with the placer ?20:42
*** kuldeep has joined #yosys20:43
corecodeRAM cpu_top.iram_iram_0_0 Illegally placed at (0,21)20:44
corecodeRAM cpu_top.cpu.cpu_execute.rstack.stack_mem_stack_mem_0_0 Illegally placed at (0,1)20:44
corecodeused logic cells: 62220:44
corecodePacking failed due to placement violation!20:44
tntThat's huh .. weird.20:44
tntDid you try another target ? (like up5k or hx),20:45
corecodeso yosys can deal with localparams that are declared after they are being referenced20:45
corecodesynopsys cannot20:45
corecodeso i guess i need to make it a parameter20:45
corecodeicarus can deal with it as well20:46
*** cr1901_modern has quit IRC20:46
* sxpert is having issues with synch between modules. this thing is probably more complicated than it should20:47
* sxpert is about to throw it all out and start over20:48
corecodewhat's the problem20:48
*** cr1901_modern has joined #yosys20:49
sxpertcorecode: well, the thing is becoming a big mess of inter-acting stall flags...20:49
sxpertit's no good, period20:49
sxpertwhen it starts looking like spaghetti and timing horror, it's because it's coded the wrong way ;-)20:50
corecodeany idea why this is?20:51
sxpertstarted with the wrong bit, I guess ;)20:51
*** m4ssi has joined #yosys20:51
sxpertno problem, I'm doing this to learn, so I can start over as many times as it will take ;-)20:52
tntsxpert: heh, I feel you. Always takes me a while to figure things out ... paper helps in my case (drawing block diagram / logic diagram / timing waveforms ...)20:52
corecodeoh now synplify shits its pants20:52
corecodeconflicting driver!20:52
sxperthah !20:52
sxpertseen that before ;-)20:53
corecodebut not during compile20:53
corecodebut during map20:53
corecodethat sounds to me like some optimization side effect20:53
tnt... or you have two drivers :p  (which is valid in verilog ... and you can produce that with yosys too ... but nextpnr would complain later on)20:54
sxpertmaybe synplify checks that at compile time20:54
corecode@E:MF529 :  | Tristates on constant net GND (in view: work.top_u4k(verilog)) triggering multiple-drivers failure:20:56
corecode@E:MF531 : gpio.v(38) | Conflicting driver top.cpu_top.membus.gpio.genblk1\[7\]\.un59_pins (in view: work.top_u4k(verilog))20:56
corecodeon GND?20:56
corecodei think what happens is that it can't deal with mismatched port sizes20:57
corecodeand somehow decided to connect the unused net to gnd20:57
corecodeand now complains that gnd is being driven20:57
sxpertthere, moved everything to the attic20:58
sxperttime to start over ;)20:58
corecodeare you using CVS still? :)20:59
tntsxpert: is that your first experience with fpga btw ?20:59
sxperttnt: yeah, apart from your basic blink21:00
sxpertcorecode: god no21:00
corecodesxpert: i'm a beginner too; i noticed that heavy factoring into modules is useful21:01
corecodeyou can test them separately, you can synthesize them separately and see what the tool produces21:02
tntsxpert: you sure didn't pick something trivial :p  CPU are always a bit tricky with the control logic, and the Saturn is especially twisted architecture.21:02
sxpertthat's where the fun is ;-)21:02
sxperttnt: but I learned from my mistakes, will start from the ground up...21:04
sxperttnt: I did start by the instruction decoder, which was the wrong move21:04
corecodefirst start with the functional units21:05
tntyeah you probably want to start with the datapath ... see what needs to move where. Then figure out how to generate all the control signal to pilot that DP.21:05
sxpertalso, maybe I need to use systemverilog and not classic verilog21:05
corecodethen you can't use yosys tho21:05
tntyosys doesn't do SV though.21:05
corecodeor icarus21:05
*** Laksen has quit IRC21:05
sxperthah !21:05
sxpertnever mind ;-)21:06
corecodewhy did synplify change my reset counter to 4 bits and replaced the top 4 bits with 1s?21:06
corecodehaha what is this21:06
sxpertbecause it tried to synplify your thing and tripped on it's own socks21:07
*** m4ssi has quit IRC21:07
corecodetnt: the icecube2 placer estimates 47MHz21:12
corecodebut then of course it also fails to place21:12
corecodeso it might not be correct at all21:12
tnt:/ I'm wondering wtf is causing it to fail placement. Could you pastebin the complete logs ?21:16
corecodebut you can just try yourself21:16
tnt(but yeah, icecube often still beats yosys+nextpnr in fmax ATM)21:16
corecodehm, when i add the pcf, it says E2792: Instance pins_obuft_0 incorrectly constrained at SB_IO_OD location21:17
daveshahIn icecube you need to use an SB_IO_OD primitive to use these pins21:18
corecodebut, how?21:18
corecodein my top design then?21:19
tnt" unknown variable npins."21:20
corecodethat means i either would have to route the enable, in, out signals all the way to the top21:20
daveshahAlso beware that the ports of an SB_IO_OD primitive have no underscores unlike the normal SB_IO21:20
corecodeah yea, i had to convert this localparam to a parameter21:20
corecodeor i have to put the SB_IO_OD deep into my design21:20
corecodetnt: updated21:21
tntcorecode: huh. Placed just fine here.21:24
sxperthave been getting those, am puzzled21:25
sxpertsaturn_bus.v:27: warning: Port declaration of i_clk inherits dimensions from var/net.21:25
corecodetnt: !!! WHAT21:26
corecodewhat icecube version?21:26
tntI didn't put any constraint files for the pins or anything though.21:27
corecodeon what part21:27
tntice5lp sg4821:28
corecodeso something in my project settings failed21:30
corecodenow i made a new project and it works21:30
corecodewow, 51MHz vs 29MHz21:30
corecodethat's a huge difference21:31
corecodewell i guess pebkac lead to u4k support in icestorm and nextpnr21:31
corecodewhat could make such a significant difference?21:34
daveshahTwo biggest differences are likely carry chain optimisations and placer quality21:36
corecodei guess to decide we'd have to have nextpnr place the synplify output21:37
daveshahAdding '-relut' to synth_ice40 might improve the former, and the latter21:37
tpbTitle: [EARLY WIP] HeAP-based analytical placer by daveshah1 · Pull Request #219 · YosysHQ/nextpnr · GitHub (at
corecodeand the lattice tool place yosys output21:37
sxpertthe lattice tool looks like something escaped from the early 200021:49
corecodedaveshah: is there a way to test yosys vs nextpnr?  do the edifs work across?21:53
daveshahcorecode: no, Yosys doesn't parse EDIF and the icecube EDIF parser segfaults on Yosys EDIFs21:54
corecodeyey :/21:54
daveshahYou can export Verilog from Yosys and import to icecube, although I had some trouble with that too21:54
*** maikmerten has quit IRC22:03
corecodehm, what's the easiest way to selectively use SB_IO_OD...22:07
daveshahSounds like a case of an if/generate22:12
emebcorecode: how's  your u4k addition to icestorm going?22:35
sxperttnt: ok, put down the basics, time to go to bed ;-)22:40
tntcorecode: why the ul4k btw ?22:43
tntsxpert: o/22:43
emebtnt: as you suggested a few days ago, I tried to build the TinyFPGA BX bootloader in icecube2 - managed to get it done but it didn't meet timing @ 48MHz.22:45
emebbest I got was ~39MHz22:45
emebwas wondering if that's what you saw too?22:45
emeb(targeting a up5k device)22:45
*** dys has quit IRC22:47
tntI'm pretty sure it met timing. I might have cheated a little by using 'typical' settings instead of 'worst case' :p22:52
MoeIcenowyemeb: how about nextpnr?22:56
*** dys has joined #yosys23:02
*** chaseemory has joined #yosys23:25
corecodetnt: it's the chip i have on my board23:27
emebMoeIcenowy: what about nextpnr?23:34
emebtnt: Yep - changing the timing condition to Typ makes it pass23:37
emeb60MHz instead of 3923:37
corecodeoh wow23:37
emebgood enough for hobby work. probably not something I'd want to ship in volume.23:38
corecodewow what on best with icecube2 it shows 83MHz for my design23:40
emeblooks like the long paths in the TinyFPGA bootloader are some of the adder carry chains in the ROM address generator.23:41
emebIIRC that's all stuff that can be made to run @ 12MHz.23:42
emebI looked over the pull request where they split the design into 48MHz and 12MHz sections and it didn't look too bad. That hasn't been accepted yet though.23:43
corecodedoesn't most of the design only have to run at much lower speeds?23:44
emebthat's my understanding23:44
emebI haven't studied the design closely though.23:45
emebI'm going to knock out a PCB with the USB circuit & oscillator for a UP5k / u4k SG48 package so I can try fiddling with it.23:47
corecodei still am baffled by the difference in timing between icecube and nextpnr23:49
emebIs it due to differences in routing, or differences in the way timing is computed?23:50
corecodei don't know23:50
corecodecritical path is a different one23:50
emebdo the icestorm and icecube timing estimates agree for the same design?23:51
corecodeit has RAM out, 4 LUTs, carry chain, 3 more LUTs23:51
emeball in one async path?23:52
corecodeoh that is a good question - how do i get a timing report from a .asc or vlog output?23:52
corecodefrom clock to clock23:52
daveshahcorecode: use icetime23:52
daveshahThe timing differences are for lots of reasons23:52
corecodeso there are 7 luts and routing between them23:52
daveshahone issue is how Yosys is quite poor at optimising certain things like carries23:53
corecodei don't quite understand why some luts are 1.2 and some are 1.323:53
daveshahAnother is nextpnr not being very well tuned23:53
daveshahcorecode: different LUT inputs have different delays23:53
corecodeout of 35ns, carry is 5.823:53
corecodeso not really much23:54
daveshahThe problem is optimising around the carry chain23:54

Generated by 2.13.1 by Marius Gedminas - find it at!