20 Jun
2016
20 Jun
'16
3:35 p.m.
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Why are folks referring to "Verilogging" and "doing a verilog" on
older
chips. Is there some way you can stuff an IC into a socket or alligator
clip a bunch of tiny leads onto it and then "map" it somehow into Verilog?
Is that what folks who write emulators do? Ie.. they exhaustively dump
Verilog code for all the chips then figure out how to implement that in
some computer programming language like C ? What do folks do for ROM chips
and PLCs? I'd think they must dump the code and disassemble it. No?
I'm just curious and this is a tough question to answer with Google since
I'm pretty clueless and don't know the right words to search for. I notice
people talk about correcting their Verilog code, so it must be somewhat of
a manual process. I'm just wondering how someone even gets started with a
process like that.
-Swift
20 Jun
20 Jun
4:02 p.m.
On 2016-06-20 3:35 PM, Swift Griggs wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Why are folks referring to "Verilogging" and "doing a verilog" on
older
chips. Is there some way you can stuff an IC into a socket or alligator
clip a bunch of tiny leads onto it and then "map" it somehow into Verilog?
Is that what folks who write emulators do?
They firstly go by documentation, and if that fails, reverse engineer,
painfully. This is why preserving, archiving, publishing documentation
is so incredibly important!
Ie.. they exhaustively dump
Verilog code for all the chips then figure out how to implement that in
You can't in general get Verilog *out* of a chip. It goes the other way.
You can compile Verilog into gates and netlists etc.
some computer programming language like C ? What do
folks do for ROM chips
and PLCs? I'd think they must dump the code and disassemble it. No?
Yes, they do that where possible.
I'm just curious and this is a tough question to answer with Google since
I'm pretty clueless and don't know the right words to search for. I notice
You can google "EDA tools". You can also grab toolchains from major
vendors like Altera and play with Verilog/VHDL and simulate the results,
too.
people talk about correcting their Verilog code, so it
must be somewhat of
a manual process. I'm just wondering how someone even gets started with a
process like that.
I'd suggest hitting some textbooks, not Google.
Niklaus Wirth's book is fantastic, for people more comfortable in
software, if you take it step by step:
https://www.amazon.ca/Digital-Circuit-Computer-Science-Students/dp/35405857…
--Toby
-Swift
4:07 p.m.
The hardest part of the process is distilling the functional specification
of the part you are trying to replace. This is the heart of the topic. Some
ways this can be done:
If adequate documentation exists, use it.
Observe the part's behavior in-system
Build a test bench to observe behavior of part outside of system
General leetness
There is no one approach, it is more art than science.
For going from a functional specification to a synthesizable model, this is
simply writing HDL.
I suggest this book, which covers the basics of this process.
https://www.amazon.com/Verilog-Digital-System-Design-Verification/dp/007144…
If you have no 100-level understanding of digital logic, start here:
https://www.amazon.com/Contemporary-Logic-Design-Randy-Katz/dp/0201308576
Thanks,
- Ian
On Mon, Jun 20, 2016 at 1:02 PM, Toby Thain <toby at telegraphics.com.au>
wrote:
On 2016-06-20 3:35 PM, Swift Griggs wrote:
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Why are folks referring to "Verilogging" and "doing a verilog" on
older
chips. Is there some way you can stuff an IC into a socket or alligator
clip a bunch of tiny leads onto it and then "map" it somehow into Verilog?
Is that what folks who write emulators do?
They firstly go by documentation, and if that fails, reverse engineer,
painfully. This is why preserving, archiving, publishing documentation is
so incredibly important!
Ie.. they exhaustively dump
Verilog code for all the chips then figure out
how to implement that in
You can't in general get Verilog *out* of a chip. It goes the other way.
You can compile Verilog into gates and netlists etc.
some computer programming language like C ? What do folks do for ROM chips
and PLCs? I'd think they must dump the code
and disassemble it. No?
Yes, they do that where possible.
I'm just curious and this is a tough question
to answer with Google since
I'm pretty clueless and don't know the right words to search for. I notice
You can google "EDA tools". You can also grab toolchains from major
vendors like Altera and play with Verilog/VHDL and simulate the results,
too.
people talk about correcting their Verilog code, so it must be somewhat of
a manual process. I'm just wondering how
someone even gets started with a
process like that.
I'd suggest hitting some textbooks, not Google.
Niklaus Wirth's book is fantastic, for people more comfortable in
software, if you take it step by step:
https://www.amazon.ca/Digital-Circuit-Computer-Science-Students/dp/35405857…
--Toby
-Swift
4:17 p.m.
To expand on my response-
Some PALs, PLAs, and GALs will yield the fuse map if you try and read them
with a programmer. This makes your job really easy. Take the fuse map and
compare to the original data sheet. Cool beans.
Some have the security bits set- in this case you would use a home-made
test setup to stimulate enough test conditions to build a truth table that
would allow you to infer the underlying logic.
If the part is registered, then things get tricker. For that, I might take
substantial in-system dumps with a logic analyzer (My favorite beginner LA
is the Agilent 16700, which comes with DOOM preinstalled, so you know it's
good stuff)
ROMS are easy- once you read a bit about how HDLs work, you will be able to
build one. Many languages offer functions to help with these (see readmemh
and readmemb in verilog)
Things get more complicated quickly- this is a deep topic and not something
that can be covered quickly. I suggest you start with the two books I
linked, and if you like them, there are a lot more around. Any edition
should be suitable- get or find whatever is cheapest.
We have not touched yet on practical things, like how to interface modern
1.8v FPGA I/O lines with 5V TTL logic- that is a topic for another day.
Cheers,
- Ian
On Mon, Jun 20, 2016 at 1:07 PM, Ian Finder <ian.finder at gmail.com> wrote:
The hardest part of the process is distilling the
functional specification
of the part you are trying to replace. This is the heart of the topic. Some
ways this can be done:
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
If adequate documentation exists, use it.
Observe the part's behavior in-system
Build a test bench to observe behavior of part outside of system
General leetness
There is no one approach, it is more art than science.
For going from a functional specification to a synthesizable model, this
is simply writing HDL.
I suggest this book, which covers the basics of this process.
https://www.amazon.com/Verilog-Digital-System-Design-Verification/dp/007144…
If you have no 100-level understanding of digital logic, start here:
https://www.amazon.com/Contemporary-Logic-Design-Randy-Katz/dp/0201308576
Thanks,
- Ian
On Mon, Jun 20, 2016 at 1:02 PM, Toby Thain <toby at telegraphics.com.au>
wrote:
On 2016-06-20 3:35 PM, Swift Griggs wrote:
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Why are folks referring to "Verilogging" and "doing a verilog" on
older
chips. Is there some way you can stuff an IC into a socket or alligator
clip a bunch of tiny leads onto it and then "map" it somehow into
Verilog?
Is that what folks who write emulators do?
They firstly go by documentation, and if that fails, reverse engineer,
painfully. This is why preserving, archiving, publishing documentation is
so incredibly important!
Ie.. they exhaustively dump
Verilog code for all the chips then figure out
how to implement that in
You can't in general get Verilog *out* of a chip. It goes the other way.
You can compile Verilog into gates and netlists etc.
some computer programming language like C ? What do folks do for ROM chips
and PLCs? I'd think they must dump the code
and disassemble it. No?
Yes, they do that where possible.
I'm just curious and this is a tough question
to answer with Google since
I'm pretty clueless and don't know the right words to search for. I
notice
You can google "EDA tools". You can also grab toolchains from major
vendors like Altera and play with Verilog/VHDL and simulate the results,
too.
people talk about correcting their Verilog code, so it must be somewhat of
a manual process. I'm just wondering how
someone even gets started with a
process like that.
I'd suggest hitting some textbooks, not Google.
Niklaus Wirth's book is fantastic, for people more comfortable in
software, if you take it step by step:
https://www.amazon.ca/Digital-Circuit-Computer-Science-Students/dp/35405857…
--Toby
-Swift
4:47 p.m.
On Mon, 20 Jun 2016, Ian Finder wrote:
Some PALs, PLAs, and GALs will yield the fuse map if
you try and read them
with a programmer. This makes your job really easy. Take the fuse map and
compare to the original data sheet. Cool beans.
That sounds like magic. I'm reading about what "fuse map" is, now.
That's
a new term for me.
Some have the security bits set- in this case you
would use a home-made
test setup to stimulate enough test conditions to build a truth table
that would allow you to infer the underlying logic.
Hmm, so there is something akin to "copy protection" even at the chip
level. Ugh. I'm not surprised.
If the part is registered, then things get tricker.
For that, I might
take substantial in-system dumps with a logic analyzer (My favorite
beginner LA is the Agilent 16700, which comes with DOOM preinstalled, so
you know it's good stuff)
Oh, cool. I was just browsing for one a few days ago. I was looking at the
ones from Saleae and Tektronix. I'll have to check that out. If they were
cool enough to pre-install Doom, I think we have a winner. :-)
ROMS are easy- once you read a bit about how HDLs
work, you will be able
to build one. Many languages offer functions to help with these (see
readmemh and readmemb in verilog)
I actually did burn some ROM code in college. I remember it being fairly
easy. However, I would look like a stunned fish if someone asked me to
reverse engineer one.
Things get more complicated quickly- this is a deep
topic and not
something that can be covered quickly. I suggest you start with the two
books I linked, and if you like them, there are a lot more around. Any
edition should be suitable- get or find whatever is cheapest.
Oh good lord, I'm so out of my depth already. However, it's still
interesting and I'm still trying (I'm stubborn that way). I've got to get
the simplest basics down before I dive in all the way with a "real" book.
I'm going to try to stick with my digital logic self-refresh first, but
this Verilog business is awfully cool. I will be sorely tempted to come
back to this same point, I'm sure.
We have not touched yet on practical things, like how
to interface
modern 1.8v FPGA I/O lines with 5V TTL logic- that is a topic for
another day.
Hmm, I never even knew of that problem, but after doing a bunch of analog,
I get the impression that would create a lot of hassles, especially if you
were just trying to duplicate some already laid-out logic, but it was all
at 5V...
-Swift
4:53 p.m.
Most of the FPGA companies provide (free) tools that allow you to write in
verilog/VHDL and then simulate and observe the outputs (you can even ?drill
down? and see internal signals as well.
It?s fairly easy to write a little bit of code (there are lots of examples on the
web) and try it out on the simulator.
If you get an FPGA eval board (I have a number of Digilent Xilinx boards)
you can take your sample code and download it to the eval board and run it.
TTFN - Guy
On Jun 20, 2016, at 1:47 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
On Mon, 20 Jun 2016, Ian Finder wrote:
Some PALs, PLAs, and GALs will yield the fuse map
if you try and read them
with a programmer. This makes your job really easy. Take the fuse map and
compare to the original data sheet. Cool beans.
That sounds like magic. I'm reading about what "fuse map" is, now.
That's
a new term for me.
Some have the security bits set- in this case you
would use a home-made
test setup to stimulate enough test conditions to build a truth table
that would allow you to infer the underlying logic.
Hmm, so there is something akin to "copy protection" even at the chip
level. Ugh. I'm not surprised.
If the part is registered, then things get
tricker. For that, I might
take substantial in-system dumps with a logic analyzer (My favorite
beginner LA is the Agilent 16700, which comes with DOOM preinstalled, so
you know it's good stuff)
Oh, cool. I was just browsing for one a few days ago. I was looking at the
ones from Saleae and Tektronix. I'll have to check that out. If they were
cool enough to pre-install Doom, I think we have a winner. :-)
ROMS are easy- once you read a bit about how HDLs
work, you will be able
to build one. Many languages offer functions to help with these (see
readmemh and readmemb in verilog)
I actually did burn some ROM code in college. I remember it being fairly
easy. However, I would look like a stunned fish if someone asked me to
reverse engineer one.
Things get more complicated quickly- this is a
deep topic and not
something that can be covered quickly. I suggest you start with the two
books I linked, and if you like them, there are a lot more around. Any
edition should be suitable- get or find whatever is cheapest.
Oh good lord, I'm so out of my depth already. However, it's still
interesting and I'm still trying (I'm stubborn that way). I've got to get
the simplest basics down before I dive in all the way with a "real" book.
I'm going to try to stick with my digital logic self-refresh first, but
this Verilog business is awfully cool. I will be sorely tempted to come
back to this same point, I'm sure.
We have not touched yet on practical things, like
how to interface
modern 1.8v FPGA I/O lines with 5V TTL logic- that is a topic for
another day.
Hmm, I never even knew of that problem, but after doing a bunch of analog,
I get the impression that would create a lot of hassles, especially if you
were just trying to duplicate some already laid-out logic, but it was all
at 5V...
-Swift
4:36 p.m.
On Mon, 20 Jun 2016, Ian Finder wrote:
The hardest part of the process is distilling the
functional
specification of the part you are trying to replace. This is the heart
of the topic.
Hmm, okay so that's pretty much what I expected. They start with what that
particular chip or ROM etc.. _does_ then they re-implement as a process of
discovery. Does that sound accurate?
There is no one approach, it is more art than science.
That's also what I expected. I guess as I was reading through other
material, I got the impression that it might be more deterministic, but my
gut feeling was right, I think. Nothing is ever *that* easy.
For going from a functional specification to a
synthesizable model, this
is simply writing HDL. I suggest this book, which covers the basics of
this process.
https://www.amazon.com/Verilog-Digital-System-Design-Verification/dp/007144…
Whoa. That's a pricey sucker. I'm probably not going to be able to make
use of Verilog for a little bit yet. I'm still designing all my little
"homework assignment" type projects on paper or using a tool I found in
pkgsrc called "The Eagle Layout Editor." It's got some nice features (at
least for me so far). I'll probably go with the Wirth book since it's a
bit cheaper, but I still appreciate your suggestion.
If you have no 100-level understanding of digital
logic, start here:
https://www.amazon.com/Contemporary-Logic-Design-Randy-Katz/dp/0201308576
I have about a 100-level understanding, now. I took a digital logic class
in college and I still have my book. It's "Fundamentals of Digital Design"
I believe (or something very close to that). It was a while back, though.
I understand boolean logic, changing base for numbering systems, etc..
However, I have a breathtaking lack of experience in applying that stuff
to "real" digital logic. I'm just using online tutorials and guides for
the moment, but the main one I focus on is this one:
http://www.learningelectronics.net/vol_4/index.html
So far, it's been great. I'm just finishing up some of the analog stuff on
that same site, and I've greedily skipped ahead a bit to digital. However,
I'm just now getting to TTLs and gates. I have to actually write out
examples or test things physically to really "get it". However, I'm just
plodding along. I have a nice little mess happening on my workbench in the
garage. I'm about to move on past just using simple capacitors, resistors,
and diodes to using some ICs. It's a little intimidating, actually. I
thought I could get to the point I'm at now in about two weeks. It
actually took about five or six weeks (just for an analog refresher). I'm
still a bit shaky on some of that stuff, too. It's hard to test/see
everything. So, some things I just read about, shrug, and keep going.
-Swift
5:08 p.m.
On 6/20/2016 2:36 PM, Swift Griggs wrote:
So far, it's been great. I'm just finishing up
some of the analog stuff on
that same site, and I've greedily skipped ahead a bit to digital. However,
I'm just now getting to TTLs and gates. I have to actually write out
examples or test things physically to really "get it". However, I'm just
plodding along. I have a nice little mess happening on my workbench in the
garage. I'm about to move on past just using simple capacitors, resistors,
and diodes to using some ICs. It's a little intimidating, actually. I
thought I could get to the point I'm at now in about two weeks. It
actually took about five or six weeks (just for an analog refresher). I'm
still a bit shaky on some of that stuff, too. It's hard to test/see
everything. So, some things I just read about, shrug, and keep going.
But of course the real stuff is TOP SECRET, unless you PAY.
-Swift
A good read on LSI in the late 1970's.
http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/VLSIText.html
Ben.
5:07 p.m.
On Mon, Jun 20, 2016, Ian Finder wrote:
The hardest part of the process is distilling the
functional specification
of the part you are trying to replace. This is the heart of the topic. Some
ways this can be done:
For learning, I really recommend this Coursera MOOC:
https://www.coursera.org/learn/build-a-computer/home/welcome
It has a part 2, which covers writing programs from machine language up;
I haven't taken that one yet. Part 1 talks about logic gates, boolean
logic, etc. (like in the web book Swift posted the URL of), but it also
lets you dip your toes in an HDL/Verilog-like toy language, and has
simulators (note: they require Java) to run the circuits you design.
If adequate documentation exists, use it.
Observe the part's behavior in-system
Build a test bench to observe behavior of part outside of system
General leetness
There is no one approach, it is more art than science.
For going from a functional specification to a synthesizable model, this is
simply writing HDL.
I suggest this book, which covers the basics of this process.
https://www.amazon.com/Verilog-Digital-System-Design-Verification/dp/007144…
If you have no 100-level understanding of digital logic, start here:
https://www.amazon.com/Contemporary-Logic-Design-Randy-Katz/dp/0201308576
Thanks,
- Ian On Mon, Jun 20, 2016 at 1:02 PM, Toby Thain <toby
at telegraphics.com.au>
wrote:
> On 2016-06-20 3:35 PM, Swift Griggs wrote:
>
>>
>> In my recent studies of electronics (I'm a noob for all practical
>> purposes) I keep seeing folks refer to Verilog almost as a verb. I read
>> about it in Wikipedia and it sounds pretty interesting. It's basically
>> described as a coding scheme for electronics, similar to programming but
>> with extras like signal strength and propagation included. Hey, cool!
>>
>> Why are folks referring to "Verilogging" and "doing a
verilog" on older
>> chips. Is there some way you can stuff an IC into a socket or alligator
>> clip a bunch of tiny leads onto it and then "map" it somehow into
Verilog?
>> Is that what folks who write emulators do?
>>
>
> They firstly go by documentation, and if that fails, reverse engineer,
> painfully. This is why preserving, archiving, publishing documentation is
> so incredibly important!
>
> > Ie.. they exhaustively dump
>
>> Verilog code for all the chips then figure out how to implement that in
>>
>
> You can't in general get Verilog *out* of a chip. It goes the other way.
> You can compile Verilog into gates and netlists etc.
>
> some computer programming language like C ? What do folks do for ROM chips
>> and PLCs? I'd think they must dump the code and disassemble it. No?
>>
>
> Yes, they do that where possible.
>
>
>> I'm just curious and this is a tough question to answer with Google since
>> I'm pretty clueless and don't know the right words to search for. I
notice
>>
>
> You can google "EDA tools". You can also grab toolchains from major
> vendors like Altera and play with Verilog/VHDL and simulate the results,
> too.
>
> people talk about correcting their Verilog code, so it must be somewhat of
>> a manual process. I'm just wondering how someone even gets started with a
>> process like that.
>>
>
> I'd suggest hitting some textbooks, not Google.
>
> Niklaus Wirth's book is fantastic, for people more comfortable in
> software, if you take it step by step:
>
>
> https://www.amazon.ca/Digital-Circuit-Computer-Science-Students/dp/35405857…
--
Eric Christopherson
5:40 p.m.
On Mon, 20 Jun 2016, Eric Christopherson wrote:
For learning, I really recommend this Coursera MOOC:
https://www.coursera.org/learn/build-a-computer/home/welcome
Hmm, I had to sign up with them, but I did it. I wanted to see this
simulator. It's a very "slick" course with lots of way-cool topics. This
is definitely awesome. Thanks.
-Swift
4:03 p.m.
What you can do (and I?ve seen it done) is define verilog modules that
provide the functions of the IC and use that in their designs. I?ve seen
at least two interesting classic computer recreations using this approach
(re-implemenation of the CADR lisp machine in verilog and an IBM 360/30
in verilog).
ROMs are easy (just instantiate a lookup table). PLCs are just combinatorial
equations which are relatively easy with the verilog ?assign? statement.
TTFN - Guy
On Jun 20, 2016, at 12:35 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Why are folks referring to "Verilogging" and "doing a verilog" on
older
chips. Is there some way you can stuff an IC into a socket or alligator
clip a bunch of tiny leads onto it and then "map" it somehow into Verilog?
Is that what folks who write emulators do? Ie.. they exhaustively dump
Verilog code for all the chips then figure out how to implement that in
some computer programming language like C ? What do folks do for ROM chips
and PLCs? I'd think they must dump the code and disassemble it. No?
I'm just curious and this is a tough question to answer with Google since
I'm pretty clueless and don't know the right words to search for. I notice
people talk about correcting their Verilog code, so it must be somewhat of
a manual process. I'm just wondering how someone even gets started with a
process like that.
-Swift
4:17 p.m.
On Jun 20, 2016, at 3:35 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Verilog and VHDL are two "hardware description languages". You can think of
them as programming languages to describe hardware behavior. Another way to look at them
is as languages designed to let you talk easily about lots of things that happen at the
same time -- which is what happens in hardware.
VHDL borrows a lot from Ada; if you know Ada then VHDL will look somewhat familiar. It
originated in the US DoD. Verilog appears to be originally a commercial product. At this
point, there are lots of implementations of both, and both are in wide use. I only know
(some) VHDL, so I can't really comment on similarities, differences, and
plus/minuses.
One key thing in hardware is that you have "signals" which change as a result of
some input event, and that change is visible at a later time. But not immediately. This
can be confusing if you're a programmer and used to how C or similar languages work.
For example, in this C code:
a = 1;
b = a;
a and b will both equal 1 at the end. But in the VHDL code:
a <= 1;
b <= a;
(where a and b are signals, as indicated by the fact that signal assignment operators are
used), a will show up as 1 at the end of the current cycle, and b will at that time show
up with the value that a had at the start of this cycle. So this is very much NOT the
same thing as the C code. But it fits hardware, where signals have to propagate and new
things happen as a result of previous actions at previous points in time.
VHDL and Verilog can be used to model hardware operation; they can also be used to
describe hardware. These are not quite the same. A model can, for example, talk about
actual delays. A hardware description does not; such a "synthesizable" model is
a subset of the full language. This is a common way to design what goes into an FPGA. A
hardware model can be used to replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes propagation delays
on some signals (which are critical to correct operation in certain spots).
Reverse engineering a design into VHDL or Verilog is just like reverse engineering a
program into C. Both can be very hard if you don't have much information. For
example, if all you have is a complex IC spec sheet, it is likely to be rather difficult.
If you have internals, it becomes more feasible.
There are plenty of textbooks on the topic. I would recommend the (large) book by Peter
Ashenden on VHDL. He also has a book on Verilog; given how he treated VHDL I expect that
one is good too but I don't have it.
paul
4:19 p.m.
On Jun 20, 2016, at 4:17 PM, Paul Koning
<paulkoning at comcast.net> wrote:
I forgot to mention: at least for VHDL, there's an open source simulator. In other
words, a program that accepts VHDL input and lets you "run" the simulated
hardware. You can feed it inputs in various ways, and observe its behavior -- for example
as waveform traces on a waveform display, like an oscilloscope. Look for GHDL. It's
a GCC front end; it takes your VHDL code and compiles it, then it's linked with a
support library to make an executable program. Since it's GCC based you can do neat
things, like run it on various hardware platforms. Or link in C functions to do stuff,
like simulate external peripherals connected to your hardware model.
I haven't looked for open source Verilog simulators.
paul
On Jun 20, 2016, at 3:35 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Verilog and VHDL are two "hardware description languages". You can think of
them as programming languages to describe hardware behavior. Another way to look at them
is as languages designed to let you talk easily about lots of things that happen at the
same time -- which is what happens in hardware.
4:24 p.m.
I find most of the open source HDL simulators kind of suck. I think you can
still get ModelSim Web edition for free from altera.
This will do mixed language designs of Verilog, VHDL and schematic, and
works rather nicely.
Remember, each module is just a set of input and output signals, so the
language really doesn't matter. Mixed language designs are very common.
Yes, you can even build FPGA designs in a schematic editor out of library
modules. No, I don't suggest you should.
On Monday, June 20, 2016, Paul Koning <paulkoning at comcast.net> wrote:
think of them as programming languages to describe hardware behavior.
Another way to look at them is as languages designed to let you talk easily
about lots of things that happen at the same time -- which is what happens
in hardware.
I forgot to mention: at least for VHDL, there's an open source simulator.
In other words, a program that accepts VHDL input and lets you "run" the
simulated hardware. You can feed it inputs in various ways, and observe
its behavior -- for example as waveform traces on a waveform display, like
an oscilloscope. Look for GHDL. It's a GCC front end; it takes your VHDL
code and compiles it, then it's linked with a support library to make an
executable program. Since it's GCC based you can do neat things, like run
it on various hardware platforms. Or link in C functions to do stuff, like
simulate external peripherals connected to your hardware model.
I haven't looked for open source Verilog simulators.
paul
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
On Jun 20, 2016, at 4:17 PM, Paul Koning
<paulkoning at comcast.net
<javascript:;>> wrote:
> On Jun 20, 2016, at 3:35 PM, Swift Griggs <swiftgriggs at gmail.com
<javascript:;>> wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Verilog and VHDL are two "hardware description languages". You can
5:01 p.m.
On 6/20/2016 2:24 PM, Ian Finder wrote:
I like the CRASH and BURN testing for FPGA's.
What I want is 5 volt I/O FPGA with a flash Boot prom for the FPGA
on tiny 64 pin PCB. This way one can emulate a vintage logic board
or cpu.
> Yes, you can even build FPGA designs in a
schematic editor out of library
> modules. No, I don't suggest you should.
With Altera, you had a TTL macro library at one time. Not sure if the
newest version still supports it.
Ben.
I find most of the open source HDL simulators kind of
suck. I think you can
still get ModelSim Web edition for free from altera.
I think you get 1 month free ... then $$$.
This will do mixed language designs of Verilog, VHDL
and schematic, and
works rather nicely.
Altera has AHDL as well. Not portable, but less confusing to write logic
in.
> Remember, each module is just a set of input and output signals, so the
> language really doesn't matter. Mixed language designs are very common.
5:05 p.m.
* On Mon, Jun 20, 2016 at 04:19:56PM -0400, Paul Koning <paulkoning at comcast.net>
wrote:
I haven't looked for open source Verilog simulators.
I've used Icarus Verilog ('iverilog') in the past. It's pretty bare
bones, but you can feed the output into gnuplot and make reasonable
diagrams from it.
paul
-Seth
--
Seth Morabito
seth at loomcom.com
21 Jun
21 Jun
10:12 a.m.
Verilator is another good tool for doing functional/behavioral
simulation of Verilog with a C/C++ test frame-work.
-Alan
On 2016-06-20 17:05, Seth Morabito wrote:
* On Mon, Jun 20, 2016 at 04:19:56PM -0400, Paul
Koning <paulkoning at comcast.net> wrote:
I haven't looked for open source Verilog
simulators.
I've used Icarus Verilog ('iverilog') in the past. It's pretty bare
bones, but you can feed the output into gnuplot and make reasonable
diagrams from it.
paul
-Seth 
20 Jun
20 Jun
9:01 p.m.
On 06/20/2016 03:19 PM, Paul Koning wrote:
Pretty much any FPGA design package will have a simulator
that will take FPGA-synthesizable VHDL or Verilog and build
a simulation environment that produces the functions
specified in the HDL. Note that there are LOTS of things
you can write in VHDL and Verilog that do not synthesize
into logic, and thus the simulators won't express what those
statements ask for.
Jon
On Jun 20,
2016, at 4:17 PM, Paul Koning <paulkoning at comcast.net> wrote:
I forgot to mention: at least for VHDL,
there's an open source simulator. In other words, a program that accepts VHDL input
and lets you "run" the simulated hardware. You can feed it inputs in various
ways, and observe its behavior -- for example as waveform traces on a waveform display,
like an oscilloscope. Look for GHDL. It's a GCC front end; it takes your VHDL code
and compiles it, then it's linked with a support library to make an executable
program. Since it's GCC based you can do neat things, like run it on various hardware
platforms. Or link in C functions to do stuff, like simulate external peripherals
connected to your hardware model.
I haven't looked for open source Verilog simulators.
On Jun 20, 2016, at 3:35 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
In my recent studies of electronics (I'm a noob for all practical
purposes) I keep seeing folks refer to Verilog almost as a verb. I read
about it in Wikipedia and it sounds pretty interesting. It's basically
described as a coding scheme for electronics, similar to programming but
with extras like signal strength and propagation included. Hey, cool!
Verilog and
VHDL are two "hardware description languages". You can think of them as
programming languages to describe hardware behavior. Another way to look at them is as
languages designed to let you talk easily about lots of things that happen at the same
time -- which is what happens in hardware.
4:22 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 2016-06-20 4:17 PM, Paul Koning wrote:
This is probably of great interest to more than just me.
Any more details? Going to publish?
--Toby
...A hardware model can
be used to replicate
what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
4:35 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 20, 2016, at 4:22 PM, Toby Thain <toby at
telegraphics.com.au> wrote:
On 2016-06-20 4:17 PM, Paul Koning wrote:
This is probably of great interest to more than just me.
Any more details? Going to publish?
Sure. You can see it at svn://akdesign.dyndns.org/dtcyber/trunk; most is in the vhdl
subdirectory but it uses some pieces from the top level. Very much work in progress.
It's derived from the 6600 wire lists on bitsavers. I OCRed them (what a pain), wrote
VHDL models (gate level structural models) of each 6000 series module, and a Python script
builds a structural model out of those elements interconnected by the wires from the wire
lists. "Sufficiently long" wires have their delay explicitly modeled.
I currently have chassis 1 (PPUs) working, at least to the point where I can do a
deadstart, have that load from the deadstart panel, and execute some instructions.
I've used it to grok some magic related to deadstart that's part of the lore but
not documented. I also have the 6612 display controller working, so I can see how the
text display on the console tubes works. Unfortunately I don't have a good SPICE
model for the analog parts, so I don't yet know why the character shapes are changed
by the circuitry in the manner that the photos show.
The CPU is work in progress. I'm trying to get exchange to work. It's hard; even
more than the PPUs, the CPU relies on hairy timing in certain spots. It appears that the
wire lists are not all the same rev, and there are also some typos in them.
Some day, if things go really well, this may result in a gate level accurate FPGA 6600.
I'm thinking I'll stop trying OCR and simply type the wire lists instead;
that's likely to be faster in the long run.
paul
...A hardware model can
be used to
replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
4:41 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 2016-06-20 4:35 PM, Paul Koning wrote:
This is frankly amazing. Thankyou for the details. Maybe one day I'll be
able to volunteer some help. (Actually if there's anything I can do now,
as an electronics noob but beginning student of digital logic & FPGA,
let me know offlist.)
--Toby
On Jun 20, 2016, at 4:22 PM, Toby Thain <toby
at telegraphics.com.au> wrote:
On 2016-06-20 4:17 PM, Paul Koning wrote:
This is probably of great interest to more than just me.
Any more details? Going to publish?
Sure. You can see it at svn://akdesign.dyndns.org/dtcyber/trunk; ...
Some day, if things go really well, this may result in a gate level accurate FPGA 6600.
I'm thinking I'll stop trying OCR and simply type the wire lists instead;
that's likely to be faster in the long run.
...A hardware model can
be used to
replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
paul
5:12 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 6/20/2016 2:41 PM, Toby Thain wrote:
This is frankly amazing. Thankyou for the details. Maybe one day I'll be
able to volunteer some help. (Actually if there's anything I can do now,
as an electronics noob but beginning student of digital logic & FPGA,
let me know offlist.)
How about a REAL FPGA board that has 5 volt I/O and 36+ bit wide memory
would make some big computers a reality.
Ben.
9:15 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 20, 2016, at 5:12 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 6/20/2016 2:41 PM, Toby Thain wrote:
Given the right level of internal detail, a PDP10 emulation should be straightforward.
Just to give you a feeling for the currently available scale, I figured that a large but
not max size FPGA can hold a complete CDC 6600 -- its 15 chassis worth of modules,
including PPU and CPU memory. The only thing that -- probably -- doesn't quite fit is
the ECS. But CPU memory, 128k words of 60 bits, is perfectly straightforward inside a
modern large FPGA. (Good thing, too; the CM timing is such that trying to hook up
external RAM is quite a pain, unless you make it SRAM. ECS is far more lenient.)
paul
This is frankly amazing. Thankyou for the details. Maybe one day I'll be
able to volunteer some help. (Actually if there's anything I can do now,
as an electronics noob but beginning student of digital logic & FPGA,
let me know offlist.)
How about a REAL FPGA board that has 5 volt I/O and 36+ bit wide memory
would make some big computers a reality.
11 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 2016-06-20 5:12 PM, ben wrote:
On 6/20/2016 2:41 PM, Toby Thain wrote:
Altera Cyclone has 9 bit byte lanes, so getting 36 bit memory is no problem.
--Toby
This is frankly amazing. Thankyou for the details. Maybe one day I'll be
able to volunteer some help. (Actually if there's anything I can do now,
as an electronics noob but beginning student of digital logic & FPGA,
let me know offlist.)
How about a REAL FPGA board that has 5 volt I/O and 36+ bit wide memory would make some big computers a reality.
Ben.
11:34 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 6/20/2016 9:00 PM, Toby Thain wrote:
Altera Cyclone has 9 bit byte lanes, so getting 36 bit memory is no
problem.
Internal memory only.
My other pet-peave is that every thing is point and click wizard for any
useful modules. Need a rom module or adder module, point and click no
portable code.
Ben.
11:43 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Mon, Jun 20, 2016 at 9:34 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
My other pet-peave is that every thing is point and
click wizard for any
useful modules. Need a rom module or adder module, point and click no
portable code.
I predominantly use Xilinx, and I don't use much point-and-click at
all. I do all my HDL editing in emacs, including instantiating any of
the Xilinx-provided IP blocks. My main interaction with the Xilinx
software (whether ISE or Vivado) is to click the "generate bitstream"
button. It's even possible to do that from the command line or a
Makefile, but I haven't bothered.
21 Jun
21 Jun
12:07 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 6/20/2016 9:43 PM, Eric Smith wrote:
On Mon, Jun 20, 2016 at 9:34 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
Do you use Static or Dynamic ram with the FPGA's?
Ben.
My other pet-peave is that every thing is point
and click wizard for any
useful modules. Need a rom module or adder module, point and click no
portable code.
I predominantly use Xilinx, and I don't use much point-and-click at
all. I do all my HDL editing in emacs, including instantiating any of
the Xilinx-provided IP blocks. My main interaction with the Xilinx
software (whether ISE or Vivado) is to click the "generate bitstream"
button. It's even possible to do that from the command line or a
Makefile, but I haven't bothered.
4:18 a.m.
New subject: DEC KS10 implementation - was CDC 6600 emulation
On 6/20/2016 9:07 PM, ben wrote:
On 6/20/2016 9:43 PM, Eric Smith wrote:
Another example -
The KS10 FPGA uses 36-bit wide 166 MHz synchronous static RAM (SSRAM)
for main memory. Main memory is as fast as the "Fast ACs". I didn't
bother to implement cache (why bother?) and the Cache Diagnostic still
whines that things that should not be cached are being cached...
Most good tools can infer about everything from a well written HDL
description. This includes single port and multi-port memory and
includes RAM and ROM. The less tool-specific things that you use, the
more portable your design is.
The only IP block that I regularly use is a phased-locked-loop block.
The DEC KS10 used a lot of asynchronous parts (memory, FIFOs/SILOs,
one-shots, delay lines, RC delays, etc) that don't map very well to
modern components - especially FPGAs. I've elected to redesign circuitry
as necessary to use the FPGA resources. Others have elected to retain
the original design as close as possible and accept the consequences.
The KS10 FPGA is at:
http://www.techtravels.org/?page_id=656
https://github.com/KS10FPGA/KS10FPGA
The ALU out of the KS10 FPGA describes a fairly complex circuit
containing memory, registers, multiplexers, shifters, adders, including
an am2901 4-bit slice processor-based ALU all written using generic
Verilog. Also the HDL description has trace tags back to the card,
schematic sheet, and reference designators of the original design - if
you'd like to compare the two.
The KS10 FPGA ALU design can be viewed at:
https://github.com/KS10FPGA/KS10FPGA/blob/master/fpga/ks10/cpu/alu.v
Regarding simulation - a full Verilog simulation of the DEC RP06 disk
diagnostic (DSRPA) requires about two and a half weeks to complete on my
fastest computer. That's maybe not suprising because that simulates the
entire CPU running the diagnostic program, memory, the unibus adapters,
the RH11 disk controller, the console terminal, and eight RP06 disk
drives. When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes.
Rob.
doyle (at) cox (dot) net
On Mon, Jun 20, 2016 at 9:34 PM, ben
<bfranchuk at jetnet.ab.ca>
wrote:
Do you use Static or Dynamic ram with the FPGA's? Ben. My other pet-peave is that every thing is point
and click wizard
for any useful modules. Need a rom module or adder module, point
and click no portable code.
I predominantly use Xilinx, and I don't use much point-and-click
at all. I do all my HDL editing in emacs, including instantiating
any of the Xilinx-provided IP blocks. My main interaction with the
Xilinx software (whether ISE or Vivado) is to click the "generate
bitstream" button. It's even possible to do that from the command
line or a Makefile, but I haven't bothered.
11:15 a.m.
New subject: DEC KS10 implementation - was CDC 6600 emulation
"When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes."
Any idea what the run-time would be a on a real KS10?
Lee C.
On Tue, Jun 21, 2016 at 1:18 AM, Rob Doyle <radioengr at gmail.com> wrote:
On 6/20/2016 9:07 PM, ben wrote:
--
Lee Courtney
+1-650-704-3934 cell
On 6/20/2016 9:43 PM, Eric Smith wrote:
Another example -
The KS10 FPGA uses 36-bit wide 166 MHz synchronous static RAM (SSRAM)
for main memory. Main memory is as fast as the "Fast ACs". I didn't
bother to implement cache (why bother?) and the Cache Diagnostic still
whines that things that should not be cached are being cached...
Most good tools can infer about everything from a well written HDL
description. This includes single port and multi-port memory and
includes RAM and ROM. The less tool-specific things that you use, the
more portable your design is.
The only IP block that I regularly use is a phased-locked-loop block.
The DEC KS10 used a lot of asynchronous parts (memory, FIFOs/SILOs,
one-shots, delay lines, RC delays, etc) that don't map very well to
modern components - especially FPGAs. I've elected to redesign circuitry
as necessary to use the FPGA resources. Others have elected to retain
the original design as close as possible and accept the consequences.
The KS10 FPGA is at:
http://www.techtravels.org/?page_id=656
https://github.com/KS10FPGA/KS10FPGA
The ALU out of the KS10 FPGA describes a fairly complex circuit
containing memory, registers, multiplexers, shifters, adders, including
an am2901 4-bit slice processor-based ALU all written using generic
Verilog. Also the HDL description has trace tags back to the card,
schematic sheet, and reference designators of the original design - if
you'd like to compare the two.
The KS10 FPGA ALU design can be viewed at:
https://github.com/KS10FPGA/KS10FPGA/blob/master/fpga/ks10/cpu/alu.v
Regarding simulation - a full Verilog simulation of the DEC RP06 disk
diagnostic (DSRPA) requires about two and a half weeks to complete on my
fastest computer. That's maybe not suprising because that simulates the
entire CPU running the diagnostic program, memory, the unibus adapters,
the RH11 disk controller, the console terminal, and eight RP06 disk
drives. When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes.
Rob.
doyle (at) cox (dot) net
On Mon, Jun 20, 2016 at 9:34 PM, ben
<bfranchuk at jetnet.ab.ca>
wrote:
My other pet-peave is that every thing is point
and click wizard
for any useful modules. Need a rom module or adder module, point
and click no portable code.
I predominantly use Xilinx, and I don't use much point-and-click
at all. I do all my HDL editing in emacs, including instantiating
any of the Xilinx-provided IP blocks. My main interaction with the
Xilinx software (whether ISE or Vivado) is to click the "generate
bitstream" button. It's even possible to do that from the command
line or a Makefile, but I haven't bothered.
Do you use Static or Dynamic ram with the FPGA's? Ben.
1:46 p.m.
New subject: DEC KS10 implementation - was CDC 6600 emulation
On 6/21/2016 8:15 AM, Lee Courtney wrote:
"When run on the target FPGA, the DSRPA
diagnostic completes in
slightly less than 9 minutes."
Any idea what the run-time would be a on a real KS10?
Lee C.
I don't know. I suspect it wouldn't be very different. The KS10 FPGA
CPU is about 4x faster than the DEC KS10.
http://www.techtravels.org/KS10FPGA/DSKFA.pdf
Having said that, the RP06 Disk can be conditionally compiled in one
of two modes: "fast and loose" and "slow but accurate".
The "slow but accurate" mode is required to pass many of the DSRPA
diagnostics. The FPGA simulates head motion (seek times), disk
rotation (search times), and data transfer rates.
I'm guessing that the physical delays in the disk drive dominate the
timing of the DSRPA diagnostic - and those delays should be pretty accurate.
The RP06 uses a Secure Digital Card (SDHC) as media. The "fast and
loose" mode just uses the SD Card with very little external delays.
That seems to be good enough for everything but everything except
the diagnostics and is consistent with the SIMH implementation.
https://github.com/KS10FPGA/KS10FPGA/issues/8
Rob.
20 Jun
20 Jun
11:53 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
Are you going for the 6600 CPU with PPU or just the CPU itself?
The 6400 CPU, on the other hand was one of the initial proof of concept
targets when Neil Lincoln at (then) ADL and later ETA was playing with
his "box of Chiclets" IC concept. To the best of my knowledge, a 6600
was not attempted. Even then (in the 1970s) the small footprint was
amazing.
--Chuck
21 Jun
21 Jun
10:25 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 20, 2016, at 11:53 PM, Chuck Guzis <cclist
at sydex.com> wrote:
Are you going for the 6600 CPU with PPU or just the CPU itself?
The whole thing. The intent is to be able to run code, and you need PPUs for that.
Besides, part of the motivation was to understand esoteric details of how PPUs work. The
PPUs are actually straightforward; I have those running. The CPU is trickier, and of
course much larger.
paul
11:24 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 06/21/2016 07:25 AM, Paul Koning wrote:
I take it that your PPs use the "one ALU, ten memories" model of the
6600 and not the independent PPUs of the 7600 and 180?
Will your 6600 have an option for ECS?
--Chuck
On Jun 20, 2016, at 11:53 PM, Chuck Guzis
<cclist at sydex.com>
wrote:
Are you going for the 6600 CPU with PPU or just the CPU itself?
The whole thing. The intent is to be able to run code, and you need
PPUs for that. Besides, part of the motivation was to understand
esoteric details of how PPUs work. The PPUs are actually
straightforward; I have those running. The CPU is trickier, and of
course much larger.
11:35 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 21, 2016, at 11:24 AM, Chuck Guzis <cclist
at sydex.com> wrote:
On 06/21/2016 07:25 AM, Paul Koning wrote:
I take it that your PPs use the "one ALU, ten memories" model of the
6600 and not the independent PPUs of the 7600 and 180?
Correct, because my model is a gate level transcription of the original design. I'm
NOT building this model from the system functional specification, but rather from the
actual module schematics and wire lists.
On Jun 20, 2016, at 11:53 PM, Chuck Guzis
<cclist at sydex.com>
wrote:
Are you going for the 6600 CPU with PPU or just the CPU itself?
The whole thing. The intent is to be able to run code, and you need
PPUs for that. Besides, part of the motivation was to understand
esoteric details of how PPUs work. The PPUs are actually
straightforward; I have those running. The CPU is trickier, and of
course much larger. Will your 6600 have an option for ECS?
That's the intent. This is tricky because I have not seen wire lists for the ECS
coupler. I should be able to do without the ECS controller (modeling ECS functionally at
that interface point). But the ECS coupler contains details that the CPU hooks into, and
also some semi-unrelated details like central/monitor exchange jump processing.
There are block diagrams, and those will have to serve if all else fails, but that means
reverse engineering the module level detail (or, more precisely, constructing a
functionally equivalent set of module level details). I keep hoping that some day the
missing details will be found. Similarly, there are some other details that are missing;
the PPU wire lists predate the central/monitor exchange jump feature so that too would
have to be reconstructed from less detailed information.
paul
12:07 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 06/21/2016 08:35 AM, Paul Koning wrote:
There are block diagrams, and those will have to serve
if all else
fails, but that means reverse engineering the module level detail
(or, more precisely, constructing a functionally equivalent set of
module level details). I keep hoping that some day the missing
details will be found. Similarly, there are some other details that
are missing; the PPU wire lists predate the central/monitor exchange
jump feature so that too would have to be reconstructed from less
detailed information.
Wasn't CEJ/MEJ a field-installable ECO? Maybe there's paper on that
somewhere.
ECS to me would be the real bugger, since it isn't just a box of core
sitting off to the side. On the Cybers, didn't it also include the ILR?
That was too many years ago. I do remember that it made the business
of RCH/DCH much simpler in PPRES--no need to go through MTR.
Well, when you're done with the 6600, you can work up a STAR 100 :) I'm
not aware of even a software emulator being available for that one.
--Chuck
12:24 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 21, 2016, at 12:07 PM, Chuck Guzis <cclist
at sydex.com> wrote:
On 06/21/2016 08:35 AM, Paul Koning wrote:
Early on it may have been an ECO; later it became "standard option 10104 C/D".
An ECO document would certainly serve, but I haven't seen that either.
There are block diagrams, and those will have to
serve if all else
fails, but that means reverse engineering the module level detail
(or, more precisely, constructing a functionally equivalent set of
module level details). I keep hoping that some day the missing
details will be found. Similarly, there are some other details that
are missing; the PPU wire lists predate the central/monitor exchange
jump feature so that too would have to be reconstructed from less
detailed information.
Wasn't CEJ/MEJ a field-installable ECO? Maybe there's paper on that
somewhere. ECS to me would be the real bugger, since it isn't
just a box of core
sitting off to the side. On the Cybers, didn't it also include the ILR?
That was too many years ago. I do remember that it made the business
of RCH/DCH much simpler in PPRES--no need to go through MTR.
I don't recognize "ILR". The control for central exchange (XJ instruction)
is is largely in the ECS coupler partly because some of the exchange package state
(RAX/FLX/MA) lives there, as does the monitor mode flag. Also partly because XJ and RE/WE
are 01 opcodes that use the same address calculation. I think once you get past the
coupler into ECS itself and the ECS controller, there aren't any execution-related
bits. Not unless you count the Flag Register, which is a set of mutexes operated on by
ECS read/write operations.
paul
1:02 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 06/21/2016 09:24 AM, Paul Koning wrote:
I don't recognize "ILR". The control
for central exchange (XJ
instruction) is is largely in the ECS coupler partly because some of
the exchange package state (RAX/FLX/MA) lives there, as does the
monitor mode flag. Also partly because XJ and RE/WE are 01 opcodes
that use the same address calculation. I think once you get past the
coupler into ECS itself and the ECS controller, there aren't any
execution-related bits. Not unless you count the Flag Register,
which is a set of mutexes operated on by ECS read/write operations.
ILR = "Interlock Register"
It was mutex setup, but on a per-system, rather than as a global ECS
thing like the flags register--and accessible only to PPs. Any word in
it could be read by any PP.
Either 64 or 128 bits located on PP channel 15 (octal). The only
mention that I could find of it in the bitsavers collection was for the
Cyber 74, but it was on lower Cybers as well.
http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/cyber_70/6034740…
PDF page 48.
I don't know if it was a retrofit for older 6000 systems, but it would
seem to make sense if it was. It simplified the RCH/DCH PP channel
reservation calls enormously.
--Chuck
11:47 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
One has to realize that all complex chips are done in Verilog or VHDL. Many old designs in
processors can be re-implemented from timing and bus diagrams.
This is no longer possible with todays processors like Intel or AMD processors. The
complexity of possible sequential events are more than is practical to try to analyze from
the pins.
One can implement an instruction set but you'll never get close to the bus activity of
current processors.
I would say that the most important part of either language is the ability to describe
the time of simultaneous events. This is unlike most programs written in C or such. Of
course, one can write a simulation language in C.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Chuck Guzis <cclist
at sydex.com>
Sent: Tuesday, June 21, 2016 8:24:44 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 06/21/2016 07:25 AM, Paul Koning wrote:
I take it that your PPs use the "one ALU, ten memories" model of the
6600 and not the independent PPUs of the 7600 and 180?
Will your 6600 have an option for ECS?
--Chuck
On Jun 20, 2016, at 11:53 PM, Chuck Guzis
<cclist at sydex.com>
wrote:
Are you going for the 6600 CPU with PPU or just the CPU itself?
The whole thing. The intent is to be able to run code, and you need
PPUs for that. Besides, part of the motivation was to understand
esoteric details of how PPUs work. The PPUs are actually
straightforward; I have those running. The CPU is trickier, and of
course much larger.
12:17 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 06/21/2016 08:47 AM, dwight wrote:
I would say that the most important part of either
language is the
ability to describe the time of simultaneous events. This is unlike
most programs written in C or such. Of course, one can write a
simulation language in C.
I tend to think of Verilog/VHDL/SystemC as being first cousins to the
much older event simulation languages, Simscript Simula and GPSS. I
believe that in the early days of LSI, one or more of them were actually
used in the design process.
If you've used any of the aforementioned simulation languages, then
transitioning to VHDL/Verilog is much easier.
--Chuck
2:53 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 6/21/2016 9:47 AM, dwight wrote:
One has to realize that all complex chips are done in
Verilog or
VHDL. Many old designs in processors can be re-implemented from
timing and bus diagrams.
Where do you get this info? Most of the little stuff I have seen
it is still graphic layout and Intel (or IBM ...) is not going to
tell you their design style.
This is no longer possible with todays processors like
Intel or AMD
processors. The complexity of possible sequential events are more
than is practical to try to analyze from the pins.
One can implement an instruction set but you'll never get close to
the bus activity of current processors.
Who knows what secrets the cache holds?
I would say that the most important part of either
language is the
ability to describe the time of simultaneous events. This is unlike
most programs written in C or such. Of course, one can write a
simulation language in C.
And a useless feature in my view. Real hardware has real delays
and simulation is prone errors translating to the real hardware.
Ben.
Dwight
PS: With the speed of modern transistors routing capacitance
and large die size; I think Vacuum tube/Drum memory might be better
model for modern computing.
22 Jun
22 Jun
2:07 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
Well Ben
I'll tell you a secret. I work for one of those two companies.
Processors are designed from such code, simulated and then
synthesized to silicon gates. I don't think that is too much of a
secret.
How the architecture is done is very much a secret. I can tell you that it is more
complicated than one person can completely understand. It is a team effort with many
people working from a general description of what each part does and how it should
interact. Some work only on arrays while others work on floating point alu's and so
on.
Each processor generation shares only a little with previous designs. To try to describe
to someone outside how one of todays processor worked inside would require a book for each
generation. Some parts are the same while other are vastly different.
It is interesting that I just read an article about the Chinese creating a faster supper
computer. I suspect that many might think they did it with RISK design while most US made
machines were stuck in CISC machines.
I don't have the real inside scoop but I can tell you what I think. Processors made
today are general purpose. Floating point is a side function and not where the most
emphasis is placed. I suspect that the Chinese designed the processors they used
specifically to do floating point and were not the reuse of general purpose processors.
The RISK/CISC is really not even relevant in todays processors since the main limiting
factor is memory access bandwidth and effective use of caches. The instruction set used is
only to deal with older software.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of ben <bfranchuk at
jetnet.ab.ca>
Sent: Tuesday, June 21, 2016 11:53:20 AM
To: cctalk at classiccmp.org
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On 6/21/2016 9:47 AM, dwight wrote:
One has to realize that all complex chips are done in
Verilog or
VHDL. Many old designs in processors can be re-implemented from
timing and bus diagrams.
Where do you get this info? Most of the little stuff I have seen
it is still graphic layout and Intel (or IBM ...) is not going to
tell you their design style.
This is no longer possible with todays processors like
Intel or AMD
processors. The complexity of possible sequential events are more
than is practical to try to analyze from the pins.
One can implement an instruction set but you'll never get close to
the bus activity of current processors.
Who knows what secrets the cache holds?
I would say that the most important part of either
language is the
ability to describe the time of simultaneous events. This is unlike
most programs written in C or such. Of course, one can write a
simulation language in C.
And a useless feature in my view. Real hardware has real delays
and simulation is prone errors translating to the real hardware.
Ben.
Dwight
PS: With the speed of modern transistors routing capacitance
and large die size; I think Vacuum tube/Drum memory might be better
model for modern computing.
7:54 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 21, 2016, at 11:07 PM, dwight <dkelvey at
hotmail.com> wrote:
Well Ben
I'll tell you a secret. I work for one of those two companies.
Processors are designed from such code, simulated and then
synthesized to silicon gates. I don't think that is too much of a
secret.
How the architecture is done is very much a secret. I can tell you that it is more
complicated than one person can completely understand. It is a team effort with many
people working from a general description of what each part does and how it should
interact. Some work only on arrays while others work on floating point alu's and so
on.
Having worked for both of those companies, I can also state the the number of people doing
the high level design/architecture of
these chips is measured in the 100?s. Most of the time the architects (I was one) write
documentation in excruciating detail as to how
something is to work (and why) to be handed off to the design team(s) to actually
implement. In many ways it would?ve just been
easier/faster to write ?code? but it?s harder for others to really know the why?s and
wherefore?s and make sure that everything is worked
out properly before hand (on one new chip we literally spent *months* working out all of
the details for the various reset and power
management flows?and that was just the docs describing how it should be done?no
implementation).
Each processor generation shares only a little with previous designs. To try to describe
to someone outside how one of todays processor worked inside would require a book for each
generation. Some parts are the same while other are vastly different.
If the book were several 1000 pages. ;-)
It is interesting that I just read an article about the Chinese creating a faster supper
computer. I suspect that many might think they did it with RISK design while most US made
machines were stuck in CISC machines.
I don't have the real inside scoop but I can tell you what I think. Processors made
today are general purpose. Floating point is a side function and not where the most
emphasis is placed. I suspect that the Chinese designed the processors they used
specifically to do floating point and were not the reuse of general purpose processors.
The RISK/CISC is really not even relevant in todays processors since the main limiting
factor is memory access bandwidth and effective use of caches. The instruction set used is
only to deal with older software.
The issue is that (much like many of the earlier supercomputers) is that they are vector
processors. Today?s supercomputers have a
(large) number of general purpose cores (ie POWER, x86) but they are there to manage the
real work horses which are based on graphics chips. It turns out that modern graphics
chips have enormous FP capabilities. For example, NVIDIA?s newest/baddest GPU
can do 10.6TFLOPS of single precision FP (using 3584 processors on the die). Now multiply
by 100?s of GPUs that are put into modern super computers.
Are they general purpose, no?they require specialized programming to perform the
computations. But the HPC (high performance
computing) guys will do what it takes (and have for decades) to get the most out of the
HW.
TTFN - Guy
23 Jun
23 Jun
12:17 a.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
Are they general purpose, no?they require specialized
> programming to perform the computations. But the HPC > (high performance
computing) guys will do what it takes (and have for > decades) to get the most
out of the HW.
I have a friend that works for NSA that does just that.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Guy Sotomayor Jr
<ggs at shiresoft.com>
Sent: Wednesday, June 22, 2016 4:54:04 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 21, 2016, at 11:07 PM, dwight <dkelvey at
hotmail.com> wrote:
Well Ben
I'll tell you a secret. I work for one of those two companies.
Processors are designed from such code, simulated and then
synthesized to silicon gates. I don't think that is too much of a
secret.
How the architecture is done is very much a secret. I can tell you that it is more
complicated than one person can completely understand. It is a team effort with many
people working from a general description of what each part does and how it should
interact. Some work only on arrays while others work on floating point alu's and so
on.
Having worked for both of those companies, I can also state the the number of people doing
the high level design/architecture of
these chips is measured in the 100?s. Most of the time the architects (I was one) write
documentation in excruciating detail as to how
something is to work (and why) to be handed off to the design team(s) to actually
implement. In many ways it would?ve just been
easier/faster to write ?code? but it?s harder for others to really know the why?s and
wherefore?s and make sure that everything is worked
out properly before hand (on one new chip we literally spent *months* working out all of
the details for the various reset and power
management flows?and that was just the docs describing how it should be done?no
implementation).
Each processor generation shares only a little with previous designs. To try to describe
to someone outside how one of todays processor worked inside would require a book for each
generation. Some parts are the same while other are vastly different.
If the book were several 1000 pages. ;-)
It is interesting that I just read an article about the Chinese creating a faster supper
computer. I suspect that many might think they did it with RISK design while most US made
machines were stuck in CISC machines.
I don't have the real inside scoop but I can tell you what I think. Processors made
today are general purpose. Floating point is a side function and not where the most
emphasis is placed. I suspect that the Chinese designed the processors they used
specifically to do floating point and were not the reuse of general purpose processors.
The RISK/CISC is really not even relevant in todays processors since the main limiting
factor is memory access bandwidth and effective use of caches. The instruction set used is
only to deal with older software.
The issue is that (much like many of the earlier supercomputers) is that they are vector
processors. Today?s supercomputers have a
(large) number of general purpose cores (ie POWER, x86) but they are there to manage the
real work horses which are based on graphics chips. It turns out that modern graphics
chips have enormous FP capabilities. For example, NVIDIA?s newest/baddest GPU
can do 10.6TFLOPS of single precision FP (using 3584 processors on the die). Now multiply
by 100?s of GPUs that are put into modern super computers.
Are they general purpose, no?they require specialized programming to perform the
computations. But the HPC (high performance
computing) guys will do what it takes (and have for decades) to get the most out of the
HW.
TTFN - Guy
20 Jun
20 Jun
4:43 p.m.
New subject: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
Paul wrote:
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
>> I'm thinking I'll stop trying OCR and
simply type the wire lists
instead; that's likely to be faster in the long run.
If you need someone to help, I'd be happy to transcribe some shit while
watching TV if you send me the docs and desired schema. I'm no stranger to
this sort of process :)
On Mon, Jun 20, 2016 at 1:35 PM, Paul Koning <paulkoning at comcast.net> wrote:
On Jun 20, 2016, at 4:22 PM, Toby Thain <toby
at telegraphics.com.au>
wrote:
On 2016-06-20 4:17 PM, Paul Koning wrote:
This is probably of great interest to more than just me.
Any more details? Going to publish?
Sure. You can see it at svn://akdesign.dyndns.org/dtcyber/trunk; most is
in the vhdl subdirectory but it uses some pieces from the top level. Very
much work in progress.
It's derived from the 6600 wire lists on bitsavers. I OCRed them (what a
pain), wrote VHDL models (gate level structural models) of each 6000 series
module, and a Python script builds a structural model out of those elements
interconnected by the wires from the wire lists. "Sufficiently long" wires
have their delay explicitly modeled.
I currently have chassis 1 (PPUs) working, at least to the point where I
can do a deadstart, have that load from the deadstart panel, and execute
some instructions. I've used it to grok some magic related to deadstart
that's part of the lore but not documented. I also have the 6612 display
controller working, so I can see how the text display on the console tubes
works. Unfortunately I don't have a good SPICE model for the analog parts,
so I don't yet know why the character shapes are changed by the circuitry
in the manner that the photos show.
The CPU is work in progress. I'm trying to get exchange to work. It's
hard; even more than the PPUs, the CPU relies on hairy timing in certain
spots. It appears that the wire lists are not all the same rev, and there
are also some typos in them.
Some day, if things go really well, this may result in a gate level
accurate FPGA 6600. I'm thinking I'll stop trying OCR and simply type the
wire lists instead; that's likely to be faster in the long run.
paul
...A hardware model can
be used to
replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
4:56 p.m.
On Mon, 20 Jun 2016, Paul Koning wrote:
used to how C or similar languages work. For example,
in this C code:
a = 1;
b = a;
a and b will both equal 1 at the end. But in the VHDL code:
a <= 1;
b <= a;
Whoa. That makes total sense, though. In the real world, I'm guessing the
"less than" just reflects that a signal might not have the level you
expect.
But it fits hardware, where signals have to propagate
and new things
happen as a result of previous actions at previous points in time.
It makes me wonder what kind of person had to figure out all those effects
and enshrine them in a deterministic language. That sounds very
challenging. Hats off to them.
VHDL and Verilog can be used to model hardware
operation; they can also
be used to describe hardware. These are not quite the same.
I've got a tab in my browser with an article about the differences. I like
strongly typed languages, so I'd probably start with VHDL if I can get
that far.
A model can, for example, talk about actual delays. A
hardware
description does not; such a "synthesizable" model is a subset of the
full language.
Ah, okay. I had wondered what that meant when Ian had mentioned it.
This is a common way to design what goes into an FPGA.
A hardware model
can be used to replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
Wow. All I can say is "I wish I could do something like that, too." :-)
For example, if all you have is a complex IC spec
sheet, it is likely to
be rather difficult. If you have internals, it becomes more feasible.
Hehe, I keep up this page a lot: https://www.sparkfun.com/tutorials/223
It's concerning how to read spec sheets.
... because reading these sheets is about like reading a man page for
non-UNIX users, it's tough at first, but then becomes very valuable!
There are plenty of textbooks on the topic. I would
recommend the
(large) book by Peter Ashenden on VHDL. He also has a book on Verilog;
given how he treated VHDL I expect that one is good too but I don't have
it.
I'm not there yet, but I've bookmarked a copy at Half-Price Books and I'll
come back to it if I make it through my digital logic course with brain
cells to spare.
-Swift
PS: Thanks to you and Ian for the nice explanations and answers.
5:06 p.m.
On Jun 20, 2016, at 1:56 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
On Mon, 20 Jun 2016, Paul Koning wrote:
The best way to think about the two different assignment operators (<= is an
assignment *not* less-than-or-equal) is that one happens ?now? and the other
is resolved on clock edges.
So assuming that a & b are 1 bit wide and that initially both a and b are 0 (or
in verilog terms 1b0).
In the first example, both a and b will be 1b1. In the second example, at the end
of the first clock cycle, a will be 1b1 and b will be 1b0. At the end of the next
clock cycle, a will be 1b1 and b will be 1b1 also.
TTFN - Guy
used to how C or similar languages work. For
example, in this C code:
a = 1;
b = a;
a and b will both equal 1 at the end. But in the VHDL code:
a <= 1;
b <= a;
Whoa. That makes total sense, though. In the real world, I'm guessing the
"less than" just reflects that a signal might not have the level you
expect.
11:33 p.m.
On Mon, Jun 20, 2016 at 2:56 PM, Swift Griggs <swiftgriggs at gmail.com> wrote:
On Mon, 20 Jun 2016, Paul Koning wrote:
It's not a "less than". In VHDL, "<=" is a token for a left
arrow,
for signal assignment, as in the quote above.
Also "=>" is a token for a right arrow, used for mappings, e.g.,
signal foo: std_logic_vector (7 downto 0) := (7 downto 4 => '0',
others => '1');
is one way to declare a signal that is an 8-bit vector, with the left
four bits initialized to 0, and the right four bits initialized to 1.
In this specific case, it probably would be more clear to write:
signal foo: std_logic_vector (7 downto 0) := "00001111";
but I didn't do that because I wanted to give an example of "=>".
"=>" can also be used to map formal to actual parameters of
subprograms, and (conceptually similarly) to map ports of components
to signals.
(VHDL allows indices to be descending, using "downto", or ascending,
using "to", but it's usually best not to try to mix them in a design.
I almost exclusively use "downto", as it matches the most commonly
used bit numbering of busses, where the most significant bit is
conceptually on the left, and has the highest bit number, and the
place-value weight of each bit is 2^n.)
VHDL is often criticized for being more verbose than Verilog. IMHO, it
more than makes up for that by offering strong type checking, whereas
Verilog makes it easier to shoot yourself in the foot without any
warning. (Much like Ada vs. C.) I personally don't find the verbosity
to be an issue, because I can type much faster than I can think about
anything complicated. I rarely, if ever, find that the verbosity slows
me down in the slightest, but certainly YMMV.
Originally VHDL was a more expressive language than Verilog, but more
recent Verilog standards have closed much of the gap.
Both Verilog and VHDL make it easy to write code that cannot be
synthesized to hardware (or to "reasonable" hardware), so one learns
to stick to a subset of the language capabilities that is
synthesizable. AFAIK, there is no formal spec for a synthesizable
subset of either language; different synthesizers have variations in
what they accept.
To some extent, knowing what features of the language can be used in
synthesis is a matter of understanding what hardware (gates and
flip-flops) you're trying to represent. While VHDL and Verilog can
provide a higher abstraction than individual gates and flip-flops,
synthesis has to turn everything into those, and if you're writing HDL
code and aren't sure how the synthesizer can turn the specific
constructs into hardware, it's entirely likely that it can't.
A common misconception about both VHDL and Verilog is that they make
it trivial for programmers to become hardware developers. Despite all
of the hoopla over "high level synthesis", the reality is that if you
don't know how to design hardware using gates and flip-flops, anything
you try to build in an HDL, even with high-level synthesis, is likely
to either not work, or to be extremely inefficient.
The parallelism that Paul described in his example is one of the
hardest concepts for programmers new to hardware design to grasp.
Verilog has an innate distinction between "wires" and "registers".
VHDL just has signals. The idiom for a register in VHDL is:
process (clock)
begin
if rising_edge (clock) then
b <= a;
end if;
end process;
This shows a signal assignment (b <= a) as a sequential statement,
which occurs only when the condition (rising edge of clock) is met.
Outside a process, a signal assignment is a concurrent statement, and
happens all of the time.
Here's an example of a VHDL process that works perfectly well in
simulation, but probably not at all in synthesis:
process (clock)
begin
if clock'event then
b <= a;
end if;
end process;
That process models a register that is clocked on both edges of the
clock input, e.g., any time the clock signal changes. That's easy to
simulate, but difficult to synthesize as generally speaking no
flip-flops that clock on both edges are available.
Another example of a non-synthesizable VHDL construct is:
b <= a after 15 ns;
That isn't synthesizable because there isn't any time delay element
available in logic synthesis. The only way to do it is to have some
clock with a cycle time that is a submultiple of 15 ns, and to use a
shift register or counter clocked by that to implement the delay. The
synthesizer won't do that for you; you have to specify it explicitly.
Historically, it seemed that ASIC designers have preferred Verilog,
while FPGA designers have preferred VHDL. I'm not sure that's nearly
as true as it once was.
It's claimed, and perhaps may even be true, that Verilog is easier to
learn than VHDL. I still advise learning VHDL first. If you need to
know both, it's my opinion that it's easier to learn Verilog after
knowing VHDL than vice versa.
My favorite VHDL book is Peter Ashenden's _Designer's Guide to VHDL_.
I'm not going to claim that it's a particularly great example to
study, but one of my recent VHDL projects was to implement IEEE-488
(aka GPIB or HP-IB) in an FPGA:
https://github.com/brouhaha/gpib
I coded all of the IEEE-488 function state machines other than the
newfangled no-handshake transfers, which almost no equipment supports.
So far I have only actually tested the L, T, SH, and AH functions,
which are the key interface functions required for data transfer, and
the only ones that are fully implemented by normal IEEE-488 interface
chips (e.g., TI TMS9914, Intel 8291, Motorola MC68488, NEC uPD7210).
a and b will both equal 1 at the end. But in the
VHDL code:
a <= 1;
b <= a;
Whoa. That makes total sense, though. In the real world, I'm guessing the
"less than" just reflects that a signal might not have the level you
expect. 
21 Jun
21 Jun
5:56 a.m.
On Mon, Jun 20, 2016 at 01:35:46PM -0600, Swift Griggs wrote:
[...]
Why are folks referring to "Verilogging" and
"doing a verilog" on older
chips. Is there some way you can stuff an IC into a socket or alligator clip
a bunch of tiny leads onto it and then "map" it somehow into Verilog?
Only for trivial chips that do not maintain (much) state, such as ROMs and 74xx
chips which (almost) always generate the same output for a given set of inputs,
so it is possible to exhaustively search all of the possible states.
Useful chips use RTL[0] designs which contain registers (aka latches,
flip-flops, etc) that hold internal state. The outputs now vary not only on the
inputs but also on the registers, and there are far to many states to be able
to search them all. An example of a chip that makes heavy use of registers is a
CPU itself, and it is not plausible to try and automatically figure out the
instruction set of a novel CPU based just on its bus interface.
In practice, one would hoover up as much documentation as possible and come up
with a prototype in HDL that implements the inferred spec, then compare it
against how the real chip works. This will almost certainly not work first
time, so one then gets to fix the bugs and iterate until the copy is good
enough for the given application. This is the sort of thing that effortlessly
soaks up man-years of effort.
[0] https://en.wikipedia.org/wiki/Register-transfer_level
2985
days inactive
2988
days old
47 comments
16 participants
participants (16)
-
abuse＠cabal.org.uk -
alan＠alanlee.org -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
dkelvey＠hotmail.com -
echristopherson＠gmail.com -
elson＠pico-systems.com -
ggs＠shiresoft.com -
ian.finder＠gmail.com -
leec2124＠gmail.com -
lists＠loomcom.com -
paulkoning＠comcast.net -
radioengr＠gmail.com -
spacewar＠gmail.com -
swiftgriggs＠gmail.com -
toby＠telegraphics.com.au