View unanswered posts | View active topics It is currently Thu Mar 28, 2024 11:59 am



Reply to topic  [ 102 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
 rf68000 - 68k similar core 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Another project has been started that’s based around the 68k’s instruction set. It’s hoped to be able to use slightly modified tools for the 68k. The instruction set is almost identical, but the core’s little endian rather than big endian. It also supports high-speed task switching and vectoring to tasks rather than jumping to interrupt processing routines. One of the issues with the 68k is it’s slow task switch / interrupt response time. This core makes it fast taking only a handful of clock cycles to switch tasks.
It’s estimated to run up to about 85MHz in an -1 Artix7 FPGA. It also typically uses fewer clock cycles than the 68k in order to execute instructions. The core is a hard-coded state machine and not micro-coded.
http://github.com/robfinch/Cores/blob/master/FT68000/trunk/rtl/verilog/FT68000.v

_________________
Robert Finch http://www.finitron.ca


Last edited by robfinch on Sun Jan 15, 2023 3:54 pm, edited 1 time in total.



Tue Jan 31, 2017 11:44 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
A little-endian 68K?!! I love it!! :D So much more sensible.

_________________
http://LaughtonElectronics.com


Tue Jan 31, 2017 2:34 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Wow - a CISC! That's going to be a lot of work, surely?


Tue Jan 31, 2017 4:19 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
2017/01/31
Yes, a lot (maybe too much) work. But if it can be made to work well enough for it’s intended purpose then that’s okay. It has to be able to move 32 bit values around to memory mapped I/O. FT68000 has a simpler to debug non-overlapped pipeline, but the instruction decode is a lot more complex than a RISC machine.

It was shelved in the past for fear of the amount of effort to validate everything. It was first coded about 2008, so it’s a project that’s been resurrected. The hope is that existing tools for the 68k can be used to validate and make use of the core.

A 32 bit processor (32 bit data bus) with a Windows based toolset available was desired. I’d like to put together a music machine with multiple cores (MCMM – multi-core music machine) and sound generators for each core. A couple of 32 bit machines were reviewed which were on the order of 3,000 LUTs. The larger project may end up using something like RISC-V cores or DSD7. But for now using the FT68000 is being explored.

The biggest issue is getting software for the core to work. A 68k ‘C’ compiler that outputs assembler code should work.

_________________
Robert Finch http://www.finitron.ca


Tue Jan 31, 2017 7:33 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Certainly sounds interesting! Having a validation suite would be a big help.


Tue Jan 31, 2017 7:38 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
robfinch wrote:
The hope is that existing tools for the 68k can be used to validate and make use of the core. [...] A 68k ‘C’ compiler that outputs assembler code should work.

So, if you supply your own assembler then you're OK. But besides the compiler are there other tools you could adapt to your purpose?

BTW have you considered targeting the Coldfire (68K subset) instruction set instead? Betcha it'd save you a lot of work, and have minimal downside.
https://en.wikipedia.org/wiki/Freescale_ColdFire

_________________
http://LaughtonElectronics.com


Wed Feb 01, 2017 2:01 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
BTW have you considered targeting the Coldfire (68K subset) instruction set instead? Betcha it'd save you a lot of work, and have minimal downside.
https://en.wikipedia.org/wiki/Freescale_ColdFire


I probably will end up working with a subset of the core's capabilities which would probably happen to be something like the ColdFire core. It's NXP's Coldfire now.
It's a good idea, but I wrote the core already to support the full instruction set.
It's too bad one can't purchase IP cores for single use like one can purchase chips.

2017/02/01

A 68k assembler was modified to work with FT68k. A eight core system was setup with an on chip network.
The following test program has virtually no chance of working. It turns on the LEDs onboard. Complicated by the fact the core is working through a network controller.
Anyway I'm going to try it as a first test.

Code:
NOCC       EQU       0xFFD80000
NOCC_PKTLO     EQU       0x00
NOCC_PKTMID    EQU       0x04
NOCC_PKTHI     EQU       0x08
NOCC_TXPULSE   EQU       0x18
NOCC_STAT      EQU       0x1C

   code
   org      0xFFFC0000
cold_start:
   move.l   #0x3FFC,A7      ; setup stack pointer
   move.l   #0x0000001F,d2   ; select write cycle to main system
   move.l   #0xFFDC0600,d1   ; LEDs address
   moveq.l   #127,d0                   ; LEDs data
   jsr      xmitPacket
cs1:
   bra.s   cs1

;---------------------------------------------------------------------------
;---------------------------------------------------------------------------

xmitPacket:
   move.l      d7,-(a7)
   move.l      a0,-(a7)
  ; first wait until the transmitter isn't busy
   move.l      #NOCC,a0
xmtP1:
   move.l      NOCC_STAT,d7
   and.w      #0x8000,d7   ; bit 15 is xmit status
   bne.s      xmtP1
   ; Now transmit packet
   move.l      NOCC_PKTHI(a0),d2   ; set high order packet word (control)
   move.l      NOCC_PKTMID(a0),d1   ; set middle packet word (address)
   move.l      NOCC_PKTLO(a0),d0   ; and set low order packet word (data)
   clr.l      NOCC_TXPULSE(a0)   ; and send the packet
   move.l      (a7)+,a0
   move.l      (a7)+,d7
   rts

_________________
Robert Finch http://www.finitron.ca


Thu Feb 02, 2017 7:08 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
2017/02/03
Well it didn’t work at all. So I’ve decided to use the DSD core instead, something that’s at least partially working.

_________________
Robert Finch http://www.finitron.ca


Sun Feb 05, 2017 12:47 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
This project is going again as it's being used to test the audio/video controller core. A version with a 16 bit data bus was created to be compatible with the test system. It boots up displays a couple of led statuses (that's further than it got before) and hangs when it goes to return from a subroutine. The strange thing is the 68k core hangs in the same spot. Two processors with slightly different object code both hang in the same spot. Makes me think it's a system problem not a processor problem.

