<cr1901_modern>
ghdlsynth isn't feature complete, but has meaningful yosys support. The NVC simulator is feature complete but doesn't have meaningful yosys support; the idea would be to generate yosys RTLIL from NVC.
maikmerten has joined #yosys
<FL4SHK>
oh hey, cr1901_modern, do I know you?
<FL4SHK>
looks like you're in at least one other channel I'm in...
<FL4SHK>
vup2, cr1901_modern : any way to use the yosys formal verification with that?
<daveshah>
I don't think either of those frontends support assert or PSL
<daveshah>
So your properties would have to be in SV
<FL4SHK>
Okay. Is that a big deal?
<FL4SHK>
I'm honestly just trying to figure out my best option going forward at this point.
<FL4SHK>
I think I'd prefer to just stick to SystemVerilog.
<FL4SHK>
now... I'd like to improve the yosys read_verilog -sv interface support
<FL4SHK>
it just... doesn't seem to support passing a parameter into an interface
<FL4SHK>
even without the localparam being in package, it doesn't work.
<FL4SHK>
it also doesn't seem to think the parameters of an interface are constant?
<FL4SHK>
such that, in that "Adder" module, I couldn't access the parameters of the interface that was passed in
<FL4SHK>
"couldn't detect width of signal"
<FL4SHK>
or, "Failed to detect width for parameter"
<FL4SHK>
appears to be a bug in evaluation of parameters inside packages?
<daveshah>
Yes, that looks like a bug
<daveshah>
also seem to have it some kind of issue in the frontend debugging, -dump_ast2 which usually helps with this kind of stuff is hitting an assert fail
<FL4SHK>
I'm gonna try to fix thi
<FL4SHK>
s
<daveshah>
Cheers!
<daveshah>
that would be great
<FL4SHK>
...it's in "type2str"
<FL4SHK>
apparently it's an AstNodeType with value 95
<FL4SHK>
which is just...
<FL4SHK>
hmmmmm
<FL4SHK>
how do I do debug build?
<FL4SHK>
I believe I found the thing to do with the makefile.
<FL4SHK>
make ENABLE_DEBUG=1 looks like it
<FL4SHK>
I was afraid of digging into this yesterday... but now I think I'm going to give it a shot
<FL4SHK>
oh, you know what that ast assert bug appears to be?
<FL4SHK>
Looks like there was no update of the X macro in type2str
<FL4SHK>
...could stand to have a list of things there tbh
<daveshah>
Yes, that makes sense
jwagen has joined #yosys
<FL4SHK>
Okay, I think this is too tough for me
davos has quit [Ping timeout: 256 seconds]
maikmerten has quit [Quit: Ex-Chat]
davos has joined #yosys
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
davos has left #yosys [#yosys]
davos has joined #yosys
<davos>
hey all. I'm not able to get yosys to infer an SB_SPI. I have to add a (* keep *) tag to the module instance, for it to be inferred, so something is not quite right. I'm using an iceup5k-sg48. Im not seeing any warnings from yosys, it seems to silently optimize away the block, but I could just not be reading the yosys output correctly. Any recommendations on how to debug the issue further? the sb_spi is being used as a slave, im not
<davos>
even connecting a miso line, just SCK, SS, and MOSI, along with the internal SB ports.
<davos>
Thanks
<daveshah>
davos: it will only be optimised away if none of its outputs (including the system bus outputs) are used
<daveshah>
Most likely because other logic is being optimised away
<daveshah>
Looking for the names of the wires connected to those ports in the Yosys log output might help to debug this
<davos>
ok, thanks, thats a good sanity check. Its probably due to how im crossing the clock domain, from spi to rest of the logic; still new at this. for instance SCKI is 6mghz and SBCLKI is 12 mghz
<davos>
actually, the SB_SPI should cross the clock domain for me... i think. i get what your saying, is there a way to have yosys optimize my logic LESS aggressively?
<tnt>
davos: post your code somewhere
<davos>
im gonna fight with it for another round first haha. Ill be back later with either a KO or a code post. daveshah's comment narrows it down pretty well