Hi Guys,
              I am a student at okalhoma state university and  I am trying to develop an
ASIC version of the HC11 controller using verilog. This should be able to runn all the Hc1
instructions except for the ports and A/D. I am simulating the RAM and ROM through
external buses. I want to tst my verilog code for functionality and timing. Is there a set
of C/assembly test programs that would excercise all the HC11 instructions and possibly
give me a result as well as to whether those instructions passed. Please I need to get
this testing done as early as possible. Thanks a lot in advance.
   
  Sincerely,
  S.Ranganathan

__________________________________________________
">http://mail.yahoo.com 

[Non-text portions of this message have been removed]
	

Ranganathan Sridharan wrote:
> Hi Guys,

I'd appreciate it if you kept your lines shorter. Hit return
once in a while.

> I am a student at okalhoma state university and I am trying to
> develop
an ASIC version of the HC11 controller using verilog. This should be
able to runn all the Hc1 instructions except for the ports and A/D. I am

Ok. Someone already did one of those, I'm sure.

> simulating the RAM and ROM through external buses. I want to tst my
> verilog code for functionality and timing. Is there a set of C/assembly

For functionality, you could simply write a program which exercises
each instruction with each address mode. One commonly used technique
for large computers is to write a program which computes PI to a
large number of digits. This exercises the computer pretty thoroughly
for the instructions it tests. I have some numerical routines
which compute several mathematical constants which I can compile
and run on the '11. We could probably work out an arrangement
for you to use them for test.

That is again for functionality. If you are trying to get actual
cycle counts, that's a different matter. In that case, then
one needs to know exactly how closely are you trying to emulate?
IOW, the back of the manuals shows what is on the bus on a cycle-
by-cycle basis. Are you trying to emulate that? Or are you just
trying to get the overall timing of each instruction correct?

I'd think that writing a program which exercises each instruction
in each address mode and writing out the contents of the registers
(including the flags register) in some special manner then doing
a capture with a logic analyzer (or a PC with a little special
external hardware) could then compare the output of your little
emulation chip with a real '11.

Really doing a correct job would be quite an undertaking. Be sure
to think about things like the half carry bit. Are you going to
emulate instructions like WAI and STOP? How about the X bit then?
It interacts with these instructions.

> test programs that would excercise all the HC11 instructions and
> possibly give me a result as well as to whether those instructions
> passed. Please I need to get this testing done as early as possible.
> Thanks a lot in advance.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Ranganathan Sridharan wrote:
> Hi Guys,
> I am a student at okalhoma state university and  I am trying to
> develop an ASIC version of the HC11 controller using verilog. This
> should be able to runn all the Hc1 instructions except for the ports
> and A/D. I am simulating the RAM and ROM through external buses. I
> want to tst my verilog code for functionality and timing. Is there a
> set of C/assembly test programs that would excercise all the HC11
> instructions and possibly give me a result as well as to whether
> those instructions passed. Please I need to get this testing done as
> early as possible. Thanks a lot in advance.

What did you eventually get going?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

 i am really sorry sir. I was sick for a while now and was not able to reply to your
mail. thanks a lot 
for all your suggestions on what all could be used for testing. I have been following
this group for a while
and I really admire the way in which you handle questions and the way you answer them (I
am trying to copy you)
i am trying to write a routine that would calculate PI but so far I am not sure on how to
implement divide (with 
   
  repeated subtract right?) and hence that part is pending. other than that once i have
something that people
can test easily I will post it to the groups and people with verilog skills might be able
to test it and give 
me some bugs and suggestions hopefully. please let me know if i can get some routines to
test based on what 
I have described below. Thanks a lot again.
   
  >Ok. Someone already did one of those, I'm sure.
  Yes the opencore.org site has a VHDL version of just the central core controller.
   
  > For functionality, you could simply write a program 
> which exercises each instruction with each address 
> mode. 
       This is what I am doing for now and I am almost done with coding most
instructions. 
  Part of the problem was with instructions that deal with stack and interrupts as they
were
  on the longest delay chain and were hard to code and optimize.
   
  > One commonly used technique for large computers is to write a program which
computes PI to a
> large number of digits. This exercises the computer pretty thoroughly for the
instructions it tests.
> I have some numerical routines
> which compute several mathematical constants which I can compile
> and run on the '11. We could probably work out an arrangement
> for you to use them for test.
   
            If you have any of these routines that you could give me it would be greatly
