Obsolete processors resurected in FPGAs

Monte Dalrymple wrote:

<snip>
>>4) How close can the internal timings be recreated?
> 
> 
> It's actually an interesting exercise to try to figure out how the original
> design was implemented to come up with the original timings. I have done this twice,
> for the  Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all
> cases. The Z8000 was a different story, for two reasons. First, the exact
> timing for the case of the interrupt acknowledge was not specified except "1 to 7
> clock cycles" for an aborted instruction fetch. Second, the published timing for
> both the multiply and divide instruction was clearly incorrect, as it did not
> account for the different addressing modes correctly, besides not making sense (from
> a  clock cycle standpoint) relative to whether a bit in the divisor was set or
> not.
<snip>

Interesting, Sounds a lot of work on the Z8000, can you elaborate on the 
reasons/needs for this core, in particular.
Could also be a good example, for the OP.

-jg

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:ytxld.1198$3U4.104987@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> <snip>
> >>4) How close can the internal timings be recreated?
> >
> >
> > It's actually an interesting exercise to try to figure out how the
original
> > design was implemented to come up with the original timings. I have done
this twice,
> > for the  Z180 and the Z8000. I was able to match the Z180 clock cycle
timing in all
> > cases. The Z8000 was a different story, for two reasons. First, the
exact
> > timing for the case of the interrupt acknowledge was not specified
except "1 to 7
> > clock cycles" for an aborted instruction fetch. Second, the published
timing for
> > both the multiply and divide instruction was clearly incorrect, as it
did not
> > account for the different addressing modes correctly, besides not making
sense (from
> > a  clock cycle standpoint) relative to whether a bit in the divisor was
set or
> > not.
> <snip>
>
> Interesting, Sounds a lot of work on the Z8000, can you elaborate on the
> reasons/needs for this core, in particular.
> Could also be a good example, for the OP.
>
> -jg
>
>

The original customer for this design makes air data computers, and projects
demand to continue well beyond when the "obsolete part stock" quantities of
the Z8000 will be around. Since the software for this system has to be FAA
certified, changing even one line of code is horrendously expensive. I'm
sure
that the OP was talking about exactly these kinds of applications. There are
a number of similar applications out there, because the Z8000 was the first
MIL-qualified 16-bit CPU and was designed into quite a few military and
mil-spec systems. These are the kinds of systems with very long lifetimes. I
know that the Z8000 was used in the F-15, the F-16, the 747 and the 757,
for example. All of these aircraft are still flying and are still in
production as
far as I know. These kinds of applications are the exact opposite of the
more
common "throw-it-away-in-18 months" that most people deal with today.

Monte

"vax, 9000" <vax9000@gmail.com> wrote in message
news:cn61r8$37l$1@charm.magnus.acs.ohio-state.edu...
> Monte Dalrymple wrote:
>
> > It's actually an interesting exercise to try to figure out how the
> > original design was
> > implemented to come up with the original timings. I have done this
twice,
> > for the
> > Z180 and the Z8000. I was able to match the Z180 clock cycle timing in
all
> > cases. The Z8000 was a different story, for two reasons. First, the
exact
> > timing...
>
>   Since you are an expert of Z8000, I'd like to ask you a question about
> Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what
> these bugs were, and whether they are corrected? Thank you.
>
> vax, 9000

You can download the spec for my clone design at

http://www.systemyde.com/pdf/y8002.pdf

All of the differences between the published spec and what we found with
the actual silicon are detailed there. I think that most of the bugs were
back-annotated into the spec. For example, register R0 can't be used
with some instructions, for no obvious reason. I think that some of the
"undefined" flag settings were actually bugs that were deemed not
important. The biggest one, in my opinion, had to do with divide not
handling the one boundary case, as I mentioned in the previous post.
And there is also the issue of cycle counts for both multiply and divide
that can't be correct in the published spec.

Monte

"Alex Gibson" <al xx at tpg dot com dot au - remove spaces replace dot> 
wrote in message 
news:4195db13$0$31718$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au...
>
> quite a few 6502 cores available

Always read the small print though.

Several 6502 cores have been published but most of them come with notes 
about not being completely finished. For example, BCD instructions missing.

Daniel Wallner seems to be the only one who gets round to finishing stuff 
and testing it.

> http://www.howell1964.freeserve.co.uk/logic/index_logic.htm  lots of stuff

Recently announced plans to clone Atari 800XL, which will be a bigger task 
than the Atom. 

Monte Dalrymple wrote:

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
>>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the
>>reasons/needs for this core, in particular.
>>Could also be a good example, for the OP.
>>
>>-jg
>>
>>
> 
> 
> The original customer for this design makes air data computers, and projects
> demand to continue well beyond when the "obsolete part stock" quantities of
> the Z8000 will be around. Since the software for this system has to be FAA
> certified, changing even one line of code is horrendously expensive. I'm
> sure
> that the OP was talking about exactly these kinds of applications. There are
> a number of similar applications out there, because the Z8000 was the first
> MIL-qualified 16-bit CPU and was designed into quite a few military and
> mil-spec systems. These are the kinds of systems with very long lifetimes. I
> know that the Z8000 was used in the F-15, the F-16, the 747 and the 757,
> for example. All of these aircraft are still flying and are still in
> production as
> far as I know. These kinds of applications are the exact opposite of the
> more
> common "throw-it-away-in-18 months" that most people deal with today.

..and industrial systems are somewhere in-between.

