| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** twix <[email protected]> has quit IRC (Quit: ZNC 1.9.1+deb2+b3 - https://znc.in) | 02:17 | |
| *** twix <[email protected]> has joined #yosys | 02:17 | |
| *** FabM <FabM!~FabM@2a03:d604:106:ee00:95b8:90ed:b0b3:b4a4> has joined #yosys | 05:27 | |
| adehop[m] | lofty: i realized that gmpack in the Suite right now as it magically worked when switching to newer releases. Thanks to you and the team for this, and generally for the progress and stunning work you do with this toolchain. | 06:08 |
|---|---|---|
| adehop[m] | Glad to hear you're aware of the Hold/min time violation problem (so there's no need to open an issue i guess?). Though i generally have basic knowledge about timing constraints, it would be very interesting to hear what the new requirements are for GateMate compared to e.g. ECP5. Couldn't the parts for timing optimization of the PnR algorithm be adopted here? | 06:08 |
| *** Wolfvak_ <Wolfvak_!~Wolfvak@user/wolfvak> has joined #yosys | 06:38 | |
| *** Wolfvak <Wolfvak!~Wolfvak@user/wolfvak> has quit IRC (Ping timeout: 260 seconds) | 06:40 | |
| *** zero-xray9 <zero-xray9!~nonlinear@user/nonlinear> has joined #yosys | 07:39 | |
| *** zero-xray <zero-xray!~nonlinear@user/nonlinear> has quit IRC (Ping timeout: 260 seconds) | 07:42 | |
| *** zero-xray9 is now known as zero-xray | 07:42 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Ping timeout: 272 seconds) | 08:04 | |
| *** zero-xray1 <zero-xray1!~nonlinear@user/nonlinear> has joined #yosys | 08:08 | |
| *** zero-xray <zero-xray!~nonlinear@user/nonlinear> has quit IRC (Ping timeout: 265 seconds) | 08:11 | |
| *** zero-xray1 is now known as zero-xray | 08:11 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has joined #yosys | 08:14 | |
| *** flinner <flinner!~lambda@user/flinner> has quit IRC (Ping timeout: 252 seconds) | 09:17 | |
| *** flinner <[email protected]> has joined #yosys | 09:17 | |
| *** zero-xray0 <zero-xray0!~nonlinear@user/nonlinear> has joined #yosys | 09:52 | |
| *** zero-xray <zero-xray!~nonlinear@user/nonlinear> has quit IRC (Ping timeout: 248 seconds) | 09:54 | |
| *** zero-xray0 is now known as zero-xray | 09:54 | |
| *** flinner <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 10:27 | |
| *** flinner <[email protected]> has joined #yosys | 10:28 | |
| *** flinner <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 13:15 | |
| *** flinner <[email protected]> has joined #yosys | 13:16 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Ping timeout: 252 seconds) | 16:48 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 265 seconds) | 18:33 | |
| lofty[m] | <adehop[m]> "lofty: i realized that gmpack in..." <- > Couldn't the parts for timing optimization of the PnR algorithm be adopted here? | 20:20 |
| lofty[m] | no, because the ECP5 has a dedicated, low-skew clock tree, and the GateMate does not; one must use general routing and perhaps some fast signal propagation to achieve that. without the clock tree, nextpnr has to attempt to build its own clock tree, which is something unique to this architecture. | 20:20 |
| adehop[m] | That's some very interesting detail, i did not know that. Why would an architecture want to lack a dedicated clock tree? Until now i thought thats a key component to enable fast digital designs? | 20:35 |
| lofty[m] | adehop[m]: to be entirely honest I have been wondering this too. | 20:37 |
| lofty[m] | but, uh, I have been wondering about a number of design decisions regarding the gatemate | 20:38 |
| adehop[m] | I took a look into GM datasheet DS1001, they describe "GlobalMesh" which seems to be sort of a global clock tree. Is that much different from other architectures clock distribution networks? | 20:48 |
| adehop[m] | Ok, they also discuss pros and cons for clock distribution methods; general routing of clock signals seems to be most flexible but also very demanding towards PnR. Interesting insights into this architecture anyway. | 20:59 |
| tnt | Yeah, when I read the datasheet the globalmesh looked exactly like the global network of other fpga. Similar to ice40 where you can use it for clock, but also any other signal. (as opposed to ecp5 where IIRC the clock network is pretty separate and for clocks only). | 22:05 |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:08 | |
| *** nonchip <[email protected]> has joined #yosys | 22:08 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Quit: "Every day, computers are making people easier to use." David Temkin) | 22:43 | |
| *** Wanda[cis] <Wanda[cis]!mwkmwkmwkm@2a01:4f8:c012:5b7:0:1:0:c> has joined #yosys | 22:51 | |
| Wanda[cis] | look carefully, it's not a tree at all | 22:51 |
| Wanda[cis] | it's a ring around the whole die, plus like 4 columns total | 22:52 |
| Wanda[cis] | even with the global mesh, you get to do the final leg of distribution yourself | 22:52 |
| lofty[m] | wanda beat me to it, but even with the columns, one still needs to get the clock onto global routing. | 22:54 |
| lofty[m] | (and also, because it's a ring, worst-case skew is a bit nightmarish already)# | 22:56 |
| lofty[m] | * (and also, because it's a ring, worst-case skew is a bit nightmarish already) | 22:56 |
| lofty[m] | it is, at best, a way of ensuring low clock skew for I/O FFs | 22:56 |
| lofty[m] | even on the official CPE diagram on page 25 of DS1001, clocks either come from the "CLK"/"EN" inputs (...poorly named) or the CINY2/PINY2 lines. | 23:01 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!