14:55 <daveshah> So, as I continue to work on placer improvements in nextpnr (which seems to be dragging on, but hopefully should have big long-run improvements), I am looking at APIs that would give the placer more visibility into the packing situation (e.g. a basic understanding of control sets, rather than having to check validity for every move.) Also, some kind of clock region legalisation would be useful

14:56 <daveshah> Is there a good summary of the Intel arch, or any thoughts any of you have, that would be helpful for the design process for this?

14:57 <Lofty> daveshah: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_5v2.pdf <-- figure 1-4

14:57 <daveshah> Thanks

14:58 <daveshah> so, looks like 6 clocks per row (a bit like a clock region)

14:58 <daveshah> two clocks per LAB

14:59 <Lofty> Although the LABs have clock inverters

14:59 <daveshah> I see

14:59 <daveshah> what is the clk[2:0] about in 1-6?

15:00 <Lofty> Figure 1-4 has labclk0, labclk1 and labclk2

15:00 <daveshah> how does clk[2:0] correspond to "two unique clock signals"?

15:01 <Lofty> I'm presuming it lets you do things like clk0, ~clk0 and clk1

15:01 <daveshah> ah, I see

15:01 <Lofty> Since the muxes have optional inverters

15:01 <daveshah> that's definitely the most complicated arrangement yet, so a good basis for API design

15:01 <daveshah> going to need to think some more about that

15:02 <daveshah> usually inversion would either be per unique clock, or per 'SLICE' etc, rather than 2 clocks but 3 inversion possibilities

15:03 <Lofty> I'm not expecting this to come up very often

15:04 <Lofty> So, two unique clocks is probably good enough

15:04 <daveshah> another question, is a MLAB a superset of a LAB (like a Xilinx SLICEM)

15:05 <Lofty> Yes

15:05 <Lofty> MLABs can be LABs, though the timings seem to differ

15:05 <daveshah> that's fine, I think Xilinx is the same

15:05 <Lofty> But anything you can place on a LAB you can place on an MLAB

15:06 <daveshah> I'm thinking if I can create some generic code for this kind of stuff, it should enable slightly more powerful and faster legalisation code then always calling into the arch-specific "is this tile legal" function

15:06 <Lofty> Which is fair

15:07 <daveshah> The clock region stuff is also hard to do in pure arch-specific code, so it would be nice to make a placer clock region aware

15:08 <daveshah> This way we can also deal with stuff that has been ignored for now like the fact the ECP5 supports 64 global clocks - 16 per quadrant - currently I assume that all quadrants use the same clock

15:08 <daveshah> Looks like Intel has a similar quadrant scheme going on, actually

15:09 <Lofty> Yeah, GCLK, RCLK and PCLK

15:09 <Lofty> 16 global clocks, and up to 88 regional clocks, it seems

15:09 <daveshah> I do wonder who is actually using that many clock domains

15:09 <mwk> quadrants are common, yea

15:10 <mwk> spartan3e/3a also involve quadrants

15:10 <mwk> and virtex2 maybe?

15:10 <Lofty> Though one of the quadrants isn't available on FPGA SoCs

15:10 <Lofty> So keep that in mind :P

15:11 <daveshah> I guess the large number of global signals is also useful for doing things like resets, enables, etc

15:11 <daveshah> particurlaly the regional ones

15:11 <mwk> hmm

15:11 <mwk> aren't the regional ones supposed to be used for stuff like interface logic?

15:12 <Lofty> There's PCLKs for that, it seems

15:12 <mwk> I mean xilinx has IOCLKs, RCLKs, GCLKs

15:12 <daveshah> Yeah, that is another use

15:12 <daveshah> ECP5 also has edge clocks that are only useful for the "high speed" side of the IO gearboxen

15:13 <mwk> IOCLK can only be used by IO registers (and gearboxes), and are *fast*, RCLK would be divided by some factor and used for the actual logic

15:13 <daveshah> yeah that sounds quite similar