lambda has quit [Read error: Connection reset by peer]
lambda has joined #symbiflow
plexj has joined #symbiflow
az0re has quit [Remote host closed the connection]
citypw has quit [Read error: Connection reset by peer]
plexj has quit [Remote host closed the connection]
_whitelogger has joined #symbiflow
sf-slack4 has joined #symbiflow
sf-slack has quit [Remote host closed the connection]
OmniMancer has quit [Quit: Leaving.]
az0re has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 256 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 260 seconds]
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 260 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 265 seconds]
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 246 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 260 seconds]
<litghost>
hosana: Currently we only build the conda packages for Linux. It is not suprising that OS X is not working yet. This is something we are working on.
pdp7 has left #symbiflow [#symbiflow]
mkru has joined #symbiflow
<mkru>
Is there any evaluation kit that you would recommend for playing with open source synthesis and implementation?
<daveshah>
Also note that the open Xilinx PCIe core, litepcie, being discussed is Migen not nMigen
<daveshah>
But in general LiteX stuff is possible to use from Verilog too
<litghost>
The examples for the 7-series are a mixture of Verilog and some LiteX generated
<litghost>
mkru: I also want to clarify something. We have not demonstrated LitePCIe on an open place and route flow yet. Only DDR and ethernet. There is almost certainly more work required to do 7-series PCIe on a fully open flows. However I have no reason to believe at this time it isn't simply a matter of expanding the fuzzers under prjxray to document the relevant bits.
<sorear>
is there a thing anywhere saying what is known to work on 7-series with fully open tools? I had no idea you had DDR working
<litghost>
DDR was working back in march :/ Woops. It is worth noting that it required hacking up the LiteX outputs to make it work, so we've been head down to remove those hacks.
<litghost>
We are getting very close to the point where the outputs directly from LiteX just work. There are just handful of XDC constraints we are working on finishing up
<litghost>
MMCM support is also needed for some targets, as LiteX sometimes wants to use the MMCM instead of the PLL
<litghost>
MMCM support is coming along, but not done yet
<daveshah>
I definitely had the output from LiteX working with nextpnr-xilinx directly at one point, maybe with reduced clock
<daveshah>
But yeah since then there have been quite big changes to LiteX
<daveshah>
That was also just ignoring those xdc constraints...
<litghost>
Ya, we've been working on adding support for the XDC constraints
<litghost>
It's mostly working, but still needs more iterations before it is fully baked
<daveshah>
Mmm
<mkru>
Lets assume I have some stuff written in VHDL, and I use yosys ghdl frontend for synthesis. How do I couple my part of the design with /DDR/Ethernet/PCIe or whatever part related? Do you I need to know LiteX, nMigen? I already use FuseSoc and I am more than happy, I do not want to learn another build tools.
<litghost>
Ah, tcal might have exactly what you want
<daveshah>
LiteX has some generators for generating standalone verilog cores for dram etc
<mkru>
The pictures on the symbiflow mentions tools such as yosys, nextpnr, Verilog to Routing, but examples on github all the time mention Litex or nMigen
<litghost>
So I think we need to seperate something for a minute
<litghost>
yosys consumes VHDL/verilog and generates elaborated netlists. nextpnr/VTR can then consume those elaborated netlists and generate place and routed designs
<litghost>
LiteX/nMigen/etc are generators that create VHDL/verilog/etc
<litghost>
The open P&R tools (generally) don't care where the elaborated netlist originates or what made it
<litghost>
You do need supply useful clock constraints, etc
<litghost>
So there is some coupling there
<daveshah>
Its notable that in general, both LiteX and nMigen put at least equal effort into integration into vendor tools as into open tools
<mkru>
Ok, so if you say, that you have added support for DDR, or you mention that you are working on MMCM, on which level are operating? Does support for such primitives depend on Litex or nMigen?
<litghost>
So MMCM and PHY support (e.g. GTX) are at the place and route level generally
<litghost>
So for 7 series that would be some prjxray work, and then support in the relevant P&R tooling
<litghost>
So as a concrete example, the fact that we got DDR working translates to support OSERDES/ISERDES/IDELAY and relevant differential buffer modes
<daveshah>
It is always possible to use such primitives without LiteX, nMigen, etc in Verilog or VHDL
<litghost>
Exactly
<daveshah>
However, for things like DDR3, there might not actually be an extant raw-Verilog-or-VHDL open source core that uses those primitives
<daveshah>
but that is simply because the people developing those cores have preferred to use a higher level HDL framework for more flexible meta-programming, not because anything stops you from developing one in Verilog
<mkru>
Ok, maybe I should just buy some board and check how it works. I would like to use open source tool chain for FPGA development, and I really honor what you do, but as a new comer I have an impression, that Litex and nMigen are crucial parts on this tool chain.
<daveshah>
It really depends what you are doing. You can, for example, simply treat LiteX the same way as the DDR3 core generator in Vivado which probably has some kind of scripting under its hood, but that's not something that end user considers an integral part of Vivado
<whitequark>
beyond that, as a part of working on nMigen I'm trying to improve cross-language integration; I would like to make it possible for people using Verilog to instantiate nMigen modules easily
<mkru>
Well, they should probably don't even care that some modules use nMigen
<tcal>
Hi mkru: your your "part of the design" -- do you envision it as a bus master controlling its own access to ethernet and DDR peripherals (IP blocks)? I am not yet familiar with FuseSoc -- does it use a standard bus to connect cores/blocks together?
<mkru>
no, it is rather build and dependency management tool. You can use any bus and cores you want, or no bus at all.
<mkru>
It is not build tool focused on SoCs solely, it is much more generic
<tcal>
Thanks mkru, I will probably learn it soon, I've had a few people recommend FuseSoc to me.
<sf-slack4>
<kgugala> you can always talk to @olof.kindgren
<sf-slack4>
<kgugala> :)
<mkru>
When you try it, you will realize how people coming from FuseSoc would like to use part related cores
<umarcor>
Anton's microwatt (VHDL 2008) has been tested on several boards, using open and non-open tools
az0re has quit [Quit: Leaving]
<sf-slack4>
<olof.kindgren> Hi @mkru. As @daveshah mentions, there has been work on wrapping Litex cores in FuseSoC generators
<sf-slack4>
<olof.kindgren> But this will have to be done on a core-by-core basis as there is no common way of acheiving this. The first target will be be LiteDRAM and I have submitted some patches to make integration easier
<umarcor>
overall, I also had the perception that LiteX and/or migen/nmigen are required, but as dave said, that's only because users contributing examples use Python rather than traditional HDLs.
<umarcor>
in the context of Fomu, I'm looking forward to generating some black-box USB-to-UART core with litex/nmigen, which HDL designers can then instantiate "as a vendor component"
<sf-slack4>
<olof.kindgren> Right now I generate the LiteDRAM core manually and store the generated verilog, but the ambition is to (optionally) allow users to specify the LiteDRAM generation parameters in the .core file and have it generated on the fly
<umarcor>
FTR, the people working on microwatt is combining a VHDL 2008 SoC with Litedram (Verilog). Simulation is done with GHDL's VHPIDIRECT + Verilator: https://github.com/ghdl/ghdl/issues/1335.
<sf-slack4>
<olof.kindgren> Next in line would probably be liteETH. I have used the OpenCores ethmac for ten years (I'm even listed as a maintainer) but it just isn't very good and there are surprisingly few good ethernet macs
<sf-slack4>
<olof.kindgren> FTR, Microwatt has FuseSoC support too.
<umarcor>
however, I'm not sure about microwatt being tested on open source boards using open source tools only
<sf-slack4>
<olof.kindgren> Don't know that either. I just submitted support for running on a Nexys A7
<umarcor>
on the one hand, I know they have tested it on Digilent boards. on the other hand, I know that Anton was tinkering with GHDL + Yosys and the OrangeCrab. but I don't remember any tweet/comment combining both.
<sf-slack4>
<cjearls> I have a Genesys2 board with a Xilinx Kintex-7 FPGA in it, what's the current status on the Kintex-7? Anything usable?
<litghost>
cjearls: Most focus has been on Artix and Zynq support, but we have the ability to create bitstreams for Kintex-7. We have not had someone try to stand-up support for it and test it. I believe if the Genesys2 part is in WebPack, it should be possible to add the fabric data for it, and add support for it.
<daveshah>
I don't think it is in WebPack
<daveshah>
Unless they've changed the threshold recently
<sf-slack4>
<cjearls> It is not in WebPack, Digilent provides board files for it
<litghost>
So it not being in WebPack means that the current way we generate the prjxray data won't work without a significant amount of effort. However, I believe if you have a version of Vivado that runs locally, you could in theory run the fuzzers yourself. However because we haven't tested on that part, it means you will likely hit edge cases we are not prepared to handle
<daveshah>
Does prjxray have hpio yet? I had a brief look at making it work a while ago, as I have that board too, but that was one of the limitations
<daveshah>
A lot of the interesting IO is hpio
<sf-slack4>
<cjearls> I see. I have a local version of Vivado, but I haven't ever used Symbiflow, so it sounds like getting it working for my board will probably be too difficult for me right now
<litghost>
prjxray does not have HPIO fuzzers right now
<litghost>
Do any WebPack parts have HPIO banks?
<daveshah>
Yeah, that means you'd pretty much need an ROI with that board
<daveshah>
I think the k70 probably does
<litghost>
Oh good
<litghost>
Well we have the basic database for the k70, so someone could write a HPIO fuzzer
<litghost>
Given the focus on the Artix and Zynq parts, I don't believe there has been a need to get a HPIO fuzzer stood up
<daveshah>
And if you don't care about the fancier modes, the existing HRIO fuzzer with the higher voltages removed would probably be a good base
<daveshah>
Likewise the HPIO IOLOGIC is a tiny bit different (adds the ODELAY)
<sf-slack4>
<cjearls> Do you have a recommendation for hardware to use to get involved for someone new? I have my Bachelor's degree in Computer Engineering and am currently working on my Master's degree, so I have hardware and software design experience.
<daveshah>
Depends what you want to do. icebreaker, ULX3S and Arty A35T are all quite well supported boards
<umarcor>
cjearls, how much I/O do you want? do you need DDR?
<sf-slack4>
<cjearls> I'm not sure about how much I/O. I'd like to do some RISC-V designs in the future, so I think I'd like DDR
<umarcor>
for tinkering with RISC-V from a computer architecture and SoC design perspective, I believe that absolutely any board will fit. just need to scale the design, and there are some really tiny cores out there.
<sorear>
you may have trouble with ice40lp384 ;)
<umarcor>
if you want to then run Linux and do some "acceptable" processing, DDR might be desirable. but you should first have some application that needs to crunch data fast.
<sorear>
possibly more important question: what is your budget
<umarcor>
sorear: that's true :), not the smallest, but UP5K, HX1K, HX4K, HX8K, ECP5, Artys...
<sorear>
there are a lot of good ca. 100 USD boards, if you're trying to go much less than that there are difficult choices
<umarcor>
sorear: which boards are you thinking about? On the open source side, I think 50-75€ is an acceptable budget (60-120 USB).
<sf-slack4>
<cjearls> I don't have a set budget, just nothing too crazy into the several hundreds of US dollars
<sf-slack4>
<cjearls> Both of those budgets sound reasonable to me
<tpb>
Title: Community Sourced - Lattice Semiconductor (at www.latticesemi.com)
<sf-slack4>
<cjearls> Oh, awesome, I didn't realize that they were listed on their website, that's great
<umarcor>
icebreaker, icesugar, alhambra, doppler, blackice... all of those are the same concept: uC or FTDI + FPGA. the price is similar too. so it's mostly a matter of taste.
<umarcor>
tinyfpga and Fomu don't have an auxiliary uC or FTDI. Instead, they have an HDL bootloader.
<umarcor>
orangecrab, matt venn's ecp5 dev board, radiona's ULX3S... those have the more capable ECP5 FPGAs, instead of ICE40 family devices (as all the previous).
<sorear>
if you want to do computer architecture with more than 16 kB of RAM you want something with a ddr interface
<sf-slack4>
<cjearls> A DDR interface allowing for connecting external DDR, or DDR on the board itself?
<umarcor>
from there on, I would look into Digilent and AVNET boards. which are traditional vendors for Xilinx dev boards.
<umarcor>
cjearls: typically, on the board itself
<sf-slack4>
<cjearls> I see, so the amount of RAM the board comes with is the maximum that will be available
<umarcor>
for the <150USD boards yes
<umarcor>
those are "low-cost" development boards
<umarcor>
the mid-range boards (500-2000 USD) might have RAM sockets for you to plug SODIMM or so
<sf-slack4>
<cjearls> Alright, sounds good. I'll probably start off with something cheap to get my feet wet
<sf-slack4>
<cjearls> Other than the amount of RAM, are there other things I should consider?
<umarcor>
I would look at what I expect to connect the board to: VGA/HDMI/Ethernet, camera interfaces, displays, etc. However, if you plant to focus on computer architecture and the full system stack, those are mostly irrelevant.
<sorear>
make sure the fpga chip is compatible with the tools you intend to use