Hi Boris:

an excellent project description. 
You have a broad area of interest from financial publishing
to hardware development.

See:

http://www.ccs.neu.edu/home/lieber/zeus/zeus.html

for my older interests in this area.

Good luck with your project. I am your primary host 
with Doug Orleans as your secondary host.

>Define the languages for hardware design hierarchy and connectivity. Write a
>proof-of-concept CAD tool (using Demeter) that will generate interface HDL
>fubs using these files.

Can you reuse an XML version of VHDL or similar language
and write a cd for that mark-up language? Or are you using
a more concise syntax?

-- Karl

>From Boris.Gaber@tfsma-ims.tfn.com Tue Nov  9 16:53:09 1999
>From: "Gaber, Boris" <Boris.Gaber@tfn.com>
>To: com3360-grader@ccs.neu.edu
>Subject: Project Proposal for com3360
>
>Hello,
>
>This is the project I was thinking about doing:
>
>This project dates back to my days as a programmer in Intel's Athena CAD
>department. The department wrote software for hardware designers at Intel
>and the designers used these tools in creation of Intel CPUs, such as
>P200MMX, Merced, etc.
>
>Technical Background:
>---------------------
>Any processor consists of functional blocks (fubs). A fub can be an ALU,
>cache, counter, bus controller, whatever. Fubs can contain other fubs. The
>logical design is a hierarchical structure of fubs. In modern CPUs there are
>hundreds of fubs. A fub can be compared to a procedure in software, but fubs
>are actually implemented in real hardware in the end of the process and thus
>have specific constraints - no recursion, for example.
>
>The logical description of fubs is written in HDL - hardware definition
>language. In Intel we used iHDL, which is proprietary, but there are
>publicly available HDL's such as VHDL or Verilog HDL - and they all are
>alike. The HDL description of every fub must include an interface section -
>this section describes the signals that are crossing the border of this fub,
>meaning input and output signals (wires).
>
>The main functionality of a CPU is in the leaf fubs - the lowest fubs in the
>hierarchy. Most of the fubs in the higher levels are there just to enforce
>partitioning. A designer is usually responsible for one or more leaf fubs.
>Leaf fubs usually don't have too much input/output signals, but the higher
>the fub is in the hierarchy - the more signals it has. The numbers reach
>thousands in fubs on the highest levels.
>
>The design is constantly changing. Leaf fubs and whole blocks of leaf fubs
>are moving in the hierarchy. They might move from one part of the CPU to
>another or they can have more or less ancestors above them. The changes can
>be due to layout constraints or timing requirements or manager's mood.
>
>These changes result in tremendous overhead to maintain the interface
>sections of the higher fubs. The process of doing it is tedious and
>error-prone - and the last thing we need is another bug in an Intel CPU,
>right? The information appearing in these higher fubs (interface fubs) seems
>to be redundant and can be deduced from the leaf fubs - there must be a way
>of automating this process.
>
>So, there needs to be a way of separating the connectivity of leaf fubs from
>the design hierarchy. This can be achieved by dividing the two into
>different sets of input files and generating the interface HDL fubs from
>these files. This way, when the hierarchy changes - the interface HDL can be
>reliably, quickly and cheaply regenerated.
>
>The Project:
>------------
>Define the languages for hardware design hierarchy and connectivity. Write a
>proof-of-concept CAD tool (using Demeter) that will generate interface HDL
>fubs using these files.
>
>
>Boris Gaber.
>
>boris@ccs.neu.edu
>Boris.Gaber@tfn.com
>
>