az0re has quit [Remote host closed the connection]
mkru has joined #symbiflow
<sf-slack>
<olof.kindgren> Trying to build nextpnr-xilinx but I'm getting a bit confused. According to the docs I need to first download and build prjxray, but looking at the prjxray docs it seems this needs a copy of Vivado 2017.2. Do I really need all this to build nextpnr-xilinx?
<sf-slack>
<olof.kindgren> Oops. I was in the wrong project directory. Nevermind
kraiskil has joined #symbiflow
az0re has joined #symbiflow
az0re has quit [Remote host closed the connection]
ZipCPU has quit [Excess Flood]
ZipCPU has joined #symbiflow
<_whitenotifier-f>
[symbiflow-examples] tcal-x opened issue #58: Error with "make README.rst": "TypeError: Got secondary option for non boolean flag." - https://git.io/JTt08
rvalles_ is now known as rvalles
az0re has joined #symbiflow
<sf-slack>
<olof.kindgren> ok, so for nextpnr-xilinx the chip definition files are distributed with prjxray, analogous to how they are shipped with trellis and icestorm for the ecp5 and ice40 cases, right?
<daveshah>
X-ray or RapidWright
<sf-slack>
<olof.kindgren> True
<sf-slack>
<olof.kindgren> I was thinking, wouldn't it be nice if we could set the path to these files at compile-time, like we do for the other nextpnr versions?
<sf-slack>
<olof.kindgren> For me as an end-user it would be preferable
<sf-slack>
<olof.kindgren> Another option would be to do like yosys (yosys-config) and offer a command for getting relevant paths
<sf-slack>
<olof.kindgren> And still allow overriding with `--chipdb` for those who need that
<daveshah>
It's not end user ready and won't be until next year
<daveshah>
There's no point focusing on small usability issues before bigger ones like timing data and overall robustness
<sf-slack>
<olof.kindgren> I guess the only reason from my point of view would be that it can be easier to do comparisons if there's an Edalize backend for the flow
OmniMancer1 has joined #symbiflow
<sf-slack>
<olof.kindgren> Long term I'm hoping to enable external backends to plugin more easily. That way an experimental backend can be developed more easily in isolation
OmniMancer has quit [Ping timeout: 260 seconds]
kraiskil has quit [Ping timeout: 272 seconds]
<sf-slack>
<olof.kindgren> But at this point I would need a good reason to add the backend. @acomodi @kgugala, is fpga-perf-tool the main (only?) use case for this backend, or did I miss something?
<sf-slack>
<kgugala> I think it is the main use case right now. Currently we need to use edalize fork to get nextpnr (I'd be awesome to switch to mainline)
<sf-slack>
<olof.kindgren> Thanks. That's good to know. I'm starting to get a clearer view of the situation now
<sf-slack>
<olof.kindgren> I'm open to merge it even if it's not good enough for end-users yet under the condition that I know it's being worked on and that there won't be any changes coming up that will need larger changes to the Edalize backend, because that will be a mess to keep track of
<sf-slack>
<olof.kindgren> In that case it will come with a disclaimer that it's alpha quality and that vivado (or yosys+vpr?) is the better option for now
<sf-slack>
<olof.kindgren> I also think by now that it would make more sense to call the backend xray rather than nextpnr-xilinx, since that's what it's really about
<sf-slack>
<olof.kindgren> Analogous to how we have trellis and icestorm backends that uses yosys+nextpnr+<backend-specific stuff>
<tpb>
Title: El Correo Libre Issue 32. Antmicro Integrates Embench for Quick… | by Gareth Halfacree | LibreCores | Oct, 2020 | Medium (at medium.com)
<sf-slack>
<kgugala> :)
<sf-slack>
<acomodi> I think that nextpnr and xray are two separate things. Meaning that what nextpnr outputs is a fasm file, as well as vpr. XRay contains the libraries and data to write the bitstream, and calling nextpnr-xilinx "xray" might lead to confusion.
<sf-slack>
<olof.kindgren> The whole thing is slightly confusing for sure :)
<sf-slack>
<olof.kindgren> Calling it xray would be consistent with how the other yosys+nextpnr backends are called, and the yosys+vpr+fasm flow is already merged as symbiflow
<sf-slack>
<olof.kindgren> But we're at the limit of how far the naming scheme can be stretched. Ahh!! Could everyone please just stop creating EDA tools for a second?! ;)
<sf-slack>
<olof.kindgren> The other sensible (for me at least) option would be to have nextpnr as an alternative to vpr in the existing symbiflow backend
<sf-slack>
<olof.kindgren> Like the icestorm backend can switch between nextpnr and arachne
<sf-slack>
<acomodi> That makes sense I think, because the end-user can choose between a variety of options to have a final synth_tool + P&R_tool + bit_tool combination
<sf-slack>
<acomodi> The P&R_tool + bit_tool is currently merged together, hence the confusion :)
<sf-slack>
<olof.kindgren> Yeah. This was the traditional way after all, like quartus, vivado, ise etc
mkru has quit [Quit: Leaving]
mkru has joined #symbiflow
mkru has quit [Client Quit]
<sf-slack>
<blue> I'd like to file an idea about having a SymbiFlow IP integrator. I don't think that exists yet, there is an RTL viewer issue but this is more a schematic editor but with IPs
<sf-slack>
<blue> This would allow you to graphically connect IPs just like Vivado IP integrator (I think it's called) and Intel Platform Designer / Qsys
<sf-slack>
<olof.kindgren> @blue I have been trying to get some traction behind IP-XACT for many years now for this purpose
<sf-slack>
<blue> That's a standard to make the symbols and parameters to the instances right?
<sf-slack>
<olof.kindgren> It's a lot of things, but the interesting parts in this area is that you can describe the perimeters (parameters, buses and single signals) of your cores and how they are connected to other cores
<sf-slack>
<blue> Oh, so it can do inter-core stuff?
<sf-slack>
<olof.kindgren> On the graphical side there is a project called Kactus2 that hasaimed to be something that you're looking for. I have followed and worked with the Kactus2 people for a long time. Unfortunately it has been _almost_ there for a very long time, but there's always something that prevents me from using it as a daily driver
<sf-slack>
<olof.kindgren> But I have built OpenRISC-based SoCs for reference with it
<tpb>
Title: Tales from Beyond the Register Map: IP-XACT: The good, the bad and the outright madness (at olofkindgren.blogspot.com)
<sf-slack>
<olof.kindgren> Also, earlier this year I finally did something I promised never to do and wrote my own rudimentary IP-XACT to verilog generator
<sf-slack>
<olof.kindgren> I already have a python library https://github.com/olofk/ipyxact that can parse and read IP-XACT files
<sf-slack>
<olof.kindgren> Because I don't think we need another standard. We need more tooling for this standard. A graphical block diagram editor is one thing. Tools to enter and extract register maps is another. Command-line-based verilog generators is a third and so on
<sf-slack>
<olof.kindgren> And FuseSoC core description files reuses concepts from IP-XACT where it makes sense and can even parse some information from IP-XACT files in an attempt to avoid duplication
<sf-slack>
<olof.kindgren> But there hasn't been enough available time to make a real push in this area, but it's something I have seen as lacking for a long time
<sf-slack>
<blue> I agree that we should unite around one standard, but likely we need a new tool to do the graphical stuff, and unless IP-XACT can describe X/Y positions of components in relative to eachother we would need a new file format to store the schematic in
<sf-slack>
<olof.kindgren> IP-XACT supports non-standard additions (vendor extensions), so it's possible to store this info in the design/component files
<sf-slack>
<olof.kindgren> But additional metadata works too
<sf-slack>
<olof.kindgren> And yes, it would be great if someone came up with a new graphical tool
<sf-slack>
<olof.kindgren> icestudio is far too simple to be used unfortunately. There have been some experimentation with using kicad, but I worry that the conceptual mismatch might be too large
<sf-slack>
<olof.kindgren> Fun fact. Vivado can import IP-XACT 2009 files. I was looking a while ago to see if they started supporting IP-XACT 2014. Found a forum post by someone who had asked the same thing with a link to my IP-XACT blog post :)
<sf-slack>
<blue> I'd likely base the software vision (not necessarily code) on VLSI schematic like xschem then. Having multiple layers and quickly being able to go into and out of sub-schematics seems to me as a killer feature
<sf-slack>
<blue> That annoys me so much with Qsys, it's very slow to descend
<_whitenotifier-f>
[fpga-tool-perf] acomodi opened issue #245: Create separate environment for different toolchains - https://git.io/JTtSt
<sf-slack>
<blue> Then you'd need some work to make a design rule checker (DRC) just like VLSI stuff to figure out when you accidentally connected two different clock domains or need to insert a bus arbiter
<sf-slack>
<blue> And then there of course needs to be a library with the bus arbiters and clock crossing helpers
<sf-slack>
<blue> Did I dream of that orpsoc-cores has stuff like that?
<sf-slack>
<blue> I seem to recall having conversations with @olof.kindgren about wishbone arbiters and autogenerated code like 7 years ago
<sf-slack>
<olof.kindgren> I have a library called wb_intercon that can generate bus interconnects. I have even written (but not released) support for generating an accompanying IP-XACT component description for the interconnect
<sf-slack>
<olof.kindgren> orpsoc-cores is mostly deprecated but you can find it in the new base library fusesoc-cores
<sf-slack>
<olof.kindgren> FuseSoC generators is another thing that intends to wrap/replace proprietary vendor standards. It's designed for the cases where you need to generate verilog, vhdl or something else that the EDA tools understand from another format
<sf-slack>
<olof.kindgren> It can be ipxact to verilog, migen to verilog, C code to a $readmemh file, a set of defines from a database or whatever
<sf-slack>
<olof.kindgren> They are created for FuseSoC, but can be used standalone as well
<sf-slack>
<olof.kindgren> One mid-term goal is to be able to generate stand-alone IP cores from most Litex cores so that they can be easily dropped into traditional verilog flows
<sf-slack>
<blue> The project could be called intergreat
<_whitenotifier-f>
[fpga-tool-perf] acomodi opened issue #246: Enable the arty a7 100T board - https://git.io/JTt9w
<sf-slack>
<olof.kindgren> :)
<sf-slack>
<blue> Probably it would make sense to have some middle-representation between the graphical schematic and the generated HDL. Something that is like a netlist. Would make it easier for other tools to also generate interconnected designs
<sf-slack>
<blue> Kaktus2 looks pretty good
<sf-slack>
<olof.kindgren> Kactus2 is definitely good enough for many things. Then there are some design decisions that I'm not super excited about. Some can be worked around, and others not
<_whitenotifier-f>
[yosys-symbiflow-plugins] tmichalak opened issue #48: Improve get_nets to return logical nets instead of wires. - https://git.io/JTtdP
citypw has quit [Ping timeout: 240 seconds]
<sf-slack>
<blue> In my head I'm visualizing something more free layout wise than Kactus2 though, like how electrical schematics are free. Blender's Node Editor comes to mind in how they have made more or less parameterizable "IPs" easy to connect to eachother
<sf-slack>
<blue> Qsys is really annoying when the designs get large in that regard
OmniMancer1 has quit [Quit: Leaving.]
<sf-slack>
<kgugala> gi
<sf-slack>
<kgugala> sorry, wrong window :)
<sf-slack>
<olof.kindgren> When it comes to EDA tools it's always a better idea to look at other things than existing EDA tools for inspiration since other tools generally make more sense :)
<sf-slack>
<olof.kindgren> And yes, the Kactus layout constraints are awful
<sf-slack>
<kgugala> you need to connect it correctly
<sf-slack>
<kgugala> SWDIO line is connected to TDI and TDO
<sf-slack>
<olof.kindgren> ah ok. I see it
<sf-slack>
<kgugala> the resitor there is quite important
<sf-slack>
<olof.kindgren> And then they just run the ft232h in jtag or spi mode I guess
<sf-slack>
<olof.kindgren> JTAG. See now
<sf-slack>
<kgugala> yep
<sf-slack>
<olof.kindgren> Got it. Then I need to check if I have any FTDI chips with easily accesible pinout that can run in JTAG mode. Should be able to use the USB blaster otherwise I guess
<sf-slack>
<kgugala> the toolchain can also generate programming script for segger JTAG programmer
<sf-slack>
<olof.kindgren> Hmm.. Does it matter which JTAG programmer it is? Doesn't OpenOCD provide abstraction for the type of JTAG programmer?
<sf-slack>
<kgugala> if you use openOCD it does not matter
<sf-slack>
<olof.kindgren> Cool. And there's a driver for the USB Blaster, so I'd thought that could work
<sf-slack>
<kgugala> mhm - it can work
<sf-slack>
<kgugala> haven't tested this combo
<sf-slack>
<olof.kindgren> I think my only standalone FTDI adapter is an FT232R which only implements UART, so the Blaster is probably the only real JTAG adapter I have with OpenOCD support
<sf-slack>
<kgugala> `top.cfg` is generated by the toolchain from bitstream file
<_whitenotifier-f>
[symbiflow-examples] tcal-x opened issue #59: Redundant conda download when doing 'make README.rst' - https://git.io/JTqND
<sf-slack>
<olof.kindgren> Thanks. I think I have the concept now and I believe it should work with any JTAG adapter, so I'll might give it a try tomorrow unless I finda proper SWD adapter somehwere before that
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #symbiflow
kraiskil has joined #symbiflow
awordnot has quit [Quit: Ping timeout (120 seconds)]
awordnot has joined #symbiflow
Ultrasauce has quit [Remote host closed the connection]