oldtopman has quit [Read error: Connection reset by peer]
oldtopman has joined #yosys
dxld has quit [Ping timeout: 272 seconds]
dxld has joined #yosys
emeb_mac has quit [Quit: Leaving.]
emeb_mac has joined #yosys
citypw has quit [Ping timeout: 264 seconds]
emeb_mac has quit [Quit: Leaving.]
citypw has joined #yosys
SpaimaCarpatilor has quit [Remote host closed the connection]
dys has joined #yosys
dys has quit [Ping timeout: 256 seconds]
dys has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
jakobwenzel1 has joined #yosys
elfGamal has joined #yosys
hackerfoo has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
captain_morgan has quit [*.net *.split]
elGamal has quit [*.net *.split]
hackerfoo has joined #yosys
dys has quit [Ping timeout: 250 seconds]
dys has joined #yosys
klotz has joined #yosys
lambda has quit [Quit: WeeChat 2.7.1]
lambda has joined #yosys
klotz has quit [Quit: klotz]
twnqx has joined #yosys
gromero has joined #yosys
Stary has quit [Ping timeout: 268 seconds]
Stary has joined #yosys
fevv8[m] has quit [Ping timeout: 245 seconds]
fevv8[m] has joined #yosys
_whitelogger has joined #yosys
daniellimws has joined #yosys
kbeckmann has joined #yosys
rjeschmi has joined #yosys
emeb has joined #yosys
az0re has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 246 seconds]
s_frit has joined #yosys
jakobwenzel1 has quit [Remote host closed the connection]
az0re has joined #yosys
dys has quit [Ping timeout: 264 seconds]
klotz has joined #yosys
gromero has quit [Ping timeout: 246 seconds]
emeb_mac has joined #yosys
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
gorbak25 has quit [Ping timeout: 260 seconds]
gorbak25 has joined #yosys
klotz has quit [Quit: klotz]
<twnqx>
*sigh* is it really impossible to get a d-flipflop with asynchronous reset implemented in an LP384? nextpnr-ice40 threw "ERROR: cell type '$_DFFSR_PPP_' is unsupported" at me
<daveshah>
You can't have a flipflop with both async set and reset
<daveshah>
At least without horrible trickery involving latches that's almost guaranteed to fail
<daveshah>
Either async set or async reset is fine though
<mwk>
twnqx: please show the code.
<mwk>
async reset FF is definitely supported in ice40
<twnqx>
(yes, only one bit shall have async reset, i can split this)
<mwk>
you have mixed blocking and nonblocking assignment to the same thing, don't do that
<mwk>
but, putting that aside
<mwk>
when I'm asking for code
<mwk>
I mean actual file I can download together with a yosys command that reproduces the issue
<mwk>
I'm not going to take 20 guesses at what other stuff you have in your file aside of the small snippet that you posted that could also be causing the issue
<twnqx>
right, right, working on it
<mwk>
alright...
<mwk>
so there are a few bugs here
<twnqx>
i am really long gone from FPGA code writing... last was during diploma thesis 10 years back
<mwk>
twnqx: first of all, this code is *not* legit
<mwk>
as in, it's not a valid async reset pattern, and it will result in synth-sim mismatches even if the synthesizer accepts it
<twnqx>
because of its multiple clock domains?
<mwk>
no
<mwk>
because you're resetting part of the register
<mwk>
hmm
<twnqx>
so i need to break it up? i suspected that much due to the warning
<mwk>
or is it...
<mwk>
oh yes, there is a sim-synth mismatch
<mwk>
consider what happens when PROGRST is 1, and there's a rising edge on SCLK
<twnqx>
i'd expect the register's bits 7 and 5-0 to be unchanged and 6 guaranteed zero, as that's what's written
<mwk>
in synth, FFs on bits other than 6 will get a new value as usual (because they're plain resetless FFs), while in sim nothing will happen (because the process goes into the first branch of the if)
<twnqx>
(but honestly, it doesn't matter)
<mwk>
at the same time, yosys is doing.... I don't know what it's doing, but something really dumb
<twnqx>
so i'm breaking bit 6 out, not that bad
<twnqx>
right, then it compiles (explicitly modeling the behaviour you describe)
<daveshah>
Random guess is that it's trying to create some kind of latch type construct using set and reset for the bits that don't change
<daveshah>
Instead of a clock enable
<mwk>
correct
<twnqx>
i mean, there's even unused bits in the "register", but those are optimized out internally, right?
<twnqx>
i think i read that in the full output at some point
<mwk>
alright, so... I think the construct is synthesizable in theory, but it doesn't match the 1364.1 patterns so probably synthesizers won't actually support it?
<mwk>
as in, can be made into hardware without sim mismatch
<twnqx>
it's also not needed by me, either way (not changing, or actually loading) is fine with me
<daveshah>
Yeah, the clock enable approach seems correct to me too
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
<mwk>
daveshah: right, the question here is whether I should file a bug for shitty synth result, or a bug for a missing error for invalid code
<mwk>
(or at least warning)
<daveshah>
Personally the latter
<daveshah>
if its not in 1364.1
<mwk>
I'd need to read it closely
<twnqx>
well, there *is* a warning
<mwk>
it... doesn't say a whole lot
<mwk>
so I have nfi what's actually supposed to happen
<twnqx>
well, if the error on nextpnr wouldn't have been there, i'd have tried splitting the reg into loading and resettable parts on my own :X
<mwk>
heh
* mwk
has an item on her TODO list that would emulate async set+reset FFs using async set-or-reset FFs + latches
<mwk>
... wait, can I actually get a latch on ice40?
<twnqx>
in worst case, boil it down to the NAND gate equivalent, i guess...
<twnqx>
but it would be costly in cell count
<daveshah>
A mux in a LUT with feedback is how it ends up
<daveshah>
iCE40 doesn't have native latches in fabric
<mwk>
so, non-initializable latch...
<daveshah>
The only latches it has are "power saving" ones for the IO inputs with one enable per bank
<daveshah>
There's probably some even more crazy way to initialise it
<ZirconiumX>
daveshah: I'd noticed in the ALM block diagram that it had feedback muxes from flop out to LUT in, and now I know what they're for
<daveshah>
Flop out to LUT in sounds more like for things like counters and FSMs
<mwk>
yeah
<ZirconiumX>
Well, as far as I can tell the ALM can't directly implement a latch, which is a bit problematic
<daveshah>
Incidentally cursed thing I read a few weeks ago - Ultrascale FPGAs can apparently turn the leaf clock buffer into a pulse generator and then use latch mode for associated FFs to borrow timing slack in some cases
<daveshah>
I've never actually been able to trigger this in Vivado though
<mwk>
whaaat
<mwk>
the BUFCE_LEAF thing?
<daveshah>
Yeah
<daveshah>
It has programmable delay too, which is more commonly used to meet marginal timing
<mwk>
... huh
<daveshah>
Meanwhile the row buffers also have programmable delay used to balance out skews in the clock distribution
<mwk>
that's some crazy shit
<mwk>
... now I need to get that fuzzer up and running
<daveshah>
It's enabled by NoTile/Delay_Arc_Index=<number> after the route through pip in FIXED_ROUTE
<daveshah>
I strongly suspect a different kind of NoTile node would enable the pulse generator mode but I haven't figured out what it's called
<mwk>
mhm
<daveshah>
The other nice Ultrascale trick is the programmable clock inversion in the leaf buffers to compensate for possibly inverted routing
<daveshah>
Except for the XIPHYs which don't have leaf buffers so the final site inversion is xor'd with the clock routing inversion state
<daveshah>
Overall other than those two things the Ultrascale is surprisingly non-cursed imo
<mwk>
it really sounds like the arch where they changed everything
<daveshah>
Yeah, quite different INT and logic structure
<daveshah>
Also all the INT pips are good old fashioned one bit per pip, no decoding
<mwk>
no wonder they had to dump ISE for this
<daveshah>
From my nextpnr experience it's a fair bit harder to route for than xc7
<daveshah>
Certainly feels like fewer routing resources
<twnqx>
so.. gating the reset by changing "if (PRGOGRST)" to "if (PROGRST && cmd[7])" makes yosys not recognize the reset construct any more, mh
<mwk>
that's definitely not a synthesizable construct
<mwk>
the condition in the if and the posedge in the trigger list must match
<mwk>
use "assign arst = PROGRST && cmd[7];" and use that if you must
<twnqx>
already did that, yes
<twnqx>
if i'm ever bored enough i'll try what ISE does with constructs like this :>
<mwk>
that'd be interesting, yes
<mwk>
(the first one; the second one is obviously non-synthesizable)
<ZirconiumX>
Writing in Verilog feels a lot like applied cargo-cult programming: writing in a specific pattern in the hopes of achieving your end goal
* mwk
mutters something about BRAM inference
<ZirconiumX>
It's one of the things I like about nMigen: to get a memory you instantiate a memory
<twnqx>
that's how i did it with ISE too... bram primitives
<ZirconiumX>
mwk: Yosys is at least not the worst BRAM inference system I've seen
<mwk>
that's hopelessly tied to a particular FPGA architecture though
<mwk>
nmigen has it somewhat generic
<ZirconiumX>
Basically nMigen asks Yosys to do it for it
<mwk>
(not quite as generic as I'd like, but eh, that's not going to improve until we get our shit together in yosys)
<az0re>
What was that you were muttering, mwk?
<az0re>
:)
<ZirconiumX>
Anyway, Quartus has major problems with initialised memories. You know, like the ones nMigen produces.
<az0re>
How bad is it in Yosys?
<mwk>
ZirconiumX: ... I managed to segfault ISE with weirdass memory corruption while trying to infer a simple memory
<mwk>
... in class, in front of all my students, on projector
<mwk>
az0re: lots of features are just not supported
<az0re>
At least you have witnesses
<az0re>
I see
<mwk>
the major problem being that the only supported kind of memory is simple dual port
<mwk>
so — no true dual port, no single port
<az0re>
Are there any tickets for BRAM inference?
<mwk>
yes
<ZirconiumX>
It will (pathologically slowly) write the inline `initial` block into an Altera MIF, turn the memory into an `altsyncram` that references the MIF, load the MIF, turn the MIF into an inline memory parameter and then actually initialise the memory.
<mwk>
but eh, that's beyond tickets
<mwk>
it just need a full redesign
<ZirconiumX>
🎵 rip it up and start again 🎵
<twnqx>
i think my toolchain back in university was synplify + xilinx' place and route tools, all in a makefile
<az0re>
I see
<az0re>
I'm not the right person to do it but it would obviously be great to have good BRAM inference support
<mwk>
one day
<ZirconiumX>
And one day we'll replace ABC too
<az0re>
Anything we can do to promote device independence helps
<mwk>
first, someone needs to sit down, read blockram documentation for every single reasonably-popular FPGA architecture, and make note of supported features
<ZirconiumX>
But it's a problem people run away screaming at when you introduce the real world