helpful.
  I looked around and found a benchmark program called dhrystone.c that I tried to
convert to 
  Hc11 assembly and then test that but the problem I was only emulating RAM and EPROM and
not 
  any other device and this routine used a lot of modules that did this I/O. is there
anyway in the
  compiler I can filter out such type of instructios?.
     
> That is again for functionality. If you are trying to get actual
> cycle counts, that's a different matter. In that case, then
> one needs to know exactly how closely are you trying to emulate?
> IOW, the back of the manuals shows what is on the bus on a cycle-
> by-cycle basis. Are you trying to emulate that? Or are you just
> trying to get the overall timing of each instruction correct?
   
        As of now I am only trying to maintain the overall functionality at the end of
the 
 actual cycle counts and the cycle-by-cycle operation is not necessarily similar to the 
 original Hc11. I am not sure if this has to be done if the controller is said to be
 compatible to Hc11. what is your thought on this?
     
> I'd think that writing a program which exercises each instruction
> in each address mode and writing out the contents of the registers
> (including the flags register) in some special manner then doing
> a capture with a logic analyzer (or a PC with a little special
> external hardware) could then compare the output of your little
> emulation chip with a real '11.
  
   Right now I am writing out the register values at the end of each instruction to a 
 verilog dump file and then simulating the same program in a Hc11 simulator (HCSIM.EXE) 
 and verifying the results. Actually if it was possible for a simulator also to write the
 register values to a text file I can automate this comparison but could not find one
yet.
    If I did what you are saying I would have to match the cycle-by-cycle operation of
the HC11
 for the capture and my simulation to coincide. Is this necessary when I tell that this
controller 
 if fabricated would be HC11 compatible. I mean would people be using (I guess some might
be checking) 
 these intermediate values.
   
  > Really doing a correct job would be quite an undertaking. Be sure
> to think about things like the half carry bit. Are you going to
> emulate instructions like WAI and STOP? How about the X bit then?
> It interacts with these instructions.
      yeah i have implemented the functionality for the half carry bit but as I told
before
  I have not implemented DAA instruction so far and not sure of a way to simplify the
logic 
  for this. I am implementing interrupts as well but the interrupt controller is going to
be outside
  main controller/alu that I am designing now. So what I have done is make the I and X
bits available as
 outputs from this module and then have a interrupt avaiable (iavail) input that the
interrupt controller
 would enable after checking I and X bits and any interrupts and once i accept an
interrupt i make another
 output iaccept go high to indicate this to inmterrupt controller which clears the
interrupt then.
   
  sincerely,
S.Ranganathan
	---------------------------------
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!

[Non-text portions of this message have been removed]
	

Ranganathan Sridharan wrote:
>  i am really sorry sir. I was sick for a while now and was not able to reply to your
mail. thanks a lot

No problem.

> for all your suggestions on what all could be used for testing. I have been
following this group for a while
> and I really admire the way in which you handle questions and the way you answer
them (I am trying to copy you)

Well, thanks.

> i am trying to write a routine that would calculate PI but so far I am not sure on
how to implement divide (with 
>   repeated subtract right?) and hence that part is pending. other than that once i
have something that people

I would use the IDIV instruction.
As I mentioned, I have written programs to compute a number
of mathematical constants, including PI.

[snip]

>   > For functionality, you could simply write a program 
> 
>>which exercises each instruction with each address 
>>mode. 
> 
>        This is what I am doing for now and I am almost done with coding most
instructions. 
>   Part of the problem was with instructions that deal with stack and interrupts as
they were
>   on the longest delay chain and were hard to code and optimize.

Well, if you exercise each instruction, then you could run
the program on an '11 simulator, and capture the states of
all registers and flags after each instruction, and convert
that to a file which your Verilog emulator can use to compare.

>   > One commonly used technique for large computers is to write a program which
computes PI to a
> 
>>large number of digits. This exercises the computer pretty thoroughly for the
instructions it tests.
>>I have some numerical routines
>>which compute several mathematical constants which I can compile
>>and run on the '11. We could probably work out an arrangement
>>for you to use them for test.
> 
>    
>             If you have any of these routines that you could give me it would be
greatly helpful.

