*** tpb has joined #yosys | 00:00 | |
*** pie__ has quit IRC | 00:45 | |
*** pie__ has joined #yosys | 00:45 | |
*** FL4SHK has joined #yosys | 01:23 | |
*** rohitksingh has quit IRC | 01:39 | |
*** rohitksingh has joined #yosys | 01:40 | |
*** leviathanch has joined #yosys | 02:39 | |
*** _whitelogger has quit IRC | 03:45 | |
*** _whitelogger has joined #yosys | 03:47 | |
*** seldridge has joined #yosys | 04:21 | |
*** seldridge has quit IRC | 04:35 | |
*** pie___ has joined #yosys | 05:51 | |
*** pie__ has quit IRC | 05:54 | |
*** emeb_mac has quit IRC | 06:35 | |
*** _whitelogger has quit IRC | 06:46 | |
*** _whitelogger has joined #yosys | 07:17 | |
*** s_frit has quit IRC | 07:59 | |
*** s_frit has joined #yosys | 08:00 | |
*** dys has quit IRC | 08:50 | |
*** dys has joined #yosys | 09:20 | |
*** _whitelogger has quit IRC | 09:30 | |
*** _whitelogger has joined #yosys | 09:32 | |
*** leviathanch has quit IRC | 11:30 | |
*** leviathanch has joined #yosys | 11:31 | |
*** _whitelogger has quit IRC | 13:27 | |
*** _whitelogger has joined #yosys | 13:29 | |
*** develonepi3 has quit IRC | 13:33 | |
*** develonepi3 has joined #yosys | 13:38 | |
*** pie__ has joined #yosys | 13:39 | |
*** pie___ has quit IRC | 13:40 | |
*** rohitksingh has quit IRC | 13:58 | |
swetland | is there some reliable way of preventing yosys from obliterating specific signal names? | 14:20 |
---|---|---|
swetland | I'd love for my clocks to somehow survive so I can meaningfully designate them to nextpnr | 14:20 |
*** lutsabound has joined #yosys | 14:28 | |
swetland | hmm. maybe it's nextpnr. I'm seeing the entities I want to refer to in the json file yosys produces | 14:42 |
daveshah | I think the problem is that Yosys uses multiple names for a net and nextpnr just picks the first one arbitrarily | 15:17 |
daveshah | I'm contemplating a rewrite the JSON import soon anyway to support hierarchical designs, so I'll leave this for now though | 15:18 |
daveshah | Eventually we probably want some system for net aliases | 15:18 |
*** emeb_mac has joined #yosys | 15:29 | |
*** pie___ has joined #yosys | 15:52 | |
*** pie__ has quit IRC | 15:53 | |
* swetland nods | 16:16 | |
swetland | looking at the json file, it seems nets are just numbered and referenced from any number of entities | 16:18 |
swetland | one could imagine both tracking all the names (as aliases) for the sake of being able to refer to them, but also maybe prioritizing names that came from the original verilog over synthetic ones when picking one for display. that, I suppose would require yosys to flag "true" or "original" names as such | 16:19 |
*** leviathanch has quit IRC | 16:26 | |
daveshah | IMO a quick solution would be to pick the name with the fewest dollars; fewest dots; ties broken alphabetically | 16:33 |
daveshah | swetland: https://github.com/YosysHQ/nextpnr/pull/182 | 16:52 |
tpb | Title: json: Prefer higher level net names when a net has multiple names by daveshah1 · Pull Request #182 · YosysHQ/nextpnr · GitHub (at github.com) | 16:52 |
swetland | ahaha you are too fast | 16:58 |
swetland | I just found the spot where the net name is always overwritten by the most recent import of that netid | 16:58 |
daveshah | I still want to do a proper implementation with aliases at some point | 16:58 |
swetland | Info: Max frequency for clock 'system.clk12m': 15.83 MHz (PASS at 12.00 MHz) | 17:08 |
swetland | Info: Max frequency for clock 'phy_refclk_glb': 60.12 MHz (PASS at 50.00 MHz) | 17:08 |
swetland | Info: Max frequency for clock 'hdmi_clk_src': 37.09 MHz (PASS at 12.00 MHz) | 17:08 |
swetland | yeah that counts as a quality of life improvement | 17:08 |
swetland | it's not perfect -- ideally I'd specify system.clk25m rather than hdmi_clk_src, but it's much more sensible and at least will be consistent now from build to build provided I don't rename things | 17:09 |
daveshah | Yeah, consistency was the main point atm | 17:11 |
*** rohitksingh has joined #yosys | 17:45 | |
*** ouznext has joined #yosys | 17:47 | |
*** ouznext is now known as adumont | 17:47 | |
adumont | Hi, I have a project that runs automated builds every week in travis ci (test, simulation, synthesis, pnr...) with the latest versions of the icestorm toolchain (built from source). Today the project has failed to PNR. Here is the log: https://travis-ci.org/adumont/hrm-cpu/builds/468681334 | 17:49 |
tpb | Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) | 17:50 |
adumont | arachne-pnr fails with builddir/alhambra/top.blif:30: fatal error: invalid formal-actual | 17:51 |
adumont | Since last week build which was successfull, arachne-pnr is at the same commit, so it's not the culprit. | 17:52 |
adumont | Latest build was done with yosys commit 47a5dfdaa4bd7d400c6e3d58476de80904df460d, it was OK. No error. | 17:52 |
adumont | Today at yosys commit ddff75b60ab6b29bbc8425c7f5ac2e6ebbbf32a6 it fails with that error. | 17:53 |
adumont | I'm running a git bisect run right now, which will hopefully find the commit in yosys that make my project fail to run the PNR step. | 17:54 |
*** rohitksingh has quit IRC | 17:54 | |
adumont | I'm wondering though, is it a problem on my end in my project? Is it that yosys now "generate" something new in the blif file that latest arachne-pnr stil doesn't understand? | 17:54 |
* adumont "Bisecting: 3 revisions left to test after this (roughly 2 steps)" | 17:55 | |
daveshah | adumont: Can you post the blif file causing the problems? | 18:27 |
*** pie___ has quit IRC | 18:33 | |
*** pie__ has joined #yosys | 18:33 | |
adumont | @daveshah: here's the faulty blif http://termbin.com/lzt31 | 18:34 |
daveshah | Oh, I see | 18:34 |
daveshah | I'll get clifford to revert the commit that broke that | 18:34 |
daveshah | A change I made occasionally adds spaces to names which breaks blif | 18:37 |
*** seldridge has joined #yosys | 18:39 | |
adumont | @daveshah: ok thanks :). just opened issue 743 https://github.com/YosysHQ/yosys/issues/743 if you wan't to follow up on it on github. Thanks again :-D | 18:47 |
tpb | Title: fatal error: invalid formal-actual when running arachne-pnr · Issue #743 · YosysHQ/yosys · GitHub (at github.com) | 18:47 |
*** emeb_mac has quit IRC | 18:47 | |
*** develonepi3 has quit IRC | 19:30 | |
*** adumont has quit IRC | 19:35 | |
mrsteveman1 | Is $readmemb() expected to work with a single-bit memory? e.g. "reg [0:0] framebuffer [0:8191]", either with or without the [0:0] | 19:36 |
mrsteveman1 | I'm pre-initializing an OLED framebuffer, it works in Lattice Diamond but Yosys says "Failed to evaluate system function `\$readmemb' with non-memory 2nd argument" | 19:37 |
mrsteveman1 | perhaps it's really a difference in what can be synthesized for an ice40 vs a machxo2? | 19:50 |
daveshah | mrsteveman1: this sounds like a possible Yosys issue. Could you put your code somewhere? | 20:06 |
*** Laksen has joined #yosys | 20:10 | |
mrsteveman1 | daveshah actually looks like this is a false alarm, sorry! It was a typo in the readmemb() line, I just caught it :O | 20:16 |
mrsteveman1 | it was working on machxo2 because there's an ifdef for it containing a separate readmemb line (different relative path), without the typo in the memory name | 20:23 |
mrsteveman1 | thank you though :) | 20:23 |
*** FL4SHK has quit IRC | 20:34 | |
*** FL4SHK has joined #yosys | 21:14 | |
*** dys has quit IRC | 21:18 | |
*** dys has joined #yosys | 21:31 | |
*** seldridge has quit IRC | 23:19 | |
*** Laksen has quit IRC | 23:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!