View unanswered posts | View active topics It is currently Fri Mar 29, 2024 6:46 am



Reply to topic  [ 66 posts ]  Go to page 1, 2, 3, 4, 5  Next
 Started 6809 core 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Works been started on a 6809 core, hopefully I can create a souped up version with more regs/wider addressing that's backwards compatible.
I'm keeping a repo on GitHub. It's lookig to be around 3,000 lines of verilog.

I' wonder if I can make a pmod with a real 6809 on it for comparison purposes. The pmod would have have to connect the 6809 to an FPGA with a minimum number of I/O's. So I was thinking of trying some sort of serial interface. All the 6809 signals would be serialized to and from the FPGA. It's only a 1MHz part that I've got, so if I run the serial interface at 50 MHz. I should be able to capture all the pins.
I have to interface it to the FPGA with 8 pins or less. Any advice ?

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


Thu Oct 24, 2013 7:57 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Attached is a rough schematic of what I'm thinking.

The 6809 is surrounded by 74hct299 shift registers. The shift registers controls signals come from a 74hct259 bit addressable latch.
Another '259 drives some of the inputs to the 6809.
This requires about 7 pins to control from the FPGA.

Attachment:
sch6809pmod.jpg
sch6809pmod.jpg [ 24.58 KiB | Viewed 9514 times ]

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


Thu Oct 24, 2013 9:32 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
How fast do you think you can clock those shift registers? Can you slow down or stop the clock on the 6809 to help out?


Thu Oct 24, 2013 8:04 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
According to the spec sheet the 6809 can be clocked as slow as 100kHz. I'd likely need a clock about 40 to 50 times as fast as the 6809 is running to shift 32 bits and have some settling time for reads the 6809 makes. Ideally I'd run the clock 40 to 50MHz and clock the 6809 at 1MHz. But the parts may not work that well at 50 MHz I need to check the specs. So I'll start at 5 MHz clocking the 6809 at 100 kHz.

There is only a single readback bit to interface to the FPGA, so I think just a 100 ohm resister (or a couple of diodes) in series might work for level translation. The FPGA should be able to output a high enough level for high signals to the 5V logic. I plan on using 74HCT parts.

This concept could be used with other slower speed micros. (8088 6502 Z80 6800,...)

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


