| *** tpb has joined #vtr-dev | 00:00 | |
| mithro | kem_: any feedback on this proposed format change to the port specification format? | 17:35 |
|---|---|---|
| mithro | https://www.irccloud.com/pastebin/ceEIFk7R/ | 17:35 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 17:35 |
| mithro | kem_: The big thing I'm trying to achieve with that change is to not have the name of the blocks repeated in the port specifications (so that things are easier to compose) | 17:36 |
| mithro | kem_: I currently have a xslt script which transform this format to the existing format | 17:37 |
| mithro | daveshah: With the above change it makes it very easy to do the xinclude stuff I mentioned above | 17:41 |
| *** eddieh has joined #vtr-dev | 17:51 | |
| eddieh | Howdy do | 18:30 |
| * eddieh hasn't used IRC for a loooong time | 18:30 | |
| daveshah | eddieh: hey | 18:30 |
| eddieh | Ooh it still works | 18:30 |
| eddieh | So until recently I thought VTR was something that fell out of favour... at least from the academic side | 18:33 |
| eddieh | To be overtaken by these new-fangled "HLS", "ML", etc. buzzwords | 18:34 |
| eddieh | But now I'm excited to learn that doesn't appear to be the case! | 18:35 |
| mithro | hey eddieh :-) | 19:43 |
| mithro | john is digshadow | 19:43 |
| mithro | eddieh: I'll be back in about an hour, just going to lunch now | 19:43 |
| digshadow | hey eddieh! | 20:23 |
| digshadow | hehe I see I bullied you enough to show up :) | 20:23 |
| eddieh | hello indeed! I feel like I need a cool pseudonym too | 20:37 |
| *** eddieh is now known as heddie | 20:47 | |
| heddie | there...! | 20:47 |
| mithro | :-P | 20:49 |
| mithro | heddie: So, I'm currently concentrating on vtr for ice40 | 20:50 |
| mithro | heddie: We have blinky working and elms is looking at the blockram | 20:52 |
| heddie | sounds good | 20:52 |
| mithro | heddie: Then we will go back to doing artix-7 | 20:53 |
| heddie | I have no experience working with lattice | 20:53 |
| mithro | heddie: Artix-7 is really just waiting on me finishing the rr_graph generation | 20:53 |
| heddie | But I have VTR-to-Bits "working" for V6 and Artix7 zc7020 | 20:54 |
| mithro | heddie: I have a python script which prints the rr_graph in human form | 20:54 |
| heddie | My approach is encumbered by the use of XDLRC, though | 20:54 |
| mithro | heddie: We have taken the approach of having a Python library for generating the rr_graph | 20:55 |
| heddie | Interesting | 20:56 |
| mithro | heddie: mapping real fabric to the rr_graph format has a bit of impedance mismatch, but the Python library kind of "papers over" a lot of it | 20:57 |
| heddie | As I'm sure you know VPR procedural generates the routing graph in order to support architecture exploration | 20:57 |
| mithro | heddie: Yes - but it can now load an xml file with the routing | 20:57 |
| mithro | heddie: I believe it might have been added after your VtB work | 20:58 |
| heddie | However, mapping to a real architecture, will all its nooks, crannies, and exceptions means it was painful to teach it to account for those exceptions | 20:58 |
| mithro | https://docs.verilogtorouting.org/en/latest/vpr/file_formats/#routing-resource-graph-file-format-xml | 20:58 |
| heddie | Yes, that is new to me | 20:58 |
| heddie | s/new/news/ | 20:58 |
| mithro | heddie: Dunno /how/ new that stuff is | 20:59 |
| heddie | I recall the UoT people were talking about doing it | 20:59 |
| heddie | This was in 2015, after which I lost touch with this area | 20:59 |
| mithro | heddie: Well, they did it sometime between your work and the time we started working | 20:59 |
| mithro | heddie: FYI - Our "architecture definitions" can be found at https://github.com/SymbiFlow/symbiflow-arch-defs | 21:00 |
| tpb | Title: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at github.com) | 21:00 |
| mithro | heddie: We are moving towards generating all the VPR XML configuration from specially annotated Verilog simulation models | 21:00 |
| mithro | heddie: I'm also hoping to auto generate graphics and documentation from these sim models too | 21:01 |
| heddie | Sounds like a decent approach | 21:02 |
| mithro | heddie: We also make heavy use of XML includes to make it easier for composible | 21:03 |
| heddie | My biggest concern would be how exceptions are handled | 21:03 |
| heddie | at boundaries, across holes in the fabric, etc. | 21:03 |
| mithro | heddie: Will be interesting to see how far we can push it | 21:04 |
| heddie | I also expect there to be some discrepancies between logical layout and physical timing | 21:05 |
| heddie | with not all timing arcs being the same | 21:05 |
| mithro | heddie: I have a example of my thinking about fabric -> https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/286 | 21:05 |
| tpb | Title: Proposal for alternative fabric and switch specification format · Issue #286 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 21:05 |
| mithro | heddie: Playing with that idea here -> https://github.com/mithro/symbiflow-arch-defs/blob/77fdf28c1227a2e92e03132c43a54ea5023e18f1/ice40/utils/ice40_generate_routing.py | 21:08 |
| tpb | Title: symbiflow-arch-defs/ice40_generate_routing.py at 77fdf28c1227a2e92e03132c43a54ea5023e18f1 · mithro/symbiflow-arch-defs · GitHub (at github.com) | 21:08 |
| heddie | Looks interesting! | 21:09 |
| heddie | I of course took the easy approach and just generated a binary blob to be slurped into memory | 21:09 |
| mithro | heddie: I'm thinking about a flat buffer based replacement for the rr_graph in the future -- but the XML isn't a huge blocking factor, it's more getting things actually working | 21:11 |
| mithro | heddie: Even like 2g of XML only takes a second to load | 21:12 |
| heddie | But then that begs the question of why slurp in a massive XML only to have to process it from human-readable to binary? | 21:13 |
| mithro | heddie: being able to open the file in a text editor has been rather helpful | 21:14 |
| heddie | Not to sound like I'm on the attack, just trying to understand what your thought pattern is | 21:14 |
| mithro | heddie: And VtR already had the rr_graph xml support, so the least amount of change to VtR | 21:15 |
| heddie | Indeed, but it sounds like XML is the middle man that's generated from a python script | 21:15 |
| mithro | heddie: Yeap, and probably go away in the future -- but for a temporary solution it is "good enough" | 21:16 |
| mithro | perfect is the enemy of ever getting anything done :-P | 21:16 |
| heddie | a very fair comment! | 21:16 |
| mithro | heddie: The goal is to get something which can do PicoSoC and then go back and improve the tooling | 21:18 |
| heddie | Right | 21:18 |
| mithro | it's much easier to understand the correct approach for the tooling once you have something which works :-P | 21:20 |
| heddie | Absolutely | 21:20 |
| mithro | we are also have been focused on "proving what is possible" rather then "doing it the best way" | 21:22 |
| heddie | Not to toot my own horn, would the approach taken by VTR-to-Bitstream tick the "it's possible" box? | 21:23 |
| heddie | Minus bitgen | 21:23 |
| heddie | But is XDLRC considered polluting? | 21:24 |
| mithro | heddie: I don't think I recall you publishing anything for the Series 7? | 21:24 |
| heddie | No, it's in my github | 21:24 |
| heddie | The same XDLRC can be applied to any ISE family | 21:25 |
| heddie | The same XDLRC *approach* can be applied to any family supported by ISE | 21:25 |
| mithro | XDLRC requires the vendor tools? | 21:25 |
| heddie | Yes | 21:26 |
| mithro | It's been quite a long time since I last looked at VtB | 21:26 |
| mithro | heddie: Our goal was to prove you could do it *without* vendor tools | 21:26 |
| heddie | XDLRC step is a one-off procedure that converts the info provided by vendor tools into a pre-generated rr_graph binary array | 21:26 |
| heddie | (I use Torc to access that XDLRC data) | 21:27 |
| heddie | I made a modification to VPR to load in that rr_graph binary blob and put it exactly where the procedurally generated result would otherwise be | 21:27 |
| heddie | The only step I need vendor tools for (and a license for non webpack devices) is bitgen | 21:29 |
| mithro | heddie: Yeah - we wanted to be able to generate something we can load on a FPGA without touching the vendor tools at all | 21:30 |
| mithro | IE No bitgen either | 21:30 |
| heddie | That last step wasn't particularly interesting to me as it gave me nothing new | 21:31 |
| daveshah | heddie: did you hear about the Rapidwright business recently? | 21:31 |
| heddie | Plus it was known to be a legally gray area... | 21:31 |
| heddie | Hi Dave. Yes, I learned that from Clifford when I saw him at DAC | 21:31 |
| heddie | Would love to know the story behind that | 21:32 |
| daveshah | Yeah, it was very odd. | 21:32 |
| daveshah | I've had a bit of contact with Xilinx about this stuff because the asked me to remove my fork but didn't get a reason | 21:32 |
| heddie | I reached out to someone close to the author and they didn't know much more... yet | 21:33 |
| daveshah | I think they want to release it in a more binary blobified form | 21:33 |
| daveshah | But have to sort out gpl dependencies | 21:33 |
| heddie | That's a more promising result than I thought it would be | 21:33 |
| daveshah | Interestingly, Lattice Diamond has a lot of similar low level interfaces to ISE (because they share NeoCAD routes) although even less documented | 21:34 |
| daveshah | I have used them extensively for my ECP5 fuzzing | 21:34 |
| daveshah | They have ncl (NeoCAD listing) which is quite similar to xdl | 21:34 |
| heddie | interesting! | 21:35 |
| heddie | I have zero experience with lattice | 21:36 |
| heddie | The research labs I was in were all Xilinx/Altera devices | 21:36 |
| daveshah | Yeah, Lattice have a pretty low presence in unis (except those using icestorm for intro teaching :D) | 21:37 |
| daveshah | ECP5 are pretty nice parts, particularly considering pricing | 21:38 |
| heddie | Fair enough! Never had to go out and buy one myself | 21:44 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!