20 May
2020
20 May
'20
7:22 p.m.
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
21 May
21 May
4:34 a.m.
If you?re targeting FPGA hardware (opposed to a design for a foundry, or a design you want
to run exclusively in a simulator), it is kind of inevitable that you work with the
toolchains that the hardware vendor supplies. Would be nice if you could choose freely
from competing toolchains, but the hardware isn?t exactly open, so that?s not going to
happen.
So basically what it comes down to is Quartus or Vivado. I?ve kind of implicitly chosen
Quartus, because the Altera based development boards tend to be a lot nicer and cheaper
than the Xilinx based stuff. I haven?t even followed the upgrades from ISE to Vivado.
Not sure if the level of doggyness is any different between those, it?s more like getting
to know the specific bugs and working around them. Can be pretty annoying at times though.
For instance, one of the things Quartus doesn?t get is that if source files are changed,
it might make sense to recompile - it only gets that if you change sources through its own
editor. Not really a big problem maybe, but it shows that the tools are far from
friendly.
One of the things I?ve done with my pdp11 vhdl from the start is that I?ve not used any
vendor specific constructs or language extensions. That?s probably the only design
decision that I?m still really happy about - it allows me to change to another vendor and
another tool chain at will.
Cheers
Sytse
On 21 May 2020, at 04:22, 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
5:41 a.m.
On Thu, May 21, 2020 at 01:34:09PM +0200, Sytse van Slooten via cctalk wrote:
[...]
So basically what it comes down to is Quartus or
Vivado. I?ve kind of
implicitly chosen Quartus, because the Altera based development boards tend
to be a lot nicer and cheaper than the Xilinx based stuff. I haven?t even
followed the upgrades from ISE to Vivado.
My understanding from when I was looing at FPGAs in ~2013 is that Xilinx make
better FPGAs than Altera (now Intel), but Altera's tools are better. Having had
the "joy" of using Altera's Quartus, I dread to think how terrible ISE must
be.
From a cursory check, Vivado appears to be just an
rebranded newer version of
ISE rather than a fundamental change.
Quartus puts me in mind of the dark days of the 1980s with its expensive,
closed-source, and generally shoddy software development environments before
GNU came along and wiped them out. Good riddance do the lot of them.
Even the HDLs themselves are stuck in the 1980s. Verilog is described as being
C-like, but that's not exactly a compliment. VHDL is Ada-like or Pascal-like,
i.e. designed by a committee and/or academics who have definite opinions about
how other people should write code, but don't do much of it themselves.
There are at least finally some open-source HDLs banging about which have
incorporated useful ideas from the last four decades of language design and
thus be easier to create correct code. (Thich is a crucial difference from
"easier to create something which runs", which is C/Verilog's schtick.)
Unfortunately, because of the lack of documententation on the FPGA bitstreams,
the best they can do is be a source-to-source translator piped into the
proprietary tooling.
9:06 a.m.
On 5/21/2020 7:41 AM, Peter Corlett via cctalk wrote:
On Thu, May 21, 2020 at 01:34:09PM +0200, Sytse van
Slooten via cctalk wrote:
[...]
ISE isn't/wasn't so bad, performance-wise. Vivado has been painful.
So basically what it comes down to is Quartus or
Vivado. I?ve kind of
implicitly chosen Quartus, because the Altera based development boards tend
to be a lot nicer and cheaper than the Xilinx based stuff. I haven?t even
followed the upgrades from ISE to Vivado.
My understanding from when I was looing at FPGAs in ~2013 is that Xilinx make
better FPGAs than Altera (now Intel), but Altera's tools are better. Having had
the "joy" of using Altera's Quartus, I dread to think how terrible ISE must
be.
From a cursory check, Vivado appears to be just an
rebranded newer version of
ISE rather than a fundamental change.
Quartus puts me in mind of the dark days of the 1980s with its expensive,
closed-source, and generally shoddy software development environments before
GNU came along and wiped them out. Good riddance do the lot of them.
Even the HDLs themselves are stuck in the 1980s. Verilog is described as being
C-like, but that's not exactly a compliment. VHDL is Ada-like or Pascal-like,
i.e. designed by a committee and/or academics who have definite opinions about
how other people should write code, but don't do much of it themselves.
The design of my application is such that it should not be difficult to
adapt it to generate whatever kind of HDL one might want. I learned
both Verilog and VHDL along the way, using the Mano/Kime book "Logic and
Computer Design Fundamentals" - it was a coin flip which I decided to
work with first. (Prof. Charles Kime was my adviser when I was an ECE
student in the early 1970's).
There are at least finally some open-source HDLs banging about which have
incorporated useful ideas from the last four decades of language design and
thus be easier to create correct code. (Thich is a crucial difference from
"easier to create something which runs", which is C/Verilog's schtick.)
Unfortunately, because of the lack of documententation on the FPGA bitstreams,
the best they can do is be a source-to-source translator piped into the
proprietary tooling.
That's an interesting idea for later, maybe.
Thanks.
JRJ
6:23 a.m.
I've taken to using parts supported by the open source toolchains & IP,
that mostly limits me to using Lattice parts, but the efficiencies obtained
from not instancing all the extra garbage from a
vendor's IP library is
worth it. When you use the vendor tools, they want to
waste as many gates
as they can get away with so you buy larger more expensive parts. The open
source toolchains optimize out stuff that would just get left dangling.
https://www.bunniestudios.com/blog/?p=5018 gives a good overview of what
this can look like and the NeTV2 is a project that uses the migen/litex
toolchain well.
On Thu, May 21, 2020, 7:34 AM Sytse van Slooten via cctalk <
cctalk at classiccmp.org> wrote:
If you?re targeting FPGA hardware (opposed to a design
for a foundry, or a
design you want to run exclusively in a simulator), it is kind of
inevitable that you work with the toolchains that the hardware vendor
supplies. Would be nice if you could choose freely from competing
toolchains, but the hardware isn?t exactly open, so that?s not going to
happen.
So basically what it comes down to is Quartus or Vivado. I?ve kind of
implicitly chosen Quartus, because the Altera based development boards tend
to be a lot nicer and cheaper than the Xilinx based stuff. I haven?t even
followed the upgrades from ISE to Vivado.
Not sure if the level of doggyness is any different between those, it?s
more like getting to know the specific bugs and working around them. Can be
pretty annoying at times though. For instance, one of the things Quartus
doesn?t get is that if source files are changed, it might make sense to
recompile - it only gets that if you change sources through its own editor.
Not really a big problem maybe, but it shows that the tools are far from
friendly.
One of the things I?ve done with my pdp11 vhdl from the start is that I?ve
not used any vendor specific constructs or language extensions. That?s
probably the only design decision that I?m still really happy about - it
allows me to change to another vendor and another tool chain at will.
Cheers
Sytse
On 21 May 2020, at 04:22, 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
12:13 p.m.
I call complete BS on Bunnie Huang's notion that both the way the HDL
module is written and the lack of area optimization is due to some
nefarious intent to sell bigger silicon by Xilinx. I'm really not a fan
of that guy so maybe my glasses are tinted anti-rose. But the design of
large HDL modules like their DDR controller and PCI Express cores are
written to be as flexible as possible to the largest set of
applications. People code 'code' and thus it is always subject to
design over-sights and mistakes. Actually Lattice has some of the most
bloated and abstracted code I've seen from the bigger 4 vendors. The
lack of a compile time flag to turn off the sub-bridge was most likely
an oversight.
Xilinx and Intel/Altera's main customer base are large customers that
buy expensive chips. Their canned IP is always going to be designed for
those larger applications first.
He also makes the assertion Vivado declined to optimize out that
sub-module when all it's inputs were at deterministic levels. I find
that impossible to believe. IMPOSSIBLE. The tools just don't do that.
It's 1000 times more likely there was a path in the code that he missed
that was causing a logic inference that cascaded throughout that module.
Yet he immediately jumped to the conclusion Xilinx was just after more
money - the main reason I think that guy is a class A tool.
I'm a fan of the FOSS toolchains for Lattice ice40 and ESP5 parts
myself. But not for the reasons you argue. We can arm-wrestle over it
later.
-A
On 2020-05-21 09:23, David Kuder via cctalk wrote:
I've taken to using parts supported by the open
source toolchains & IP,
that mostly limits me to using Lattice parts, but the efficiencies
obtained
from not instancing all the extra garbage from a vendor's IP library is
worth it. When you use the vendor tools, they want to waste as many
gates
as they can get away with so you buy larger more expensive parts. The
open
source toolchains optimize out stuff that would just get left dangling.
https://www.bunniestudios.com/blog/?p=5018 gives a good overview of
what
this can look like and the NeTV2 is a project that uses the migen/litex
toolchain well.
On Thu, May 21, 2020, 7:34 AM Sytse van Slooten via cctalk <
cctalk at classiccmp.org> wrote:
8:46 a.m.
Helpful tips - I agree with avoiding vendor extensions. Thanks.
I seem to recall some issues regarding edits inside vs. outside Vivado
as well, but it has been more than a year, so the recollection is fuzzy.
JRJ
On 5/21/2020 6:34 AM, Sytse van Slooten wrote:
If you?re targeting FPGA hardware (opposed to a design
for a foundry, or a design you want to run exclusively in a simulator), it is kind of
inevitable that you work with the toolchains that the hardware vendor supplies. Would be
nice if you could choose freely from competing toolchains, but the hardware isn?t exactly
open, so that?s not going to happen.
So basically what it comes down to is Quartus or Vivado. I?ve kind of implicitly chosen
Quartus, because the Altera based development boards tend to be a lot nicer and cheaper
than the Xilinx based stuff. I haven?t even followed the upgrades from ISE to Vivado.
Not sure if the level of doggyness is any different between those, it?s more like getting
to know the specific bugs and working around them. Can be pretty annoying at times though.
For instance, one of the things Quartus doesn?t get is that if source files are changed,
it might make sense to recompile - it only gets that if you change sources through its own
editor. Not really a big problem maybe, but it shows that the tools are far from
friendly.
One of the things I?ve done with my pdp11 vhdl from the start is that I?ve not used any
vendor specific constructs or language extensions. That?s probably the only design
decision that I?m still really happy about - it allows me to change to another vendor and
another tool chain at will.
Cheers
Sytse
On 21 May 2020, at 04:22, 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
22 May
22 May
2:45 p.m.
On May 21, 2020, at 8:46 AM, Jay Jaeger via cctalk <cctalk at classiccmp.org>
wrote:
Helpful tips - I agree with avoiding vendor extensions. Thanks.
I?d strongly suggest that the situation with FPGAs & HDLs requires a bit more nuance
than that. You *should* probably avoid or carefully isolate vendor *language extensions*.
However, you *should not* avoid vendor *IP blocks*.
As an example, let?s say you have a design that needs a RAM controller. Do you:
(1) Write your own DDR controller as part of your design; or,
(2) Interface your design to your FPGA vendor?s DDR controller IP block?
In general you *should* do the latter?as long as you can do so via a sane
abstraction?rather than the former, unless you have an extremely compelling case for doing
the former.
And ?portability? isn?t actually that compelling of a case: Virtually every set of tools
and chips you might want to work with will have a similar variety of IP blocks available,
many implemented via dedicated on-device logic (rather than consuming general-purpose
logic cells), so as long as you can isolate their use you can still keep your overall
design portable.
This is particularly important for things that have strict timing requirements and that
might otherwise soak up a lot of your device?s bandwidth, e.g. HDMI input/output, RAM
control, Ethernet, and so on.
-- Chris
23 May
23 May
7:54 a.m.
On 5/22/2020 4:45 PM, Chris Hanson wrote:
On May 21, 2020, at 8:46 AM, Jay Jaeger via cctalk
<cctalk at classiccmp.org> wrote:
I don't think a 100K character IBM SMS machine needs DDR. 8D For my
old student ECE ZAP machine, I just used very simple
on-development-board RAM, with a layer in between. Probably do the same
here.
Ethernet might be nice, but I don't think I'd include a whole IP just to
get that - probably just use I2C or SPI to an external micro controller
(for lamps, switches, the console selectric, etc.) Doing this would
also help me fit to a smaller FPGA.
Context matters. ;)
Helpful tips - I agree with avoiding vendor extensions. Thanks.
I?d strongly suggest that the situation with FPGAs & HDLs requires a bit more nuance
than that. You *should* probably avoid or carefully isolate vendor *language extensions*.
However, you *should not* avoid vendor *IP blocks*.
As an example, let?s say you have a design that needs a RAM controller. Do you:
(1) Write your own DDR controller as part of your design; or,
(2) Interface your design to your FPGA vendor?s DDR controller IP block?
In general you *should* do the latter?as long as you can do so via a sane
abstraction?rather than the former, unless you have an extremely compelling case for doing
the former.
And ?portability? isn?t actually that compelling of a case: Virtually every set of tools
and chips you might want to work with will have a similar variety of IP blocks available,
many implemented via dedicated on-device logic (rather than consuming general-purpose
logic cells), so as long as you can isolate their use you can still keep your overall
design portable.
This is particularly important for things that have strict timing requirements and that
might otherwise soak up a lot of your device?s bandwidth, e.g. HDMI input/output, RAM
control, Ethernet, and so on.
-- Chris
JRJ
3:07 p.m.
New subject: GHDL Thanks (Re: (V)HDL Toolsets)
Thanks to all of those who suggested looking at GHDL. Essentially
instant "analyze" runs. That alone is going to save me hours => days =>
even weeks of time compared to Vivado or even ISE.
I tried one file I had already generated and it worked as is, except for
the need to yank out the library/use statements for Vivado default
libraries and replace them with use WORK.ALL (and added a template file
that gets automatically included, so one can put in whatever one wants
to use). Also simulated fine.
GTKWave is a little flaky (sometimes it hangs when closing - I am using
a pre-built Windows version, so it might be a little long in the tooth),
but it certainly gets the job done.
Thanks!
JRJ
4:47 p.m.
On May 23, 2020, at 7:54 AM, Jay Jaeger <cube1 at charter.net> wrote:
I don't think a 100K character IBM SMS machine needs DDR. 8D For my
old student ECE ZAP machine, I just used very simple
on-development-board RAM, with a layer in between. Probably do the same
here.
These days, the RAM on a lot of development boards is DDR or something else that requires
a significant amount of controller work.
Ethernet might be nice, but I don't think I'd
include a whole IP just to
get that
I think it depends on whether you want to expose *Ethernet* to the device you?re
implementing, or just to provide access to it *over* Ethernet. Exposing serial and other
channels via SPI or I2C is certainly straightforward.
probably just use I2C or SPI to an external micro
controller
(for lamps, switches, the console selectric, etc.) Doing this would
also help me fit to a smaller FPGA.
Of course, there are also IP blocks for I2C and SPI, some of which may again map to
dedicated hardware on the FPGA, providing more room for your logic.
So yes, context matters, but you need to look at both what you want to accomplish *and*
what the tooling and FPGA you?re using can provide.
Why do more integration work than you have to when you can focus on the interesting
stuff?
-- Chris
7:40 p.m.
On 5/23/2020 6:47 PM, Chris Hanson wrote:
On May 23, 2020, at 7:54 AM, Jay Jaeger <cube1 at
charter.net> wrote:
I think it depends on whether you want to expose *Ethernet* to the device you?re
implementing, or just to provide access to it *over* Ethernet. Exposing serial and other
channels via SPI or I2C is certainly straightforward.
Actually, neither, really. This is an ollllllllllllld mainframe I am
implementing. I will be exposing the lamps and switches (machine state
vector), a selectric console typewriter I/O and 7 track tape drives, and
maybe, eventually, a tiny (10MB) random access device. SPI or I2C
to/from a microcontroller (PIC, Arduino, whatever) will do the trick
nicely - it can then talk TCP to the PC for data for the tapes and disk.
JRJ
21 May
21 May
11:09 a.m.
On 2020-05-21 07:34, Sytse van Slooten via cctalk wrote:
One of the things I?ve done with my pdp11 vhdl from
the start is that I?ve not used any vendor specific constructs or language extensions.
That?s probably the only design decision that I?m still really happy about - it allows me
to change to another vendor and another tool chain at will.
That's actually VERY important!
There is always a way, to get around the vendor specifics, and actually,
all three (altera/lattice/xilinx) got better over time, to figure what
you actually like to do (inferring RAM/ROM/Tables etc.).
So using the vendor specific stuff, gets you the last ns squeezed out of
the design, but in most cases it isn't necessary. However, in some
cases, you can't get around (DDR3/DDR4/etc) it is simpler to use the
Macros/Wizard to do.
And, just look around, there are some open projects, which use all three
in them, so you can learn a lot, how to hide the differences ...
Personally, I like to play with all of them, also to be able to compare
chips & tool chain. (made some carrier boards, and plug in little
modules, which just contain the FPGAs on them, to be able to easier
exchange them)
Cheers!
4:45 a.m.
On 2020-05-20 22:22, Jay Jaeger via cctalk 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.
I feel your pain ;-)
To deal with the ISE<->Vivado speeds, we always chose a target which is
supported on both. One of the reasons, I have the artix7-100 on all my
boards, makes life much easier.
Then just use ISE for the "quick around" time, and vivado for the tough
stuff.
Vivado was pretty much useless in the first revisions, but now it is at
a stage, where it is really usable. Yes, it is slow :(
On the other hand, the simulator in Vivado got much better, and works
for both, Verilog & VHDL, and also in mixed mode, which helps a lot.
And it is tough to complain about a free tool, which runs on Linux & Win ...
A lot of guys I know, use also GHDL for simulations, if command line is
your thing.
8:55 a.m.
On 5/21/2020 6:45 AM, emanuel stiebler wrote:
On 2020-05-20 22:22, Jay Jaeger via cctalk wrote:
That's a great suggestion. Fortunately, I do have experience with the
DLL fix for ISE, which they no longer support, so I can run ISE if I
want to. And, hey, if the design fits, I even have an older Nexsys 2 to
fit it to.
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.
I feel your pain ;-)
To deal with the ISE<->Vivado speeds, we always chose a target which is
supported on both. One of the reasons, I have the artix7-100 on all my
boards, makes life much easier.
Then just use ISE for the "quick around" time, and vivado for the tough
stuff.
Vivado was pretty much useless in the first revisions,
but now it is at
a stage, where it is really usable. Yes, it is slow :(
Even that confirmation is helpful. ;)
On the other hand, the simulator in Vivado got much
better, and works
for both, Verilog & VHDL, and also in mixed mode, which helps a lot.
And it is tough to complain about a free tool, which runs on Linux & Win ...
As a hobbyist, I agree. If I were doing this stuff professionally, in
quantity, I'd be all over them like a wet blanket just from a standpoint
of lost productive time. I suspect that if either one, Intel/Altera or
Xilinx came up with a substantially more productive toolchain, it could
move the needle on market share.
A lot of guys I know, use also GHDL for simulations,
if command line is
your thing.
I have seen that suggestion from another correspondent on the list as
well, and I think it is a good one, likely to save lots of time. I
don't mind command lines - I go all the way back through UNIX 6th
edition to card decks. ;)
Thanks.
JRJ
5:57 a.m.
On 5/20/20 10:22 PM, Jay Jaeger via cctech wrote:
I'd be interesting in hearing from folks what
toolsets they have used
for HDL (VHDL in particular).
I've been using Verilog rather than VHDL but I started with Quartus for
a little while then moved over to Vivado which I like a little better.?
I agree with Peter's point that I sure wish the bitstreams were open so
that a crop of open-source tools could be developed and we'd have a bit
more choice.? Along these lines, I've been wondering if I ought to take
a closer look at SymbiFlow, but I have digressed.
What I really use more often though is the Icarus Verilog simulator.?
Besides Verilog testbenches, I've been running the PDP-10 diagnostics
under Icarus.? I even wrote a PDP-10 disassembler in Verilog so it
disassembles and prints out the instructions as it executes them.
I also came across Verilator, a Verilog to C++ compiler.? It makes for
faster running simulations but so far I'm only using it for its 'lint'
function which is pretty nice.? It catches logic loops that just put
Icarus into infinite loops.
7:51 a.m.
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.
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.
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. :-(
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).
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.
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.
paul
8 a.m.
On 5/21/20 9:51 AM, Paul Koning via cctalk wrote:
Paul, your project is super interesting. Is there a website where I can track it?
--tom
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.
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.
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. :-(
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).
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.
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.
paul
9:22 a.m.
On 5/21/2020 10:00 AM, Tom Uban wrote:
Paul,
your project is super interesting. Is there a website where I can track it?
--tom
Mainly the github.com/cube1us/IBM1410SMS .
I do have a website: www.computercollection.net . I do post there, but
not often.
JRJ
9:27 a.m.
On 5/21/2020 11:22 AM, Jay Jaeger via cctalk wrote:
On 5/21/2020 10:00 AM, Tom Uban wrote:
Paul, your project is super interesting. Is there a website where I can track it?
--tom
Mainly the github.com/cube1us/IBM1410SMS .
I do have a website: www.computercollection.net . I do post there, but
not often.
JRJ
D'oh. Never mind. I'm not Paul, of cousre. ;)
JRJ
9:45 a.m.
On 5/21/20 11:27 AM, Jay Jaeger via cctalk wrote:
On 5/21/2020 11:22 AM, Jay Jaeger via cctalk wrote:
No worries. Your collection looks quite nice, matching mine with regard to
PDP-11s in many ways.
I never did anything with IBM machines, but old hardware is still interesting.
Best,
--tom
On 5/21/2020 10:00 AM, Tom Uban wrote:
D'oh. Never mind. I'm not Paul, of cousre. ;)
JRJ Paul, your project is super interesting. Is there
a website where I can track it?
--tom
Mainly the github.com/cube1us/IBM1410SMS .
I do have a website: www.computercollection.net . I do post there, but
not often.
JRJ
9:48 a.m.
On May 21, 2020, at 11:00 AM, Tom Uban <tom at
figureeightbrewing.com> wrote:
On 5/21/20 9:51 AM, Paul Koning via cctalk wrote:
Paul, your project is super interesting. Is there a website where I can track
it?
Not a website, but you can see the source files on my Subversion server:
svn://akdesign.dyndns.org/dtcyber/trunk -- the model code and tools are in the
"vhdl" subdirectory. FYA, there's also a "spice" subdirectory,
which contains my attempts at a model of the DD60 display console. It's not accurate
enough yet, unfortunately.
The 6600 model has working peripherals processors and display controller. The CPU
doesn't work yet, I'm still debugging the instruction fetch machinery to get all
the variations of branch timing right. It does start, though (the "exchange
jump" instruction works).
paul
...
I have been working, very slowly, on a
project analogous to yours: a gate level model of the CDC 6600 supercomputer.
...
9:21 a.m.
On 5/21/2020 9:51 AM, Paul Koning wrote:
I recall you mentioning that along the way. You have my sympathy and
empathy. ;)
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.
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
9:55 a.m.
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:
...
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.
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.
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
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.
12:56 p.m.
On 5/21/2020 11:55 AM, Paul Koning wrote:
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.
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:
...
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. 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.
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
1:20 p.m.
On May 21, 2020, at 3:56 PM, Jay Jaeger <cube1 at
charter.net> wrote:
On 5/21/2020 11:55 AM, Paul Koning wrote:
As I said, for most machines it is not likely to be useful to model wire lengths. For the
6600, it is mandatory, and obvious from the design files: when you see a 96 inch wire
connecting two modules one inch apart, you know there is a reason why that wasn't a 4
inch wire instead. Not to mention when "adjust to get x ns pulse" shows up in
an annotation.
One good example of this is the master clock oscillator. In most 6600s it's a 10 MHz
crystal clock, but in the first 7 units built, it's a 4 stage ring oscillator, with 96
inch wires to produce 25 ns delay between the four main phases. The later version gets
rid of the ring oscillator, but retains the four buffers with wire delays, as n * 25 ns
phase shifters.
If I were working on, say, a PDP-11, I wouldn't expect to have to deal with any of
this sort of craziness. But a 6600 is at, if not over, the hairy edge of possible speed
for when it was built. Even the peripheral processors are well optimized, so they can run
many of their instructions in 1 microsecond -- which is the memory cycle time. Fetching
and executing a new opcode every cycle is a pretty hard task. The PPUs are actually
pipelined, though the descriptions you'll read about them don't make this clear at
all.
Come to think of it, another nice optimization example is the process context switch,
which in the 6000 series is a single instruction -- 16 read/modify/write core memory
cycles 100 ns apart, so the whole thing including pipeline drain and restart takes 3 or so
microseconds. Watching that in simulation is fun.
paul
...
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. 
9:07 a.m.
On 05/20/2020 09:22 PM, Jay Jaeger via cctalk 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.
Well,
I don't use the latest, super fast FPGAs, I go for old
standards that are cheap.
Right now, I have ise 13.4 installed on Linux, it seems to
be stable, quite fast for the small FPGAs
I do, and doesn't complain about my coding style. I use
mostly Spartan 3 in the
XC3S50A(N) sizes. I've done some units with 32-bit
counters running at 150 MHz with plenty
of margin left, that's fast enough for me. I only use VHDL,
although I can read Verilog.
(I also use Coolrunner II and XC9500XL devices in some of my
products.)
Jon
9:24 a.m.
On 5/21/2020 11:07 AM, Jon Elson wrote:
On 05/20/2020 09:22 PM, Jay Jaeger via cctalk wrote:
Yes, ISE was much better than Vivado, but doesn't support the chip on my
Nexys4 Xilink development board. I do have ISE running with the
requisite DLL fixup.
JRJ
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.
Well, I don't use the latest, super fast FPGAs, I go for old standards
that are cheap.
Right now, I have ise 13.4 installed on Linux, it seems to be stable,
quite fast for the small FPGAs
I do, and doesn't complain about my coding style.? I use mostly Spartan
3 in the
XC3S50A(N)? sizes.? I've done some units with 32-bit counters running at
150 MHz with plenty
of margin left, that's fast enough for me.? I only use VHDL, although I
can read Verilog.
(I also use Coolrunner II and XC9500XL devices in some of my products.)
Jon 
10:24 a.m.
On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk <cctalk at classiccmp.org>
wrote:
(I also use Coolrunner II and XC9500XL devices in some
of my
products.)
I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have
switched to Lattice LC4000ZE series because they are less expensive and
lower power, and (like the XC9500XL) have 5V tolerant inputs.
I'm not thrilled with having to use yet another different toolset, but
c'est la vie.
10:42 a.m.
On 5/21/2020 12:24 PM, Eric Smith via cctalk wrote:
On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk
<cctalk at classiccmp.org>
wrote:
Is it possible for you or someone to post about how to get an
environment up and running in Windows and/or Linux? (or link to one you
used?)
I use xc9500xl parts with IDE 14.7 on Win10 x64 (with DLL fix) here, and
the environment works well.? But, I have a few things that I would love
to fix/address:
* CPLD work goes fine with the fix, but the FPGA toolchain portions of
ISE won't work in Windows 10, even with the DLL fix (at least for
me).? I'd like to fix this, as some of my designs are too big for
xc95288xl.
* Alan Hightower praises the open source toolchains and Lattice units,
but my initial attempt to bring up a working environment here went
down in flames. I think I need a step-by-step guide (and maybe
someone who has time to help a poor soul get something up and running)
* As much as I like the GUI, I want to learn how to write (or
beg/borrow/steal) Makefile-based tooling for all my CPLD projects,
whether Xilinx or other.
All my existing CPLD work is online: https://github.com/go4retro/ ,
warts and all.
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
(I also use Coolrunner II and XC9500XL devices in
some of my
products.)
I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have
switched to Lattice LC4000ZE series because they are less expensive and
lower power, and (like the XC9500XL) have 5V tolerant inputs.
I'm not thrilled with having to use yet another different toolset, but
c'est la vie.
3:37 p.m.
On 05/21/2020 12:42 PM, Jim Brain via cctalk wrote:
On 5/21/2020 12:24 PM, Eric Smith via cctalk wrote:
Windows should be trivial, just read the release notes on
what systems it is compatible with.
Linux generally will install on many OS variants, even if
not the specific ones Xilinx says are
supported. They have an install script that tells you if
other packages need to be installed.
The only tricky area is to support certain download/debug
"cables". I had a HELL of a time
getting a Digilent pod to work at work. But, I bought a
(probably clone) Xilinx Platform Cable USB and it worked
pretty much right away on my home system.
I only do smaller FPGAs, such as XC3S50A, but the last
versions of ise support much higher-end chips.
Xilinx changed the built-in serial PROM on the XC3S50AN, and
that requires a patch file to be used instead of the
default. Otherwise, it all just works under Linux as expected.
Ise ver. 10 cannot be run on a 64-bit system, due to export
controls. It should be able to be hacked, but i couldn't
get it to work. Later versions seem to install fine on
64-bit OS's.
Jon
On Thu, May 21, 2020 at 10:07 AM Jon Elson via
cctalk
<cctalk at classiccmp.org>
wrote:
Is it possible for you or someone to post about how to get
an environment up and running in Windows and/or Linux? (or
link to one you used?)
(I also use Coolrunner II and XC9500XL devices in
some
of my
products.)
I used to use XC9500XL series (mostly XC9572XL) quite a
bit, but I have
switched to Lattice LC4000ZE series because they are less
expensive and
lower power, and (like the XC9500XL) have 5V tolerant
inputs.
I'm not thrilled with having to use yet another different
toolset, but
c'est la vie.
7:44 p.m.
On 5/21/2020 5:37 PM, Jon Elson wrote:
Windows should be trivial, just read the release notes
on what systems
it is compatible with.
I must have miscommunicated.? I have Xilinx ISE WebPack installed and
running.? I was asking about getting the Lattice toolchain up and
running, which programming cable to get, and suggestions for a test
board for Lattice.
--
Jim Brain
brain at jbrain.com
www.jbrain.com
22 May
22 May
4:51 a.m.
On 2020-05-21 22:44, Jim Brain via cctalk wrote:
I must have miscommunicated.? I have Xilinx ISE
WebPack installed and
running.? I was asking about getting the Lattice toolchain up and
running, which programming cable to get,
Are you talking Lattice/Diamond on Win10 or linux?
I don't remember having problems installing it on both ...
and suggestions for a test
board for Lattice.
That's a cute board, with really good software support (f32c, and a lot
of games)
https://radiona.org/ulx3s/
No clue, how to get one in the US at the moment ...
What would you like to do with it?
21 May
21 May
10:25 a.m.
On 5/20/2020 8:22 PM, Jay Jaeger via cctech 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 use ALTERA (now INTEL) as hobby and the AHDL programing language. What
I found is compiling simple logic is no problem
but real world problems tend to device specific to the FPGA brand
like ram or rom memory and acessing said items. Things are not
portable is if need a popup wizard to define some feature.
Ben.
1456
days inactive
1459
days old
33 comments
14 participants
participants (14)
-
abuse＠cabal.org.uk -
alan＠alanlee.org -
bfranchuk＠jetnet.ab.ca -
brain＠jbrain.com -
cclist＠sytse.net -
cmhanson＠eschatologist.net -
cube1＠charter.net -
dab＠froghouse.org -
dk＠thewaffleiron.net -
elson＠pico-systems.com -
emu＠e-bbes.com -
paulkoning＠comcast.net -
spacewar＠gmail.com -
tom＠figureeightbrewing.com