Well, I'm not sure "give" is the appropriate term. Programs
used to test/verify proper operation of new hardware have
a commercial value. Let's say we can work out an arrangement
which won't cost you anything.
Send me some private e-mail.

>   I looked around and found a benchmark program called dhrystone.c that I tried to
convert to 
>   Hc11 assembly and then test that but the problem I was only emulating RAM and
EPROM and not 
>   any other device and this routine used a lot of modules that did this I/O. is
there anyway in the
>   compiler I can filter out such type of instructios?.

What technique do you use to convert Dhrystone to machine code?

>>That is again for functionality. If you are trying to get actual
>>cycle counts, that's a different matter. In that case, then
>>one needs to know exactly how closely are you trying to emulate?
>>IOW, the back of the manuals shows what is on the bus on a cycle-
>>by-cycle basis. Are you trying to emulate that? Or are you just
>>trying to get the overall timing of each instruction correct?
> 
>    
>         As of now I am only trying to maintain the overall functionality at the end
of the 
>  actual cycle counts and the cycle-by-cycle operation is not necessarily similar to
the 
>  original Hc11. I am not sure if this has to be done if the controller is said to be
>  compatible to Hc11. what is your thought on this?

It's your project, you define "compatible". I'm sure that there
are, somewhere in the world, some people who verify the cycle-
by-cycle operation of some program somewhere. I have no idea
who they might be.

>>I'd think that writing a program which exercises each instruction
>>in each address mode and writing out the contents of the registers
>>(including the flags register) in some special manner then doing
>>a capture with a logic analyzer (or a PC with a little special
>>external hardware) could then compare the output of your little
>>emulation chip with a real '11.
> 
>   
>    Right now I am writing out the register values at the end of each instruction to
a 
>  verilog dump file and then simulating the same program in a Hc11 simulator
(HCSIM.EXE) 
>  and verifying the results. Actually if it was possible for a simulator also to
write the
>  register values to a text file I can automate this comparison but could not find
one yet.
>     If I did what you are saying I would have to match the cycle-by-cycle operation
of the HC11
>  for the capture and my simulation to coincide. Is this necessary when I tell that
this controller 
>  if fabricated would be HC11 compatible. I mean would people be using (I guess some
might be checking) 
>  these intermediate values.

Hey, wait a minute. If there actually are commercial considerations
here, then we'll have to discuss the terms of use in more detail.
I had thought to do a simple NDA, but this looks like there might
need to be some consideration.

Also, if you have potential customers, then you need to find
out from *them* what constitutes "compatible".

>   > Really doing a correct job would be quite an undertaking. Be sure
> 
>>to think about things like the half carry bit. Are you going to
>>emulate instructions like WAI and STOP? How about the X bit then?
>>It interacts with these instructions.
> 
>       yeah i have implemented the functionality for the half carry bit but as I told
before
>   I have not implemented DAA instruction so far and not sure of a way to simplify
the logic 
>   for this. I am implementing interrupts as well but the interrupt controller is
going to be outside
>   main controller/alu that I am designing now. So what I have done is make the I and
X bits available as
>  outputs from this module and then have a interrupt avaiable (iavail) input that the
interrupt controller
>  would enable after checking I and X bits and any interrupts and once i accept an
interrupt i make another
>  output iaccept go high to indicate this to inmterrupt controller which clears the
interrupt then.

Well, good luck on finding customers for a two-chip solution
to a problem which already has a one-chip solution.

Are you going to do a STATIC implementation?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Thnaks again for the fast response. I would really appreciate it if you can guide me
on a proper simulator that can format and store cycle-by-cycle or instruction by
instruction register values to a file. Thanks.

> I would use the IDIV instruction.
> As I mentioned, I have written programs to compute a number of mathematical
constants, including PI.
   I understand what you are saying. But I have not implemented IDIV and FDIV as I am not
yet sure of how 
  it is done in hardware. I am sure they dont have a dedicated divide circuitry as it
takes 41 cycles. I am
  guessing that they would use the ALU's adder/subtractor to perform repeated subtraction
every cycle and
  then compute the quotient and remainder but at this point I am not sure how.
	> Well, if you exercise each instruction, then you could run
