sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
cedric has quit [Read error: Connection reset by peer]
bluebugs has joined #m-labs
bluebugs has quit [Changing host]
bluebugs has joined #m-labs
rohitksingh_work has joined #m-labs
FelixVi has joined #m-labs
<FelixVi> sb0: I have synthesized over 200 different phase combinations by now and can't find one where the random address test in memtest passes
<FelixVi> Another 100 combinations are running, but I'm getting pretty close to saying it doesn't work
<FelixVi> My feeling is that the slower fabric on the -2 speedgrade makes it so the addr can't be ready on the right cpu clock edge
<FelixVi> So no matter how much you optimize, the only way to get it to work is by reducing the number of logic levels or by pipeling some of the address generation
<FelixVi> Not sure if there is another mechanism, i.e. using a serdes for address or delaying non-address signals by routing delays
<FelixVi> let me know if you have any ideas
<FelixVi> another thing could be setting up odelays, but for s6 they aren't temperature compensated
<FelixVi> the way xilinx does it is, I believe, by dynamic correction
<FelixVi> question is if that's the way to go... I don't like that solution very much
_whitelogger has joined #m-labs
<FelixVi> later tonight (or tomorrow ;), I'll be able to do some timing analysis and find out exactly what paths are problematic
<FelixVi> all I know this far is that it's in the address clock domain and (afaik) related to the dfi bus
<mithro> sb0: ping?
bluebugs is now known as cedric
FabM has joined #m-labs
FelixVi has quit [Ping timeout: 240 seconds]
FelixVi has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo> whitequark: how is the switch issue coming along?
rohitksingh_work has joined #m-labs
<rjo> sb0: is the interframe gap question resolved?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub53> [artiq] jbqubit commented on issue #847: What is Vivado doing that ARTIQ is not? @gkasprow please spell out exactly what the switches are that need to be set for booting from FLASH. Have you seen booting-from-flash failure that @sbourdeauducq reports? https://github.com/m-labs/artiq/issues/847#issuecomment-346852339
<GitHub9> [artiq] gkasprow commented on issue #847: The switch position does not matter if you load both fpgas via jtag.
<GitHub168> [artiq] gkasprow commented on issue #847: So far the FLASH configures only AMC side.
<GitHub84> [artiq] jbqubit commented on issue #847: ARTIQ loading: 1. flash FPGA proxy .bit using JTAG, 2. send flash data to FPGA which writes to flash, 3. FPGA resets and expects to load .bit from flash. Please detail what the switch configuration needs to be for step 3. https://github.com/m-labs/artiq/issues/847#issuecomment-346858387
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub64> [artiq] sbourdeauducq commented on issue #846: That's not the right source, you should be looking at MiSoC, and it has been tested on KC705, Papilio Pro, Pipistrello and probably others. https://github.com/m-labs/artiq/issues/846#issuecomment-346868607
<sb0> mithro, yes?
<sb0> rjo, looking into the artix-7 transceiver right now. also it would be nice if _florent_ took care of such details when coding...
<rjo> isn't the interframe gap at the mac level and not at the phy/xceiver level?
<rjo> sb0: but ack.
<sb0> yes, it's in the generic ethernet code that _florent_ wrote
<_florent_> sb0: hmmmm
hdante has joined #m-labs
Ultrasauce has quit [Ping timeout: 248 seconds]
hdante has quit [Quit: hdante]
hdante has joined #m-labs
hdante has quit [Read error: Connection reset by peer]
<bb-m-labs> build #900 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/900
Ultrasauce has joined #m-labs
<bb-m-labs> build #1783 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1783 blamelist: Robert Jordens <rj@m-labs.hk>
hdante has joined #m-labs
<FelixVi> sb0: still no luck with the ddr @ 75 MHz cpu freq - just can't get the address to the chip fast enough
<FelixVi> this is the first failing path: https://pastebin.com/Z9bgU3Du
<FelixVi> it's getting from lm32_cpu/load_store_unit to ddrphy_record1
hdante has quit [Quit: hdante]
<cr1901_modern> Where are they calculating 6.683ns from? (Clearly it fails due to negative slack. But not by that much)
<cr1901_modern> Won't have time to check till later- prior engagement :(
<FelixVi> cr1901_modern: 6.683 is for the full path
<FelixVi> the part I'm showing is where timing breaks down first for me
<FelixVi> it's basically the first setup time that gets violated when the timing starts to go off
<FelixVi> my conclusion is that lm32 won't be able to run at 75 MHz
<FelixVi> so I think I'll just get it going @ 40 MHz
<FelixVi> but wanted to see if anybody else has ideas
<FelixVi> cr1901_modern: I still got a couple more combinations to test - maybe I get lucky
<FelixVi> my concern would be that even if, does this break down as soon as you start adding stuff and the design gets more dense on the fabric?
<cr1901_modern> FelixVi: mimasv2 is a S6LX9 with speed grade 2. We were able to get that working at 83.33MHz with a DRAM controller
<FelixVi> cr1901_modern: I tried those setting but didn't get it to work
<FelixVi> but I should probably try again now that I have a bit more sense about what's going on
<FelixVi> I think I got timing violations with the exact same settings
<FelixVi> cr1901_modern: to be sure I'll run the mimas settings will all bitslip options and doublecheck
<cr1901_modern> Ack.
<FelixVi> cr1901_modern: timing violation on system clock
<FelixVi> cr1901_modern: The numato website makes no reference to speed grade - can you confirm that they use -2? I'm pretty sure they do
<FelixVi> cr1901_modern: NVM, it is -2 in the target file
<cr1901_modern> FelixVi: Oh right I forgot about that. But we uploaded the bitstream anyway and it worked :3
<FelixVi> oh, so you had a violation, too?
<FelixVi> i'm running the original mimasv2 right now to see
<cr1901_modern> Actually, that error wasn't "fatal" in our case- return value from that synthesis step was 0, so it kept going
<FelixVi> but running files with timing violation isn't really something I'd like to do
<FelixVi> may work fine at room temperature and break when things get hot or other weird stuff like that
<cr1901_modern> Totally fair. What I was getting at is that it works at 83.333MHz at all, even w/ speed grade 2
<FelixVi> the original mimas file gives me a timing violation on sysclk as well
<cr1901_modern> so I find that a bigger FPGA in the same family with the same speed grade as being odd
<FelixVi> well, the fabric is as slow as in the small one
<cr1901_modern> so I find that a bigger FPGA in the same family with the same speed grade only passing timing at _half_ the speed as being odd*
<FelixVi> you you get the same violations
<FelixVi> it doesn't pass at 83 or 75
<FelixVi> it does at 25
<cr1901_modern> mimas or yours?
<FelixVi> and I think it does at 40 (need to do that one next)
<FelixVi> mine
<FelixVi> by pass I mean no timing violations and passing memtest
<cr1901_modern> Try 50 if possible and work from there
* cr1901_modern has to go do meatspace things
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
hdante has joined #m-labs
hdante has quit [Remote host closed the connection]