Asu` has joined ##openfpga
<ZirconiumX> Also fraught with people not reviewing my Yosys pull request, but that's by the by
Asu` has quit [Client Quit]
mwk has quit [Ping timeout: 268 seconds]
mwk has joined ##openfpga
<GenTooMan> Yosys is definitely imperfect, it is however functional enough to use. Since I haven't used Quartus since the last decade I can't comment. Sorry to hear about the MiSTer experience, why can't we all get along? :D
<ZirconiumX> I have an ICE that is unique to me
<GenTooMan> is that good or bad?
<ZirconiumX> And I get it pretty often when trying to feed Yosys netlists to Quartus
<ZirconiumX> Bad, because Intel are basically guaranteed to never fix it
<TD-Linux> so you get to guess at workarounds?
<ZirconiumX> All I know is that it happens when it tries to expand altsyncram "primitives"
<tpw_rules> ICE?
<ZirconiumX> Internal Compiler Error
<tpw_rules> oof
tlwoerner has joined ##openfpga
Bob_Dole has joined ##openfpga
genii has quit [Quit: Time for beer and hockey.]
<GenTooMan> Well could be worse ... I think. Maybe not if you can't do anything that kind of stops everything. How has your PS2 hardware fun progressed?
<omnitechnomancer> antic mix of 4 and 5, half the slices are lut4s and can be used as RAM, the other half are LUT5 which can also be used as two LUT4s with shared inputs
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
Bike has quit [Quit: Lost terminal]
uovo has joined ##openfpga
oeuf has quit [Ping timeout: 276 seconds]
Thorn has quit [Ping timeout: 276 seconds]
oeuf has joined ##openfpga
uovo has quit [Ping timeout: 276 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
____ has joined ##openfpga
Hamilton has joined ##openfpga
AndrevS has joined ##openfpga
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
Jybz has joined ##openfpga
Zorix has quit [Ping timeout: 250 seconds]
Zorix has joined ##openfpga
<tnt> Does anyone know how the IO2 / IO3 lines of the ECP5 configuration port behave during configuration if you're using dual io config (and not quad io) ? I'm hoping that (1) they'd behave the same on the crosslink-nx (2) they stay hi-z ...
<daveshah> I guess they can't do anything too weird, otherwise a flash with all lines connected but in SPI mode could end up with hold asserted
<tnt> good point. I want to use them for soft USB, but I'm afraid they'd be driven high or have pull-ups strong enough to be detected by the host side.
ZombieChicken is now known as ZombieGoose
Asu has joined ##openfpga
ZombieGoose is now known as ZombieChicken
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Thorn has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 265 seconds]
<q3k> q3k | so, anyone every noticed a regression in yosys that stops it from inferring some kinds of BRAM?
<mwk> ugh
<mwk> that... may not be unintended
<mwk> got a testcase?
<mwk> *sigh* we need to take our bram passes and blow them all up
<q3k> mwk: i got a big honking .v for ya
<q3k> if you wanna try minimizing
<q3k> ./yosys -p 'read_verilog /home/q3k/Projects/m16c-interface/adapter/build/top.v; attrmap -tocase keep -imap keep="true" keep=1 -imap keep="false" keep=0 -remove keep=0; synth_ice40 -top top -edif dupa.edif'
<q3k> which i've nabbed from migen-at-the-time's build process
<q3k> as tnt mention, this might be instead a migen bug where it just generates a weird fifo
<q3k> since that bram is the fifo backing ram
<q3k> i'll also try bumping the version of migen i use
<q3k> bumped migen to current master, generates 'bad' verilog anyway
<q3k> so either a migen bug, yosys bug or i'm holding the fifo wrong :)
pie_ has quit [Ping timeout: 276 seconds]
<mwk> hrm
<mwk> well there's an obvious async read port here...
<q3k> there is
<q3k> doesn't the ice40 have async read bram?
<q3k> i don't remember
<mwk> does anything have async read bram? that sounds strange
<q3k> fuck if i know
<q3k> i can just switch to a SyncFIFOBuffered that will not use an async read port from what i understand
<mwk> anyway, what happened here
<mwk> is that the async port was being converted to a sync port with a hammer before
<mwk> by merging the FF on address input
<q3k> i mean, it only is used in a dff anyway afterwards
<q3k> so maybe
<mwk> it's not, there's a mux
<q3k> oh
<mwk> on the output path
<q3k> what is the memory_dff pass supposed to do?
<mwk> well, initially all mem read ports in yosys are async
<q3k> This pass detects DFFs at memory ports and merges them into the memory port.
<q3k> I.e. it consumes an asynchronous memory port and the flip-flops at its
<q3k> interface and yields a synchronous memory port.
<q3k> yeah it's the hammer
<mwk> memory_dff looks for two patterns
<mwk> reg <= mem[addr];
<mwk> ie. output of async read port going straight to register and nothing else
<mwk> and the other pattern
<mwk> addr <= something;
<mwk> the first is the usual sync memory pattern (which you don't have here)
<mwk> the second is an alternative one: merge a FF on address input into an async port to get a sync port
<mwk> but it turns out it's only a sound transformation if the address register isn't initialized
<mwk> and it is initialized in your case (to 0)
<mwk> the yosys commit you references adds the check that the address reg is not, in fact, initialized
<mwk> thus preventing memory_dff from working
<mwk> whitequark: what do you think of it?
<q3k> yeah, i'm not sure either
<mwk> I think we can loosen the check in memory_dff pass a bit
<q3k> or make migen not emit initial values in this case, if possible?
<mwk> because it's still a sound transform if the address is initialized, but the memory is not
<mwk> (the output will be 'x either way)
pie_ has joined ##openfpga
<mwk> (or is it? double check plz)
<mwk> hmm
<mwk> or wait
<mwk> actually, is the second pattern *ever* sound in the presence of two different clocks
<mwk> .... this is going to be another messy yosys JF agenda item for next week, isn't it
<mwk> q3k: so my thoughts are, yosys is being overly permissive here, and the circuit is not realisable with sync read port without very shaky unsound transforms
<mwk> yeah, the second transform is unsound as fuck
<mwk> q3k: sorry, your fifo (or its inference) was built on a lie
<q3k> it's a migen fifo
<q3k> SyncFIFO
<mwk> well, that's why I'm summoning whitequark
* ZirconiumX complains bitterly about the Verilog Quartus Mapping format
<tnt> mwk: when you have different clocks, read and write at the same address is pretty much always undefined in brams anyway.
Bike has joined ##openfpga
mifune has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
SpaceCoaster has joined ##openfpga
SpaceCoaster_ has joined ##openfpga
SpaceCoaster has quit [Read error: Connection reset by peer]
<ZirconiumX> Desperation level: outputting EDIF instead of VQM to circumvent parser bugs
OmniMancer has joined ##openfpga
SpaceCoaster_ has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
SpaceCoaster has joined ##openfpga
<ZirconiumX> *** Fatal Error: Access Violation at 0X00007FFF979FCC69
<ZirconiumX> I broke Quartus in a new and exciting way
<GenTooMan> ZirconiumX perhaps it was already broken and you merely discovered another flawed facet?
<ZirconiumX> Of course, but the alternative is trying to implement PnR by myself
<ZirconiumX> And I do not have the time or focus for that
<omnitechnomancer> ZirconiumX: do you have any routing knowledge?
<ZirconiumX> Little to none
<omnitechnomancer> most inconvenient then :/
<ZirconiumX> I would have to RE the chip data to get that
<omnitechnomancer> anticw: Sorry I didnt ping you right before, its a mixture of LUT4 and LUT5
<omnitechnomancer> ZirconiumX: no convenient routing pip format to explore then?
<ZirconiumX> There's a text-based RCF format for this, but it needs a special parser, being a unique format
<omnitechnomancer> Well I guess given your existing trouble with parsers it probably has many ways to crash it trying to do anything interesting
____ has quit [Remote host closed the connection]
<ZirconiumX> Am I just naturally cursed with bad luck regarding vendor tools?
<OK_b00m3r> i don't think it's you
<omnitechnomancer> I think Altera might just have extremely cursed vendor tools
<q3k> they're all cursed
<omnitechnomancer> I am actually kind of surprised how vaguely reasonable Tang Dynasty seems so far
* jn__ is now curious about the FPGA tools of the Tang Dynasty
<omnitechnomancer> Well that is what the tools are called
<omnitechnomancer> for Anlogic
<OK_b00m3r> o_o
<omnitechnomancer> Mostly I like how not multiple Gigabytes tehy are
<jn__> weird name, but ok
<omnitechnomancer> It is kind of weird
<omnitechnomancer> Hmm, I think I need to adjust the RoutingGraph as well for my purposes, I think I will touch this tomorrow when more awake.
moho1 has quit [Quit: WeeChat 2.4]
rohitksingh has quit [Ping timeout: 250 seconds]
<GenTooMan> ZirconiumX can't even use nextpnr possibly?
<GenTooMan> ZirconiumX everytime I work on something some bizarre flaw comes out. For example ST-Link won't upgrade under linux. ST simply doesn't care about it and didn't even TRY to answer the why.
<ZirconiumX> GenTooMan: nextpnr requires bitstream and timing data from Quartus
pie__ has joined ##openfpga
<GenTooMan> ZirconiumX doesn't nextpnr use the output of yosys? Wait does yosys work with quartus?
<ZirconiumX> I'm trying to get yosys to work with quartus
<ZirconiumX> Since Quartus accepts netlists in EDIF and VQM
moho1 has joined ##openfpga
Kekskruemel has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
<omnitechnomancer> GenTooMan: to write a nextpnr arch you require knowing how the placement and rouing of things on the FPGA work, you need a database of how things can actually be routed
<omnitechnomancer> and then you need a way to turn the result into a bitstream
moho1 has quit [Quit: WeeChat 2.6]
moho1 has joined ##openfpga
Hamilton has quit [Ping timeout: 240 seconds]
<GenTooMan> Ahh now I see the disruption of the process. I can see that being frustrating at least. Sort of like wanting to make a plugin for Eclipse kind of thing.
<GenTooMan> people always complained about Eclipse because making a plugin fort it required them to use Java which is not a very common language (my explanation) so plug ins for Eclipse often didn't get made for compilers et al. That's changing some because jython and things that create java byte code. Is quartus written in Java C/C++, or "WTH"?
OmniMancer has quit [Quit: Leaving.]
<OK_b00m3r> not a very common language? :)
<GenTooMan> not compared to javascript C C++ python etc.
<OK_b00m3r> oh
<ZirconiumX> GenTooMan: C++.
<SpaceCoaster> omnitechnomancer: I agree with you about TD. Small and not unpleasant at all. Running from makefiles is easy. Do you know how to make it produce fewer messages? It seems a bit chatty.
<GenTooMan> ZirconiumX: that explains the maintenance of quartus. I presume your running it under windows too. I definitely commiserate with you on that.
<ZirconiumX> I mean, it works fine under either Windows or Linux
Kekskruemel has quit [Ping timeout: 268 seconds]
mkru has joined ##openfpga
<GenTooMan> Linux? really... Well I guess since Intel's entire engineering staff uses Linux that might give impetus to that happening. Anyhow C++ is hard to maintain, even if one was the original programmer.
<ZirconiumX> Yosys and nextpnr are written in C++ and people seem to have no real issues maintaining that :P
Bird|ghosted has joined ##openfpga
Bird|otherbox has quit [Ping timeout: 240 seconds]
<GenTooMan> Yes but... they wrote it and they did so with a staff that volunteered to work with each other. Right I'll explain in as brutal fashion as possible. It depends on who wrote it and their style of writting. If the mentality and style are mature good, else God help whoever has to keep it working. It's like mentors PADs (disaster) was purposefully made bad by the person in charge.
<OK_b00m3r> they are likely under-resourced and under excessive pressure to ship, and not allowed to pay down technical debt
Hamilton has joined ##openfpga
<GenTooMan> It's not likely a failure of the people doing the work but those who are in charge of them. Mentors PADs suffered such a horrible fate.
<GenTooMan> Actually most of my projects suffered from that as well. I wonder how people can be such horrible planners.
_whitelogger has joined ##openfpga
<OK_b00m3r> GenTooMan: exactly
<GenTooMan> That is a big concern, it seems to have become "acceptable" practice. One literally has to lie to people to get that past most competent upper level managers.
<kc8apf> Quartus was designed for *nix first.
<kc8apf> Vivado ended up being some hellish amalgamation of Java calling C++ and running a TCL interpreter.
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
mkru has quit [Quit: Leaving]
Hamilton has quit [Quit: Leaving]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 265 seconds]
Bob_Dole has joined ##openfpga
Asu` has quit [Ping timeout: 252 seconds]
Asu has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined ##openfpga
X-Scale` is now known as X-Scale
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 246 seconds]
Asu` has joined ##openfpga
Asu` has quit [Client Quit]
Asu has quit [Ping timeout: 265 seconds]
Asu` has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 268 seconds]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 268 seconds]
Jybz has quit [Quit: Konversation terminated!]
AndrevS has quit [Quit: umount /dev/irc]
Asu` has quit [Quit: Konversation terminated!]
ZombieChicken has left ##openfpga ["Using Circe, the loveliest of all IRC clients"]
Kekskruemel has joined ##openfpga
Kekskruemel has quit [Quit: Leaving]