(V)HDL Toolsets

[Jay Jaeger]

On 5/21/2020 11:55 AM, Paul Koning wrote:
> 
> 
>> On May 21, 2020, at 12:21 PM, Jay Jaeger <cube1 at 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