clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
jkiv_ has joined #yosys
jkiv has quit [Ping timeout: 260 seconds]
jkiv_ has quit [Ping timeout: 252 seconds]
sebastian has joined #yosys
sebastian is now known as Guest60635
ar3itrary has quit [Ping timeout: 256 seconds]
Linko has joined #yosys
Linko has left #yosys [#yosys]
m_w has quit [Ping timeout: 240 seconds]
<strfry> i understand that icestorm partly supports lattice ultraplus and it's DSP resources. but i don't see it in yosys, does that mean it's not actually supported yet for synthesis?
<awygle> strfry: what is 'it' in this context? specifically the DSP, or the ultraplus generally?
<awygle> regardless, the answer is "no, synthesis is supported". the DSP cells are in https://github.com/YosysHQ/yosys/blob/07bfe8ba4099d0d9e040923447583446449d73b1/techlibs/ice40/cells_sim.v as SB_MAC16
<strfry> awygle: thanks, i just grep'ed for DSP
<awygle> strfry: no problem. the ice40 primitives all start with SB_ (for siliconblue, who originally developed the series before lattice bought them)
<strfry> besides that, finding out stuff about an FPGA architecture by grep'ing through the toolchain source is just *so* awesome :)
<awygle> wellllll yes :) someday maybe we'll have documentation. ENOTIME.
<strfry> no sarcasm intended ;)
<awygle> haha well yes i suppose you couldn't do that with vivado
<strfry> actually, i'm currently trying to figure out if converting 6 PDM microphone streams on a single 5k device is feasible or not
<strfry> just following a crazy idea ;)
<strfry> i found some lattice example code for 4 microphones, and that uses 4 SB_MAC16's.
<awygle> makes sense to me
<strfry> i found 8 lines of MAC16 in the chipdb file, does that mean that there are 8 available?
<awygle> i believe so yes. i know for sure there's at least one 8 DSP SKU in the ultraplus line
leviathanch has joined #yosys
<strfry> finally found it in the datasheet. the "big" UP5K has 8 DSP blocks :)
dys has quit [Ping timeout: 276 seconds]
dys has joined #yosys
adj__ has quit [Ping timeout: 252 seconds]
adj__ has joined #yosys
eduardo_ has joined #yosys
eduardo__ has quit [Ping timeout: 248 seconds]
nrossi has joined #yosys
m_t has joined #yosys
m_w has joined #yosys
m_w has quit [Ping timeout: 276 seconds]
leviathanch has quit [Remote host closed the connection]
eduardo_ has quit [Read error: Connection reset by peer]
maroni has joined #yosys
maroni has quit [Quit: leaving]
m_t has quit [Quit: Leaving]
m_w has joined #yosys
m_w has quit [Quit: Leaving]
leviathanch has joined #yosys
leviathanch has quit [Read error: Connection reset by peer]
DeadSanity has joined #yosys
DeadSanity has left #yosys [#yosys]
leviathanch has joined #yosys
gnufan1 has joined #yosys
gnufan has quit [Ping timeout: 256 seconds]
eduardo_ has joined #yosys
gnufan has joined #yosys
gnufan1 has quit [Ping timeout: 240 seconds]
nrossi has quit [Quit: Connection closed for inactivity]
<strfry> i'm running into a problem with this lattice code, yosys emits a '$mem' cell that is not understood by arachne
<strfry> my guess is that some HDL that intends to synthesize to block RAM is not properly mapped by yosys onto hardware resources, do i need to describe that memory in a different way?
<awygle> strfry: what synth command(s) are you using?
<strfry> if you mean the conent of my .ys file, lots of read_verilog, then "hierarchy; proc; opt; techmap; opt"
<strfry> then synth_ice40
ZipCPU|Laptop has joined #yosys
dys has quit [Ping timeout: 248 seconds]
<awygle> do you see "Executing MEMORY_BRAM pass" in your yosys output?
<awygle> i think you probably don't want "techmap" in there actually, though i'm not sure. synth_ice40 runs techmap several times internally so you might be over-helping the synthesizer by doing it yourself
<awygle> strfry: ^ i'd just try it with synth_ice40 alone and add other stuff in afterwards
<strfry> cool, that brought me one step further
<strfry> now arachne crashes with std::out_of_range ;)
<awygle> see http://www.clifford.at/yosys/cmd_synth_ice40.html for hte list of what synth_ice40 runs so you can decide what else you might want to do
<ZipCPU|Laptop> I might be jumping into the conversation in the middle, but ... what chip are you trying to build for?
<awygle> strfry: i'm guessing you're using very recent versions of icestorm, yosys, and arachne? "use latest" is my only real suggestion for your out_of_range problem
<strfry> awygle: yeah, it's probably time for a pull and rebuild cycle
<strfry> ZipCPU|Laptop: iCE40UP5K
<ZipCPU|Laptop> So ... yosys should handle this as is, right? The issue is in arachne-pnr?
captain_morgan has quit [Read error: Connection reset by peer]
captain_morgan has joined #yosys
<strfry> ZipCPU|Laptop: yes, issue #1 was that i've no idea what i'm doing, and how to use yosys' synth commands
<ZipCPU|Laptop> Shouldn't you just be able to use synth_iCE40?
<ZipCPU|Laptop> No other commands required?
<strfry> seems like it
<strfry> now i'm in the next step, and arachne chokes on the design for some reason
<ZipCPU|Laptop> That's how it is "supposed" to work, if it doesn't work that way then let's file an issue
<strfry> updating to the newest arachne didn't help, i'm making a debug build now
<ZipCPU|Laptop> How is it crashing?
<strfry> in the route step, it throws a std::out_of_range in map::at
<ZipCPU|Laptop> Are you using any PLL's?
<ZipCPU|Laptop> There is a known issue with PLL's and SDRAM's on some boards.
<strfry> not that i know of
dys has joined #yosys
<ZipCPU|Laptop> Any other SB_ components?
<strfry> mainly SB_MAC16s
<mwk> so... you guys made a fully open-source toolchain for ice40, right?
<mwk> how feasible would it be to extend it to, say, some spartan FPGAs?
<ZipCPU|Laptop> mwk: You might find this to be a more users channel than developers channel
<ZipCPU|Laptop> However, the Spartan question has been asked
<ZipCPU|Laptop> Not sure if it was a yosys github issue, or asked on reddit
<ZipCPU|Laptop> The answer, as I recall, was that the spartan 6 FPGA is very similar to the Xilinx-7 FPGA's, which (supposedly) are now supported.
<mwk> only synthesis though, right? no P&R?
<awygle> yes, only synthesis. i think that's an important distinction.
<ZipCPU|Laptop> yosys does not do PNR. There are other options for P&R, none (to my knowledge) fully supporting Xilinx parts yet.
<awygle> the P&R tool for the ice40 toolchain is quite family-specific
m_w has joined #yosys
<awygle> there's ongoing work to bring support for series 7 P&R (and ice40 P&R for that matter) to VPR, which is more flexible
<awygle> but it's not ready yet
<ZipCPU|Laptop> awygle: Thanks, that was the name I wasn't remembering.
<mwk> hmm, and is the series 7 bitstream format known?
<sorear> not completely
<awygle> mwk: that work is also ongoing
<ZipCPU|Laptop> I thought most of it was just presented at 34C4?
<mwk> okay, that's going to be interesting
m_t has joined #yosys
<awygle> mwk: so, to answer your question - adding Yosys support for synthesis is conceptually "easy", adding VPR support for placement and routing is conceptually "difficult"
<awygle> practically i suspect both would be fairly difficult but that will depend on who's doing it of course
<sorear> For the purposes of this conversation, does P&R include bitstream generation or is that a separate step?
<awygle> sorear: technically it should be a separate step but i tend to think of it as inside of routing
<awygle> technically, quite a bit of the work of placement and routing can be done without detailed knowledge of the bitstream, but historically we haven't done it that way
<mwk> we == arachne?
<awygle> i suspect you could do placement and routing in VPR without bitstream knowledge but you'd need a way to get the information back into e.g. vivado
<awygle> (which is doable but again hasn't been done before)
<awygle> mwk: we == "the open source fpga community"
<awygle> such as it is and what there is of it
<sorear> p&r needs a detailed accounting of what muxes and buffers are available, local wires, etc, which would seem to be most of the bitstream information?
<mwk> hmm
<mwk> yosys, arachne, icestorm, VPR
<mwk> anything else I should be aware of?
<awygle> mwk: i don't see you in ##openfpga, that's more of a "developer" forum than this is (although the signal-to-noise is worse in some ways)
<mwk> awygle: yeah, I kind of just crawled out from under a rock after a few years
<awygle> mwk: the openfpga project "run" by andrew zonenberg (azonenberg) supports GreenPak4 and (kind of) Coolrunner-II
<awygle> i, personally, have plans to do a lot of the stuff i described above (P&R without bitstream knowledge) as part of a project on massively parallelizing the P&R process
<awygle> (but we all know what plans without code are worth - my excuse is i just broke my foot so i've been busy)
<sorear> and if it's not xilinx, lattice, or silego the state of the art is zip?
<awygle> sorear: yes and no. often that information is available in architectural documentation. there's a big difference between "there are span-4 wires between tiles that are 4 apart" and "set bit 10235 to 1 to route tile(7, 9) pin 17 on line 128 to tile (11, 9) pin 2"
<awygle> you can do (some amount of) P&R with the former information even if you don't have the latter
<awygle> sorear: yosys has support for synthesis for a fair amount of different targets (altera, gowin, achronix iirc), and there are some bitstream projects ("vtr", which includes "vpr") for some other targets (Virtex-5 has something iirc)
<awygle> but those are the primary targets i would say
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
leviathanch has quit [Read error: Connection reset by peer]
leviathanch has joined #yosys
leviathanch has quit [Remote host closed the connection]
m_w has quit [Ping timeout: 256 seconds]
ZipCPU|Laptop has joined #yosys
m_t has quit [Quit: Leaving]
m_w has joined #yosys