<mewt>
hi, having an issue on an updated Arch system trying to build yosys from source. I'm on d1695ad9980466ca49d7931ffbc600517682785f, I run "git clone --recursive https://github.com/YosysHQ/yosys.git" "git submodule update --init", "make -j$(nproc)", "sudo make install" from the root of the repo. In response I get the message at the following paste: https://dpaste.org/S1DXp
<mewt>
have tried removing the entire thing and cloning again several times, etc.
<mewt>
i could just dummy out check-git-abc but i would prefer to know if it matters
<mewt>
The contents of abc/.gitcommit is $Format:%H$
<mewt>
that seems like that should have been resolved by the commands above
<mewt>
alright, and I've got a second one I've talked about before -- clog2 of a localparam that is the product of 2 other localparams causes yosys to exit with ERROR: Non-constant function call in constant expression.
<mewt>
clearly this is resolvable because the two localparams in the product are constants, therefore the product is a constant, therefore log2 ceil of the product is a constant
<mewt>
module blah #(localparam PARAM1 = 1, localparam PARAM2 = 2, localparam PARAM3=PARAM1*PARAM2, localparam PARAM4 = $clog2(PARAM3)) ( ... works. Should this be different?
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
<lofty>
mewt: can you provide an example for the clog2 issue?
<mewt>
the first issue still exists, I took the strategy in the issue on github for it and just replaced the content of check-git-abc with exit 0
<mewt>
guess it's confirmation it's not debian-specific?
<mewt>
can provide whatever info and try whatever for that as well, just let me know
<lofty>
mewt: your failing test case seems to be very reliant on implementation behaviour
<lofty>
I searched 1364:2005, and it pretty much always assumes that parameters are declared before use
<mewt>
Right, so I guess I should just use 2nd case all the time, and this isn't much of a bug?
<lofty>
Or the "1995 form" where you declare port sizes after parameters
<mewt>
It's not...hard to convert things to that, so that's not the worst outcome as long as I know a consistent rule. I guess I need to read the standard
<mewt>
But why does it fail for only *this*?
<mewt>
Surely it should then fail for every single parameter I am using to set a port size
<mewt>
I have about a billion different things using the pattern with parameter declaration after they are use in a port size, and only once $clog2 gets involved, it fails
<lofty>
Using a parameter to set a port size is fine, because they're defaults, effectively
<mewt>
Yes, I am aware -- I'm saying that if the problem is where the declaration is, this is harly my only instance of doing it
<mewt>
let me get another test case
<mewt>
hardly*
<lofty>
But the standard is fairly specific that system tasks must have constant expression inputs
<mewt>
but...don't they?
<mewt>
what's non-constant about the product of 2 constants?
<lofty>
Nothing, which is why your second example works fine
<mewt>
what makes it non-constant in the first? the order the parameters appear in is certainly the same
<mewt>
does it somehow...not look at PARAM3 first if I do the first thing?
<mewt>
why does it become non-constant if the declaration of the parameters moves below the ports?
<mewt>
i really would prefer some kind of conclusive answer -- why does PARAM4 become non-constant with case 1, and why doesn't every instance of a parameter declaration after its use to set a port size fail if it's not permissible? Using PARAM1 or PARAM2 to set a port size with case 1 is just fine
<lofty>
And I'm working on trying to find that conclusive answer
<mewt>
Alright, I'll leave you to it, sorry
<lofty>
mewt: so, Yosys has a monster called simplify, which performs elaboration and constant folding at once
<lofty>
It traverses the function AST roughly from top to bottom
<mewt>
Thank you. I guess at this point if I want to understand better, I should try to debug build and have a look in the code. I think I have an intuitive sense of what won't work from this/how to avoid any similar problems at least. I think I recall starting to look at where in the code things went this way but didn't have the bg
<lofty>
In case 2, it discovers PARAM3, and transforms it into the constant 16, and then PARAM4, which is $clog(16) = 4
<lofty>
In case 1, it discovers PARAM4 first, looks at the definition of it to find it is $clog2(PARAM3), but PARAM3 has not been constant folded, so it's just an identifier, thus you get an error
<mewt>
ah ok, so my very intuitive sense that it looked at param3 before knowing what it was was...about right then
<mewt>
that makes sense
<mewt>
is that something that's intended to stay this way?
<lofty>
This feels like a situation it *could* handle, but the open source Verilog front-end is a nightmare nobody wants to touch or maintain
<lofty>
There is a pretty good reason why the team intends to migrate to slang instead of using the existing frontend
<mewt>
being able to use systemverilog straight-up like this would be nice, I need to improve my skills on that anyways
<lofty>
I mean, we also have something of a disincentive to improve SV support because we sell Verific as an SV frontend
<lofty>
(and VHDL frontend)
<lofty>
But the fact that a permissively licensed external SV frontend exists is pretty motivating
<mewt>
well, as a lowly grad student whose research will be shoved into the xilinx tools if it touches HDL stuff at all, I probably am not the target. But I'll have to follow progress on this
<mewt>
target for verific, that is
<lofty>
Oh yeah, no, I understand
<lofty>
The open frontend is Good Enough for a lot of people,
<lofty>
and our main target market for Verific is people doing formal verification
<lofty>
Anyway; sorry, I'm rambling
<lofty>
Good luck with your research :p
<mewt>
(this is just a hobby project/a way to improve my FPGA skill)
<lofty>
Small problem: I too am using Arch and I can't reproduce this
<mewt>
interesting
<mewt>
what is the content of abc/.gitcommit for you?
<lofty>
$Format:%H$
<mewt>
ok, same then... huh
<mewt>
well i don't have a lot more time, so I'll come back to this I guess unless there are other ideas. can try anything you suggest later on to disambiguate why, but it seems like something about the if statement must be different