| Author |
Message |
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1783
|
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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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.vThe 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/softwareNot 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 |
|
|
|
legacy
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 |
|
|
|
legacy
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 |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1783
|
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 |
|
|
|
legacy
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 |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1783
|
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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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 |
|
|
|
legacy
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 |
|
|
|
legacy
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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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): 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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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 |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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:
File comment: Simulator trace of display character
FISA641.gif [ 191.96 KiB | Viewed 8240 times ]
_________________Robert Finch http://www.finitron.ca
|
| Thu Mar 19, 2015 11:14 am |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
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 |
|
|
Who is online |
Users browsing this forum: AhrefsBot, Applebot 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
|
|