> the program on an '11 simulator, and capture the states of
> all registers and flags after each instruction, and convert
> that to a file which your Verilog emulator can use to compare.
   Yeah this is exactly what I was hoping to do. But the simulator I have
  cannot do this. Do you have a suggestion for a simulator that can do this.
  I tried to putchase THRsim from motorola but they said they dont support 68Hc11
  anymore and asked me to switch to 68HC12???
	> Well, I'm not sure "give" is the appropriate term. Programs
> used to test/verify proper operation of new hardware have
> a commercial value. Let's say we can work out an arrangement
> which won't cost you anything.Send me some private e-mail.
  Well I am sure this has a commercial value. But what I am trying is 
  at the student project level and I am going to post this as opensource.
  Also I am hoping to get a fabrication run for free through the university 
  from MOSIS to test it but that is how much commercical this is going to be.
  So I am not sure what I ahve to do for this. Please let me know.
	> What technique do you use to convert Dhrystone to machine code?
   I used the GCC cross-compiler for 6811 to generate the code. I tried to look 
  for options that would help me filter code but could not find one.
	> It's your project, you define "compatible". I'm sure that there
> are, somewhere in the world, some people who verify the cycle-
> by-cycle operation of some program somewhere. I have no idea
> who they might be.
    I now realize that I have to make this decision now rather than postponing]
  till the end. I am planning to implement only functionality and not cycle timing.
  What I was trying to ask was would there be many people interested in cycle timing
  in which developing a cycle by cycle emulation would be good. But if not  many people 
  are going to use then it is not worth the effort.
	> Hey, wait a minute. If there actually are commercial considerations
> here, then we'll have to discuss the terms of use in more detail.
> I had thought to do a simple NDA, but this looks like there might
> need to be some consideration.

> Also, if you have potential customers, then you need to find
> out from *them* what constitutes "compatible".
   well as I mentioned before this is going to be a opencore and not commercial
  and hence I dont have any potential customers all I have is lots of prospective
  beta testers who test the code improve it and give me suggestions!!!
	> Well, good luck on finding customers for a two-chip solution
> to a problem which already has a one-chip solution.
   No this wont be a two chip solution in the final stage. right now I have seperated
them into two
  seperate modules for ease of programmability. Then finally I can integrate both the
modules into one.
  and I am not interested in any customers anyway.

> Are you going to do a STATIC implementation?
     Yes as of now what I am planning to get it done in a static implementation.My target
is to get it working from
  DC to 2MHz. If you have any details on how hard it might be to achieve this or increase
the frequency beyond could   you please throw some light into it. Thanks.
   
Sincerely,
S.Ranganathan
	---------------------------------
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!

[Non-text portions of this message have been removed]
	

Ranganathan Sridharan wrote:
> Thnaks again for the fast response. I would really appreciate it if
you can guide me on a proper simulator that can format and store
cycle-by-cycle or instruction by instruction register values to a file.
Thanks.

The 68hc11 is a pretty good simulator for itself. Logic analyzers
can often capture cycle by cycle operation.

>>I would use the IDIV instruction.
>>As I mentioned, I have written programs to compute a number of mathematical
constants, including PI.
> 
>    I understand what you are saying. But I have not implemented IDIV and FDIV as I
am not yet sure of how 
>   it is done in hardware. I am sure they dont have a dedicated divide circuitry as
it takes 41 cycles. I am

I don't know the details of the '11, but there are two general
ways: restoring and non-restoring.

>   guessing that they would use the ALU's adder/subtractor to perform repeated
subtraction every cycle and
>   then compute the quotient and remainder but at this point I am not sure how.

Shift and add/subtract.

>>Well, if you exercise each instruction, then you could run
>>the program on an '11 simulator, and capture the states of
>>all registers and flags after each instruction, and convert
>>that to a file which your Verilog emulator can use to compare.
> 
>    Yeah this is exactly what I was hoping to do. But the simulator I have

One problem with this is you exhaustive testing takes
a lot of time. There are many cases to consider. Consider
IDIV. It takes two inputs, each 16 bits. So to test all
cases would take investigating 2^32 cases. The program
would have to look like this...

	ldd	#0	3 x 1
	std	Num1	4 x 1
	std	Num2	4 x 1
Loop:
	ldd	Num1	4 x 2^32
	ldx	Num2	4 x 2^32
	idiv	       41 x 2^32
	ldx	Num2	4 x 2^32
	inx		3 x 2^32
	stx	Num2	4 x 2^32
	  bne	Loop	3 x 2^32
	ldx	Num1	4 x 2^16
	inx		3 x 2^16
	stx	Num1	4 x 2^16
	  bne	Loop	3 x 2^16
	bra	*	3 x oo

