作者查詢 / ric2k1
作者 ric2k1 在 PTT [ EE_DSnP ] 看板的留言(推文), 共5216則
限定看板:EE_DSnP
看板排序:
1F推:因為 00...000 與 11...111 是 inverse FEC,所以還是會被01/01 23:50
2F→:放在同一組,只是加上 ! 變成 !401/01 23:51
9F推:你這麼說的確有道理,ref prog 的確沒有把這個因素考慮進去01/02 00:12
10F→:我等一下有空來改一下。01/02 00:14
12F推:不過我又想了一下,在正常的 parrallel pattern 模擬底下01/02 00:21
13F→:兩個 gates 要前一次 32 個 patterns 是 eq, 下一次 32 個01/02 00:21
14F→:patterns 是 inv-eq 的機率幾乎是 0, 為了這樣去改變我收集01/02 00:22
15F→:FEC pairs 的機制似乎不太划算,所以我就不改了。01/02 00:23
16F→:我們在測的時候會注意不要讓這樣的情形發生。01/02 00:23
20F推:不懂... 不過基本上這不會影響 FRAIG 的正確性。也許在某些01/02 00:45
21F→:case 會讓 cirp -FEC 不夠精確,但我想 sim 的重點還是要快01/02 00:46
22F→:而且夠就好,誤判的情形就交給 SAT,整體來說應該是比較好01/02 00:47
23F推:簡單的說,如果前面 32n 個 parallel patterns讓兩個 gates01/02 01:15
24F→:的反應一樣,但下 32 個亂數的 parallel patterns 卻讓01/02 01:16
26F→:這兩個 gates 的反應正好反向,這樣的電路真的是太奇怪了,01/02 01:17
27F→:都給 SAT 去解 SAT(f == g) // 因為反向01/02 01:18
28F→:應該會一下子就解出來了,所以也不會有什麼 overhead01/02 01:19
29F→:但為了要檢查這種情形,以我目前的 implement 來說卻要01/02 01:19
30F→:多記/多傳一些東西,我覺得是不值得的。01/02 01:20
1F推:Somehow 我在我的工作站不會 crash... 你有大一點的case嗎?12/31 14:47
2F→:或許我加個 exception handling 好了!12/31 14:48
13F推:呵呵,這個在 lecture note #7, p6 也有教過哦!12/29 21:50
1F→:忘了說,作業二的成績也有部分更新 (橘色標示)。12/28 00:08
4F推:orz 之前 make 的時候忘記改 makefile 了!12/27 20:38
5F→:請見 #382812/27 20:39
1F推:兩種都可以,我們在測的時候會挑一些不會有 ambiguity 的12/25 00:57
2F→:case 來測!12/25 00:57
5F推:電路比較大的關係吧!?12/25 01:34
7F推:我的意思是電路比較大比較可能有因為順序不同而造成的差異12/25 22:31
8F→:不過如果你的 strash 是按照 DFS list 的 order 來做12/25 22:32
9F→:應該會一樣吧? (但還是會有誰 merge 誰的選擇而造成 ID不同12/25 22:33
3F推:恩,一個 gate 只要被踢出 FEC group 它就不可能再回來了12/25 22:30
2F推:Optimization 如果是從PI做到PO的話應該沒有你說的問題吧?12/23 22:10
3F→:所以第一種情況應該是有點多餘吧?12/23 22:14
6F推:兩種做法都可以,結果應該是一樣,就看你要怎麼 implement.12/30 16:51
1F推:Sure. 放至 ceiba 公佈欄了!12/23 16:39
6F→:地點在 "東豐街 敦化南路 信義路交口附近"12/23 22:08