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
corecodehm00: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
daveshahhttps://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/cells_sim.v14:11
tpbTitle: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at github.com)14:11
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: https://pastebin.com/P94CzGiT14:33
tpbTitle: yosys error - Pastebin.com (at pastebin.com)14:33
jayaurathe source file is https://pastebin.com/EKHZXvvc14:33
tpbTitle: [VeriLog] VexRiscv.v SpinalHDL generated - Pastebin.com (at pastebin.com)14:33
jayauraCould someone tell me whether this error is fixable ?14:34
daveshahhttps://github.com/YosysHQ/yosys/pull/82414:34
tpbTitle: Fix WREDUCE on FF not fixing ARST_VALUE parameter. by litghost · Pull Request #824 · YosysHQ/yosys · GitHub (at github.com)14:34
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
daveshah:)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 (https://travis-ci.org/adumont/hrm-cpu/builds/494525894), 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 travis-ci.org)16:23
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: https://github.com/adumont/hrm-cpu/blob/master/verilog/hrmcpu.v#L146, defparam program0.PROGRAM = PROGRAM;16:25
tpbTitle: hrm-cpu/hrmcpu.v at master · adumont/hrm-cpu · GitHub (at github.com)16:25
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
corecodepnr*16: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 https://github.com/YosysHQ/yosys/issues/82616:38
tpbTitle: [regression] defparam failing with default_nettype none · Issue #826 · YosysHQ/yosys · GitHub (at github.com)16:38
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
corecodeah16:56
corecodevlog exposes the pin16:57
corecodefair16: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
corecodeyea17: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
corecodethis*18: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
corecodeyes18: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
corecodeyes18:49
corecodenow, is it a simulation error or a synthesis error, or my code error18:53
corecode!!!18:54
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
corecodeyes19:03
corecodesec19:03
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
corecodetnt: https://github.com/corecode/forth-cpu/tree/master/rtl19:13
tpbTitle: forth-cpu/rtl at master · corecode/forth-cpu · GitHub (at github.com)19:13
*** 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
corecodesure19:35
corecodehttps://gist.github.com/f2c95fbeafc1acf33fe7424c98bb402019:36
tpbTitle: forth-cpu-u4k_chip.v · GitHub (at gist.github.com)19:36
*** 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
corecodewhy*20: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
corecodeyes20:08
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
corecodeyes20: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
corecodeyes20: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
corecodeyep20:34
corecodethat fixed it20:34
corecodethanks!20: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
corecodeyes20:39
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
tntyeah.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
corecodeokay20: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
corecodeok20:50
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
sxpertyeah20: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
sxpertyeah21: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
corecodeyea21:05
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
sxpertah21:05
*** Laksen has quit IRC21:05
sxperthah !21:05
sxpertok21: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
corecodeyes21: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
corecodeyea21:18
corecodebut, how?21:18
corecodein my top design then?21:19
corecodemeh21:19
daveshahYeah21: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
tnt2017.08.2794021:27
tntI didn't put any constraint files for the pins or anything though.21:27
corecodeon what part21:27
tntice5lp sg4821:28
tnt4k21:28
corecodehm21:30
corecodeso something in my project settings failed21:30
corecodenow i made a new project and it works21:30
corecode...21: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 https://github.com/YosysHQ/nextpnr/pull/219 the latter21:37
tpbTitle: [EARLY WIP] HeAP-based analytical placer by daveshah1 · Pull Request #219 · YosysHQ/nextpnr · GitHub (at github.com)21:37
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
emebheh22:54
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
emebzippy!23:41
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
corecodethanks23: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 irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!