Yes, the simplest design that does the job is the best.
Unfortunately, the issue with building hardware for physics experiments is that there is never a clear-cut and exact specification for what's needed for a number of reasons: - it wouldn't be research if we understood everything completely - often, we can tolerate a decrease in HW performance by adding additional complexity elsewhere in our experiment - if we're going to spend large sums of money on HW, we want to make sure that we have some performance overhead in case our requirements change in the future -- at something like 10k a Sayma, we don't want to find that it doesn't meet our long-term needs because we skimped on the specification - we want to try to leave the door open for new use cases/experiments we haven't yet thought of So, the only way to arrive at a good design is to understand the trade-offs between performance and its impact on users and complexity, so we can try to make an informed decision about where to aim for. If you want to argue for a decrease in design complexity, that's fine, but we need details. Various changes are being discussed. How much difference would each of them actually make to you? If you just keep repeating that "simpler designs are better" without giving any more details, I don't see how we're supposed to make any progress on this. T Dr Thomas Harty Junior Research Fellow, St John's College University of Oxford, Department of Physics The Clarendon Laboratory Parks Road, Oxford, OX1 3PU Mob: +44 (0)7986 375 052 Lab: +44 (0)1865 272 572 ________________________________ From: Thomas Harty Sent: 09 August 2018 08:12 To: Sébastien Bourdeauducq; artiq@lists.m-labs.hk; Robert Jördens Subject: Re: SAWG Sébastien, Understood. But, that's quite a vague answer. We don't want to throw away performance/flexibility unnecessarily. So, the questions are: how much do we need to simplify the SAWG to make it okay to debug and maintain at the 1GSPS data rate? and, what's the way of doing that, which has the least impact on users? If we need a short exploratory project to answer those questions then so be it. Tom Dr Thomas Harty Junior Research Fellow, St John's College University of Oxford, Department of Physics The Clarendon Laboratory Parks Road, Oxford, OX1 3PU Mob: +44 (0)7986 375 052 Lab: +44 (0)1865 272 572 ________________________________ From: Sébastien Bourdeauducq <s...@m-labs.hk> Sent: 09 August 2018 02:53:43 To: Thomas Harty; artiq@lists.m-labs.hk; Robert Jördens Subject: SAWG On Thursday, August 09, 2018 03:15 AM, Thomas Harty via ARTIQ wrote: > it's a big FPGA and IIRC we're not > really pushing the resources limits yet (but maybe I'm wrong about > that?), so it's not clear that's actually a problem. I get that > multi-hour compile times are death, but at least we haven't seen any > Sayma bugs that depend on whether the Sawg is enabled or not for quite a > while (since we fixed the power supplies). So, maybe it's not actually > such an issue if the majority of Sawg testing can be done in simulation, > and any non-SAWG issues on Sayma can be debugging in non-SAWG builds? Let's not get too optimistic. There can be difficult problems with timing closure and routing congestion, which are already a bit sensitive with the current design. Those cannot be solved with a partial design only. Also, even if there are no more Sayma-bugs, simulation/hardware mismatches might still happen (due to Vivado miscompilations, Verilog simulation issues, or Migen bugs). Having a smaller, faster to compile design is valuable. Sébastien
_______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq