On 5/21/2020 11:55 AM, Paul Koning wrote: > > >> On May 21, 2020, at 12:21 PM, Jay Jaeger <cu...@charter.net> wrote: >> >> On 5/21/2020 9:51 AM, Paul Koning wrote: >>> >> ... >>> If the timing in your machine is reasonably sane and has enough margin, the >>> simulation should be painless and synthesis should produce few issues. If >>> you have bits that are sensitive to wire or circuit delays, that's >>> different. Unfortunately, the 6600 is utterly infested with such issues, >>> to the point that it's hard to see how it ever worked at all -- the timing >>> documented in the manuals and implied by the wiring can't actually work. A >>> 1410 is probably better, especially considering that IBM had some senior >>> designers who had experienced timing pain first-hand and had learned to >>> avoid it. I'm thinking of people like Gerrit Blaauw (not sure if he was on >>> that project, though). >> >> There may be some such sensitivities, but I doubt there are many - the >> 1410 was not a fast machine by any stretch of the imagination. >> Actually, the situation I am most concerned about in that department is >> that the FPGA signals will propagate faster than the original, so a >> signal might change state too quickly as compared to the original. > > This sort of question is why I found starting with the simulator is helpful. > In a simulation you can specify delays directly. So for my 6600, I have the > gate delay (5 ns) and the wire delays (1.3 ns per foot, in the twisted pair, > or 25 ns for coax cables including tx/rx circuit). Actually, I only include > wire delays for "long" wires; the design clearly uses wires longer than > needed in various places for delay reasons, but my guess is that short wires > are not time sensitive. That may be wrong; I need to run it again without > that assumption to see if it helps.
I do indeed plan on starting with simulation - just not for that reason. Its just easier to debug then the FPGA proper. ;) I suppose I could figure out the actual wire list, and thus wire lengths, but it would be have to be limited only to inter-panel wires, and even that much would be painful and very time consuming. But yeah, it makes sense to model gate delays in a general way and then perhaps lower them to see what happens at higher speeds, as you suggest below. > > Once the design works that way, I can then see what would happen in > synthesis, by replacing the original stage and wire delays by much smaller > values. Any place where that breaks things needs an explicit register > inserted to replace the wire "register". I know there will be a bunch of > those, hopefully hundreds and not tens of thousands. I hope not to introduce any delays not present in the original. Instead I do plan to insert D flip flops anywhere there is a combinatorial loop. > > For more sane machines like a 1410 or an EL-X8, the same approach lets you > determine whether there is any timing sensitive stuff in the design. If not, > then changing the model delays from "original" to "very fast" would break > nothing. If so, turning off the delays gives you a synthesizable design, or > very nearly one. > > paul > > JRJ
