> > > > So when can I legally start producing my 100% compatible opencore
> > > > transputer?
> > > Why on earth would you want to create a 100% compatible. If you have
> > > access to a cheap fab, maybe some reason if you must have plug
> > > compatible and sockets to fill. Otherwise you will have to use FPGA
> > > which is not a good platform for cloning old comp archs but is a good
> > > platform for creating new FPGA friendly cpus.
> > Fair point. The task for myself is 100% software, machine code and
> > driver compatibility. The electronics will be 100% compatible at the
> > tram level.
> > I felt duplicating the original architecture would be a good first
> > step; albeit a very big step. Building a new FPGA 'friendly' risc cpu
> > with 100% transputer code compatibility was step two. Optimization
> > will occur later.
> I think that duplicating the original architecture would be fantastic.
> Just "because it would be"... Even if it didn't quite make it 100%
> coverage for quite a while. We are not in this for raw compute speed
> are we? Why would we want the original arch on an FPGA in this case?
Fantastic it would be (in a crazy way) :-).
Quote:> If speed, then Occam->VHDL compilers seems appealing. Perhaps a
> PowerPC core (done already) and SPOC (Occam to C), with Occam->VHDL
> for speed critical bits.
vertex2Pro includes 2 or 4 PPC cores. Thats the only way a poor user
can get their hands on such things. Actually not very cheap either.
Given IBM story of selling lowend PPC off to AMCC, I am not so sure
about that anymore. It doesn't have FPU either.
> Step 2, 100% machine code, software and driver compatibility would be
> very useful. How about a dead simple micro engine, that drives a t414
> h/w interface, with event, reset, analyse, possible hardware assist
> for prefix instruction decode and little else? An initial performance
> goal of 1 T414 MIP. The idea being a small CPU core that inserts wait
> states when it can't keep up (most of the time). Would be good for
> students to learn hands on about microcoding.
> If the core was small enough, perhaps 4 could fit on one FPGA. Sharing
> the microstore to save space? [I don't know much about FPGAs if that
> is not evident already... 8-)]
A true TP clone would likely be several times bigger & slower than a
modern design. Getting 4 into a FPGA would be difficult & expensive.
The real issue is to exploit the FPGA resources that are available ie
the amazing bandwidth available to all those BlockRams. The area req
for even a simple cpu means you have access to about 4 independant
true dual ported Block rams of any binary shape between 512.32 to
16k.1. For best performance you go as wide as possible and keep the
rams working independantly to do upto 8 mem access per cycle. Now
thats quite hard to organize.
If I wasn't doing this in FPGA, I would need a budget of maybe $5m to
$20m to do a credible full custom VLSI design with maybe 5-10 EEs
working on project. Such a budget is never likely to be available for
redoing any old cpu period.
For an FPGA, my budget is basically time & free tools (WebPack), so
far I have spent only 3months and am pretty close to running code (not
TP code). Modelling is in C (Verilog cycle RTL style) and Verilog.
VHDL could as easily be used.
A 150MHz max for Spartan3 might give a core that fits in smallest
sp3-50 part that might sell for a few $, maybe $4 in 250Ks. A higher
performance virtex2pro could go 250MHz max, but it costs way more but
also has lots of extra technology feutures not used like Rocket Serdes
IO in the GHz region.
Quote:> Any form of compatible transputer core would be a bonus for home
> electronics projects, simple control, etc. I would be very happy if it
> was just compact and clocked at a handy 5mhz...
Certainly any fast cpu can run fine slower. A version in the older
Spartan2 might be 50MHz to 100MHz with far less cache. Extrnal clock
might be a few x slower than internal so 5MHz clock might be doable. I
am not sure about the DLL/PLL facilities yet.
Still don't see req for code compatibility.
When you can have a new cpu that is essentially a Transputer that can
run modern Occam & other C langs, then you have that route to run old
There are details of the old Transputer that are not good and should
not be preserved, huffman encoding is one of them, it kills
performance and complicates design no end, its very bad on 86, nobody
else uses it at byte level anymore. The stack for local exprn
evaluation is also not good, today, conventional reg style
architectures can do several times more work per cycle, just as long
as the reg file is in memory and is wp based.
Quote:> Once a s/w compatible core is done, it may spur more people to dust
> off their old software and put more Occam/transputer apps online for
> all to play with...
> As an aside, I wonder what happened to the old Inmos CAD system? Did
> ST port the designs to some other system, or did they use the Inmos
> CAD system to design the T805?
> Anyone know what the T9000 was designed on?
As the very 1st person to use FatFreddy and a regular user of the HDL
simulator, I don't think they made it very far after the 1st TPs
shipped. It became obvious that proprietary tools no matter how good
can hold you back. By 89 Inmos was using more commercial tools,
Verilog and so on, I expect (but don't know) that the T9000 was done
on mostly commercial SW. FatFreddy might have been used for cells.
Even in the earliest days, a Calma was available in the office, but
its per seat cost was high v 68k worksations thats were built for