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



Reply to topic  [ 775 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23, 24, 25 ... 52  Next
 Thor Core / FT64 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Found one gotcha in the code after examining thousands of lines of synthesis output. I had initialized a variable in two different spots using both blocking and non-blocking assignments. Simulation accepted this, but it was not okay with synthesis. After fixing this problem the core gets a tiny bit further. It displays the first LED display of ‘AA’ successfully now. However, instructions are not committing to the machine state properly. I dumped the iqentry_cmt[] signal and it’s zero for all but one instruction.

After fixing a few more synthesis warnings, (there’s literally thousands of warnings most of which can be ignored), instructions are now committing to the machine state properly :) The machine sequences through instructions to clear the screen display, but the display isn’t being cleared for some reason or other. I already found a couple of problems with the screen display, one being that the byte lane selects were zero, I forgot to hook them up. Some slow progress finally.

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


Sun Oct 28, 2018 6:39 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Found and fixed a number of bugs. One was having to do with compressed instructions. The code indicating a compressed instruction is passed forward even once the instruction is decompressed so that the core knows how much to increment the program counter by. This was not being considered in the logic that detects when a register file write occurs and as a result some instructions were flagged as not writing to the register file when they should be. That screwed up the dependency checking. There were also several bugs having to do with rearranging the bits in the instruction opcodes. The assembler didn’t get updated in a couple of spots resulting in bad code being assembled.
The integrated logic analyzer is turning out to be quite handy.
I’m trying to get the core running compiled C code now so there’s a different mix of instructions being tested.

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


Mon Oct 29, 2018 6:19 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Got the machine to clear the screen now, running a clear-screen routine written in C. But the machine hangs shortly thereafter. It appears to lock up a single address so I’m checking to see if it’s another full queue issue. -> It looks like it’s repeatedly trying to do a cache load from an invalid address. More probes to setup. Here is a screen-shot of ILA display.
Attachment:
File comment: Debug image
OverOver.png
OverOver.png [ 81.78 KiB | Viewed 6963 times ]

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


Tue Oct 30, 2018 3:23 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Figured out the looping problem. Time to get the emulator working again though. The core hangs after clearing the screen and it appears to be a software problem of some sort. The program pulls the incorrect return address off the stack and goes downhill from there. It looks to me like the stack frames are getting out of sync somehow. It seems like it’s missing or skipping over a “MOV $SP,$FP” instruction which restores the previous frame. So, by running the program in the emulator I may see what’s missing, it’s just too hard to try and follow logic analyzer output.
Latest bug finds: unsigned loads weren’t updating the register file. Store operations that update the register file (CAS, PUSH, SWC) were not setting the commit_id properly. This caused the core to hang waiting for a commit.
The PUSH instruction has crept back into the ISA. By supporting a 16-bit opcode push instruction it can save the two bytes required for decrementing the stack pointer in many cases, leading to slightly shorter faster code.

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


Fri Nov 02, 2018 3:24 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Powered up the glyph editor and updated the 8x8 bit raster font used for the display. The glyph editor is something I wrote myself so it’s pretty primitive. It can store the glyphs as .coe, .ucf, or .v files. I added some graphics characters.
There’s one perplexing video display bug. In the bottom left corner of the display the first character of the last five rows of the display show up as random characters in random colors, even after the display is cleared.
Latest bugs: multiply and divide immediate were assuming the first operand was valid. This led to incorrect calculations when the operand wasn’t valid. Specifically, the cursor didn’t show up in the right spot on the screen.
The MOV instruction was waiting for the second source operand field to become valid. Since this field is not used by the MOV instruction there is no need to wait. This was a performance issue of unnecessary stalls.
I’m now trying to get messages displayed via the debug console functions.

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


Sat Nov 03, 2018 6:31 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Is that bug a power-of two kind of problem? That maybe you have 16 or 32 rows which are good, and then 5 where something isn't initialised??


Sat Nov 03, 2018 9:29 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Is that bug a power-of two kind of problem?
It may be. It's about the 32 nd row on the screen where it starts. The screens 48 chars wide by 35 rows. I have a suspicion about what causes it, but I can't verify until I get some software running. The text controller does a high-speed divide operation when calculating the characters that can fit on-screen and I think it maybe a rounding error causing the memory addressed to be off by one. The divide's only accurate to 12 bits which I thought would be enough. Otherwise it could have to do with the power-on-screen randomizer.

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


Sat Nov 03, 2018 9:21 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Wrote an inverted page table component for a form of memory management. The page table is divided into two banks, upper and lower. Each bank has 32768 entries. Each entry represents an 8kB page of memory. The hash function uses the asid to divide the memory range into 64 partitions. The bits 13 to 21 of the virtual address are used as part of the hash to index into the partition. The first hash is used to get an address into the lower bank of the page table. This gives 64 apps a base 4MB address space to start with and translation takes only a single memory cycle. If more memory is needed, then a second hash function selects an entry in the upper bank of the page table. Data and code that needs to be accessed quickly can then be stored in the lower 4MB of the address space.
There is no caching of address translations, so occasionally a translation may take a long time depending on how many hops the translation makes. In theory a translation could be required to scan all of the table taking 65536 memory cycles. The table is implemented entirely in block ram and so has a short three-cycle access time.
Addresses at the machine operating level are not translated and so take only a single clock cycle of latency.

