rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
gregdavill has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
OmniMancer has joined ##openfpga
azonenberg_work has joined ##openfpga
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 265 seconds]
Thorn has quit [Ping timeout: 248 seconds]
rohitksingh has quit [Ping timeout: 260 seconds]
genii has quit [Quit: GO LEAFS GO!]
GenTooMan has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
ZombieChicken has joined ##openfpga
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<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
<omnitechnomancer> what assertion failed?
<tnt> what(): Assertion failure: iez != -1 (/home/tnt/projects/ecp5/nextpnr/ice40/bitstream.cc:566)
<tnt> looks like I screwed up an IOB.
<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.
Neuromod has joined ##openfpga
Neuromod has quit [Ping timeout: 260 seconds]
Asu has joined ##openfpga
X-Scale has joined ##openfpga
emeb_mac has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
mkru has quit [Quit: Leaving]
Asu has quit [Quit: Konversation terminated!]
mumptai_ has quit [Quit: Verlassend]