Even if you use direct addressing this takes 2.6x10^11
cycles, or at 2MHz that's 1d13h34m52s. FDIV takes just
as long. Other instructions will take more or less the
same amount of time, due to having multiple address modes.
So just running the test program on rough count of 53
instructions which have multiple address modes gives
a run time of about 6 weeks continuous operation.
Do you have an UPS?

Of course, you'll find some errors, and have to run
some of the tests multiple times.

>   cannot do this. Do you have a suggestion for a simulator that can do this.
>   I tried to putchase THRsim from motorola but they said they dont support 68Hc11
>   anymore and asked me to switch to 68HC12???

You might investigate Wookie over at the UTA. You might be able
to get source and modify it. At least have a conversation or
two with the author.

>>Well, I'm not sure "give" is the appropriate term. Programs
>>used to test/verify proper operation of new hardware have
>>a commercial value. Let's say we can work out an arrangement
>>which won't cost you anything.Send me some private e-mail.
> 
>   Well I am sure this has a commercial value. But what I am trying is 
>   at the student project level and I am going to post this as opensource.

Do you mean "public domain"? Or what? What is "opensource",
precisely?
GPL? I'd prefer not to contribute to a GPL project.

>   Also I am hoping to get a fabrication run for free through the university 
>   from MOSIS to test it but that is how much commercical this is going to be.
>   So I am not sure what I ahve to do for this. Please let me know.

Shoot me a private e-mail. This is off-topic for the mail echo.

>>What technique do you use to convert Dhrystone to machine code?
> 
>    I used the GCC cross-compiler for 6811 to generate the code. I tried to look 
>   for options that would help me filter code but could not find one.

One thing to consider, however you do this, is that compilers
use a limited repertoire of instructions. It's likely, for
example, that your compiler never used ldaa with the extended
addressing mode. You could check the assembly output, but I trow
it did not. Probably with direct, when multiplying two virtual
registers, and possibly with indirect indexed through X, though
possibly not through Y.

>>It's your project, you define "compatible". I'm sure that there
>>are, somewhere in the world, some people who verify the cycle-
>>by-cycle operation of some program somewhere. I have no idea
>>who they might be.
> 
>     I now realize that I have to make this decision now rather than postponing]
>   till the end. I am planning to implement only functionality and not cycle timing.

You need to spend the greatest amount of time on getting good
requirements. Requirements must be

	correct
	complete
	unambiguous
	testable
	achievable by at least one design, prferably by multiple

You must get your requirements close to finished before beginning
design. Requirements should take longer to get done than the design
does.

>   What I was trying to ask was would there be many people interested in cycle timing
>   in which developing a cycle by cycle emulation would be good. But if not  many
people 
>   are going to use then it is not worth the effort.

I wonder how many people are interested.

[snip]

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

--- In m68HC11@m68H..., Ranganathan Sridharan
<rangansmail@...> wrote:

> I understand what you are saying. But I have not implemented IDIV
> and FDIV as I am not yet sure of how it is done in hardware. I am
> sure they dont have a dedicated divide circuitry as it takes 41
> cycles. I am guessing that they would use the ALU's adder /
> subtractor to perform repeated subtraction every cycle and then
> compute the quotient and remainder but at this point I am not sure
> how.

The mechanisim that the HC11 (and many other microprocessors) use to
perform multi-cycle division is not much different than the
long-division method you learned way-back-when.  Simple successive
subtraction would be very, very SLOW in some cases; imagine if you
were dividing $FFFF / $0001 - it would take 65535 iterations to
calculate the quotient!

Below is a verbatim copy of the header comment block for a software 16
bit / 8 bit divide routine I wrote (in assembly language) for the
STMicro ST7-series microcontroller.

