| *** tpb has joined #yosys | 00:00 | |
| corecode | i guess i just found out why these fpgas are "slow" | 00:07 |
|---|---|---|
| *** cr1901_modern has joined #yosys | 00:17 | |
| corecode | Assertion failure: switches_locked[chip_info->pip_data[pip.index].switch_index] == WireId() | 00:41 |
| corecode | hm | 00:41 |
| corecode | can't read its own asc? | 00:41 |
| *** gsi__ has joined #yosys | 01:54 | |
| *** gsi_ has quit IRC | 01:57 | |
| *** emeb_mac has joined #yosys | 02:29 | |
| *** danieljabailey has joined #yosys | 02:33 | |
| *** kuldeep has quit IRC | 02:41 | |
| *** kuldeep has joined #yosys | 02:41 | |
| *** leviathanch has joined #yosys | 02:53 | |
| *** proteusguy has quit IRC | 03:13 | |
| *** citypw has quit IRC | 03:13 | |
| *** citypw has joined #yosys | 03:26 | |
| *** gsi__ is now known as gsi_ | 03:59 | |
| *** pie__ has joined #yosys | 05:02 | |
| *** pie___ has quit IRC | 05:06 | |
| *** _whitelogger has quit IRC | 05:19 | |
| *** _whitelogger has joined #yosys | 05:21 | |
| *** FL4SHK has quit IRC | 06:05 | |
| *** FL4SHK has joined #yosys | 06:22 | |
| *** emeb_mac has quit IRC | 06:56 | |
| *** indy has joined #yosys | 07:32 | |
| *** voxadam_ has quit IRC | 07:35 | |
| *** voxadam_ has joined #yosys | 07:36 | |
| *** xerpi has joined #yosys | 07:59 | |
| *** dys has quit IRC | 08:14 | |
| *** xerpi_ has joined #yosys | 08:16 | |
| *** xerpi has quit IRC | 08:19 | |
| *** FL4SHK has quit IRC | 08:56 | |
| *** xerpi_ has quit IRC | 09:06 | |
| *** xerpi_ has joined #yosys | 09:06 | |
| *** FL4SHK has joined #yosys | 09:11 | |
| *** proteusguy has joined #yosys | 09:30 | |
| *** rohitksingh has joined #yosys | 09:35 | |
| *** rohitksingh has quit IRC | 09:47 | |
| *** rohitksingh has joined #yosys | 09:59 | |
| *** leviathanch has quit IRC | 10:12 | |
| *** Laksen has joined #yosys | 10:24 | |
| *** xerpi__ has joined #yosys | 10:27 | |
| *** xerpi_ has quit IRC | 10:29 | |
| *** kuldeep has quit IRC | 10:50 | |
| *** kuldeep has joined #yosys | 10:50 | |
| *** xerpi__ has quit IRC | 10:51 | |
| *** xerpi__ has joined #yosys | 10:52 | |
| *** proteusguy has quit IRC | 11:04 | |
| *** rohitksingh has quit IRC | 11:04 | |
| *** xerpi__ has quit IRC | 11:25 | |
| *** leviathanch has joined #yosys | 11:35 | |
| *** dys has joined #yosys | 11:43 | |
| *** somlo has quit IRC | 12:09 | |
| *** somlo has joined #yosys | 12:11 | |
| corecode | is there interest in supporting .*? | 12:49 |
| daveshah | Yes, definitely | 12:50 |
| corecode | i'll look into that | 12:51 |
| tnt | .* ? | 13:02 |
| corecode | assigns same-named ports to nets | 13:03 |
| *** lutsabound has joined #yosys | 13:03 | |
| corecode | ZipCPU: Warning: Driver-driver conflict for \reset between cell $procdff$565.Q and constant 1'0 in top_u4k: Resolved using constant. | 13:07 |
| corecode | i think your POR suggestion produces this | 13:07 |
| tnt | corecode: is the code somewhere ? | 13:10 |
| tnt | corecode: and wrt to the assert above yeah ... nextpnr can't load the asc it writes :/ | 13:10 |
| lutsabound | corecode: a negative logic reset would work | 13:40 |
| lutsabound | The ice40s can't handle nonzero initial values | 13:42 |
| daveshah | they can | 13:50 |
| daveshah | Yosys automatically wraps the offending one-initialised FFs in inverters to make it zero-initialised | 13:50 |
| corecode | okay, something[tm] doesn't work | 14:05 |
| corecode | so i guess it is time to simulate what icebox_vlog produces | 14:06 |
| corecode | where do i get simulation models for SB_RAM40_4K etc? | 14:06 |
| daveshah | https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/cells_sim.v | 14:11 |
| tpb | Title: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at github.com) | 14:11 |
| daveshah | BRAM initialisation might be worth checking | 14:11 |
| daveshah | there is a test for that | 14:11 |
| *** jayaura has joined #yosys | 14:27 | |
| jayaura | Hi, I tried synth for a riscv verilog file generated by SpinalHDL, but getting errors which I do not understand: https://pastebin.com/P94CzGiT | 14:33 |
| tpb | Title: yosys error - Pastebin.com (at pastebin.com) | 14:33 |
| jayaura | the source file is https://pastebin.com/EKHZXvvc | 14:33 |
| tpb | Title: [VeriLog] VexRiscv.v SpinalHDL generated - Pastebin.com (at pastebin.com) | 14:33 |
| jayaura | Could someone tell me whether this error is fixable ? | 14:34 |
| daveshah | https://github.com/YosysHQ/yosys/pull/824 | 14:34 |
| tpb | Title: Fix WREDUCE on FF not fixing ARST_VALUE parameter. by litghost · Pull Request #824 · YosysHQ/yosys · GitHub (at github.com) | 14:34 |
| jayaura | daveshah: thanks for the quick response. I'll try rebuilding | 14:37 |
| jayaura | oh wait, was that for me? | 14:37 |
| jayaura | daveshah: thanks that patch fixes the error! | 14:38 |
| daveshah | :) | 14:38 |
| daveshah | it was a recent regression | 14:38 |
| jayaura | I see! | 14:38 |
| *** proteusguy has joined #yosys | 14:52 | |
| *** emeb has joined #yosys | 15:27 | |
| *** voxadam_ has quit IRC | 15:34 | |
| *** voxadam_ has joined #yosys | 15:34 | |
| *** citypw has quit IRC | 15:49 | |
| *** lutsabound has quit IRC | 15:53 | |
| *** develonepi3 has quit IRC | 15:53 | |
| *** rohitksingh has joined #yosys | 16:09 | |
| *** ouznext has joined #yosys | 16:19 | |
| ouznext | hi. 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 |
| tpb | Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) | 16:23 |
| ouznext | Is 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 |
| tpb | Title: hrm-cpu/hrmcpu.v at master · adumont/hrm-cpu · GitHub (at github.com) | 16:25 |
| corecode | maybe the default nettype changed | 16:27 |
| corecode | good idea | 16:27 |
| corecode | you should explicitly declare all your nets | 16:27 |
| daveshah | But this is a parameter not a net | 16:28 |
| daveshah | bisecting now | 16:28 |
| *** rohitksingh has quit IRC | 16:29 | |
| ouznext | I am using `default_nettype none , but code hasn't changed since Feb 10. Was sinthesizing fine 7 days ago with that. | 16:29 |
| corecode | oh parameter | 16:29 |
| daveshah | Offending commit seems to be 23148ffae14318bb34cb311eb13494e25ebf4593 | 16:30 |
| corecode | do you already have a testing setup | 16:31 |
| corecode | i guess yosys compiles faster than nextprn | 16:31 |
| corecode | pnr* | 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. Thanks | 16:35 |
| daveshah | The problem commit is definitely 23148ffae14318bb34cb311eb13494e25ebf4593 | 16:36 |
| daveshah | I've created https://github.com/YosysHQ/yosys/issues/826 | 16:38 |
| tpb | Title: [regression] defparam failing with default_nettype none · Issue #826 · YosysHQ/yosys · GitHub (at github.com) | 16:38 |
| tnt | ouznext: you can try the #() syntax in the mean time, it might work. | 16:41 |
| ouznext | @daveshah: confirmed, synthesis goes well with yosys@974927ad (previous commit), then fails with yosys@23148ffa | 16:48 |
| *** develonepi3 has joined #yosys | 16:50 | |
| corecode | what do i need to do to use SB_HFOSC in a design? | 16:56 |
| corecode | to simulate it | 16:56 |
| corecode | ah | 16:56 |
| corecode | vlog exposes the pin | 16:57 |
| corecode | fair | 16:57 |
| *** kuldeep has quit IRC | 17:09 | |
| *** kuldeep has joined #yosys | 17:10 | |
| *** rohitksingh has joined #yosys | 17:16 | |
| *** rohitksingh has quit IRC | 17:20 | |
| corecode | is it possible that i have to tell iverilog to initialize flops? | 17:31 |
| tnt | well if you don't have a reset they will start as 'x'. | 17:49 |
| corecode | yea | 17:49 |
| tnt | you can just assert the reset line of your core at the beginning of execution. | 17:49 |
| corecode | yea, i had a bug in my POR generator | 17:49 |
| *** xa0 has quit IRC | 17:51 | |
| *** xa0 has joined #yosys | 17:53 | |
| *** rohitksingh has joined #yosys | 18:08 | |
| corecode | so there is a difference between my top simulation and the chip top simulation | 18:34 |
| tnt | ? Usually you have a testbench that wires things up. | 18:35 |
| corecode | yes i do | 18:35 |
| corecode | and after nextpnr i dump a verilog of the synthesis and simulate tis | 18:35 |
| corecode | this* | 18:35 |
| corecode | meaning that either yosys and iverilog interpret my design differently | 18:37 |
| corecode | or somewhere in the yosys/nextpnr chain something changes the design | 18:38 |
| tnt | ah 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 |
| corecode | well, most of it is X | 18:40 |
| tnt | some hw block also lack simulation models. | 18:41 |
| corecode | yes | 18:41 |
| corecode | given that i assert a global reset, i'd expect at least the first instruction pointer to be asserted right | 18:42 |
| corecode | but not so | 18:42 |
| *** ouznext has quit IRC | 18:43 | |
| tnt | is the clock properly running ? | 18:45 |
| corecode | yes | 18:49 |
| corecode | now, is it a simulation error or a synthesis error, or my code error | 18:53 |
| corecode | !!! | 18:54 |
| corecode | well the design is doing something | 18:57 |
| corecode | some LEDs are on | 18:57 |
| corecode | but they don't toggle | 18:58 |
| corecode | so the simulation still does something else | 18:58 |
| *** maikmerten has joined #yosys | 18:59 | |
| tnt | do you have your code somewhere ? | 18:59 |
| corecode | yes | 19:03 |
| corecode | sec | 19:03 |
| corecode | so with a 1:20 chance the design will run correctly on the fpga | 19:03 |
| corecode | so there is clearly a race condition somewhere | 19:03 |
| corecode | might by my high spi speed | 19:03 |
| corecode | but why doesn't it simulate? | 19:04 |
| corecode | tnt: https://github.com/corecode/forth-cpu/tree/master/rtl | 19:13 |
| tpb | Title: forth-cpu/rtl at master · corecode/forth-cpu · GitHub (at github.com) | 19:13 |
| *** leviathanch has quit IRC | 19:22 | |
| *** rohitksingh has quit IRC | 19:28 | |
| tnt | corecode: I don't have the U4k support, could you put the synth result verilog ? | 19:34 |
| corecode | sure | 19:35 |
| corecode | https://gist.github.com/f2c95fbeafc1acf33fe7424c98bb4020 | 19:36 |
| tpb | Title: forth-cpu-u4k_chip.v · GitHub (at gist.github.com) | 19:36 |
| *** proteusguy has quit IRC | 19:46 | |
| tnt | your SCK seems a bit fast compared to the clock btw. | 19:47 |
| tnt | The result from ip_comb is undefined, so some of the inputs must be missing resets. | 19:56 |
| corecode | yes that was deliberate | 20:02 |
| corecode | yea, my is ip_comb undefined | 20:02 |
| corecode | why* | 20:02 |
| corecode | because it can run on the fpga | 20:04 |
| tnt | Well 'x' don't exit on the fpga :p | 20:05 |
| corecode | must be something about what is fetched from ram | 20:05 |
| tnt | It's doesn't even fetch anything from RAM. | 20:05 |
| corecode | how do you know? | 20:06 |
| tnt | Well, I looked at the simulation trace ... address is always underfined. | 20:07 |
| corecode | yes | 20:08 |
| corecode | i think it's a cycle | 20:08 |
| corecode | it fetches data using an undefined address | 20:08 |
| corecode | and then dispatches the next instruction pointer generation based on the undefined result | 20:09 |
| corecode | a fix point, basically :) | 20:09 |
| tnt | instruction pointer is always undefined ... | 20:10 |
| corecode | no, IP is defined while in reset | 20:10 |
| tnt | but not iaddr | 20:10 |
| corecode | yes | 20:10 |
| corecode | because that's the address to fetch in this cycle to execute next | 20:11 |
| corecode | so it is IP+1 | 20:11 |
| corecode | i did not really know how to implement this elegantly | 20:11 |
| tnt | some of the control signals to actually make it ip+1 are obviously not reset properly. | 20:13 |
| corecode | i have the feeling i should add some pipelining - the core is a bit too slow for my liking | 20:13 |
| corecode | tnt: yea, they come from RAM | 20:13 |
| corecode | i guess the question is, what do i execute in the first cycle after reset, when there is no instruction word fetched yet | 20:14 |
| *** kuldeep has quit IRC | 20:14 | |
| *** kuldeep has joined #yosys | 20:15 | |
| *** lutsabound has joined #yosys | 20:15 | |
| tnt | corecode: 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 |
| corecode | yes | 20:24 |
| corecode | the problem is that i am fetching from ip_result | 20:25 |
| tnt | you could combinatorially force iaddr to 0 during reset. | 20:26 |
| corecode | in ip_comb? | 20:26 |
| tnt | for instance | 20:27 |
| corecode | so why don't i get this problem when i simulate the design, not the synthesis result | 20:28 |
| tnt | not 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 |
| corecode | i tried to avoid another LUT in the imem fetch path | 20:32 |
| corecode | but okay | 20:32 |
| corecode | let's keep this for now | 20:32 |
| corecode | yep | 20:34 |
| corecode | that fixed it | 20:34 |
| corecode | thanks! | 20:34 |
| tnt | The reset process and initial pipeline fill is tricky ... I also had trouble with it when I first made my cpu. | 20:34 |
| corecode | how did you solve it? | 20:34 |
| tnt | By adding resets on every FF that influence the fetch address. | 20:35 |
| tnt | but I don't have any direct combinatorial dependency between the RAM output and the next address because I have a pipeline. | 20:37 |
| tnt | The downside of the pipeline is the added jump latency of course. | 20:37 |
| corecode | yes | 20:39 |
| tnt | What's the fmax on the U4k btw ? | 20:40 |
| corecode | unless you have a pre-decode, maybe? | 20:40 |
| corecode | on this design? | 20:40 |
| tnt | No idea how the fabric is compared to the up5k. | 20:40 |
| tnt | yeah. | 20:40 |
| corecode | same timing as the up5k | 20:40 |
| corecode | says 29MHz | 20:40 |
| corecode | however, synopsys estimated >40MHz | 20:41 |
| *** kuldeep has quit IRC | 20:41 | |
| corecode | but the icecube2 placer is buggy | 20:41 |
| corecode | and can't place my design | 20:41 |
| tnt | Oh ok. Yeah, I built it here with up5k target at 31 MHz. | 20:41 |
| tnt | The 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 |
| corecode | okay | 20:42 |
| tnt | What's the issue with the placer ? | 20:42 |
| *** kuldeep has joined #yosys | 20:43 | |
| corecode | RAM cpu_top.iram_iram_0_0 Illegally placed at (0,21) | 20:44 |
| corecode | RAM cpu_top.cpu.cpu_execute.rstack.stack_mem_stack_mem_0_0 Illegally placed at (0,1) | 20:44 |
| corecode | used logic cells: 622 | 20:44 |
| corecode | Packing failed due to placement violation! | 20:44 |
| tnt | That's huh .. weird. | 20:44 |
| tnt | Did you try another target ? (like up5k or hx), | 20:45 |
| corecode | so yosys can deal with localparams that are declared after they are being referenced | 20:45 |
| corecode | synopsys cannot | 20:45 |
| corecode | so i guess i need to make it a parameter | 20:45 |
| corecode | icarus can deal with it as well | 20:46 |
| *** cr1901_modern has quit IRC | 20:46 | |
| * sxpert is having issues with synch between modules. this thing is probably more complicated than it should | 20:47 | |
| * sxpert is about to throw it all out and start over | 20:48 | |
| corecode | what's the problem | 20:48 |
| *** cr1901_modern has joined #yosys | 20:49 | |
| sxpert | corecode: well, the thing is becoming a big mess of inter-acting stall flags... | 20:49 |
| sxpert | it's no good, period | 20:49 |
| corecode | ok | 20:50 |
| sxpert | when it starts looking like spaghetti and timing horror, it's because it's coded the wrong way ;-) | 20:50 |
| corecode | any idea why this is? | 20:51 |
| sxpert | started with the wrong bit, I guess ;) | 20:51 |
| *** m4ssi has joined #yosys | 20:51 | |
| sxpert | no problem, I'm doing this to learn, so I can start over as many times as it will take ;-) | 20:52 |
| tnt | sxpert: 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 |
| corecode | oh now synplify shits its pants | 20:52 |
| corecode | conflicting driver! | 20:52 |
| sxpert | hah ! | 20:52 |
| sxpert | seen that before ;-) | 20:53 |
| corecode | but not during compile | 20:53 |
| corecode | but during map | 20:53 |
| corecode | that sounds to me like some optimization side effect | 20: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 |
| sxpert | yeah | 20:54 |
| sxpert | maybe synplify checks that at compile time | 20: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 |
| corecode | on GND? | 20:56 |
| corecode | i think what happens is that it can't deal with mismatched port sizes | 20:57 |
| corecode | and somehow decided to connect the unused net to gnd | 20:57 |
| corecode | and now complains that gnd is being driven | 20:57 |
| sxpert | there, moved everything to the attic | 20:58 |
| sxpert | time to start over ;) | 20:58 |
| corecode | are you using CVS still? :) | 20:59 |
| tnt | sxpert: is that your first experience with fpga btw ? | 20:59 |
| sxpert | tnt: yeah, apart from your basic blink | 21:00 |
| sxpert | corecode: god no | 21:00 |
| corecode | sxpert: i'm a beginner too; i noticed that heavy factoring into modules is useful | 21:01 |
| corecode | you can test them separately, you can synthesize them separately and see what the tool produces | 21:02 |
| tnt | sxpert: 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 |
| sxpert | yeah | 21:02 |
| sxpert | that's where the fun is ;-) | 21:02 |
| sxpert | tnt: but I learned from my mistakes, will start from the ground up... | 21:04 |
| sxpert | tnt: I did start by the instruction decoder, which was the wrong move | 21:04 |
| corecode | yea | 21:05 |
| corecode | first start with the functional units | 21:05 |
| tnt | yeah 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 |
| sxpert | also, maybe I need to use systemverilog and not classic verilog | 21:05 |
| corecode | then you can't use yosys tho | 21:05 |
| tnt | yosys doesn't do SV though. | 21:05 |
| corecode | or icarus | 21:05 |
| sxpert | ah | 21:05 |
| *** Laksen has quit IRC | 21:05 | |
| sxpert | hah ! | 21:05 |
| sxpert | ok | 21:05 |
| sxpert | never mind ;-) | 21:06 |
| corecode | why did synplify change my reset counter to 4 bits and replaced the top 4 bits with 1s? | 21:06 |
| corecode | haha what is this | 21:06 |
| sxpert | because it tried to synplify your thing and tripped on it's own socks | 21:07 |
| *** m4ssi has quit IRC | 21:07 | |
| corecode | tnt: the icecube2 placer estimates 47MHz | 21:12 |
| corecode | but then of course it also fails to place | 21:12 |
| corecode | so it might not be correct at all | 21:12 |
| tnt | :/ I'm wondering wtf is causing it to fail placement. Could you pastebin the complete logs ? | 21:16 |
| corecode | yes | 21:16 |
| corecode | but you can just try yourself | 21:16 |
| tnt | (but yeah, icecube often still beats yosys+nextpnr in fmax ATM) | 21:16 |
| corecode | hm, when i add the pcf, it says E2792: Instance pins_obuft_0 incorrectly constrained at SB_IO_OD location | 21:17 |
| daveshah | In icecube you need to use an SB_IO_OD primitive to use these pins | 21:18 |
| corecode | yea | 21:18 |
| corecode | but, how? | 21:18 |
| corecode | in my top design then? | 21:19 |
| corecode | meh | 21:19 |
| daveshah | Yeah | 21:19 |
| tnt | " unknown variable npins." | 21:20 |
| corecode | that means i either would have to route the enable, in, out signals all the way to the top | 21:20 |
| daveshah | Also beware that the ports of an SB_IO_OD primitive have no underscores unlike the normal SB_IO | 21:20 |
| corecode | ah yea, i had to convert this localparam to a parameter | 21:20 |
| corecode | or i have to put the SB_IO_OD deep into my design | 21:20 |
| corecode | tnt: updated | 21:21 |
| tnt | corecode: huh. Placed just fine here. | 21:24 |
| sxpert | have been getting those, am puzzled | 21:25 |
| sxpert | saturn_bus.v:27: warning: Port declaration of i_clk inherits dimensions from var/net. | 21:25 |
| corecode | tnt: !!! WHAT | 21:26 |
| corecode | what icecube version? | 21:26 |
| tnt | 2017.08.27940 | 21:27 |
| tnt | I didn't put any constraint files for the pins or anything though. | 21:27 |
| corecode | on what part | 21:27 |
| tnt | ice5lp sg48 | 21:28 |
| tnt | 4k | 21:28 |
| corecode | hm | 21:30 |
| corecode | so something in my project settings failed | 21:30 |
| corecode | now i made a new project and it works | 21:30 |
| corecode | ... | 21:30 |
| corecode | wow, 51MHz vs 29MHz | 21:30 |
| corecode | that's a huge difference | 21:31 |
| corecode | well i guess pebkac lead to u4k support in icestorm and nextpnr | 21:31 |
| corecode | what could make such a significant difference? | 21:34 |
| daveshah | Two biggest differences are likely carry chain optimisations and placer quality | 21:36 |
| corecode | i guess to decide we'd have to have nextpnr place the synplify output | 21:37 |
| daveshah | Adding '-relut' to synth_ice40 might improve the former, and https://github.com/YosysHQ/nextpnr/pull/219 the latter | 21:37 |
| tpb | Title: [EARLY WIP] HeAP-based analytical placer by daveshah1 · Pull Request #219 · YosysHQ/nextpnr · GitHub (at github.com) | 21:37 |
| corecode | and the lattice tool place yosys output | 21:37 |
| sxpert | the lattice tool looks like something escaped from the early 2000 | 21:49 |
| corecode | daveshah: is there a way to test yosys vs nextpnr? do the edifs work across? | 21:53 |
| daveshah | corecode: no, Yosys doesn't parse EDIF and the icecube EDIF parser segfaults on Yosys EDIFs | 21:54 |
| corecode | yey :/ | 21:54 |
| daveshah | You can export Verilog from Yosys and import to icecube, although I had some trouble with that too | 21:54 |
| *** maikmerten has quit IRC | 22:03 | |
| corecode | hm, what's the easiest way to selectively use SB_IO_OD... | 22:07 |
| daveshah | Sounds like a case of an if/generate | 22:12 |
| emeb | corecode: how's your u4k addition to icestorm going? | 22:35 |
| sxpert | tnt: ok, put down the basics, time to go to bed ;-) | 22:40 |
| tnt | corecode: why the ul4k btw ? | 22:43 |
| tnt | sxpert: o/ | 22:43 |
| emeb | tnt: 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 |
| emeb | best I got was ~39MHz | 22:45 |
| emeb | was wondering if that's what you saw too? | 22:45 |
| emeb | (targeting a up5k device) | 22:45 |
| *** dys has quit IRC | 22:47 | |
| tnt | I'm pretty sure it met timing. I might have cheated a little by using 'typical' settings instead of 'worst case' :p | 22:52 |
| emeb | heh | 22:54 |
| MoeIcenowy | emeb: how about nextpnr? | 22:56 |
| *** dys has joined #yosys | 23:02 | |
| *** chaseemory has joined #yosys | 23:25 | |
| corecode | tnt: it's the chip i have on my board | 23:27 |
| emeb | MoeIcenowy: what about nextpnr? | 23:34 |
| emeb | tnt: Yep - changing the timing condition to Typ makes it pass | 23:37 |
| emeb | 60MHz instead of 39 | 23:37 |
| corecode | oh wow | 23:37 |
| emeb | good enough for hobby work. probably not something I'd want to ship in volume. | 23:38 |
| corecode | wow what on best with icecube2 it shows 83MHz for my design | 23:40 |
| emeb | zippy! | 23:41 |
| emeb | looks like the long paths in the TinyFPGA bootloader are some of the adder carry chains in the ROM address generator. | 23:41 |
| emeb | IIRC that's all stuff that can be made to run @ 12MHz. | 23:42 |
| emeb | I 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 |
| corecode | doesn't most of the design only have to run at much lower speeds? | 23:44 |
| emeb | that's my understanding | 23:44 |
| emeb | I haven't studied the design closely though. | 23:45 |
| emeb | I'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 |
| corecode | i still am baffled by the difference in timing between icecube and nextpnr | 23:49 |
| emeb | Is it due to differences in routing, or differences in the way timing is computed? | 23:50 |
| corecode | i don't know | 23:50 |
| corecode | critical path is a different one | 23:50 |
| emeb | do the icestorm and icecube timing estimates agree for the same design? | 23:51 |
| corecode | it has RAM out, 4 LUTs, carry chain, 3 more LUTs | 23:51 |
| emeb | all in one async path? | 23:52 |
| corecode | oh that is a good question - how do i get a timing report from a .asc or vlog output? | 23:52 |
| corecode | from clock to clock | 23:52 |
| daveshah | corecode: use icetime | 23:52 |
| corecode | thanks | 23:52 |
| daveshah | The timing differences are for lots of reasons | 23:52 |
| corecode | so there are 7 luts and routing between them | 23:52 |
| daveshah | one issue is how Yosys is quite poor at optimising certain things like carries | 23:53 |
| corecode | i don't quite understand why some luts are 1.2 and some are 1.3 | 23:53 |
| daveshah | Another is nextpnr not being very well tuned | 23:53 |
| daveshah | corecode: different LUT inputs have different delays | 23:53 |
| corecode | out of 35ns, carry is 5.8 | 23:53 |
| corecode | so not really much | 23:54 |
| daveshah | The problem is optimising around the carry chain | 23:54 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!