*** tpb has joined #yosys | 00:00 | |
*** danieljabailey has quit IRC | 00:06 | |
*** danieljabailey has joined #yosys | 00:06 | |
*** pie___ has joined #yosys | 00:06 | |
*** pie__ has quit IRC | 00:07 | |
*** tecepe has joined #yosys | 01:56 | |
tecepe | hi, guys. yosys just came to my sight and i'm very impressed with your work. congratulations. | 02:07 |
---|---|---|
tecepe | do you know the FLAVIA project? (Free Logic Array via...) | 02:08 |
tecepe | I was wondering if I wold be able to synthesize verilog code to that kind of architecture | 02:09 |
tecepe | thank you very much for any suggestions =) i'm kind of lost on how to start | 02:10 |
ZipCPU | FLAVIA? | 02:52 |
* ZipCPU googles FLAVIA | 02:52 | |
* ZipCPU finds Offic coffee machines, mars drinks, and amazon page for a flavia creation 150 brewer ... | 02:53 | |
tecepe | ZipCPU: google for flavia free logic array | 02:56 |
tecepe | =) | 02:56 |
tecepe | it is a very simple fpga implementation | 02:57 |
tecepe | it emulates an fpga in an fpga | 02:57 |
ZipCPU | I had heard about something like this, but lost the link a long time ago | 02:59 |
ZipCPU | It was sort of a "java byte code" for FPGAs sort of thing--something that could run on all FPGA's | 03:00 |
ZipCPU | Last I heard, it wasn't very efficient at all | 03:00 |
ZipCPU | Do you have any idea how efficient flavia is? | 03:00 |
tecepe | It is not efficient | 03:01 |
ZipCPU | Got it. Okay. Yosys is about as good as the device itself, although nextpnr isn't quite as good as the device is capable of | 03:02 |
tecepe | Biggest problem is to provide access to io pins, where you need to multiplex everything to the cell | 03:02 |
tecepe | to be honest, i'm not worried at all about the efficiency | 03:02 |
ZipCPU | What are you concerned with then? | 03:03 |
tecepe | i just wanted to put this path together, but i don't know how to start | 03:03 |
tecepe | i imagine i have to "teach" yosys how to deal with that architecture, right? | 03:04 |
ZipCPU | Hmm ... Okay, good question. I know more of how to use the tools than how to build with them | 03:04 |
ZipCPU | Yes, you would need to implement your own back end | 03:04 |
ZipCPU | Many backends have already been written | 03:04 |
ZipCPU | Check out the technologymap (IIRC) directory of the yosys repo | 03:04 |
ZipCPU | You should be able to find examples of what you need within there. | 03:05 |
tecepe | ok, i think i was in the right path. i just was not able to find much info about this step | 03:05 |
ZipCPU | Perhaps the best info would be from those who have done it | 03:05 |
tecepe | I'll check that directory, thank you, this is already a good start =) | 03:06 |
ZipCPU | rqou: Were you the one who had done the coolrunner2 implementation? | 03:06 |
tecepe | Of course, if people that implemented those backend are around, it would be very helpful =) | 03:06 |
ZipCPU | daveshah has been working on an ecp5 implementation. He's on European time, so you'll have to wait for his morning before chatting with hi | 03:07 |
* ZipCPU is sadly not one of them | 03:07 | |
ZipCPU | There's two problems though that you will need to work out: 1) The yosys back end, and 2) a place and route back end | 03:07 |
tecepe | np, i'm glad you stepped in =) | 03:07 |
ZipCPU | Most of the yosys team has been working on nextpnr, so you'll find backends for ice40 and ecp5 these days | 03:08 |
* tecepe is looking at that directory | 03:08 | |
ZipCPU | The yosys directory you need is the techlibs directory | 03:08 |
ZipCPU | There's support within there for Altera/Intel, coolrunner2, easic (an ASIC flow), ecp5, gowin, greenpak4, ice40, intel, sf2, and xilinx | 03:09 |
ZipCPU | I'm familiar with only some of those---mostly the ice40s | 03:09 |
*** pie__ has joined #yosys | 03:10 | |
tecepe | that is great info | 03:10 |
tecepe | thank you | 03:10 |
*** pie___ has quit IRC | 03:10 | |
ZipCPU | ;) | 03:11 |
tecepe | nextpnr is a new place and route tool? | 03:13 |
q3k | yes | 03:13 |
tecepe | i have heard about arachne-pnr | 03:13 |
q3k | arachne was developed as an ice40-specific pnr | 03:13 |
tecepe | sorry, this world outside of vendor tools is pretty new for me | 03:13 |
q3k | nextpnr is a new tool that's portable across multiple architectures | 03:13 |
q3k | it has feature parity with arachne for ice40, and in progress support for ecp5 | 03:14 |
q3k | also a python-defined 'generic' architecture for experimentation | 03:14 |
q3k | also it has a cute qt gui | 03:14 |
q3k | and is timing driven (that's important :)) | 03:15 |
tecepe | wow, sounds fantastic | 03:15 |
tecepe | you guys have been busy =) | 03:15 |
q3k | mostly clifford and daveshah ^^ | 03:16 |
tecepe | how does this "python-defined generic" architecture work? | 03:16 |
q3k | so every architecture backend currently defines what an architecture is to the core of nextpnr | 03:17 |
q3k | by defining available Bels (basic elements, ie. physical blocks onto which Cells can be placed) | 03:17 |
q3k | Pips (programmable inter..something point, ie. programmable switches) | 03:18 |
q3k | and static Wires that connect Pips and Bels | 03:18 |
q3k | for ice40 and ecp5 these are defined in C++ as a bunch of iterators and access functions (ie. letting the nextpnr core know what Bels exist, what Wires do these Bels connect to, etc.) | 03:19 |
q3k | for the generic architecture, it starts with an empty definition of all of these in a bunch of hashmaps, and exposes a Python API to modify the architecture (add bels, pips, wires) | 03:19 |
q3k | so you would write Python code that populates all the architecture elements in the architecture, and then tell nextpnr to get to work | 03:20 |
q3k | you might want to read https://github.com/YosysHQ/nextpnr/blob/master/docs/archapi.md | 03:20 |
tpb | Title: nextpnr/archapi.md at master · YosysHQ/nextpnr · GitHub (at github.com) | 03:20 |
tecepe | it seems to ease development | 03:20 |
q3k | which is the documentation of the arch api expected to be provided by architectures to the nextpnr core | 03:20 |
tecepe | i'll take a look | 03:21 |
q3k | the 'generic' architecture is mostly for experimentation | 03:21 |
q3k | as it keeps all architecture non-deduplicated in memory, it's quite heavy | 03:21 |
q3k | so you wouldn't want to take a 7-series architecture model and implement PnRing it via the generic architecture :) | 03:21 |
tecepe | =) | 03:24 |
tecepe | very interesting work | 03:24 |
tecepe | ok, so in this case, as arachne is focused in ice40, if i want to have a pnr tool for the flavia architecture, i'd need to work with nextpnr | 03:25 |
tecepe | i just saw the picture in the nextpnr gui in the repository, it is very cute =) | 03:28 |
tecepe | haha i can say that a new world opened to me today =) | 03:32 |
tecepe | thank you very much, guys. it was interesting. | 03:33 |
tecepe | i've to go now. talk to you another time | 03:34 |
q3k | i need to head to sleep as well | 03:34 |
*** lutsabound has quit IRC | 03:36 | |
tecepe | good that nextpnr is already creating documentation: https://github.com/YosysHQ/nextpnr/blob/master/docs/faq.md#adding-new-architectures-to-nextpnr | 03:36 |
tpb | Title: nextpnr/faq.md at master · YosysHQ/nextpnr · GitHub (at github.com) | 03:36 |
tecepe | so much good info... just discovered VTR | 03:38 |
tecepe | well, good night guys | 03:44 |
tecepe | =) | 03:44 |
*** seldridge has joined #yosys | 05:10 | |
*** brandonz has quit IRC | 05:11 | |
*** rohitksingh_work has joined #yosys | 05:20 | |
*** brandonz has joined #yosys | 05:25 | |
*** seldridge has quit IRC | 05:56 | |
*** emeb_mac has quit IRC | 06:54 | |
*** dys has quit IRC | 07:40 | |
*** m4ssi has joined #yosys | 08:29 | |
*** kuldeep has joined #yosys | 09:14 | |
*** rohitksingh_work has quit IRC | 10:34 | |
*** rohitksingh_work has joined #yosys | 10:35 | |
*** rohitksingh_work has quit IRC | 11:17 | |
*** rohitksingh_work has joined #yosys | 11:46 | |
*** fsasm has joined #yosys | 11:53 | |
*** seldridge has joined #yosys | 12:19 | |
*** fsasm has quit IRC | 13:01 | |
*** pie___ has joined #yosys | 13:24 | |
*** pie__ has quit IRC | 13:25 | |
*** rohitksingh_work has quit IRC | 13:29 | |
*** seldridge has quit IRC | 13:32 | |
*** kuldeep has quit IRC | 13:37 | |
*** cr1901_modern has quit IRC | 13:49 | |
*** rohitksingh has joined #yosys | 14:07 | |
*** tecepe1 has joined #yosys | 14:17 | |
*** rohitksingh has quit IRC | 14:24 | |
*** rohitksingh has joined #yosys | 14:27 | |
*** cr1901_modern has joined #yosys | 15:00 | |
*** emeb_mac has joined #yosys | 15:25 | |
*** indy has quit IRC | 15:39 | |
*** seldridge has joined #yosys | 15:40 | |
*** FL4SHK has joined #yosys | 15:43 | |
ZipCPU | Hey, this is cool: I just adjusted how I was going about the formal verification of the ZipCPU. By checking the current state instead of transitions between states, I can now verify the CPU in less than 15 steps--vs 18 (or more) before | 15:49 |
*** indy has joined #yosys | 15:50 | |
ZipCPU | I'm current working with the ZipCPU+data cache, and I can verify the two together in only 10 steps | 15:50 |
ZipCPU | That's a full proof: BMC+Induction too | 15:50 |
*** seldridge has quit IRC | 16:12 | |
*** emeb_mac has quit IRC | 16:27 | |
*** seldridge has joined #yosys | 16:27 | |
*** lutsabound has joined #yosys | 16:43 | |
*** maikmerten has joined #yosys | 17:24 | |
*** m4ssi has quit IRC | 18:06 | |
*** rohitksingh has quit IRC | 18:09 | |
*** dys has joined #yosys | 18:31 | |
*** develonepi3 has joined #yosys | 19:07 | |
jer | ZipCPU, cool | 19:33 |
*** lutsabound has quit IRC | 19:53 | |
*** tecepe1 has quit IRC | 20:31 | |
*** lutsabound has joined #yosys | 20:36 | |
*** FL4SHK has quit IRC | 21:28 | |
*** ashfixit has quit IRC | 21:29 | |
*** maikmerten has quit IRC | 21:38 | |
*** emeb_mac has joined #yosys | 22:05 | |
*** tecepe has quit IRC | 22:19 | |
*** seldridge has quit IRC | 22:40 | |
*** lutsabound has quit IRC | 22:43 | |
*** zng has joined #yosys | 23:02 | |
*** Forty-Bot has quit IRC | 23:02 | |
*** ashfixit has joined #yosys | 23:05 | |
*** Forty-Bot has joined #yosys | 23:05 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!