Home   News   Concept   AMIGA-Compatible   Hardware   Forum   Questions+Answers   Pictures   Contact & Team

Welcome to the Natami / Amiga Forum

This forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.



All TopicsNewsQAFeaturesTalkTEAMLogin to post    Create account
Do you have questions about the Natami?
Post it here and we will answer it!

FC2-FC0 Function Codes In MC68000page  1 2 
Ganesh Bawaskar

Posts 20
09 Mar 2011 07:24

How 68k geneates FC2-FC0 function codes?
means how 68k knows it is accessing user/supervisor data/program once it gets intsruvtion to execute?

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 08:40

Ganesh Bawaskar wrote:

How 68k geneates FC2-FC0 function codes?
  means how 68k knows it is accessing user/supervisor data/program once it gets intsruvtion to execute?

It knows it because it knows the state it is in (supervisor or user state) and the data it currently fetches (data or instruction), or - in addition - if it acknowledges an interrupt.

Thus, all the information lies in the state of the CPU and is available to the CPU core.

The function codes are available on external pins of the 68K family member (and, in case of the 68020 and 68030, are also used to index the cache).

Greetings,
Thomas
 

Ganesh Bawaskar

Posts 20
09 Mar 2011 08:48

We are not telling 68k like my user program/data is starting from so and so address and supervisory program/data from so and so address. It only fetches instruction opcode/operand and from instruction opcode/operand how it decides whether the instruction is in user/supervisor program/data?

Regards,
Ganesh

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 09:07

Ganesh Bawaskar wrote:

We are not telling 68k like my user program/data is starting from so and so address and supervisory program/data from so and so address. It only fetches instruction opcode/operand and from instruction opcode/operand how it decides whether the instruction is in user/supervisor program/data?

I don't get your question, or rather, I provided already an answer.

move.l Data,d0

This causes:

a) a user space instruction fetch if this is part of a user program, namely to fetch the move instruction,

b) a user space data fetch from the indicated address.

If this program is, however, running from supervisor space,

a) a supervisor instruction fetch to fetch the move instruction and the address - and -
b) a supervisor data fetch to read from the address.

Did that help?



Ganesh Bawaskar

Posts 20
09 Mar 2011 09:13

Yes thanks.

one more query. How 68k differentiates between data fetch and instruction fetch? I mean how it knows whatever it has fetched is it a instruction/data?

Regards,
Ganesh

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 10:06

Ganesh Bawaskar wrote:

Yes thanks.
 
  one more query. How 68k differentiates between data fetch and instruction fetch? I mean how it knows whatever it has fetched is it a instruction/data?