_________________
Robert Finch http://www.finitron.ca


Wed Dec 13, 2017 11:23 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I started taking another look at this core after realizing how well the 68k compares to other architectures; this core being really just a variant of the 68k.

Been doing some reading on comp.arch and it seems that the 68k has some advantages over other architectures in performance, power consumption and code size. Including comparisons to RISC processors like ARM, or the INTEL cores. Given charts that people present it’s a wonder that there aren’t more 68k systems; the 68k seems to compare fairly well to other processing cores.

Compared to FT68k core the FT64 core is an ideal compiler target. FT68k is not as easy a machine to develop a reasonable compiler for. But FT68k is probably hard to beat for assembler language level programs.

So onward I work.

_________________
Robert Finch http://www.finitron.ca


Mon Jun 04, 2018 1:40 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Deliberating whether or not to modify all the bus access code that looks like this:
Code:
IFETCH:
   if (!cyc_o) begin
      < ... start bus cycle ... >
   end
   else if (ack_i) begin
      < ... term. bus cycle ... >
      state <= DECODE;
   end

To be like this:
Code:
IFETCH:
   if (!cyc_o) begin
      if (!ack_i) begin
         < ... start bus cycle ... >
      end
   end
   else if (ack_i) begin
      < ... term. bus cycle ... >
      state <= DECODE;
   end

The benefit is higher reliability because one bus cycle is guarenteed to be over before the next
one will start. The drawback is that it's code bloat and takes more hardware. It should not really
be neccessary to wait for !ack_i because ack_i is supposed to automatically go away at the end of
a bus cycle. In the case of the current system that's within one clock cycle. Higher reliability
comes from the fact that if the ack_i misses timing by a clock cycle the next bus cycle won't start.

Most of the WISHBONE cores I've seen don't bother with this sort of thing and just assume ack_i will be negated after a clock cycle.

_________________
Robert Finch http://www.finitron.ca


Mon Jun 04, 2018 4:27 am
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
That's similar to I²C where you might want to make sure the clock line is up before pulling it down again. If it's still down, it could be because of bus capacitance not being charged up yet by the pullup resistor, or by a device asking for more time by holding the clock line down. I've never implemented that overhead though. I know Samuel Falvo liked four-phase bus transactions.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Mon Jun 04, 2018 8:38 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Opcodes 4E7B to 4E7F were used up to add CSR read / write instructions. Most processors have configuration and status registers and instructions for manipulating them. The 68k only operates on the status register. CSR instructions are needed by FT68000. Currently only the tick and task registers are supported, but the instruction format allows for up to 1024 CSR registers.

While the 68k has dual stack pointers (one for each of user mode and supervisor mode) the FT68k doesn’t. It has only a single stack pointer. The reason being that an FT68k requiring multiple privilege levels will use multiple processor cores to implement them. Each core has a complete set of registers.

I’m pondering the use of hardware mailboxes and messaging to pass arguments to the operating system or device drivers.

_________________
Robert Finch http://www.finitron.ca


Fri Jun 08, 2018 10:29 pm
Profile WWW

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 213
Location: Huntsville, AL
I like the idea of mailboxes / message passing. I have used those concepts in a number of systems I've built in the past, and the concepts have helped avoid many shared memory access faults that may have been a concern otherwise. I thought a variation on your NOC ideas would be particularly applicable to a multi-processor like what you appear to be working toward.

_________________
Michael A.


Sat Jun 09, 2018 4:26 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Just looking at the OS message structure the messages are small enough that a wide circular buffer could be used to store message info.
Each message element could be loaded into a latch, then all the latches loaded in a single clock cycle to the circular buffer.
The buffer would have an eight-to-one mux on it to be able to load from up to eight different cores.
Using a single cycle load means not having to worry about locking access to the mailbox for multiple clock cycles. I suppose a diagram would be helpful.
I want to avoid putting the mailbox on a shared memory or network bus, hence input eight ports to the mailbox. The mailbox needs only a single output port to the core servicing the mailbox. The idea is the mailbox looks like a simple peripheral.


It'll be a lot of wires and interconnect to implement eight mailboxes, one for each core.

Code:
typedef struct tagMSG{
   unsigned __int16 link;
   unsigned __int16 retadr;    // return address
   unsigned __int16 tgtadr;    // target address
   unsigned __int16 type;
   unsigned int d1;            // payload data 1
   unsigned int d2;            // payload data 2
   unsigned int d3;            // payload data 3
} MSG;

_________________
Robert Finch http://www.finitron.ca


Sun Jun 10, 2018 2:12 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 102 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next

Who is online

Users browsing this forum: Applebot and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software