View unanswered posts | View active topics It is currently Wed Nov 21, 2018 12:55 pm



Reply to topic  [ 342 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23
 Thor Core / FT64 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Quote:
Oh, I'd leave that whole randomness question to other parts of the system: a peripheral for sources of randomness, and the OS to make use of it. Surely not a job for the CPU.

That’s actually what I was thinking but didn’t explain very well. Having the OS read a random number generator peripheral and using that as a key for the mmu. There’s a random number generator using George Marsaglia's multiply method in the system that has support for multiple streams of random numbers. The idea being that each app can have it’s own stream of numbers so that the sequences can be made to repeat by using the same key. Stream #0 is used by the BIOS / OS.

Being able to get strings to display I decided to work on the input side of things.
Having some fun getting keyboard I/O working. The monitor program echos keystrokes to the screen as it receives them. But what’s being echoed isn’t 100% correct. It’s as if the shift key on the keyboard were stuck down. And the echo is echoing the key break codes as well as the key make codes and it’s not supposed to. The key-up codes are supposed to be absorbed by the keyboard routine. It may have to do with the keyboard not being reset and initialized properly. In my first attempt at interfacing I haven’t bothered to reset the keyboard, and am just using default settings hopefully.

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


Fri Nov 09, 2018 4:11 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Bugs: The inverted logical ops (nand, nor, xnor) were not flagged as updating the register file resulting in them acting like a nop. xnor was used a fair bit to test for equivalence.
Some of the keyboard software has been updated. There is now a pause at startup as the software tries to reset the keyboard. Getting dumps of numeric displays has been a challenge.

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


Sat Nov 10, 2018 4:56 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Working on data cache issues today. There seems to be a problem reading data after a cache load. For instance, the string “Keyboard not responding” is displaying as “Keyboard n” where the ‘n’ is the first character of the next line in the data cache following characters are not displayed. I wrote a small test routine for the data cache and it fails almost immediately. This has me a bit stumped because subroutine data (call addresses, frame pointer) are going through the data cache. I suppose it could have something to do with the data-size as well.

The wrong register was being read from the I2C controller for the RTC causing the software to hang waiting for a status that is never set. Next the software was waiting for a nack from the RTC after the I2C stop condition was being set. This caused a hang. I’m thinking that maybe a watchdog timer should be setup to interrupt the I2C if it’s taking too long. The system shouldn’t hang just because of a bad I2C device or device driver.
The compressed version of the ANDI instruction did not have the constant encoded properly by the assembler. This affected the nibble display routine among other things.
The target register and second source operand register fields were swapped for most of the set instructions. No doubt this would cause all sorts of problems.

Some progress with the keyboard input. The LEDs on the keyboard can be made to flash while resetting it. But the BIOS sends back a ‘keyboard not responding message”.

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


Sun Nov 11, 2018 4:34 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Much to my disbelief the source operand three register field wasn’t being decoded properly in the processor core. This would cause instructions using indexed address mode not to work. While not used that often, the mode did get used for the data-cache test routine. This error was found debugging the conditional move instruction, which also uses three source registers.
BEQI was using the wrong opcode when the immediate value was too large for the instruction. This was the source of trouble for keyboard scan-code processing as several of the scan-codes are too large for the BEQI instruction. Keyboard input works a bit better now, the break codes are being filtered out.
The target register for the reduction or operation was always set to zero. This caused the hex output routine to fail and display 18 digits instead of the specified 6 digits.
ramtest() routine is almost working. There's an incrementing display of the memory address updated. But at the end of the loop the program gets off track and crashes.
Wrote a parallel transfer interface component. Soon will be able to transfer files to the board via usb.

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


Mon Nov 12, 2018 5:47 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Got a simple Intel hex downloader written and the parallel transfer interface logic written. I also wrote a simple download utility running on the pc. In theory it should now be possible to download files to the system running on the FPGA.
Well the file isn’t being downloaded properly yet. The data is getting to the input fifo of the FPGA though. There’s a dump of the number of entries in the input fifo which goes to $7ff when a file is transferred. For some reason the input read loop isn’t working. I’m guessing a bad branch instruction.

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


Tue Nov 13, 2018 6:08 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
The latest shenanigans.
The compiler didn’t recognize the hex and decimal character escape sequences like “\x22”. It was only recognizing octal escape sequences. It also didn’t recognize enough digits to support the two-byte wide characters.
The compiler wasn’t dereferencing function pointers correctly in all cases.
It also was not allocating storage for temporaries on the stack properly. This caused some variables to overwrite others on the stack. The compiler now allocates a little too much stack space but doesn’t overwrite variables. It tracks the maximum space used, but the actual space used typically turns out to be less due to optimizations.
For the hardware the JAL instruction didn’t store the right return address for a compressed version of the JAL. It stored the next address as if it were a non-compressed JAL instruction. The compressed JAL is rarely used but is used to implement function pointers.
There is now a problem displaying the start-up message. In the middle of the message it drops down and continues displaying on the second line. It's almost as if a CR LF pair crept in somehow.

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


Thu Nov 15, 2018 4:41 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Added a loopback mode to the pti (parallel transfer interface). The pti is a usb connection to the host that manifests itself as a parallel port connection on the FPGA. It’s been a challenge to get working. It almost works, I suspect some sort of issue with the core’s hardware. When the hex loader is run, it breaks from it’s continuous status display if a file transfer is attempted, so some sort of data makes it through. On the host side a corrupted response can been seen, it’s supposed to be “Ok” but it arrives as funny characters. Loopback mode works so it’s not physical layer issues.

High-lights from the latest batch of error fixes:
Register field for indirect jumps was encoded incorrectly. This caused a crash.
The rti instruction was encoded incorrectly. The incorrect encoding of the rti instruction caused the ISR to loop back onto itself so processing was stuck executing the ISR routine.

The cpu’s operating frequency was bumped up to 20MHz from 10MHz. It had been set so low to enable quick system builds, but it seems to build fairly quickly at 20MHz too. The trick will be to get it working at 40MHz or higher.

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


Fri Nov 16, 2018 4:03 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Got a good chunk of a color syntax hi-liting editor written while waiting for system builds. The text editor I normally use seemed to lose some of its functionality (drop down boxes don’t work anymore). It occurred to me that it could be because it’s passed its one-year date. Anyway, I wanted to see how much I could get written in a short time. For what I need it for I may just roll my own editor. I’m using C# to write the editor, deviating from my norm of C++.

The hex downloader works a little bit better. It’s now visibly downloading the first few records then it gets screwed up. Along the way the keyboard is working a bit better. It’s now possible to cursor around the screen (cursor keypad didn’t seem to work before). Reading characters from the text screen doesn’t seem to work. That’s how monitor commands are processed, by using the text screen as a command buffer.

A compiler fix was needed for the return value of a function. Normally a function returns a value in r1 which is okay to use until multiple functions are called in the same expression. With multiple function calls the value in r1 needs to be preserved in another temporary register, otherwise it gets overwritten by the next function call. The compiler wasn’t doing this so when multiple function calls were made in an expression, the value of r1 got overwritten causing errors.

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


Sat Nov 17, 2018 6:31 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
The core doesn’t seem to be able to read un-cached data very reliably. The data being read from the text display is being echoed back to the text display and what’s echoed back isn’t what it’s supposed to be. The core seems to be able to read cached data okay although there appears to be the occasional glitch. It has to be reading cached data including byte and char oriented data because that’s what’s used to display messages on-screen. So reading from the BIOS rom works okay.
I believe I have found a problem a solution to which is just being built now for testing. Both the alu and memory data bus were updating the common data bus. Data should be coming only from the data bus and not the alu for memory instructions.
Attachment:
File comment: FT64v7 data input path
DataInputPath.png
DataInputPath.png [ 28.54 KiB | Viewed 50 times ]

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


Mon Nov 19, 2018 5:18 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1025
Oh, is that a one-off diagram or is there some rich documentation somewhere?


Mon Nov 19, 2018 9:09 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
Quote:
Oh, is that a one-off diagram or is there some rich documentation somewhere?
Another one-off.
There isn’t really a tremendous amount of documentation, but there is a doc directory in my Github account. It contains a couple of powerpoint slide files and word documents. Some of the docs are a bit dated. The last slide was wrong. It’s the result bus that gets updated by the load, not the argument registers.

Updating code for the alu / dram data bus update improved the operation of the core. Now text coming from the display memory can be recognized and thus commands can now be executed from the monitor. But the core is hanging during the HexLoader() routine in the function prologue code. The likely candidate for a hang is a memory store operation. The only thing I could find here was potentially the write buffer pointer could be stuck at the end of the write buffer causing subsequent memory store ops to stall.
Not being able to find anything, I did a cheesy thing and added a timeout to the core’s queue head advance. If the head of the queue doesn’t advance within 300 clock cycles, then the instruction at the head of the queue is marked as exceptioned and forced to commit so the head will advance. All the exception routine does is go back and re-run the instruction. This means that if there’s a commit issue the machine will run really slowly but it’ll still advance. The 300 cycles was chosen as it’s longer than the longest running instruction (about 150 clocks) plus time for a cache load.

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


Tue Nov 20, 2018 4:33 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 712
Location: Canada
I rebuilt the core as a two-way superscalar, I haven’t done that for a while and there were a couple of glitches. The complete SoC took about 127,437 LUTs (204,000LC’s), so the FPGA is pretty full, but it still built in under an hour. However, the core did not work at all, doesn’t even get out of reset which is strange because I’ve had it running before. So, it’s back to the one-way core until more bugs are fixed.
I managed to replicate one of the issues with core in simulation. It’s just a matter of time now before it’s fixed. For some reason the core’s advancing text to the next screen line when it shouldn’t be. This can be traced back to a load of the cursor row, which is loading a one instead of a zero. This can be traced back further to bad branch instruction I think.

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


Wed Nov 21, 2018 4:06 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 342 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23

Who is online

Users browsing this forum: No registered users and 1 guest


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