| *** pbsds <pbsds!~pbsds@193.71.241.70> has quit IRC | 00:54 | |
| *** pbsds <pbsds!~pbsds@193.71.241.70> has joined #f4pga | 00:55 | |
| *** pbsds <pbsds!~pbsds@193.71.241.70> has quit IRC | 01:07 | |
| *** pbsds <pbsds!~pbsds@193.71.241.70> has joined #f4pga | 01:10 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC | 02:11 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga | 02:11 | |
| *** bl0x <bl0x!~bl0x@p200300d7a70f6e009c44a667b446581e.dip0.t-ipconnect.de> has joined #f4pga | 02:38 | |
| *** bl0x_ <bl0x_!~bl0x@p54a7022e.dip0.t-ipconnect.de> has quit IRC | 02:40 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 05:24 | |
| *** jn <jn!~quassel@ip-095-223-044-193.um35.pools.vodafone-ip.de> has joined #f4pga | 05:25 | |
| *** jn <jn!~quassel@ip-095-223-044-193.um35.pools.vodafone-ip.de> has quit IRC | 05:25 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #f4pga | 05:25 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has quit IRC | 06:14 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has joined #f4pga | 06:15 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has quit IRC | 06:45 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has joined #f4pga | 06:45 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has quit IRC | 07:27 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has joined #f4pga | 07:29 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC | 07:31 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga | 07:32 | |
| *** indy_ is now known as indy | 09:08 | |
| *** bl0x <bl0x!~bl0x@p200300d7a70f6e009c44a667b446581e.dip0.t-ipconnect.de> has quit IRC | 09:33 | |
| *** bl0x <bl0x!~bl0x@p4ff4491b.dip0.t-ipconnect.de> has joined #f4pga | 09:34 | |
| *** TMM__ <TMM__!hp@amanda.tmm.cx> has quit IRC | 10:16 | |
| *** TMM_ <TMM_!hp@amanda.tmm.cx> has joined #f4pga | 10:16 | |
| F4PGASlackBridge | <tmichalak> Hmm, so the math looks good when taking tilegrid into account: ``` "RIOB18_X73Y25": { "bits": { "CLB_IO_CLK": { "baseaddr": "0x00442480", "frames": 42, "offset": 51, "words": 4 } }, ``` The bit in the `unknown_segbits` is the absolute value, so in case of `004424a7_54_31` it's 39th frame (as you already | 11:09 |
|---|---|---|
| F4PGASlackBridge | calculated) and `54*32+31=1759` th bit. Since the word offset for this tile is 51 then 54 is inthe range expressed by `words`. So I am kind of surprised that you get this `out of range` error | 11:09 |
| F4PGASlackBridge | <hansfbaier> @tmichalak What would the .db style bit entry look like? 39_1759 obviously doesn't work (gives me the out of range error).... | 11:46 |
| F4PGASlackBridge | <hansfbaier> @tmichalak Ah, probably it will be 1759-51*32? | 11:50 |
| F4PGASlackBridge | <tmichalak> The db entry is relative to the beginning of the segment, so in this case it's `(54-51)*32+31 = 127`, hence 39_127 | 11:51 |
| F4PGASlackBridge | <hansfbaier> @tmichalak Great, thanks, I begin to understand. Let me try to insert that manually in the db and see if it works :) | 11:51 |
| F4PGASlackBridge | <tmichalak> Sure, no problem. I am running the fuzzer locally, to see if this feature is there anywhere and why it ends up at 0 candidates | 11:53 |
| F4PGASlackBridge | <hansfbaier> @tmichalak If that is solved, DDR3 might work on the high performance banks! It already works for all the bits on the Y1 pads! | 11:55 |
| F4PGASlackBridge | <hansfbaier> https://twitter.com/i/timeline | 11:55 |
| F4PGASlackBridge | <tmichalak> Oh, cool - it really seems that every other bit works !!! | 11:58 |
| F4PGASlackBridge | <hansfbaier> YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 12:01 |
| F4PGASlackBridge | <tmichalak> Great !!! | 12:02 |
| F4PGASlackBridge | <kgugala> Awesome | 12:02 |
| F4PGASlackBridge | <hansfbaier> ```RIOB18.IOB_Y0.SSTL12_SSTL135_SSTL15.IN 39_127``` This line did the trick | 12:04 |
| F4PGASlackBridge | <tmichalak> Ok, now we need to make sure the fuzzer does spit it out :) | 12:09 |
| F4PGASlackBridge | <hansfbaier> Yes | 12:19 |
| F4PGASlackBridge | <hansfbaier> I really wonder why it doesn't find the bit. I found a couple of minor bugs in the fuzzer (see PR today), but those didn't do the trick | 12:20 |
| F4PGASlackBridge | <hansfbaier> | 12:21 |
| F4PGASlackBridge | <hansfbaier> :tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada: | 12:28 |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has quit IRC | 15:03 | |
| *** chexum <chexum!~quassel@gateway/tor-sasl/chexum> has joined #f4pga | 15:04 | |
| *** gromero <gromero!~gromero@189-47-47-185.dsl.telesp.net.br> has quit IRC | 16:37 | |
| F4PGASlackBridge | <tmichalak> @hansfbaier I had a quick look at segmatch (after quite some time) and pushed some dirty changes (https://github.com/antmicro/prjxray/commit/5db9cc86d533e2dbfa524964099e974128252faf) which shows at which segment in which specimen the candidate bits disappear which results in "0 candidates" in the .rdb. From what I can see we are aiming at `39_127` for the following features: `RIOB18.IOB_Y0.SSTL12.IN` | 17:07 |
| F4PGASlackBridge | `RIOB18.IOB_Y0.SSTL135.IN` and `RIOB18.IOB_Y0.SSTL15.IN`, but in several segments there is no `39_127` even though the features above are set to `1` | 17:07 |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC | 17:08 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga | 17:09 | |
| *** jacobk <jacobk!~quassel@47-186-81-17.dlls.tx.frontiernet.net> has quit IRC | 19:13 | |
| *** jacobk <jacobk!~quassel@47-186-81-17.dlls.tx.frontiernet.net> has joined #f4pga | 19:23 | |
| F4PGASlackBridge | <hansfbaier> @tmichalak Actually the bit appears in RIOB18.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18.IN 38_126 39_127 | 21:28 |
| F4PGASlackBridge | <hansfbaier> So analogous to Y1, the correct line should be like that to exclude the other bit which is specific to LVCMOS: | 21:47 |
| F4PGASlackBridge | <tmichalak> Yes, there should be at least one negated bit to distinguish between LVCMOS and SSTL | 22:42 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!