How? Heck, because it's the CPU, that's why. (-: Of course the CPU knows what it needs the data for. If you go to the store next block to buy a bottle of milk, you also know what you need the milk for, don't you? (-;

Greetings,
Thomas



Ganesh Bawaskar

Posts 20
09 Mar 2011 10:37

I am designing MC68000 soft core in VHDL. And i need to generate FC2-FC0 signals for bus cycles.

And i want to implement the same logic the mc68000 has to check whatever it has fetched its a data/instruction.

i think when 68k fetches the instruction, from L/W/B it knows how many operands are following after this and after that i will get the instruction again. so the remaining operands it consider as data. correct me if i am wrong?

Regards,
Ganesh

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 11:30

Ganesh Bawaskar wrote:

  And i want to implement the same logic the mc68000 has to check whatever it has fetched its a data/instruction.
 
  i think when 68k fetches the instruction, from L/W/B it knows how many operands are following after this and after that i will get the instruction again. so the remaining operands it consider as data. correct me if i am wrong?
 

  So you want the definition of an instruction cycle, right? No, the complete instruction, with all the extension words, is apparently loaded with the function codes for instruction memory access (remember, these could be separate memory spaces!). That is, also the immediate extension word containing the data, the extension word for indirect addressing, etc, are all loaded into the CPU via the instruction function code.
 
  The difference starts when the instruction includes an address, and data should be loaded into the CPU via this address, i.e. memory indirect modes (Ax), d(Ax), d(Ax,Rx), (ax)+, -(ax) are data fetches.
 
  Likewise, while I don't know it, but I would believe that addressing modes d(PC) and d(PC,Rx) will also generate instruction(!) type memory fetches because this is data relative to the PC and hence relative to the program.
 
  This is the difference why d(PC) and d(PC,rX) instructions are only available for read-access, i.e. there is add d(PC),rx, but no add rx,d(PC) - it is instruction memory space, and not data memory space, and the Havard architecture disallows programs modifying its code. (There is a design principle behind all this).
 
  Just consider your program as consisting of two "hunks": A code hunk, which is only and completely reachable in the instruction memory space, and the data hunk, which is only reachable in the data address space. A hardware architecture using separate instruction and data memory (and hence uses the function codes) would be able to place the code hunk in code memory, the data hunk in data memory, and the program would run.
 
  HTHH,
 
  Thomas
 

Ganesh Bawaskar

Posts 20
09 Mar 2011 12:29

then what about the previlaged instructions like move to SR?
because without exception, 68k cannt enter into supervisor mode. and this instruction produces a PRIVILEGE VIOLATION EXCEPTION and
As we have not written any ISR for this vector number then how processor switches to supervisor mode?

Regards,
Ganesh

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 12:50

Ganesh Bawaskar wrote:

  then what about the previlaged instructions like move to SR?
 

  So what about it? The instruction is of course read like any other instruction. User mode instruction access. What else?
 
 
Ganesh Bawaskar wrote:

  because without exception, 68k cannt enter into supervisor mode.
 

  And your point is....?
 
 
Ganesh Bawaskar wrote:

  and this instruction produces a PRIVILEGE VIOLATION EXCEPTION
 

  yes, and? The exception, like any other exception, pulls the exception vector in the supervisor data function class, and then continues in the supervisor instruction mode to pull instructions.
 
 
 
Ganesh Bawaskar wrote:

  and
  As we have not written any ISR for this vector number then how processor switches to supervisor mode?
 

  Huh? The Os has written the ISR for this vector number, apparently, so where is the problem? You can write and read from other function code memory, this is the purpose of the SFC and DFC registers, and the moves instruction. For good reasons, it is privileged.
 
  That is, on init, the CPU pulls the reset vector (ROM, supervisor data space), starts execution (ROM, supervisor instruction space)
  initializes the interrupt table (supervisor data space), loads data (ROM, supervisor instruction and data space) copies it into the user instruction and data space (moves, or DMA) and starts executing user programs by dropping the supervisor state. Hence, were is the problem?
 
  No problem.
 
  So long,
  Thomas
 

Ganesh Bawaskar

Posts 20
09 Mar 2011 13:26

If os has written the ISR for this exception then what is the ISR starting address?

Because what i think is
once 68k gets an exception it generates vector offset by multiplying vector number by 4. Its our duty to provide ISR routine address there (long word at vector offset)

and for which exceptions we have to write the exception routine and for other what are the ISR starting addressees?

Regards,
Ganesh

Jakob Eriksson
Sweden
(Moderator)
Posts 1097
09 Mar 2011 13:31

Genesh, you can probably also get good answers about MC68000 programming in general on EXTERNAL LINK 

Thomas Richter
Germany
(MX-Board Owner)
Posts 1425
09 Mar 2011 13:45

Ganesh Bawaskar wrote:

  If os has written the ISR for this exception then what is the ISR starting address?
 

  I don't get your question. The start address of the ISR is whatever is in the interrupt vector base, and that is also defined by the Os.
 
 
Ganesh Bawaskar wrote:

  once 68k gets an exception it generates vector offset by multiplying vector number by 4.
 

  Interrupt vector * 4 + vector base register = an address in the supervisor data memory from where the interrupt vector is fetched. This address is a supervisor instruction memory address, which is loaded into the PC, after the PC, the exception stack frame and the status register have been pushed onto the supervisor stack, which resides in supervisor data memory.
 
  Sorry, I neither understand your problem, nor do I get your question.
 
 

Ganesh Bawaskar

Posts 20
10 Mar 2011 04:43

I think OS has provided only the interrupts for unusual conditions like PRIVILEGE VIOLATION, DIVIDE BY ZERO, BUS ERROR etc. When such interrupts occur processor goes to the supervisory data memory    (  Interrupt vector * 4 + vector base register = an address in the supervisor data memory). where we put the address of the ISR which tells the processor what is to be done if such interrrupts occur.

Let us consider a case, DIVIDE BY ZERO exception/interrupt occur, and processor goes to the 14H location (for 68K) where put the starting address of ISR as 00070020H. So it jumps to memory location 00070020H and start executing the instructions from here till it finds RTE instruction to return from the ISR. So we can write any instructions starting from 00070020H.

so do you got my point what i mean to say?
Processor doesnt have ISRs for any of the exceptions. Its our duty to put the starting address of the ISR and write the ISR to tell the processor what is to be done if such interrupt/exception occurs.

please correct me if i am getting wrong

Gunnar von Boehn
Germany
(Moderator)
Posts 5775
10 Mar 2011 06:49

Ganesh Bawaskar wrote:

  I am designing MC68000 soft core in VHDL.
 

 
  Why are you desining an 68K?
 
 
 
Ganesh Bawaskar wrote:

  And i need to generate FC2-FC0 signals for bus cycles.
 

For a normal system you would not need those.
As all 68K Computers that I know use a single address space - which means these signals are ignored.
 
 
 
Ganesh Bawaskar wrote:

  I think when 68k fetches the instruction, from L/W/B it knows how many operands are following after this and after that i will get the instruction again. so the remaining operands it consider as data. correct me if i am wrong?
 

  This is wrong.
 
  Your 68K pipeline looks like this:
 
  1) Instruction fetch  *
  2) Instruction decode
  3) EA Calculation
  4) Data Fetch *
  5) ALU
  6) Data Writeback *
 
  Stage 1,4,and 6 can do memory access.
  Stage 1 will always use the PC as address for the memory access.
  Stage 1 will NEVER do memory access on a Odd,Byte address.
  Stage 1 are Instructions fetches.
  Stage 1 will always read.
 
 
  Stage 3 will calculate an EA.
  Stage 4 and 6 will always do Data-Access.
  Stage 4 and 6 will always use the Calculated EA for Memory Access.
  Stage 4 will read, Stage 6 will write.
 
 
 
  If you do an exception.
  Then your CPU will jump into some internal Microcode which will basically do this:

