clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
emeb_mac has joined #yosys
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
emeb has quit [Quit: Leaving.]
citypw has joined #yosys
whitequark has joined #yosys
npe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stary has quit [Ping timeout: 264 seconds]
Stary has joined #yosys
N2TOH_US has quit [Remote host closed the connection]
N2TOH_US has joined #yosys
npe has joined #yosys
smarter_ has joined #yosys
vup2 has joined #yosys
daniellimws has joined #yosys
vup has quit [*.net *.split]
m_hackerfoo has quit [*.net *.split]
anuejn has quit [*.net *.split]
grazfather has quit [*.net *.split]
m_hackerfoo has joined #yosys
npe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
emeb_mac has quit [Quit: Leaving.]
anuejn_ has joined #yosys
dys has joined #yosys
<Sarayan> How can I have yosys tell me the exact compiler invocaitons on make?
<Sarayan> V=1 doesn't do a thing and neither VERBOSE=1
vidbina_ has joined #yosys
<whitequark> Sarayan: make PRETTY=
<Sarayan> thanks :-)
<sensille> is there a preferred way to get warnings from yosys/nextpnr? it's rather noisy
<daveshah> -q
<whitequark> have i mentioned the cxxrtl backend here yet? it's a backend i'm working on that emits C++ simulating ~arbitrary RTLIL netlists https://github.com/YosysHQ/yosys/pull/1562
<tpb> Title: write_cxxrtl: new backend by whitequark · Pull Request #1562 · YosysHQ/yosys · GitHub (at github.com)
<whitequark> if any of you have use case for it, i'd be quite curious to hear
<daveshah> I plan to try it for some mixed language sim fairly soon
<sensille> daveshah: nice, thanks. to you normally aim for zero warnings?
<daveshah> Yes
<daveshah> For designs not doing anything particularly odd, zero warnings should be achievable with nextpnr and Yosys
<sensille> my fear would be that the design changes be yosys-specific
<daveshah> What warnings are you talking about?
<whitequark> daveshah: nice!
<sensille> like "Replacing memory ... with list of registers."
<sensille> or "Resizing cell port ... from 5 bits to 8 bits."
<daveshah> The resizing cell port one sounds like it would be good practice to fix
<sensille> "Yosys has only limited support for tri-state logic at the moment."
<daveshah> The replacing memory with list of registers is probably one that can be ignored (in the worst case it is a QoR issue, if you intended a memory to be used)
<whitequark> you can mark the memory with (* ram_block *) if you intend a BRAM to be always used
<daveshah> Does the frontend look at this?
<daveshah> "Replacing memory ... with list of registers." means $memrd/$memwr and then $mem will never be created
<whitequark> oh
<whitequark> I have to fix that sometime
<whitequark> I totally forgot that the Verilog frontend does that *too* for some reason
<daveshah> It's for patterns that don't even make sense as $memrd/$memwr
<daveshah> I think mostly things that involve continuous/async writes
<whitequark> ah I see
<daveshah> Usually, it is when the concept is an array rather than a memory anyway
<whitequark> hm, $memwr does have a \CLK_ENABLE port
<daveshah> I have a feeling from discussions with Claire in the past that there are a few other cases that need to be mem2reg'd in the frontend
<daveshah> but I can't remember any details, just that there was a bug around this at one point
<whitequark> yes, that's my impression too
<sensille> it might be nice to see the utilization summary from nextpnr even with -q
<whitequark> i also understand that the Verilog frontend in Yosys is perhaps one step above a proof of concept
<daveshah> Yes, I think it was always intended to be rewritten but never was
<daveshah> There are various talks of a new SV frontend based on one of the new parsers but I don't know if anything is actually happening
<daveshah> ime, parsing is easy, elaborating is hard
<whitequark> yup
<whitequark> I feel like Yosys would be better off completely ditching the Verilog frontend and using some external project focusing on that specifically
<whitequark> not only would this result in a much better frontend, but also it would reduce the intertwinedness of the Verilog frontend and optimization passe
<daveshah> Yeah, ghdlsynth has shown this can be done
<whitequark> and connect_rpc shows this can be done even if your frontend isn't in C++ :)
jakobwenzel has joined #yosys
<whitequark> daveshah: oh btw, any idea if transparent ports with RE can be supported by yosys reaonably easily?
<whitequark> I feel like we discussed this before
<daveshah> I'm tempted to automatically reply no for anything memory-related in yosys...
<whitequark> oh yeah, they can't be, because the way it handles transparency groups at the moment is flawed
<whitequark> blech
<daveshah> I can't remember, I think it gets a bit complicated across clocks
<daveshah> Yes
<Sarayan> wq: I'm working today on seeing if I can integrate slang
<whitequark> slang?
<whitequark> oh the SV thing
<daveshah> How much elaboration does it do?
<Sarayan> Good question, it's on the way to integrate llvm, which I find, err, interesting :-)
<Sarayan> (it's optional, so not an issue)
<whitequark> llvm would not help you elaborate SV
<Sarayan> Can you do sim-related code generation without having done elaboration first?
<whitequark> no
<Sarayan> Features
<Sarayan> Fully parse, analyze, and elaborate all SystemVerilog features - see this page for current status.
<whitequark> that sounds quite good
<Sarayan> yeah
<whitequark> perhaps too good? it took how many years for synopsys to implement all of SV?
<Sarayan> no idea
<Sarayan> it will be better than what's currently in there in any case
<whitequark> indeed
<tpb> Title: Language Support | slang C++ docs (at sv-lang.com)
<Sarayan> there's a lot of red, but there's also a lot of green
daniellimws has left #yosys ["Leaving..."]
<Sarayan> I'm not capable of seeing what's significant in there
<whitequark> seems reasonable to me
<whitequark> SVA seems to be largely missing
<Sarayan> I don't even know what sva means :-)
<whitequark> systemverilog assertions
<whitequark> formal verification features, one of the most directly useful parts of systemverilog
<daveshah> I think the big problem with anything like slang is the netlist generation side
<daveshah> Which I can't see much of atm, but may be missing
<daveshah> Certainly with adding synthesis to ghdl that has looked to have been fairly complicated
jryans has quit [Quit: killed]
promach3 has quit [Quit: killed]
fevv8[m] has quit [Quit: killed]
rjo has quit [Quit: killed]
emily has quit [Quit: killed]
<Sarayan> hmmm, annoying caveat, slang really requires c++17
oldtopman has joined #yosys
<sensille> hm. -defer does not help with default parameters set to invalid values for the design
Vinalon has quit [Ping timeout: 240 seconds]
rjo has joined #yosys
<sensille> the "Resizing cell port" warning is also from a difference in default parameters
<daveshah> In what context are you using -defer?
<daveshah> This is exactly what it is intended for
<sensille> you recommended it to me a few days ago
<sensille> i initially set all default parameters to 0, which led to errors
<daveshah> So you are using read_verilog -defer and you still get a warning based on the default parameters?
<sensille> yosys -defer -p "synth_ecp5 -json $(TARGET).json" $(SRC)
<sensille> oh, it's an option to read_verilog
<sensille> i'm afraid i have to understand more of yosys
<daveshah> It's an unfortunate consequence of getopt that -defer is accepted (it is parsed as -d -e fer)
<sensille> i was shortly wondering about that
<sensille> so yosys -p "verilog_defaults -add -defer" -p "synth_ecp5 -json $(TARGET).json" $(SRC)?
<sensille> probably not, still complains
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sensille> doing that on the command line works, though
jryans has joined #yosys
promach3 has joined #yosys
emily has joined #yosys
fevv8[m] has joined #yosys
jakobwenzel has quit [Ping timeout: 265 seconds]
<sensille> i have no idea where the read_verilog comes from on my current command line
<ZirconiumX> sensille: if you specify a .v file for Yosys it'll invoke read_verilog on it
<sensille> ok, then the next question is why verilog_defaults doesn't work on that
<daveshah> Because -p runs after command line frontends
<daveshah> I think -f "verilog -defer" should use read_verilog -defer for command line files
jakobwenzel has joined #yosys
<sensille> with this i get less warnings, but an error "Module ... is not part of the design"
<sensille> so it probably replaces more than just the read_verilog
<daveshah> When using defer, you need to pass -top to synth_ecp5
vidbina_ has quit [Ping timeout: 240 seconds]
<sensille> finally :) most warnings are gone, and now i can see that the "Resizing cell size" warnings are my own fault
vidbina_ has joined #yosys
lambda has quit [Quit: WeeChat 2.7.1]
lambda has joined #yosys
lambda has quit [Client Quit]
lambda has joined #yosys
<Sarayan> ok, slang compiles in a yosys tree, now for the fun part, plugging it in
vup2 is now known as vup
vidbina_ has quit [Ping timeout: 264 seconds]
vidbina_ has joined #yosys
jfcaron has joined #yosys
vidbina_ has quit [Ping timeout: 264 seconds]
vidbina_ has joined #yosys
sorear has quit [Ping timeout: 240 seconds]
<Sarayan> So, sv is parsed into... something
sorear has joined #yosys
<Sarayan> now to see how to introduce that somthing to yosys
<whitequark> that was fast
<Sarayan> :-)
<Sarayan> it's rather minimal for now, as in I don't parse options (but that will be trivial, I just want to make the rest work first)
<Sarayan> ok, terminology, elaboration, that's something that happens before or after the ast?
<ZirconiumX> elaboration is turning a generic module into a concrete instance, AIUI
<Sarayan> e.g. if I use whatever elaboration support is in slang, do I hook at the ast level or, i guess, at the rtlil level?
<ZirconiumX> Yosys would take in concrete RTLIL, I think.
<whitequark> ideally at rtlil level
<ZirconiumX> So I think you'd want to elaborate before feeding into Yosys, right?
<Sarayan> ZX: I'm into yosys in the first place
<whitequark> rtlil is a relatively clean and well documented boundary, using it saves you a lot of trouble extending ast to suit slang's needs
<whitequark> by using rtlil at the interface you leave both slang and yosys doing what they do best
<Sarayan> ok, makes sense
<Sarayan> also, are you supposed to be able to have multiple files in a read_* command?
<Sarayan> if yes, how do that jive with the frontend execute interface, if no how do you input a design that is in three files?
<ZirconiumX> Sarayan: I think order matters a fair bit in that respect
<ZirconiumX> Either you can do what e.g. read_verilog -defer does, which resolves modules later, or you can require the user to input in topological order
<Sarayan> hmmm ok
<Sarayan> gonna try for topo order for now, once everything else works it gets easier to refine that kind of questions
Vinalon has joined #yosys
vidbina_ has quit [Ping timeout: 264 seconds]
Cerpin has quit [Quit: leaving]
<whitequark> does anyone here have strong opinions on the way cxxrtl should be emitting blackbox cells that are replaced with C++ models?
<whitequark> i'm primarily deciding between making it a property of the *module* (therefore necessitating creation of blackbox modules) or a property of the *cell*
<whitequark> i.e. if it is a property of the cell, then any undefined cell can be marked so that it turns into a C++ blackbox
<whitequark> if it is a property of the module, something somewhere in the design flow has to create the blackbox modules
miek has joined #yosys
emeb has joined #yosys
<ZirconiumX> It seems to me like it should be a property of the module, whitequark
<ZirconiumX> Even though it requires more effort, I'd prefer it goes "hey, this module isn't defined" sooner in the event of a problem than have to wade through, what, linker errors?
<whitequark> that was what I thought at first, but here is an issue with it: parametric blackboxes
<whitequark> the thing is that I can't really generate a C++ class parameterized by port widths, at least not easily and possibly not at all
<Sarayan> ok ,cat is gone, I can work on the code again
<qu1j0t3> rm /bin/cat
<Sarayan> qu1j0t3: more like spontaneous relocation
<Sarayan> does somebody have a non-entirely-trivial systemverilog example that works with yosys?
dys has quit [Ping timeout: 256 seconds]
<Sarayan> ah, found something
npe has joined #yosys
az0re has quit [Remote host closed the connection]
jakobwenzel has quit [Remote host closed the connection]
<Sarayan> what is the attribute ID::cells_not_processed ? I don't find it in the yosys manual
vidbina_ has joined #yosys
Cerpin has joined #yosys
vidbina_ has quit [Ping timeout: 260 seconds]
citypw has quit [Ping timeout: 240 seconds]
az0re has joined #yosys
vidbina_ has joined #yosys
futarisIRCcloud has joined #yosys
npe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
az0re has quit [Ping timeout: 240 seconds]
npe has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
dh73 has joined #yosys
dh73 has quit [Client Quit]
dh73 has joined #yosys
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
smarter_ is now known as smarter
Cerpin has quit [Remote host closed the connection]
Cerpin has joined #yosys
jfcaron has quit [Ping timeout: 256 seconds]
dh73 has quit [Quit: Leaving.]
emeb has quit [Quit: Leaving.]
emeb_mac has joined #yosys