;************************************************************************************
;Name:      DIV168
;Function:  Unsigned integer division, 16 bits / 8 bits
;
;	Y,X <-> 16-bit dividend, returns with quotient (Y=MSB)
;	A   <-> 8-bit divisor, returns with remainder
;	CF  <-  SET if attempt to divide by 0
;
;Notes:	This routine performs a bitwise unsigned division of (Y,X) by (A).
;	The procedure used is:
;
;	1). Set remainder = 0
;	2). Left shift out next MSbit from dividend
;	    (this step also shifts a 0 into the LSbit of quotient)
;	3). Left shift into the LSbit of the remainder the dividend
;	    MSbit shifted out in step (2) above.
;	4). Attempt to subtract the divisor from the remainder
;	    (e.g. calculate 'temporary' remainder)
;	5). If the subtraction above generated a borrow:
;	      Discard temporary remainder (retain original rem.)
;	      Set LSbit of quotient to 0 (done implicity in step 2)
;	    Otherwise:
;	      Set remainder to value calculated in step (4)
;	      Set LSbit of quotient to 1
;	6). Repeat steps 2 through 5 for 16 bits.
;
;	All local variables and intermediate results are saved on the stack.
;	This routine is fully re-entrant.
;
;Stack use:	4 bytes + CALL overhead (2 bytes)
;Destroyed:	Nothing (all registers used to pass back results)
;************************************************************************************

Further notes:

Step 2 states that the left shift of the dividend also shifts a 0 into
the LSbit of the quotient.  This is the case because I use the (Y,X)
register pair to store both the dividend AND the quotient.  Both
dividend and quotient are utilized/resolved on a bit-by-bit basis;
they are never used in their entirety during any given iteration of
the division routine.  Given this, a single 16-bit register (or two
8-bit registers, in this specific case) can be used to store both the
ever-shrinking dividend and ever-growing quotient at the same time. 
This "trick" makes the routine efficient both computationally and in
terms of memory/stack utilization.

If you think back to how you go about performing base-10 long
division, you will come to the realization that the algorithim
discussed here is much the same thing, only the number base is base-2
instead of base-10.

The algorithim cited above works just as well for larger numbers (e.g.
16 or 32 bit dividends/quotients and/or divisors); the only difference
is the bit-width of the subtractor (= bit width of dividend and
divisor) and the number of iterations required to complete the
division (= bit width of dividend).  The bit-width of the quotient is
equal to that of the dividend, and the bit-width of the remainder is
equal to that of the divisor.

I would think that such an algorithim could be incorporated into a
VHDL or Verilog design without undue difficulty.

If you would like to see the (well-commented assembly language) source
code for my division routine, send me a private e-mail.  Be warned
that it is written for the ST7 microcontroller, which has a different
instruction set from the HC11.  However, the ST7 is similar enough to
the HC11 (it is in-between the HC05 and HC11 in capability, in my
estimation) that you should be able to follow it, esp. since the code
in question is quite thoroughly commented.

I would have to give a bit of thought as to how to implement FDIV; I
suspect that the basic algorithim would be the same as discussed
above, with minor variations.

At the risk of straying off-topic, I would appreciate your opinions on
where one might find good educational resources for learning VHDL
and/or Verilog, esp. with regards to the sub-set of these languages
that is actually sythesizable.
	

--- In m68HC11@m68H..., Ranganathan Sridharan
<rangansmail@...> wrote:

> Thnaks again for the fast response. I would really appreciate it if
> you can guide me on a proper simulator that can format and store
> cycle-by-cycle or instruction by instruction register values
> to a file
> ...

In the HC11 Reference Manual, in the section that discusses the
instruction set in detail, you will find at least some of the
information you are looking for.  There is usually a table at the end
of each instruction that shows what the bus activity would look like
on a (CPU/EClock) cycle-by-cycle basis for each instruction and
variant - address, data and R/W state.

You might also consider using a actual HC11 device with its address,
data and bus control signals connected to a logic analyzer, assuming
you have such equipment available to you.  One of the nice things
about the HC11 is that it is (almost) a fully static design; you may
run the clock at any rate from DC to the maximum rating of the device
(usually 8 MHz) so you can watch the external bus activity at a "human
perceivable" rate.  About the only thing that will not work reliably
at very low clock speeds is the A/D converter, and even this can be
worked around if you configure the ADC to use the internal R/C
oscillator.  You will also want to disable the clock monitor function
if you happen to be using it.  It is disabled by default, so this
should not pose a problem unless you explicitly enable it.

Of course, neither of these approaches will show you what is happening
inside the device, the various transfers of data between internal
registers, holding latches and such.  Nonetheless, the information
that is available in the reference manual (or by examination of the
external bus) should still prove useful.