twix has quit [Quit: ZNC 1.9.1+deb2+b3 - https://znc.in]
twix has joined #yosys
FabM has joined #yosys
<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.
<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?
Wolfvak_ has joined #yosys
Wolfvak has quit [Ping timeout: 260 seconds]
zero-xray9 has joined #yosys
zero-xray has quit [Ping timeout: 260 seconds]
zero-xray9 is now known as zero-xray
kristianpaul has quit [Ping timeout: 272 seconds]
zero-xray1 has joined #yosys
zero-xray has quit [Ping timeout: 265 seconds]
zero-xray1 is now known as zero-xray
kristianpaul has joined #yosys
flinner has quit [Ping timeout: 252 seconds]
flinner has joined #yosys
zero-xray0 has joined #yosys
zero-xray has quit [Ping timeout: 248 seconds]
zero-xray0 is now known as zero-xray
flinner has quit [Ping timeout: 260 seconds]
flinner has joined #yosys
flinner has quit [Ping timeout: 252 seconds]
flinner has joined #yosys
kristianpaul has quit [Ping timeout: 252 seconds]
FabM has quit [Ping timeout: 265 seconds]
<lofty[m]>
<adehop[m]> "lofty: i realized that gmpack in..." <- > Couldn't the parts for timing optimization of the PnR algorithm be adopted here?
<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.
<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?
<lofty[m]>
adehop[m]: to be entirely honest I have been wondering this too.
<lofty[m]>
but, uh, I have been wondering about a number of design decisions regarding the gatemate
<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?
<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.
<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).
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
Wanda[cis] has joined #yosys
<Wanda[cis]>
look carefully, it's not a tree at all
<Wanda[cis]>
it's a ring around the whole die, plus like 4 columns total
<Wanda[cis]>
even with the global mesh, you get to do the final leg of distribution yourself
<lofty[m]>
wanda beat me to it, but even with the columns, one still needs to get the clock onto global routing.
<lofty[m]>
(and also, because it's a ring, worst-case skew is a bit nightmarish already)#
<lofty[m]>
* (and also, because it's a ring, worst-case skew is a bit nightmarish already)
<lofty[m]>
it is, at best, a way of ensuring low clock skew for I/O FFs
<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.