<vancz>
Does yosys do warning and linting and such? I accidentally some verilog where I did a two bit case statement on a register I accidentally made only 1 bit.
lofty[m] has joined #yosys
<lofty[m]>
For linting use a linter; Verilator would probably catch it
<vancz>
guess I need to combine more toolchains
<vancz>
I have a basic question; can I assert a signal and then assert another signal to deassert it on the next clock cycle? or do I need a cycle extra in between to notice the deassert signal?
<vancz>
specifically if I have two (software implementations of) chips, one asserts an IRQ, the other detects the IRQ and says to clear it with an IRQ_CLR signal
<vancz>
can I do that in two clock cycles or do I need three?
* vancz
wonders if he is asking what he actually means to ask
<lofty[m]>
csantosb: what's your intended usecase for that? to be quite honest it never worked amazingly well, and it's not like you can use the end result on real hardware
<lofty[m]>
I think the venn diagram of Guix users and people interested in the NanoXplore FPGA is two separate circles
<csantosb>
Unless a license is provided, it cannot be distributed, and this holds for all repositories.
<lofty[m]>
then do not distribute it. nextpnr is modular enough that you can simply not build the ng-ultra uarch.
<csantosb>
Any reason not to ?
<lofty[m]>
have you actually tried to use that architecture?
<lofty[m]>
you cannot use the output of it, because converting the nextpnr output to a usable bitstream requires a license for NanoXplore's Impulse toolchain
<csantosb>
Sure, this is explained in the readme
<lofty[m]>
sorry, I'm really confused here
<lofty[m]>
why do you want to package a toolchain you cannot use for anything.
<csantosb>
For exactly the same reason nextpnr considers it
<lofty[m]>
I do not think your motivation here is "so I could still have a job"