Last visit was: Wed May 18, 2022 9:12 am
It is currently Wed May 18, 2022 9:12 am



 [ 138 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 10  Next
 FISA64 - 
Author Message

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1690
BTW, I haven't used it, but Xilinx offers a sort of automatic software TAP called ChipScope. As standalone software it's expensive but you can get a free license with certain LX9 boards. If your design fits on an LX9 and you have $100 or so to spend, it might be worth considering.


Sun Mar 15, 2015 12:43 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Quote:
is your project open source ? just curious to see your tests, and your code


The source code is open-source and posted on my Github account at:
http://github.com/robfinch/Cores/blob/master/FISA64/trunk/rtl/verilog/FISA64.v
The test bench is FISA64_tb.v

http://github.com/robfinch/Cores/blob/master/FISA64/

The assembler and compiler are located in a different project directory at the moment as I'm re-using code from another project:
http://github.com/robfinch/Cores/blob/master/Table888/trunk/software
Not all of the opcodes are implemented in the assembler yet. Linking doesn't work at all.

Quote:
i had a lot of similar experiences, most of them from all the opencores projects i have followed

I've found several bugs in opencores projects that are supposedly "finished" myself. When I find a bug I notify the author. Part of the reason people post openly is so that they have a larger number of testers and debuggers.

The current test program will eventually grow into a mini-bios.
Code:
                       code
                       org     $10000
010000 02 00 02 6E        sei     ; interrupts off
010004 3F 00 00 00        nop
010008 3F 00 00 00        nop
                       ; cache misses here after first prefix fetch
01000C 7C 2B 1A 09        ldi     r1,#$1234567812345678
010010 7C 34 12 78
010014 0A 10 F0 AC
010018 82 20 02 28        addu    r2,r1,r1
01001C 3F 00 00 00        nop
010020 3F 00 00 00        nop
010024 3F 00 00 00        nop
                       ; cache misses here after second prefix fetch
010028 7C 2B 1A 09        ldi     r1,#$1234567812345678
01002C 7C 34 12 78
010030 0A 10 F0 AC
010034 82 10 04 28        addu    r1,r1,r2
010038 3F 00 00 00        nop
01003C 3F 00 00 00        nop
010040 3F 00 00 00        nop
010044 0A E0 F1 7F        ldi     r30,#16376           ; set stack pointer to top of 16k Area
010048 0A 30 14 00        ldi     r3,#10
                   loop1:
01004C 95 31 02 00        subui   r3,r3,#1
010050 BD 11 FE FF        bne     r3,loop1
010054 3F 00 00 00        nop
010058 3F 00 00 00        nop
01005C 3F 00 00 00        nop
010060 02 00 54 3C        mtspr   lotgrp,r0            ; operating system is group #0
010064 B9 04 00 00        bsr     SetupMemtags
010068 0A 10 C8 00        ldi     r1,#100
01006C 39 0C 00 00        bsr     MicroDelay
010070 3F 00 00 00        nop
010074 3F 00 00 00        nop
                   hangprg:
010078 3F 00 00 00        nop
01007C 3F 00 00 00        nop
010080 3F 00 00 00        nop
010084 BA FE FF FF        bra     hangprg
                   
                   SetupMemtags:
010088 02 00 50 3C        mtspr   ea,r0                ; select tag for first 64kB
01008C 0A 10 0C 00        ldi     r1,#$0006            ; system only: readable, writeable, not executable
010090 82 00 52 3C        mtspr   tag,r1
010094 7C 01 00 00        ldi     r1,#$10000           ; select tag for second 64kB
010098 0A 10 00 00
01009C 82 00 50 3C        mtspr   ea,r1
0100A0 0A 20 0A 00        ldi     r2,#$0005            ; systme only: readable, executable, not writeable
0100A4 02 01 52 3C        mtspr   tag,r2
0100A8 0A 30 24 00        ldi     r3,#20-2             ; number of tags to setup
                   .0001:
0100AC 7C 01 00 00        addui   r1,r1,#$10000
0100B0 94 10 00 00
0100B4 82 00 50 3C        mtspr   ea,r1
0100B8 0A 20 0C 00        ldi     r2,#$0006            ; set them up as data
0100BC 02 01 52 3C        mtspr   tag,r2
0100C0 95 31 02 00        subui   r3,r3,#1
0100C4 BD 11 F4 FF        bne     r3,.0001
0100C8 BB EF 01 00        rts

                   ; Delay for a short time for at least the specified number of clock cycles
                   ;
                   MicroDelay:
0100CC 67 E1 01 00        push    r2
0100D0 E7 E1 01 00        push    r3
0100D4 7C 01 00 00        push    $10000              ; test push memory
0100D8 66 E0 01 00
0100DC 7C 01 00 00        push    $10008
0100E0 66 E0 11 00
0100E4 02 30 08 3E        mfspr   r3,tick             ; get starting tick
                   .0001:
0100E8 02 20 08 3E        mfspr   r2,tick
0100EC 02 21 06 2A        subu    r2,r2,r3
0100F0 02 21 02 0C        cmp     r2,r2,r1
0100F4 3D 41 FA FF        blt     r2,.0001
0100F8 14 EF 21 00        addui   sp,sp,#16
0100FC D7 E1 01 00        pop     r3
010100 57 E1 01 00        pop     r2
010104 BB EF 01 00        rts

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


Sun Mar 15, 2015 5:06 pm WWW
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
removed


Last edited by legacy on Sun Apr 12, 2015 6:11 pm, edited 2 times in total.



Sun Mar 15, 2015 5:43 pm
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
removed


Last edited by legacy on Sun Apr 12, 2015 6:11 pm, edited 1 time in total.



Sun Mar 15, 2015 5:48 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1690
legacy wrote:
BigEd wrote:
BTW, I haven't used it, but Xilinx offers a sort of automatic software TAP called ChipScope


it lasts 1 year since the code activation, i have used it, it's nice but i prefer a real LA.
I have bought a 32 channels LA, then i sold it out to buy a 64 channels LA module .
really amazing !

I think - I hope - that it's not time-limited as you suggest, but is version-limited - you need to run an ISE which is not newer than the first birthday of your license. So a frozen installation of ISE kept in a safe place is enough. It is an inconvenience, but it isn't as bad as an expiring license. Do correct me if I'm wrong.


Sun Mar 15, 2015 6:57 pm
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
removed


Last edited by legacy on Sun Apr 12, 2015 6:11 pm, edited 1 time in total.



Sun Mar 15, 2015 7:38 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1690
Hmm, that's a bad situation. My license file has the word "permanent" in it, together with the version 2014.11


Sun Mar 15, 2015 10:33 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Quote:
want to know, do you compile assembly and put the binary into bram, then you simulate the whole CPU with "stimulus" from the outside, which means "test bench" vectors ?
how do you run your test ?

Yes, I run the test program using the ISE simulator ISim by running FISA64_tb. The test program is assembled and the assembler creates a file that sets up the ROM contents for the BRAM. The test file is included from the ROM in the test bench FISA64_tb.v. The test vectors for the CPU are currently the contents of the program ROM. This works for instructions but not I/O. In order to test loads and stores there is also a RAM in the test bench. I dump the contents of the RAM in ISim in order to see that stores worked properly. I don't have a setup for testing I/O yet (it's still early stages of project). One PITA is that the free version of ISIM I think doesn't allow reading and writing files for test vectors. At least I haven't been able to get the file reading / writing to work. In order to test with a dummy uart and dummy keyboard in the past, I hard-coded case statements in the dummy devices to return different values based on I/O access.