Found a register file update issue with the two-way version of the core. The register update doesn’t happen fast enough on the second write port, and an instruction that is queuing can get stale data. The register file probably has to be re-written to be as it was in days past, rather than using a 4x update clock multiple copies of the register file are needed.

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


Sun Nov 04, 2018 3:53 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
A picture of what I'm looking at. Checkout the bottom left of the display, five colored characters. How? The screen is cleared to all 'A's. The top row where 'B's are printed is the output of the DisplayString() routine with the character fetch hard coded to a 'B' for debugging. It's supposed to display the boot-up message. The color bars in the middle of the display are sprites. They are supposed to be randomly positioned by software.
Attachment:
File comment: Pic of FT64SoC display
DSCF7780.JPG
DSCF7780.JPG [ 1.26 MiB | Viewed 6894 times ]

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


Sun Nov 04, 2018 5:39 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Latest bugs: in the assembler, the low order two bits of the branch target for the BEQI instruction weren’t being shifted into position properly in the opcode, resulting in the target reached being within a couple of bytes of the desired target (a branch to the wrong location). This caused for instance, the character display to branch to the segment for deleting a character rather than performing a carriage return. Carriage return and line-feed seem to work now.
Latest addition: added a fast multiply instruction and a compiler intrinsic function __mulf(a,b) to make use of it. The multiply is a 24x16 unsigned single cycle operation.
Stuck on trying to get a string to display on-screen. I'm not sure what the issue is. In simulation the characters can be seen being written to the display memory, but in a real FPGA it's not working. If it didn't work in sim either the issue would likely be easy to resolve. It is writing something to the display memory, just not the right values.

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


Tue Nov 06, 2018 6:26 am
Profile WWW

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 213
Location: Huntsville, AL
robfinch wrote:
In simulation the characters can be seen being written to the display memory, but in a real FPGA it's not working.

I would look for latches in your code. Inadvertent latch definitions in my code has almost always led to a difference between simulation and synthesis.

_________________
Michael A.


Tue Nov 06, 2018 11:43 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
I'm reminded of what we used to do at work: as it's near-impossible to get rid of all warnings, each synthesised design was accompanied by a script which filtered out known-harmless warnings - signed-off exceptions, as it were - so that any warnings which remain can be treated as serious, or added to the filter.


Tue Nov 06, 2018 12:18 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Thanks for the tip. I’ll do another check for latches. There are latches reported in the timing report, but I haven’t been able to track down where they are (the latches should be in non-critical code). I managed to fix a couple of them. But as far as I can tell everything has default cases so there should not be any latches.
Most of the reported latches are to do with the instruction driving the alu.
Quote:
There are 128 register/latch pins with no clock driven by root clock pin: ucpu1/ucpu1/alu0_instr_reg[0]/Q (HIGH)
I think this could result in a stale value being produced by the alu, but it should only be in cases where the alu output isn’t used. If the alu is computing a new result the proper instruction seems to be selected.

I found the bug, it was a software bug and here I was looking for a hardware bug. The bbs (branch on bit set) instruction was being used incorrectly in a case statement. This caused many characters to select the back-space function ($08 = bit 3 set), deleting the characters that were being displayed.
Onto the next bug.

The latest bug discovery was unsigned branch instructions weren’t being encoded properly by the assembler resulting in them acting like nop instructions.

Finding bugs is a bit like finding prime numbers with a sieve. Once the bug is found and fixed, code runs that much further before another bug is encountered. Fixing the bug fixes it in many places at the same time.

The core doesn’t do the stores sequentially to update the display. It’s out-of-order, some characters appear on-screen before previous characters. At the display rate it’s impossible to tell though.

If messages can be displayed to the screen reliably then debugging should proceed at an accelerated rate.

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


Wed Nov 07, 2018 4:03 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Found that queue entries were being marked done in two different spots for a store operation. The conditions weren’t identical and this may have caused problems.

Bug fixes: Indexed loads and stores were assembling as a regular loads and stores when the index register was zero. This would be okay except that some instructions have only an indexed form.
The compressed form of the ldi instruction wasn’t sign extending the value when decompressed.

I’ve read that the operating system is assigned random pages of memory for memory allocations to alleviate effects from viruses and other malicious software from corrupting the memory. So I’m wondering how to add an element of randomness to the page selection in a manner that is changeable from reset to reset. My thought is to read a real-time-clock chip and use the date/time to seed a random number generator. The random number would be xor’d with the key to select a page. I don’t know if this is convoluted enough to confuse a virus.

I started writing a monitor program for the system.

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


Thu Nov 08, 2018 4:03 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
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.


Thu Nov 08, 2018 9:55 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 775 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23, 24, 25 ... 52  Next

Who is online

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