| *** tpb has joined #symbiflow | 00:00 | |
| *** tcal has quit IRC | 00:02 | |
| *** tcal has joined #symbiflow | 01:20 | |
| *** citypw has joined #symbiflow | 01:23 | |
| *** tcal has quit IRC | 01:27 | |
| *** tcal has joined #symbiflow | 01:42 | |
| *** Degi_ has joined #symbiflow | 02:04 | |
| *** yeti has quit IRC | 02:05 | |
| *** Degi has quit IRC | 02:07 | |
| *** Degi_ is now known as Degi | 02:07 | |
| *** yeti has joined #symbiflow | 02:08 | |
| sf-slack | <shashankmathew8> :wave: I’m here! What’d I miss? | 02:45 |
|---|---|---|
| sf-slack | <shashankmathew8> Greetings to everyone! | 02:45 |
| sf-slack | <shashankmathew8> I'm an undergraduate student. | 02:46 |
| sf-slack | <shashankmathew8> Studying Electronics and Communication Engineering in India. | 02:46 |
| sf-slack | <shashankmathew8> Graduating in 2021/ | 02:47 |
| sf-slack | <shashankmathew8> I hope all here are fine. | 02:48 |
| sf-slack | <shashankmathew8> Click here to view my LinkedIn profile. | 02:49 |
| sf-slack | <shashankmathew8> Let's connect! | 02:50 |
| sf-slack | <shashankmathew8> Click here to view my GitHub profile. | 02:52 |
| sf-slack | <shashankmathew8> Click here to view my StackOverflow profile | 02:53 |
| sf-slack | <shashankmathew8> I am skilled with Verilog, SystemVerilog basics, C, C++ and Python. | 02:56 |
| sf-slack | <shashankmathew8> I would love to join this project and contribute to it. | 02:56 |
| sf-slack | <shashankmathew8> I also know basics of SystemC. | 02:58 |
| sf-slack | <shashankmathew8> As our college is currently closed due to the pandemic, I have time to work on this project. | 03:00 |
| sf-slack | <shashankmathew8> I also know Bash scripting. | 03:00 |
| *** shashankvm has joined #symbiflow | 03:05 | |
| *** shashankvm has quit IRC | 03:39 | |
| *** shashankvm has joined #symbiflow | 03:40 | |
| *** adjtm has joined #symbiflow | 04:42 | |
| *** adjtm_ has quit IRC | 04:44 | |
| *** Bertl_oO is now known as bertl_zZ | 04:48 | |
| *** bertl_zZ is now known as Bertl_zZ | 04:49 | |
| *** Vonter has quit IRC | 04:56 | |
| *** Vonter has joined #symbiflow | 04:57 | |
| *** OmniMancer has joined #symbiflow | 05:07 | |
| *** OmniMancer1 has quit IRC | 05:08 | |
| *** OmniMancer has quit IRC | 06:50 | |
| *** OmniMancer has joined #symbiflow | 06:51 | |
| shashankvm | HI | 07:01 |
| shashankvm | I am an engineering student | 07:01 |
| *** tonyn14 has joined #symbiflow | 07:05 | |
| *** shashankvm has quit IRC | 07:21 | |
| *** tcal has quit IRC | 07:39 | |
| *** _whitelogger has quit IRC | 08:06 | |
| *** heijligen has quit IRC | 08:06 | |
| *** DraGonBusterz has quit IRC | 08:06 | |
| *** tucanae47 has quit IRC | 08:06 | |
| *** pdp7 has quit IRC | 08:06 | |
| *** daveshah has quit IRC | 08:06 | |
| *** _florent_ has quit IRC | 08:06 | |
| *** brent has quit IRC | 08:06 | |
| *** digshadow has quit IRC | 08:06 | |
| *** hackerfoo has quit IRC | 08:06 | |
| *** kuldeep has quit IRC | 08:06 | |
| *** brent has joined #symbiflow | 08:06 | |
| *** DraGonBusterz has joined #symbiflow | 08:06 | |
| *** tucanae47 has joined #symbiflow | 08:06 | |
| *** hackerfoo has joined #symbiflow | 08:06 | |
| *** _florent_ has joined #symbiflow | 08:06 | |
| *** digshadow has joined #symbiflow | 08:07 | |
| *** daveshah has joined #symbiflow | 08:07 | |
| *** pdp7 has joined #symbiflow | 08:07 | |
| *** pdp7 has quit IRC | 08:07 | |
| *** pdp7 has joined #symbiflow | 08:07 | |
| *** heijligen has joined #symbiflow | 08:07 | |
| *** kuldeep has joined #symbiflow | 08:07 | |
| *** _whitelogger has joined #symbiflow | 08:08 | |
| *** tonyn14 has quit IRC | 09:07 | |
| *** tbisker8 has quit IRC | 10:08 | |
| *** titanbiscuit has joined #symbiflow | 10:12 | |
| *** Bertl_zZ is now known as Bertl | 10:48 | |
| *** az0re has quit IRC | 11:04 | |
| *** Vonter has quit IRC | 12:12 | |
| *** Vonter has joined #symbiflow | 12:17 | |
| *** OmniMancer has quit IRC | 13:44 | |
| *** FFY00 has joined #symbiflow | 13:47 | |
| *** epony has quit IRC | 15:10 | |
| *** titanbiscuit has quit IRC | 15:13 | |
| *** titanbiscuit has joined #symbiflow | 15:14 | |
| *** Bertl is now known as Bertl_oO | 15:17 | |
| *** kraiskil has joined #symbiflow | 15:39 | |
| *** citypw has quit IRC | 15:43 | |
| *** clay_1 has joined #symbiflow | 15:50 | |
| *** clay_1 has quit IRC | 15:52 | |
| *** CMP1 has joined #symbiflow | 15:53 | |
| CMP1 | Hi all, I am reading the documentation in project XRAY about clocks regions, domains ad HROWs and I have got very confused | 15:54 |
| CMP1 | In the overview section is stated that `Clock domains have a fixed height of 50 interconnect tiles centered around the horizontal clock lines (25 above, 25 below)` | 15:55 |
| CMP1 | In the glossary the 'clock region' is defined as 'Portion of a device including up to 12 clock domains. A clock region is situated to the left or right of the global clock spine, and is 50 CLBs tall on Xilinx 7 series devices. The clock region includes all synchronous elements in the 50 CLBs and one I/O bank, with a horizontal clock row at its | 15:56 |
| CMP1 | center.` | 15:56 |
| CMP1 | Isnt that contradicting ? or do I understand it wrong ? | 15:57 |
| litghost | No contradiction | 15:58 |
| CMP1 | A horizontal clock row consists of 12 horizontal clock lines ? | 16:00 |
| litghost | No, you are misreading | 16:00 |
| litghost | There are up to 12 clock domains in a device, which are 50 units tall | 16:01 |
| CMP1 | each, right ? | 16:01 |
| CMP1 | also the ` A clock region is situated to the left or right of the global clock spine, and is 50 CLBs tall on Xilinx 7 series devices` doesnt indicate that the clock region is same as tall ? | 16:04 |
| litghost | ? | 16:04 |
| litghost | Both parts of that sentence is true | 16:04 |
| CMP1 | maybe the reason I dont understand it is because I have the notion that one should be superset of the other | 16:04 |
| litghost | A clock region is to the left or right | 16:04 |
| litghost | And is 50 units tall | 16:04 |
| litghost | What should be a super set of the other? | 16:06 |
| CMP1 | clock region and clock domain | 16:06 |
| litghost | Clock region (or CMT) is the only concept | 16:07 |
| *** tcal has joined #symbiflow | 16:07 | |
| litghost | Clock domain's are something else entirely | 16:07 |
| litghost | So clock domain -> Clock region | 16:07 |
| CMP1 | So clock regions are the boxes that you can see in vivado and in 7 series they are up to 12 in number. Each of them is 50 units tall (no info about withd? ) and those 50 are split in half by the Horizontal clock row (which includes 12 clocks with that number having nothing to do with the number of clock regions) | 16:10 |
| CMP1 | how correct is that statement ? | 16:10 |
| litghost | Yes | 16:14 |
| litghost | Width is weird, because some CMT's have hard blocks and such | 16:15 |
| CMP1 | I see and that 12 is refering to one half of the device so they can actually be 24? | 16:15 |
| litghost | Which parts have 24 CMT's | 16:16 |
| litghost | ? | 16:16 |
| CMP1 | I dont know, I just found this line in UG472 | 16:18 |
| CMP1 | `The number of clock regions varies with device size, from one clock region in the smallest device to 24 clock regions in the largest one` | 16:18 |
| CMP1 | so I based my assumption on that | 16:19 |
| CMP1 | Leaving that asside and combining the rest I have the following: | 16:34 |
| CMP1 | Clock domain is defined asPortion of the device controlled by one clock. A clock domain is part of a horizontal clock row By that I understand that since HROW has 12 horizontal clocks and each clock region has one HROW this means that each clock region has 12 clock domains. | 16:34 |
| litghost | Incorrect | 16:36 |
| CMP1 | In what part ? | 16:36 |
| litghost | All of it | 16:36 |
| litghost | Sentence 1 is mostly wrong | 16:37 |
| litghost | Sentence 2 is completely wrong | 16:37 |
| litghost | A clock domain is simply the netlist of things clocked by common clock | 16:37 |
| CMP1 | by sentence one you mean this part, right ? `Clock domain is defined asPortion of the device controlled by one clock. A clock domain is part of a horizontal clock row` | 16:38 |
| litghost | That is two sentences | 16:38 |
| CMP1 | so this is both the mostly wrong and the completely wrong part | 16:38 |
| litghost | Yes | 16:38 |
| litghost | A clock domain is simply the netlist of things clocked by common clock | 16:39 |
| litghost | The 7-series fabric provides BUFR, BUFMR, BUFG and BUFH drivers to express clocks | 16:39 |
| litghost | The typical clocking arrangement, is to first bring the clock to a BUFG, which drives 1 of 32 global clock spines that run to all CMT's | 16:40 |
| CMP1 | so it does not create a topological reagion ? ( By the way those two sentenses are copied from the glossary entry of clock domain should we issue a "bug" ? ) | 16:40 |
| litghost | The horizontial clock spines (12 per CMT) are driven from BUFH, which can connect to the global clock spine (or other sources) | 16:40 |
| litghost | "topological region"? meaning what? | 16:41 |
| litghost | CMP1: Have you read https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf | 16:42 |
| CMP1 | meaning a specific set of tiles. But probably it cant happen because theoretically if you have 100% utilization and only one clock you end up with one clock domain. So number of clock domains depend on how many different clocks you define in your design | 16:42 |
| CMP1 | is that correct ? | 16:43 |
| litghost | True, but clock domains are a totally independent concept from clock region (e.g. CMT) | 16:43 |
| litghost | CMT's are defined the hardware design | 16:43 |
| CMP1 | litghost not entirely but thats where I got the 25 clock regions number from | 16:43 |
| litghost | CMP1: Do you understand figure 1-1? | 16:44 |
| litghost | Also figure 1-2 | 16:44 |
| CMP1 | Not entirely, I understand the clock regions and the HROWs that are inside them. I dont understand why it has three collumns though instead of the 2 I expected | 16:46 |
| litghost | The GT column? That isn't always present | 16:47 |
| CMP1 | good then | 16:49 |
| CMP1 | about the second one | 16:49 |
| litghost | The CMT column? | 16:49 |
| CMP1 | the clock back bone is always next to IOs ? | 16:49 |
| litghost | Yes | 16:49 |
| litghost | That is where the PLL and MMCM's are located | 16:49 |
| litghost | Along with the BUFIO's, etc | 16:49 |
| CMP1 | yes I think I understand that there are several collumns in each clock region, if its a clb collumn it will have 50 tiles , if its a BRAM 10 etc | 16:50 |
| litghost | Yes | 16:50 |
| litghost | The height of the BRAM tile is 5 | 16:50 |
| litghost | Height of a CLBLL is 1 | 16:50 |
| litghost | DSP's are 5 | 16:50 |
| CMP1 | nice | 16:50 |
| CMP1 | now about the HROW, its horizontal, and I guess that the 12 clocks are inside it but then go perpendicular to reach the elements of its column ? | 16:52 |
| litghost | Yes | 16:53 |
| CMP1 | By counting the number of CLBs, they are 12 so BRAM, DSPs share the clock with their neighboring CLBs ? | 16:54 |
| CMP1 | ( I meant CLB collumns) | 16:54 |
| litghost | Every logic tile belongs to a CMT | 16:54 |
| litghost | Every logic tile in the same CMT shares the same CMT clock sources (BUFH, BUFR, BUFMR) | 16:55 |
| litghost | BUFIO | 16:55 |
| CMP1 | I got a bit confused here, if they all share the same clock what are the 12 clock lines of HROW for ? | 16:57 |
| litghost | They don't share the same clock | 16:58 |
| litghost | In the horizonital spine there are 12 BUFH output wires | 16:58 |
| litghost | and 4 BUFIO, 4 BUFR and 8 BUFMR wires | 16:58 |
| CMP1 | I should probably read what those types are first | 16:59 |
| litghost | I recommend just opening Vivado and looking at the routing resource view | 17:00 |
| litghost | Picture, 1000 words, etc,etc | 17:00 |
| CMP1 | I think I have understood though the following part of the glossary `Portion of a device including up to 12 clock domains` It means that since the hrow has 12 clocks you can create up to 12 clock domains there, is that correct ? | 17:00 |
| litghost | No | 17:01 |
| CMP1 | And yes I totally agree with that I have it open and look at it as we speak | 17:01 |
| CMP1 | then where does this limitation come from ? | 17:03 |
| litghost | Limitation? | 17:04 |
| litghost | What limitation? | 17:04 |
| CMP1 | That a clock region is `Portion of a device including up to 12 clock domains.` | 17:05 |
| litghost | So if each clock domain is driven by a BUFH (which is typical), then each CMT can only have 12 BUFHs, therefore only 12 domains | 17:07 |
| litghost | Techinically speaking you can more domains if you get creative and use BUFR's, BUFIO's and BUFMR's, but then you are straying from the global clock spine and have to worry about skew | 17:08 |
| CMP1 | So what I said earlier is correct as long as you keep using the global spine ? | 17:09 |
| litghost | Which sentence? | 17:09 |
| CMP1 | I think I have understood though the following part of the glossary `Portion of a device including up to 12 clock domains` It means that since the hrow has 12 clocks you can create up to 12 clock domains there, is that correct ? | 17:10 |
| litghost | Basically | 17:12 |
| litghost | And that statement is full of caveats | 17:13 |
| litghost | For example, if you wanted to clock gate some logic (for power savings), but have that logic be on the sameish domain as the other logic, that would require two BUFH's | 17:13 |
| litghost | The more specific and correct version of the above sentence is that a CMT has 12 BUFH's, which could accommodate 12 clock domains | 17:14 |
| CMP1 | great ! thank you very much for all your patience | 17:15 |
| litghost | Again, a CMT can have more than 12 clock domains if you use: interconnect based clocks, BUFR's, BUFMR's, BUFIO's | 17:15 |
| litghost | However BUFR/BUFMR/BUFIO and interconnect drive clocks are not typical usage at all | 17:15 |
| CMP1 | that means that vivado would never use them without you asking specifically for it, right ? | 17:16 |
| litghost | Correct | 17:16 |
| litghost | I believe by default all clocks get an implicit BUFG, which then requires a BUFH to enter the CMT | 17:16 |
| *** az0re has joined #symbiflow | 17:16 | |
| litghost | Therefore, 12 clock domains per CMT is a reasonable approximation of the truth for most users | 17:17 |
| litghost | I want to be clear though, the clock domain may span multiple CMT's | 17:17 |
| litghost | That is typical and expected | 17:17 |
| CMP1 | I see, its because if you have a big design with a signle clock it will need to span to more area than the one of a CMT, right ? | 17:19 |
| litghost | Sure | 17:19 |
| CMP1 | and when that happens it gets connected to one of the 12 clocks of the neighbouring CMT, correct ? | 17:20 |
| litghost | no | 17:21 |
| litghost | The global clock spine has capacity for 32 clocks | 17:21 |
| litghost | When using BUFGs, the domain begins at the BUFG, then enters a CMT via a BUFH | 17:21 |
| litghost | The whole point of the global clock spine is that neighbooring CMT's don't matter | 17:22 |
| litghost | BUFMR affects neighbooring CMT's, but again that is not typical usage | 17:22 |
| CMP1 | So every CMT that is beeing used will have one out of 12 HROW clocks connected to the global clock spine ? | 17:24 |
| litghost | No | 17:25 |
| litghost | Each clock domain in use in a CMT from the global clock will consume 1 BUFH | 17:26 |
| CMP1 | so if we assume all CMTs are in the same clock domain | 17:28 |
| CMP1 | they will have to spend one BUFH each to get connected in the global clock | 17:28 |
| CMP1 | right ? | 17:28 |
| litghost | yes | 17:28 |
| litghost | And each CMT has 12 BUFH's that can connect to any of the global clock spine clocks | 17:29 |
| litghost | Amongst other sources | 17:29 |
| CMP1 | great | 17:30 |
| CMP1 | thank you ! | 17:30 |
| *** epony has joined #symbiflow | 17:38 | |
| *** CMP1 has quit IRC | 18:32 | |
| *** buzepeng has joined #symbiflow | 18:34 | |
| lambda | daveshah: any idea what could be choking nextpnr-xilinx routing with newer yosys? not sure if you saw my messages the other day, but it suddenly takes 2h to route my design and timing is horrible. | 18:51 |
| *** buzepeng has quit IRC | 18:51 | |
| daveshah | I highly doubt it is a Yosys change, probably random bad luck. I'm trying to chase down some odd router bugs, but trying a different --seed value would be interesting | 18:51 |
| lambda | daveshah: yeah, I can't reproduce it anymore now. it was reproducible before, interestingly | 19:01 |
| lambda | what's the default seed nextpnr uses? | 19:01 |
| daveshah | 1 iirc | 19:01 |
| lambda | hm, so also deterministic | 19:01 |
| daveshah | There's an occasional bug where the router gets stuck "fighting" for a particular wire often around BRAM, it was probably some manifestation of that | 19:02 |
| *** kraiskil has quit IRC | 19:03 | |
| *** tcal has quit IRC | 19:06 | |
| lambda | daveshah: by the way, I tried just commenting out https://github.com/daveshah1/nextpnr-xilinx/blob/xilinx-upstream/xilinx/python/xilinx_device.py#L467-L468, the commit that introduced it (f45c1cb38) sounds like it won't affect me, and I want to use all my PLLs ;) | 19:08 |
| tpb | Title: nextpnr-xilinx/xilinx_device.py at xilinx-upstream · daveshah1/nextpnr-xilinx · GitHub (at github.com) | 19:08 |
| lambda | ghdlsynth doesn't support inout yet, so won't get very far with DRAM anyways, but if it works I'm one step closer | 19:08 |
| lambda | welp, fasm2frames.py doesn't like that. oh well | 19:28 |
| daveshah | Yeah, I don't think the bitstream data is there for those tiles yet | 19:31 |
| *** az0re has quit IRC | 20:16 | |
| *** az0re has joined #symbiflow | 20:16 | |
| *** OmniMancer has joined #symbiflow | 20:19 | |
| *** Finde has quit IRC | 20:33 | |
| *** Finde has joined #symbiflow | 20:35 | |
| *** tcal has joined #symbiflow | 20:58 | |
| litghost | lambda: Which tile are you trying to put a PLL in? | 21:15 |
| litghost | On the A50 fabrics, the only PLL's are the ones in CMT_TOP_L_UPPER_T tile types | 21:15 |
| litghost | So I'd expect uncommenting that line would have no affect | 21:16 |
| *** _whitelogger has quit IRC | 21:16 | |
| *** _whitelogger has joined #symbiflow | 21:18 | |
| *** _whitelogger has quit IRC | 21:22 | |
| *** _whitelogger has joined #symbiflow | 21:25 | |
| *** _whitelogger has quit IRC | 21:28 | |
| *** _whitelogger has joined #symbiflow | 21:31 | |
| mithro | lambda: I would be interested to see how vpr does with your design if it is open source? We could even add it as a test bench in https://github.com/SymbiFlow/fpga-tool-perf if it is hitting some type of pathological behaviour. | 22:39 |
| tpb | Title: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at github.com) | 22:39 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!