Did you need to get certification for the Z8000 SoftCPU ? - it seems
this would need to be fully qualified as well, or have the MIL/FAA
not quite caught up with the idea of SoftCPU ?
-jg

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:jdzld.1215$3U4.105563@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> > "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> >>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the
> >>reasons/needs for this core, in particular.
> >>Could also be a good example, for the OP.
> >>
> >>-jg
> >>
> >>
> >
> >
> > The original customer for this design makes air data computers, and
projects
> > demand to continue well beyond when the "obsolete part stock" quantities
of
> > the Z8000 will be around. Since the software for this system has to be
FAA
> > certified, changing even one line of code is horrendously expensive. I'm
> > sure
> > that the OP was talking about exactly these kinds of applications. There
are
> > a number of similar applications out there, because the Z8000 was the
first
> > MIL-qualified 16-bit CPU and was designed into quite a few military and
> > mil-spec systems. These are the kinds of systems with very long
lifetimes. I
> > know that the Z8000 was used in the F-15, the F-16, the 747 and the 757,
> > for example. All of these aircraft are still flying and are still in
> > production as
> > far as I know. These kinds of applications are the exact opposite of the
> > more
> > common "throw-it-away-in-18 months" that most people deal with today.
>
> ..and industrial systems are somewhere in-between.
>
> Did you need to get certification for the Z8000 SoftCPU ? - it seems
> this would need to be fully qualified as well, or have the MIL/FAA
> not quite caught up with the idea of SoftCPU ?
> -jg
>

I am not sure of the specifics, because the customer took this
responsibility.
I suspect that the hardware certification process is easier than the
software
certification process. I saw a copy of the procedure used for software
certification and I don't know how anyone could actually get any code
written in a finite amount of time following the procedure. But then, I'm a
hardware guy. I do know that the customer found my testbench to be
very useful. As I mentioned in an earlier post, it checked every
instruction,
flag, register combination, addressing mode and boundary condition. The
customer ran it with a real chip and my design and compared the results.
Then I modified my design to match the chip where there was a difference.
The only things I didn't match was the interrupt acknowledge timing and
the execution time for multiply and divide. My design used fewer clocks,
and the customer was satisfied with this result.

Monte

Monte Dalrymple wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
<snip
>>Did you need to get certification for the Z8000 SoftCPU ? - it seems
>>this would need to be fully qualified as well, or have the MIL/FAA
>>not quite caught up with the idea of SoftCPU ?
>>-jg
>>
> 
> 
> I am not sure of the specifics, because the customer took this
> responsibility.
> I suspect that the hardware certification process is easier than the
> software
> certification process. I saw a copy of the procedure used for software
> certification and I don't know how anyone could actually get any code
> written in a finite amount of time following the procedure. But then, I'm a
> hardware guy. I do know that the customer found my testbench to be
> very useful.

Testbenchs are always under appreciated.

> As I mentioned in an earlier post, it checked every
> instruction,
> flag, register combination, addressing mode and boundary condition. The
> customer ran it with a real chip and my design and compared the results.
> Then I modified my design to match the chip where there was a difference.
> The only things I didn't match was the interrupt acknowledge timing and
> the execution time for multiply and divide. My design used fewer clocks,
> and the customer was satisfied with this result.

  An impressive case-study. Did they use an ASIC, or an FPGA (which?), 
and has that needed process revision yet ?
-jg

> > I am not sure of the specifics, because the customer took this
> > responsibility.
> > I suspect that the hardware certification process is easier than the
> > software
> > certification process. I saw a copy of the procedure used for software
> > certification and I don't know how anyone could actually get any code
> > written in a finite amount of time following the procedure. But then,
I'm a
> > hardware guy. I do know that the customer found my testbench to be
> > very useful.
>
> Testbenchs are always under appreciated.

Indeed.


>
> > As I mentioned in an earlier post, it checked every
> > instruction,
> > flag, register combination, addressing mode and boundary condition. The
> > customer ran it with a real chip and my design and compared the results.
> > Then I modified my design to match the chip where there was a
difference.
> > The only things I didn't match was the interrupt acknowledge timing and
> > the execution time for multiply and divide. My design used fewer clocks,
> > and the customer was satisfied with this result.
>
>   An impressive case-study. Did they use an ASIC, or an FPGA (which?),
> and has that needed process revision yet ?
> -jg
>

The target was an Actel FPGA. It hasn't gone through a process revision
yet that I am aware of.

Monte Dalrymple wrote:

>> > I am not sure of the specifics, because the customer took this
>> > responsibility.
>> > I suspect that the hardware certification process is easier than the
>> > software
>> > certification process. I saw a copy of the procedure used for software
>> > certification and I don't know how anyone could actually get any code
>> > written in a finite amount of time following the procedure. But then,
> I'm a
>> > hardware guy. I do know that the customer found my testbench to be
>> > very useful.
>>
>> Testbenchs are always under appreciated.
> 
> Indeed.

Agree. I only test my hobby project with a few settings and pray that
everything else works. 

Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any
difference between Z8000 and 16C00?

vax, 9000

In article <7ayld.565$a83.316@newsfe3-win.ntli.net>,
 "Kryten" <kryten_droid_obfusticator@ntlworld.com> writes:
|> Always read the small print though.
|> 
|> Several 6502 cores have been published but most of them come with notes 
|> about not being completely finished. For example, BCD instructions missing.

Next thing is, that mostly all 6502 cores I've seen so far emulate the 65C02. 
For quite a number of legacy stuff which exploited the NMOS 6502 illegal 
opcodes for timing reasons a 65C02 is plain unusable.

Rainer