Quote:
are you able to have a dummy uart into your simulator and redirect it to STDIO (something like PT/S in linux vocabulary) ?

I've been able to use a dummy uart but not redirected to STDIO.

ISim has limits on what the free version will do. It starts to take a long time to run simulations for seconds. So I typically re-arrange the program code in order to make problems appear right away rather than waiting a long time for simulations. The vast majority of problems are solved by running the simulator for short sequences of time. At some point I find I can't really make use of the simulator because it takes too long.

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


Mon Mar 16, 2015 1:52 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Moving towards providing remote debugging facilities for FISA64.
FISA64 now has debug registers similar to the x86 series. In theory(I've yet to try it) it's possible to set breakpoints for instructions and data. FISA64 also has a single-step-mode that automatically inject a software break instruction into the pipeline after an instruction, so there's no need to modify the running program.

For remote debugging my thought is to provide a dual-ported RAM for debug code as a "debug sandbox". One port of the RAM would be connected to a debug co-processor, while the other side is part of system memory. The co-processor would also have access to the breakpoint registers so that it could trigger a debug interrupt. The co-processor would be responsible for establishing the debug code in the sandbox. The debug interrupt routine would point to code in the debug sandbox. Then a debug handler could do things like write out register values or load them.
I want to isolate the hardware from remote debugging protocols so that it becomes a software task to implement a remote debugging protocol.
It's a plan anyways.

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


Mon Mar 16, 2015 3:39 pm WWW
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
removed


Last edited by legacy on Sun Apr 12, 2015 6:11 pm, edited 1 time in total.



Mon Mar 16, 2015 4:17 pm
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
removed


Last edited by legacy on Sun Apr 12, 2015 6:11 pm, edited 2 times in total.



Mon Mar 16, 2015 4:20 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
I ran into the following while converting routines from another processor to FISA64. The other processor supports memory indirect jumps, but FISA64 currently does not. So the following line of code ends up being translated into a number of lines for FISA64.

Orig (tail recursive rts):
Code:
    jmp    (OutputVec)


Translated:
Code:
OutChar:
    push    lr
    push    r2
    lw      r2,OutputVec
    jsr      [r2]
    pop     r2
    pop     lr
    rts


This is really inefficient. The problem is the OutChar routine is called for every character output. The memory indirect jumps show up infrequently in code but are often used. So I could put up with the slow performance, or I could add a memory indirect jump instruction. Of course I'd be increasing the processor size and complexity again.

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


Wed Mar 18, 2015 12:24 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
This is a copy of the first FPGA test code. It flashes LED's on the development board according to an incrementing binary pattern. It shows that a number of aspects seem to be working. There are no multi-cycle operations in this test, it's all single cycle. Multi-cycle operations have been giving me grief in simulation, but I think I've got it worked out.

Code:
start:
    sei     ; interrupts off
    ldi     r5,#$0000
    ldi     r1,#1000000
.0001:
    sc      r5,LEDS
    addui   r5,r5,#1
    bsr     MicroDelay
    bra     .0001


MicroDelay:
    mfspr   r3,tick             ; get starting tick
.0001:
    mfspr   r2,tick
    subu    r2,r2,r3
    cmp     r2,r2,r1
    blt     r2,.0001
    rtl

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


Wed Mar 18, 2015 10:44 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
I've managed to get a FISA64 test system working to the point of displaying characters on a text screen. Now it becomes a bit harder to debug because the processor run correctly for long sequences of code. Meaning there's a lot of stepping through simulator traces.
In the real FPGA system FISA64 clears the screens then displays an '@' character when it's supposed to display a message. In simulation it works correctly leading me to think that the processor works and it's some other system glitch. In the simulation if fails (as expected)when it reaches the keyboard code because there's no emulated keyboard in the simulation system. The simulation system isn't exactly the same as the real system.

One can see in the simulator output that the text controller's memory was updated with a string of characters for display.
Attachment:
FISA641.gif


You do not have the required permissions to view the files attached to this post.

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


Thu Mar 19, 2015 11:14 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Well, I got the message displaying but not in the manner I wanted to. I added an uncached mode to the processor, and now the message displays when the processor is in uncached mode. So I know it's not a software bug. However, the cursor position doesn't track correctly. The cursor is always stuck in the first column of the screen, but text is displayed correctly across the screen. That tells me the text row and column variables are working. The following routine updates the cursor position in the text controller. It has to be the ADDU that fails with r1 = zero when it shouldn't be. The funny thing is that the exact same lines of code are present In the next routine to calculate the screen location, and they work there. So I'm going to try adjusting the position of the code in memory to see if it makes a difference. It could be a bad memory bit.

Code:
                   UpdateCursorPos:
0103EC E7 EF 01 00        push    lr
0103F0 E7 E0 01 00       push   r1
0103F4 67 E1 01 00       push    r2
0103F8 67 E2 01 00       push    r4
0103FC 41 10 00 01       lbu      r1,CursorRow
010400 8C 10 7E 00       and      r1,r1,#$3f
010404 7C DA FF 00       lbu       r2,TEXTREG+TEXT_COLS+$FFD00000
010408 41 20 00 00
01040C 02 21 02 2E       mulu   r2,r2,r1
010410 41 10 02 01       lbu      r1,CursorCol
010414 8C 10 FE 00       and      r1,r1,#$7f
010418 02 21 02 28       addu   r2,r2,r1
01041C 7C DA FF 00       sc       r2,TEXTREG+TEXT_CURPOS+$FFD00000
010420 61 20 58 00
010424 57 4F 10 00       pop      r4
010428 57 2F 10 00        pop     r2
01042C 57 1F 10 00        pop     r1
010430 57 FF 11 00        pop     lr
010434 37 FF 01 00        rtl

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


Fri Mar 20, 2015 9:32 am WWW
 [ 138 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 10  Next

Who is online

Users browsing this forum: CCBot 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

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