| *** tpb <[email protected]> has joined #f4pga | 00:00 | |
| *** accul <[email protected]> has joined #f4pga | 00:11 | |
| *** accul__ <[email protected]> has joined #f4pga | 00:44 | |
| *** accul <[email protected]> has quit IRC (Quit: Connection closed) | 00:44 | |
| accul__ | Hi, is OpenFASOC also discussed in this channel? | 01:30 |
|---|---|---|
| *** accul__ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 01:45 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (*.net *.split) | 06:39 | |
| *** TMM_ <[email protected]> has quit IRC (*.net *.split) | 06:39 | |
| *** lambda <[email protected]> has quit IRC (*.net *.split) | 06:39 | |
| *** ayazar <[email protected]> has quit IRC (*.net *.split) | 06:39 | |
| *** yeti <yeti!~username@user/yeti> has quit IRC (*.net *.split) | 06:39 | |
| *** tcal <tcal!sid456577@2a03:5180:f:2::6:f781> has quit IRC (*.net *.split) | 06:39 | |
| *** TMM_ <[email protected]> has joined #f4pga | 06:39 | |
| *** ayazar <[email protected]> has joined #f4pga | 06:39 | |
| *** perillamint <[email protected]> has joined #f4pga | 06:39 | |
| *** lambda <[email protected]> has joined #f4pga | 06:39 | |
| *** yeti <[email protected]> has joined #f4pga | 06:40 | |
| *** tcal <[email protected]> has joined #f4pga | 06:40 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@2a01:e0a:5f9:9681:a0a0:bb76:611f:9da7> has joined #f4pga | 06:40 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC (*.net *.split) | 06:43 | |
| *** ecs <ecs!ecs@user/ecs> has joined #f4pga | 06:43 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #f4pga | 06:43 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has quit IRC (Ping timeout: 240 seconds) | 07:01 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has joined #f4pga | 07:02 | |
| F4PGASlackBridge | <mkurc> @hansfbaier The thing with IOBs is that there are multiple bits controlling their internals which may not directly correlate with particular IO standard. Its rather their combination that corresponds to one. With that in mind there may be some features defined in the fuzzer that do not correspond directly to such a combination. Then you will get no candidates. There are also cases when for different IO standards bit | 07:24 |
| F4PGASlackBridge | combinations are the same but to implement a standard IO bank VCCs must differ (eg for LVCMOS33 and LVCMOS25). | 07:24 |
| *** lambda <[email protected]> has quit IRC (Quit: WeeChat 3.4.1) | 07:52 | |
| *** lambda <[email protected]> has joined #f4pga | 07:52 | |
| *** lkcl <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 09:03 | |
| *** lkcl <[email protected]> has joined #f4pga | 09:41 | |
| *** lambda <[email protected]> has quit IRC (Quit: WeeChat 3.4.1) | 10:09 | |
| *** lambda <[email protected]> has joined #f4pga | 10:09 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 11:16 | |
| *** TMM_ <[email protected]> has joined #f4pga | 11:17 | |
| F4PGASlackBridge | <luccareinehr> Hi everyone! I'm an engineering student in France, looking to code with F4PGA during this GSoC. And hopefully become a member of the community afterwards :) | 12:13 |
| F4PGASlackBridge | <kgugala> hi @luccareinehr is there any particular project you're interested in? | 12:16 |
| F4PGASlackBridge | <kgugala> a project from our gsoc ideas list https://github.com/f4pga/ideas/blob/gsoc-2022/gsoc-2022-ideas.md | 12:17 |
| F4PGASlackBridge | <luccareinehr> Yes @kgugala, I was mainly looking at these both: Smart and cloud based infrastructure to test analog blocks functionality and performance in OpenFASOC F4PGA toolchain integration in mainline Edalize I would like to discuss them a bit however, to find the right one | 12:19 |
| F4PGASlackBridge | <kgugala> you can ping @acomodi about the edalize topic | 12:20 |
| F4PGASlackBridge | <kgugala> and @mehdi about OpenFASOC | 12:20 |
| F4PGASlackBridge | <luccareinehr> Alright, will do. Thanks a lot! | 12:21 |
| F4PGASlackBridge | <luccareinehr> Actually, should I send the questions here or would you prefer I leave this discussion clean and ping them as DMs? @kgugala | 12:24 |
| F4PGASlackBridge | <kgugala> @acomodi should be in the channel | 12:38 |
| F4PGASlackBridge | <acomodi> Hi @luccareinehr, thanks for the interest in the projects, how can I be of help? | 12:40 |
| F4PGASlackBridge | <luccareinehr> Hi @acomodi, nice to meet you. So, from what I understood the idea of the project would be to get the code of the fork, transfer it to the most recent Edalize version and try to get a pull request through. Am I on the right page? If so, I guess one point of difficulty would be on testing the new code to ensure it doesn't break the already existent project. Is there a way to do this other than manually testing | 12:50 |
| F4PGASlackBridge | examples? | 12:50 |
| F4PGASlackBridge | <acomodi> As for the first question, it is not only a transfering of code from the fork to upstream but rather an adaptation/rework. The current Edalize support in the fork makes use of the F4PGA wrappers on the main tools used by the toolchain (e.g. Yosys, VPR, prjxray-tools, etc.). This means that currently, Edalize is used to add yet another wrapper. The main goal would be to try and add direct support for the single | 13:17 |
| F4PGASlackBridge | tools (some of which are already supported such as yosys) and than glue them all together using the new Edalize API (https://github.com/olofk/edalize/wiki/Edalize-(Slight-return)) to define toolchains, to have an F4PGA flow that does not have any other wrapper apart from the one created by Edalize. This project will most probably have different tasks such as: • improving the VPR tool in Edalize | 13:17 |
| F4PGASlackBridge | (https://github.com/olofk/edalize/blob/master/edalize/tools/vpr.py) • Adding the prjxray tool to generate the bitstream • Create the F4PGA flow calling all the required tool underneath So, in the end it will not be a single PR (pull request), but a series of independent PRs that will eventually add full support for F4PGA to edalize | 13:17 |
| F4PGASlackBridge | <acomodi> As per the second question, I think that one of the options to test the changes would be directly in FPGA tool perf: https://github.com/chipsalliance/fpga-tool-perf. This currently uses the Edalize fork, but as it concerns testing the changes, it can be a good option, as you would have a working baseline to confront with. I expect that changes would need to be applied in FPGA tool perf as well, as it is depending | 13:21 |
| F4PGASlackBridge | on Edalize underneath | 13:21 |
| F4PGASlackBridge | <luccareinehr> Thanks a lot for the info. I will install and try to use Edalize and fpga-tool-perf to see how they work. Also, could you point me where in fpga-tool-perf's repository is located the Edalize fork? | 13:43 |
| F4PGASlackBridge | <acomodi> Sure, here is the edalize fork currently used in tool-perf: https://github.com/SymbiFlow/edalize/tree/symbiflow_update | 14:07 |
| F4PGASlackBridge | <mehdi> Hi @luccareinehr - LMK how I can help. Thanks! | 15:51 |
| *** gagana05 <[email protected]> has joined #f4pga | 17:52 | |
| *** ZipCPU_ <[email protected]> has joined #f4pga | 17:54 | |
| *** ZipCPU <ZipCPU!~ZipCPU@2601:5cd:c280:96b0:1ac0:4dff:fe02:d4f0> has quit IRC (Ping timeout: 256 seconds) | 17:54 | |
| *** ZipCPU_ is now known as ZipCPU | 17:54 | |
| *** ZipCPU_ <[email protected]> has joined #f4pga | 18:03 | |
| *** ZipCPU <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 18:06 | |
| *** ZipCPU_ is now known as ZipCPU | 18:06 | |
| *** gagana05 <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 18:52 | |
| F4PGASlackBridge | <luccareinehr> Hi Mehdi! I would like to ask a couple questions about one of your proposed projects, "Smart and cloud based infrastructure to test analog blocks functionality and performance in OpenFASOC". First off, It really intrigued me when I discovered the meaning of FASOC, and to do it with open source tools - it's very nice. Anyway: from what I understood, the project consists in creating tests to verify/evaluate | 18:55 |
| F4PGASlackBridge | the functionality of the designs created from the /generators folder? I imagine most tests would be specific to each application, except for DRC or LVS checks. Maybe we could make a general scheme that would apply for any new component, then application-specific ones (e.g., measuring the accuracy of a temp sensor)? | 18:55 |
| F4PGASlackBridge | <mehdi> Thanks for your interest! I think those checks are part of the analog generator spice simulations so we can provide those as needed. But the important part is to have the infrastructure ready, where we can come and bring a new generator and fill in its checks. So yes, I agree! | 19:53 |
| F4PGASlackBridge | <luccareinehr> I'll tinker around with the software to get a better understanding of how it works. Until then, do you have an idea of a sequence of things to implement? For example: start with the 'importing flow as python modules', then 'try to develop a simple test', 'improve the test with Google Cloud functionalities' etc. Anything helps :) | 20:24 |
| F4PGASlackBridge | <luccareinehr> That's an awesome idea! I'll join the channel and we can schedule a call from there. | 23:08 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!