Thu Oct 24, 2013 11:21 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
5MHz and 100kHz sounds like a good combination!
I read something recently to the effect that there are 3 rather different regimes: 1-2MHz is easy, 12-16MHz takes care, and 40MHz plus is really rather difficult.
(It was in the comments to http://slashdot.org/story/13/10/18/2340 ... rdware-dev but I don't necessarily recommend reading them all! It did mention "failure of 40MHz VL-bus. There's a reason why the industry took a step backwards to 33MHz for PCI, and so many budget motherboards had only 2 or 3 slots")
Cheers
Ed


Fri Oct 25, 2013 10:50 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I'm stumped at the moment. I've tried to get the 6809 core working in an FPGA system. It's outputting the previous instruction as an address, rather than the address field of the current instruction. (I dumped it to the LEDs on the FPGA board). The strange thing is that it works fine in simulation and I can't find what's causing the difference.

For the 6809 interface I got rid of the 's259 parts off the schematic as they'd probably be too slow for what I want. It's an eight wire interface with most signals direct to/from the FPGA.
Attachment:
interface6809.gif
interface6809.gif [ 18.76 KiB | Viewed 9475 times ]

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


Wed Oct 30, 2013 6:07 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Quote:
I've tried to get the 6809 core working in an FPGA system. It's outputting the previous instruction as an address, rather than the address field of the current instruction. (I dumped it to the LEDs on the FPGA board).

Any chance the mechanism that dumps the info to the LEDs is faulty? In a perplexing troubleshooting situation, one must remember to mistrust the instrumentation! Just a reminder -- I'm sure you know that already.

Re- your board with the actual 6809E: That '164 shift reg kinda had me puzzled but I guess you're only using 1 of its 8 stages. It accepts QCLK as its serial input and the very first stage's output goes to the CPU "E" input?

Also, I take it this board isn't involved in the present investigation -- instead you're just comparing the simulation of the core with the FPGA rendition...?

-- Jeff

_________________
http://LaughtonElectronics.com


Sat Nov 02, 2013 12:06 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Re- your board with the actual 6809E: That '164 shift reg kinda had me puzzled but I guess you're only using 1 of its 8 stages. It accepts QCLK as its serial input and the very first stage's output goes to the CPU "E" input?


The '164 delays the Q signal by 8 clock cycles (as much as can be done with a single shift register). The CLK signal is a 64x Q clock so E doesn't work out to be 25%(quadrature) delayed (It's only 1/8 12.5% delayed). But it's slow enough that it meets the timing requirements, and should hopefully work with a CLK up to 40MHz. I use the '164 in order to save an I/O pin from the E CLK otherwise I'd need another !/O.

I managed to get the 6809 core working past the LED thing. I still don't know how I did it, but it works now. It's now lighting up LEDs as status indicators. I hope to have the core displaying a message on-screen soon.

'HCT299 parts just arrived today. I bought them off ebay. Now to start wire-wrapping.

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


Sat Nov 02, 2013 2:11 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
It clears the screen ! That indicates large parts of the core are working. Subroutine call/return pushing / popping parameters, branching etc. The guts of clearscreen routine listed below. ScreenLocation holds a 32 bit pointer to the text screen. Far indirect mode works like the 6502 indirect addressing.

Code:
0000F1AA 108E0000                ldy             #0
                      cs1
 0000F1AE 151BEDB90010            std             far [ScreenLocation],y  ; clear the memory (far outer indexed indrect)
 0000F1B4 3122                    leay    2,y                                     ; increment y
 0000F1B6 301F                    leax    -1,x                            ; decrement x
 0000F1B8 26F4                    bne             cs1

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


Sat Nov 02, 2013 3:45 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I got the 6809 core working well enough to run FigForth. I have since started work on a new 6809 core, this time taking a different direction to expanding the memory addressing capabilities of the core. Previously I introduced “far” addressing, using more bytes to form addresses. The new core may be configured to use 12-bit bytes instead. That expands the addressing range to 24-bits or 16MB in a simple fashion. The instruction set is the 6809 instruction set, using the low order 10 bits of a 12-bit byte for instruction opcodes. One difference is in the indexing byte. The indexing byte is expanded by four bits in the middle of the byte. The top and bottom four bits retain the same meaning.

Currently I am working on getting software to work. Planning on using the VBCC compiler system. Until I can get some compiles and assembles going I am limiting the amount of effort put into creating a whole system based around 12-bit bytes. A lot of peripherals would need to be modified to use 12-bits for access.

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


Tue Jan 04, 2022 4:10 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Decided to switch back to using an eight-bit core with far addressing. It was turning out to be challenging to get the compiler to recognize a 12-bit byte.

Spent today setting up for a network-on-chip using the rf6809 core. Mulling over ideas for interconnecting the cpus. I think there will just be a single copy of a small boot rom in the system. The network nodes will copy the boot rom to local memory at startup using network DMA. I want to keep the nodes as simple as possible so they they will likely contain only a RAM and network interface.

Modified the text controller to use an eight-bit bus interface.

Had some success modifying the compiler to recognize ‘far’ addressing. It now accepts the ‘far’ keyword for a function declaration and outputs a far return at the end of the function, but on the function call side I’ve not got it recognizing a far function yet.

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


Wed Jan 05, 2022 4:33 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
robfinch wrote:
It was turning out to be challenging to get the compiler to recognize a 12-bit byte.

That was a bold idea, to try it!


Wed Jan 05, 2022 7:49 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
robfinch wrote:
It was turning out to be challenging to get the compiler to recognize a 12-bit byte.

That was a bold idea, to try it!
Well at least the core can be built for 12-bit operation, but there is no software for it.

Going great guns on this project. Have got it to the point of building a system. The system uses just over half of the LUTs available, but almost all of the block RAM. Spent some time developing the system memory map and making devices eight-bit. Most devices were either 32-bit or 64-bit bus interface.

Nodes are connected in a ring which is 64-bits wide. Packets contain address, data, and command info. The interface is memory address based.

Data is transferred across the network using DMA cycles. The network interface circuit (NIC) has both bus slave and bus master interfaces. The NIC acts like a switch to the memory system. The bus is running at 40MHz. A round trip on the ring takes 18 clock cycles. There are 17 NICs connected in the ring plus one packet ageing circuit.

Attachment:
File comment: rf6809_noc memory map
rf6809_noc Memory Map.png
rf6809_noc Memory Map.png [ 33.36 KiB | Viewed 1014 times ]


Attachments:
File comment: rf6809_noc memory map
rf6809_noc Memory Map.gif
rf6809_noc Memory Map.gif [ 19.12 KiB | Viewed 1036 times ]

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


Last edited by robfinch on Fri Jan 07, 2022 7:02 pm, edited 1 time in total.

Thu Jan 06, 2022 3:12 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Issues, issues, issues. Tonight’s issue is how to handle interrupts. My thought is not to support them directly. Instead have two of the cores continuously polling interrupt status flags. If a core is in a tight polling loop just waiting for the interrupt flag to be set, then interrupt handling will be just as fast as if it were a real interrupt. The next trick is setting the interrupt flag, which will be done by having the interrupt controller act as a bus master and write the interrupt flag into the RAM of the serving node. An issue with this approach is the PIC will flood the network with interrupt writes until one of the cores finally processes the interrupt clearing it.

On start-up all the cores attempt to access the global boot ROM at the same time. Every network slot is occupied with a request for the boot ROM and none of the requests can be satisfied because there are no open network slots in which to return a response.

On the interrupt front I decided to implement a second packet bus just for interrupts. The second bus may be flooded with interrupt requests without affecting the main packet bus. Interrupt signals are decoded and output by the NIC to the CPU. The cpu to respond to the interrupt can be controlled by the priority interrupt controller (PIC).

Helped decrease network congestion by staggering the reset of the cores. Now things are working to the point of outputting a value to the LEDs. At least one core is able to process that far in SIM. Several of the cores appear to be hung however.

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


Fri Jan 07, 2022 4:14 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
A couple of diagrams of the system.
Attachment:
node_ring.png
node_ring.png [ 31.91 KiB | Viewed 1014 times ]

Attachment:
File comment: processing node
pnode.png
pnode.png [ 40.54 KiB | Viewed 1014 times ]

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


Fri Jan 07, 2022 7:04 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 66 posts ]  Go to page 1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 13 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