pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
FL4SHK has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
leviathanch has joined #yosys
_whitelogger has joined #yosys
seldridge has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
pie___ has joined #yosys
pie__ has quit [Ping timeout: 250 seconds]
emeb_mac has quit [Quit: Leaving.]
_whitelogger has quit [Ping timeout: 250 seconds]
_whitelogger has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
dys has quit [Ping timeout: 250 seconds]
dys has joined #yosys
_whitelogger has joined #yosys
leviathanch has quit [Quit: No Ping reply in 180 seconds.]
leviathanch has joined #yosys
_whitelogger has joined #yosys
develonepi3 has quit [Quit: Leaving]
develonepi3 has joined #yosys
pie__ has joined #yosys
pie___ has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 246 seconds]
<swetland>
is there some reliable way of preventing yosys from obliterating specific signal names?
<swetland>
I'd love for my clocks to somehow survive so I can meaningfully designate them to nextpnr
lutsabound has joined #yosys
<swetland>
hmm. maybe it's nextpnr. I'm seeing the entities I want to refer to in the json file yosys produces
<daveshah>
I think the problem is that Yosys uses multiple names for a net and nextpnr just picks the first one arbitrarily
<daveshah>
I'm contemplating a rewrite the JSON import soon anyway to support hierarchical designs, so I'll leave this for now though
<daveshah>
Eventually we probably want some system for net aliases
emeb_mac has joined #yosys
pie___ has joined #yosys
pie__ has quit [Remote host closed the connection]
* swetland
nods
<swetland>
looking at the json file, it seems nets are just numbered and referenced from any number of entities
<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
leviathanch has quit [Remote host closed the connection]
<daveshah>
IMO a quick solution would be to pick the name with the fewest dollars; fewest dots; ties broken alphabetically
<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)
<swetland>
ahaha you are too fast
<swetland>
I just found the spot where the net name is always overwritten by the most recent import of that netid
<daveshah>
I still want to do a proper implementation with aliases at some point
<swetland>
Info: Max frequency for clock 'system.clk12m': 15.83 MHz (PASS at 12.00 MHz)
<swetland>
Info: Max frequency for clock 'phy_refclk_glb': 60.12 MHz (PASS at 50.00 MHz)
<swetland>
Info: Max frequency for clock 'hdmi_clk_src': 37.09 MHz (PASS at 12.00 MHz)
<swetland>
yeah that counts as a quality of life improvement
<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
<daveshah>
Yeah, consistency was the main point atm
rohitksingh has joined #yosys
ouznext has joined #yosys
ouznext is now known as adumont
<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
<tpb>
Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org)
<adumont>
arachne-pnr fails with builddir/alhambra/top.blif:30: fatal error: invalid formal-actual
<adumont>
Since last week build which was successfull, arachne-pnr is at the same commit, so it's not the culprit.
<adumont>
Latest build was done with yosys commit 47a5dfdaa4bd7d400c6e3d58476de80904df460d, it was OK. No error.
<adumont>
Today at yosys commit ddff75b60ab6b29bbc8425c7f5ac2e6ebbbf32a6 it fails with that error.
<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.
rohitksingh has quit [Remote host closed the connection]
<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?
* adumont
"Bisecting: 3 revisions left to test after this (roughly 2 steps)"
<daveshah>
adumont: Can you post the blif file causing the problems?
pie___ has quit [Remote host closed the connection]
develonepi3 has quit [Remote host closed the connection]
adumont has quit [Ping timeout: 256 seconds]
<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]
<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"
<mrsteveman1>
perhaps it's really a difference in what can be synthesized for an ice40 vs a machxo2?
<daveshah>
mrsteveman1: this sounds like a possible Yosys issue. Could you put your code somewhere?
Laksen has joined #yosys
<mrsteveman1>
daveshah actually looks like this is a false alarm, sorry! It was a typo in the readmemb() line, I just caught it :O
<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