MOVE.L SR,SR2 -- Copy
BSET SuperVisorMode,Sr
BCLR TraceMde,Sr
MOVE.L SR2,-(SSP)  -- SAVE SR old without Superbit on SupervirorStack
MOVE.L (VBR + ExceptionNo*4),PC

The Saving of the SR2 is done in stage 6.
Data move.
 
The load from the Vector is a data Fetch as its done in stage 4!
The instruction load of the first instruction done from the Vector Address is done in Stage 1 - Which means its of course an Instruction-Fetch.
 
The memory access done by the exception Microcode routine are all done after turning the Supervisorbit ON in the SR.
This means all access from then on are Supervisor accesses.

Normal 68k Computer Systems do implement 1 flat memory area.
This means the FC0-FC2 are ignored in ATARI/AMIGA/APPLE ...
and all memory access go to the same memory space.

Does this help?
 
Cheers

Ganesh Bawaskar

Posts 20
10 Mar 2011 07:01

Thats really nice explanation.
please can you explan what are the function codes that will be out by 68k during each stage of pipeline

means
1) Instruction fetch  *  FC2-FC0=?
2) Instruction decode    FC2-FC0=?
3) EA Calculation        FC2-FC0=?
4) Data Fetch *          FC2-FC0=?
5) ALU                    FC2-FC0=?
6) Data Writeback *      FC2-FC0=?

Regards,
Ganesh



Gunnar von Boehn
Germany
(Moderator)
Posts 5775
10 Mar 2011 07:10

Ganesh Bawaskar wrote:

  Thats really nice explanation.
    please can you explan what are the function codes that will be out by 68k during each stage of pipeline
   
    means
  

    1) Instruction fetch  *   FC2-FC0=?
    2) Instruction decode     FC2-FC0=?
    3) EA Calculation         FC2-FC0=?
    4) Data Fetch *           FC2-FC0=?
    5) ALU                    FC2-FC0=?
    6) Data Writeback *       FC2-FC0=?
 

    Regards,
    Ganesh
 

Stages 2,3,5 do not do memory access.
Only Stage 1,4,6 can do an access.

You can implement an 68K CPU as stage machine looping through those stages - Or you can pipeline your code.

  

 
              FC0   FC1    Instruction    Read 
   Stage 1:   0     1      1              1
   Stage 4:   *     *      0              1
   Stage 6:   1     0      0              0
 

 
  FC2 is set as your SupervisorBit in SR.
 
Please mind that Stage 4 can do two types of access!
  Access to all normal EA : FC1=1/FC0=0
  Access to PC-Relative  : FC1=0/FC0=1
 
Our new 68050 Core can also do two types of access in Stage 6,
but this is new. All previous 68K could not do this.

Gunnar von Boehn
Germany
(Moderator)
Posts 5775
10 Mar 2011 07:26

Why are you doing an 68K?
Is this a retro project or some study work?

Ganesh Bawaskar

Posts 20
10 Mar 2011 08:07

basically its a product continuation project. Earlier boards use 68k, so without affecting the F/W we have to redesign the entire board.

So we decided to implement the 68k VHDL softcore for this.

Gunnar von Boehn
Germany
(Moderator)
Posts 5775
10 Mar 2011 08:12

Ganesh Bawaskar wrote:

basically its a product continuation project. Earlier boards use 68k, so without affecting the F/W we have to redesign the entire board.
 
  So we decided to implement the 68k VHDL softcore for this.

I see.
Do you know that several people have developed 68K VHDL cores already?

We here have developed our own 68-Core also.
Our focus is getting the 68K as fast and good performing as possible.

posts 36page  1 2