(V)HDL Toolsets

[Jay Jaeger]

On 5/21/2020 9:51 AM, Paul Koning wrote:
> 
> 
>> On May 20, 2020, at 10:22 PM, Jay Jaeger via cctalk <cctalk at classiccmp.org> wrote:
>>
>> As I wrote in my last post, but write here for use as a separate thread:
>>
>> I'd be interesting in hearing from folks what toolsets they have used
>> for HDL (VHDL in particular).  I started with Xilinx ISE and then
>> graduated to Vivado for later chipsets - unfortunately, Vivado seems to
>> be something of a dog, in terms of time to compile HDL and synthesize logic.
>>
>> JRJ
> 
> I have been working, very slowly, on a project analogous to yours: a gate level model of the CDC 6600 supercomputer. 

I recall you mentioning that along the way.  You have my sympathy and
empathy.  ;)

> 
> The source material for this is the wiring lists, which show the module connections and also the module logic diagrams.  I used the diagrams to create gate-level models for each module, and ran the wire lists through OCR to get the connections.  Those are then run through a simple Python program to generate the equivalent structural model.
> 
> I wanted to start with simulation, and treat synthesis as a later step.  So rather than use any particular vendor tools I used GHDL.  That works quite nicely.  Among other benefits, since it generates executable code (it's a GCC front end) it can call C functions.  In my case, the memory and I/O devices are C models, which the VHDL code talks to.  GHDL supports output to GTKwave to let you see what it is doing.  And, at least to some extent, you can use GDB on it.  I haven't done much of that.
> 

My eventual plans for I/O devices is to use one of the various serial
busses for that, talking to additional FPGAs or even microcontrollers.

> The whole process of going from wiring to VHDL is quite straightforward.  Getting the wire lists exactly correct takes some work partly because of OCR errors and partly because there may be typos in the wire lists.  Also in the 6600 case, the wire lists are per chassis and they aren't all the same revision of the product. :-(
> 

Again, I sympathize and empathize.  I am in the same boat with the IBM
1410.  I was a little naive when I picked through the materials to
decide what to take to scan, and time was limited.

The 1410 had an "accelerator" feature.  Most of the pages I have are for
that version, but not all of them (and my reports pick up on some issues
that result from that.)  Worse, I have a few missing pages, where I'll
just have to hand code something based on the CE Instructional materials
and lessons learned when I wrote my simulator.

> 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.

I took a course in semiconductor physics from Prof. Henry Guckel at U.
Wisconsin.  He described working for IBM on some really fast machines
(like the 360/95, I think).    He described pulling their hair out (and
he didn't have much left) where they would add some delays in places to
make timing work, and by the time they were done with that effort, the
result was the machine ran more slowly than it did with a slower system
clock.

> 
> If you have delay-sensitive elements, that will probably require adding extra stages to the logic, such as additional latches, to produce the required sequencing with modern logic, which in turn may require extra clock phases.  Here too the 6600 is amazingly painful: I found myself with a 20-phase clock to get even close to sane operation, in what is typically described as a four phase clock design.

Fortunately the 1410 seems to be much much simpler, and largely
asynchronous.  It has at most two phases: the main 1.5 MHz (well, on the
ALD 1.5 MC  ;) ) clock and one that  is delayed a bit in order to make
one trigger work correctly.  After that there is just the main clock
pulse stream, and a 2nd one that is 180 degrees out of phase.

> 
> Others have mentioned Verilog.  I have no experience with that.  I landed on VHDL mostly by accident, because I wanted an open source simulator and GHDL showed up.  There may be open source Verilog simulators at this point, I'm not sure.  Avoiding Windows was also a requirement.

I looked at both.  I am using VHDL now, but the structure of the HDL
generation code is such that adding Verilog should not be difficult.

> 
> 	paul
> 

Thanks for the reply.

JRJ