<omnitechnomancer>
pepijndevos: how long does your nextpnr-generic script for gowin take to construct the FPGA structure?
Hamilton has joined ##openfpga
Jybz has joined ##openfpga
Zorix has quit [Ping timeout: 250 seconds]
Zorix has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
Thorn has joined ##openfpga
<omnitechnomancer>
The Anlogic tools do seem to like having heaps of bad FD errors and crashing the moment anything unexpected happens
<omnitechnomancer>
Oh actually the bad FD errors are the result of the aftermath of an assertion
<omnitechnomancer>
it just asserts sometimes
<omnitechnomancer>
this case I think is the vailidity check for ripple mode slices
<pepijndevos>
omnitechnomancer, depends on the size of the FPGA, but certainly more than a few seconds
<omnitechnomancer>
pepijndevos: I think mine wound up being a few minutes :/
<pepijndevos>
Yea, it takes a while... I think the new chipdb managed to speed it up a little, but... still slow.
Asu has joined ##openfpga
<omnitechnomancer>
I am trying to find the motivation to make changes to the routing graph adapted from libtrellis so that I can reasonably export a routing db for nextpnr
<pepijndevos>
How many luts does an analogic chip have?
rohitksingh has joined ##openfpga
<omnitechnomancer>
19600 for this one, but only half were exposed in the nextpnr generic backend
<pepijndevos>
Oh yea, Gowin devices I've tested so far have 9k luts. That explains something ;)
<omnitechnomancer>
I think most of the time was actually setting up the intertile wires
<omnitechnomancer>
and other routing
Jybz has quit [Quit: Konversation terminated!]
Jybz has joined ##openfpga
Jybz has quit [Client Quit]
Jybz has joined ##openfpga
Hamilton has quit [Quit: Leaving]
<omnitechnomancer>
daveshah: does lattice have verilog macros for the slices?
<omnitechnomancer>
or blackboxes I should say
<omnitechnomancer>
and do they expose the memory property of them at all?
Bob_Dole has quit [Ping timeout: 248 seconds]
AndrevS has joined ##openfpga
Morn__ is now known as Morn_
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
<tnt>
terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
<tnt>
Huh, never seen that one before, I wonder what I screwed up
<omnitechnomancer>
what were you feeding it with?
<tnt>
some big design I just modified a bit. basically an E1 recorder so I can record raw traffic to/from some GSM BTS
<tnt>
yeah, wrong param on a block, trying to use lvds on non lvds pads.
<omnitechnomancer>
ah indeed
pie_ has quit [Ping timeout: 258 seconds]
pie_ has joined ##openfpga
Bike has joined ##openfpga
GenTooMan has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
pie__ has joined ##openfpga
AndrevS has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 260 seconds]
Neuromod has joined ##openfpga
<Neuromod>
Hello
mkru has joined ##openfpga
<ZirconiumX>
Hi
<omnitechnomancer>
Hi
emeb has joined ##openfpga
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
pie__ has quit [Ping timeout: 260 seconds]
knielsen_ is now known as knielsen
Zorix has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 250 seconds]
Zorix has joined ##openfpga
Neuromod has quit [Ping timeout: 260 seconds]
Asu has quit [Remote host closed the connection]
<tux3>
>A significant part of the improvement in synchronous reset comes from synthesis optimisations that use flip-flop reset pins to clear registers whenever functional signals would otherwise assign zero to a register.
<tux3>
Is this sort of thing true with the open-source toolchains? I don't really see any improvement when switching to sync active-high control signals (actually losing a bit of area)
<tnt>
tux3: which target ?
<tux3>
Right now, iCE40. Planning to target xc7
<tnt>
ice40 you're better off using async resets.
<whitequark>
that doesn't sound right to me at all
<tnt>
xc7 it wouldn't matter.
<whitequark>
why?
<tnt>
ice40 resets are gated by the clock enable
<mwk>
ice40 doesn't seem to recognize sync SR right now
<whitequark>
oh.
<mwk>
oh, that would explain it, yes
<tnt>
err ... sycn resets. The async ones are not (obviously).
<whitequark>
does that mean yosys needs another set of dff primitives?
<mwk>
as for xc7... I've had a lot of fun last month getting it to work reasonably
<tnt>
So I use an async reset with synchronized release.
<mwk>
whitequark: yes, and I've included it in my spreadsheet
<whitequark>
ack
<mwk>
except it's not on the current... let's be generous here and call it roadmap
<mwk>
(two days ago at yosys JF we agreed that async SR+enable, sync SR, and sync SR + enable (SR having priority over enable) should become new first-class cell types in yosys)
<mwk>
anyhow; sync resets should be well-supported by synth_xilinx flow on master, and if something's going wrong, I'd like to hear about it
OmniMancer has quit [Quit: Leaving.]
<daveshah>
iCE40 has CE over sync priority - this means anything designed for Xilinx will not map well
<daveshah>
I think this is the same priority that Intel uses though
<daveshah>
Yosys should definitely map them if they're written correctly, if not something has gone wrong
GenTooMan has quit [Ping timeout: 260 seconds]
<mwk>
daveshah: I don't think we have a techmap rule to recognize that pattern for ice40
<mwk>
that'd need some hackery in dff2dffs
<daveshah>
No it's a custom pass
<mwk>
and dff2dffs is not even called in ice40
<daveshah>
ice40_ffssr
<mwk>
oh?
<mwk>
oh.
<daveshah>
or something like that
<mwk>
*sigh* why is it not in dff2dffs
<daveshah>
It's from way before I added dff2dffs
<tnt>
AFAIK it maps them fine, you just end up with more logic on the CE line because it's 'ORed' between the reset and ce line that you'd fine somewhere else.
<mwk>
that's... not that bad
<daveshah>
Yes, that's right actually, matt venn had some interesting glitch issues with that
<whitequark>
wait why would that glitch
<daveshah>
(it was a dodgy design, but the transformation made it a bit hard to debug as it seemed from the Verilog that the FF should never have been enabled)
<tnt>
mwk: well more area, longer critical path, and a new control set that can't be packed with any other FF that doesn't happen to have the exact same control set.