Hi all, I'm having trouble generating functional borph executables, and i'm hoping someone can help me figure out why. Since i'm targeting high speeds, i can't use the bee_xps workflow. So here's what i'm doing:
1) synthesize a mdl via the bee_xps interface. 2) load the netlist into PlanAhead. 3) manually place various components. 4) modify the four NET "adc[01]clk_[np]" PERIOD constraints. 5) run implementation. 6) verify that the timing score is 0. 7) run bitgen. 8) run mkbof (using core_info.tab from the bee_xps run). If i just use bee_xps from mdl to bof, i get always get a functional design at 200MHz. If i then load that netlist into PlanAhead, do not floorplan anything, do not change any constraints, and just run implementation and bitgen, then mkbof again gives me a functional executable for 200MHz. But if i then floorplan my DSP48Es and BRAMs, do not change any period constraints, and run implementation and bitgen, then mkbof gives me a broken executable for 200MHz. By "broken", i mean: i can program the fpga, but all the registers read out zero; if i write a register, it continues to read back zero. To rule out tcpborphserver, i logged into a board and manually executed my bof while monitoring dmesg. It programs without error. When i echo values into the fabric-mapped registers in /proc, reads and writes also give no errors. But i always read back zero, so something somewhere is broken. Suraj started a thread about something similar sounding last July: http://www.mail-archive.com/casper@lists.berkeley.edu/msg01694.html But there wasn't a solution, just a hack workaround requiring jtag. Based on external observations, i would guess that mkbof is making some assumptions about input bitstreams that are only guaranteed to hold for bitstreams generated by bee_xps. But i don't know anything about mkbof, so i could be wrong. I've noticed that bof files generated from PlanAhead bitstreams have 122 more bytes of metadata at offset 0x1282. Maybe mkbof doesn't expect that? I've also noticed that when i floorplan, adc0's sync input sometimes ends up in the middle of the fpga instead of on the left edge where you'd expect it to be. Maybe things like this don't happen at lower speeds with bee_xps, but it trips up mkbof when it does? But i really have no idea, so i'll stop guessing. Maybe someone more clueful about mkbof and/or borph can suggest something? Billy
