View unanswered posts | View active topics It is currently Thu Dec 05, 2019 8:44 pm



Reply to topic  [ 102 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
 DSD7 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2016/12/28
The interrupt checking instruction which didn’t execute until the EX stage turned into plain interrupt checking in the EX stage so no check instructions are required. It uses about the same resources and timing. All the fault conditions were moved to the EX stage, and so a multiplexer in the IF stage was removed.

Timing is now limited by the path from the operand registers through the ALU through the forwarding mux and back to the operand registers again. There isn’t much that can be done about this besides perhaps some good floor-planning of the ALU. Adding registers to the ALU operations doesn’t work because that turns operations into two clock cycles which halves the performance of the cpu anyways. The only other choice is to remove some of the functionality.

Coded a game of Conway’s life after reading about it in these posts http://forum.6502.org/viewtopic.php?f=2&t=4293&start=45#p49602. It processes 512 cells per row in parallel using a five port ram (1 write, 4 read). The life simulation is pipelined for the update so there is a 1:1 relationship between the calc and the clock. It’s running on a 37.5MHz clock so that’s 37.5 million rows per second. (19.2 G cells per second). It could probably run faster but hasn’t been tried. It may not be running quite right yet. The screen eventually filled with a spaghetti pattern which I think isn't the right result.

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


Fri Dec 30, 2016 10:02 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
Ah - a superwide Life engine as a memory-mapped peripheral(?) - nice!
https://github.com/robfinch/Cores/blob/ ... ife/life.v


Fri Dec 30, 2016 10:47 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
Yup, life as a memory mapped peripheral. The DSD9 test system was used to initialize the engine and set some random points in the arena. A configuration define was added so that the life game’s arena size could be set smaller to use fewer resources. (2000LUTs and 16, 36kbit BRAMs). It’s set now to 256x256 and runs in parallel with the rest of the system. Because it uses it’s own dedicated memory it doesn’t slow the system down. A frequency control register was added to allow the game to be slowed down to a better viewing speed. I should really document the register set.

The DSD9 system refuses to co-operate. A display of “Hello World!” done via compiled code isn’t working right. The chars come out completely black (foreground and background color). The data cache returning a zero value is suspect. Sim was traced through to the display of the first couple of characters and it seemed to work in sim. Character display also works from a routine written in assembler. So the problem is baffling. I’ve been stuck on this bug for several days now.

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


Sat Dec 31, 2016 1:48 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2016/12/31
Still working on the character display problem. It’s bizarre because obviously subroutine call and return work. So it’s not likely to be a bad ram interface. And it appears to be a value on stack that gets corrupted, but only in the real FPGA, not in sim. The following code was made to work simply by changing the order in which an expression was evaluated. The line commented out didn’t work. The line with the expression transposed does work. This occurs because in the first case a value is required to be pushed onto the stack, and in the second case it isn’t. I tried disabling the data cache with the same result. It might be a bad push/pop operation. Since values are passed in registers most of the time the core could appear to be working.
Code:
void DBGClearScreen()
{
     __int32 *p;
     int vc;
     
     p = DBGScreen;
//     vc = DBGAttr | AsciiToScreen(' ');
     vc = AsciiToScreen(' ') | 0x87fc00;
     memsetT(p, vc, 2604);
}


The ram test routine runs successfully with the above change.

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


Sun Jan 01, 2017 6:10 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/01
The test system was changed from using internal address decoding to externally supplied decoding, which reduced resource usage. This meant changing code for all the peripherals. A special reset mode was added to the text controller that echoes the contents of the data bus during start-up.

2017/01/02
TinyBasic was ported for the DSD9 core. It’s about 10kB. The size of the boot rom had to be increased to accommodate the basic. Still stuck on the memory bug. Push/pop seems to work, but loads or stores don’t. Wyde loads from ROM work or there would be no messages displayed. Obviously stores to the text controller memory work or there’d be no display. Time for a more exhaustive cpu/memory test.

Created a brief video for youtube. https://youtu.be/zy_7wTiIiOo

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


Tue Jan 03, 2017 9:46 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/03
Found an error in the memory controller. The read address needed to be 32 byte aligned for reads and it was only 16 byte aligned. The same problem was present for channels 0 and 7. I thought I had found “the problem” but it turns out after a fix it doesn’t make any difference. The memory bug is still there. The same error in the memory controller was present in a couple of other projects as well.

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


Thu Jan 05, 2017 10:27 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/07
Since I can’t figure out the memory bug, so I spent some time working on the test system’s sound generator instead. The sound generator is quite powerful, being similar to the SID chip. There’s a beep routine in the rom that’s supposed to sound for 1sec. at start-up. Well no output. The first problem was driving the audio output with a delta-sigma dac, why I did this originally I’m not sure. The output filter wasn’t designed to accept this as input and no sound resulted. A simple PWM circuit was substituted, fed by a simple tone generator hard wired to generate an 800Hz buzz. That circuit works so there are no problems with hardware.

The next problem was software. The beep routine had a wave input selected as the output and it was supposed to be a triangle wave output selection. Wave input doesn’t work yet at as the wave table is not connected.
The third problem was hardware. The wrong data bus was wired up to the PSG’s input. All the values being written were zeroed out. This was found by running the system in sim.

After fixing it and a couple of more minor fixes. Now sound still isn’t working, but I can hear a “click-click” as the envelope generator is gated on and off.

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


Sat Jan 07, 2017 11:48 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
Here is a picture of the sound generator output. Really short time constants were used in order to generate a trace quickly. The generator uses a digital piecewise linear approximation to an exponential curve. The curve is actually 2**n and not e**n like it should be, but hopefully it’s close enough.
The bottom trace is output from the envelope generator. The second from bottom trace is output from the tone generator, the second from top trace is an internal signal, and the top trace is output from the sound generator. Hopefully music is on the way.

Attachment:
ADSR1.png
ADSR1.png [ 18.36 KiB | Viewed 9781 times ]

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


Tue Jan 10, 2017 8:14 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/10
Trying to figure out the load / store bug, so I put the entire SoC into a test bench. This gives 100% cycle accuracy system wide. According to the sim. the display should be properly updated, but it doesn’t work in the FPGA. I tried a couple of things on a hunch that maybe things didn’t synthesize correctly, but no luck. Now I’m really stumped. Time to work on something else.

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


Wed Jan 11, 2017 1:30 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/11
Filter cofficients for the PSG were always being updated from the bus since the circuit select signal was missing from the update enable.

2017/01/13
Figured out the memory bug has to do with results forwarding during multi-cycle operations. Wrote a small test program that mimics the forwarding operation required by the display code. And it failed the same way the display code fails. The following routine failed to forward the display attribute correctly.
Code:
test_fwd:
      call   _WaitForButtonRelease[pc]
      ldi      r2,#$10D         ; j
      ldi      r1,#0x0087fc00      ; white on green
      stt      r1,_DBGAttr
      ldt      r4,_DBGAttr         ; this line should forward r4
      or      r3,r2,r4
      stt      r3,TEXTSCR+84*4
      call   _WaitForButtonPress[pc]
      ret

This code was traced through simulation and it worked. So there must be a difference between sim and synthesis somewhere.

An Ethernet controller was also wired into the system. I wrote my own MII to RMII conversion core to support the ethmac to PHY interface.

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


Sat Jan 14, 2017 4:55 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
Good to have a small testcase. Have you got anything like ChipScope which can act as a logic analyser inside the FPGA?


Sat Jan 14, 2017 8:22 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
I’ve never used chipscope before, but I think it’s available. I may end up building something similar. The usb programming port on the board doesn’t work anymore so debugging options are limited. There's no direct communication to the host. Programming files are being transferred via the USB host port and a memory stick.

2017/01/14
Well the temporary “fix” to results forwarding didn’t work, which was surprising. Since calls and returns are working, a temporary fix was to insert a jump-to-next instruction for every multi-cycle operation. This would clear the pipeline of following instructions making results forwarding unnecessary. Since it didn’t work there must be something else going on.

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


Sat Jan 14, 2017 3:45 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/01/21
Figured out why there was no sound output from the PSG. The wrong subset of bits was used for frequency generation in the tone generators which resulted in frequencies 16x higher than programmed. So the chosen frequency was outside of human hearing range. The system now produces a nice 1 second beep when started.
The past week was spent working on the FT832 project for a change and modifying the PSG to work with an eight bit bus optionally.
Still haven’t figured out the bug in the synthesized core. Results forwarding seems to work in some circumstances but not others. The following which requires forwarding works with the ‘OR’ operation removed.
Code:
test_fwd:
      call   _WaitForButtonRelease[pc]
      ldi      r2,#$10D         ; j
      ldi      r1,#0x0087fc00      ; white on green
      stt      r1,_DBGAttr
      ldt      r3,_DBGAttr         ; this line should forward r3
      //or      r3,r2,r3         ; commented out
      stt      r3,TEXTSCR+84*4
      call   _WaitForButtonPress[pc]
      ret

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


Sat Jan 21, 2017 7:54 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/02/16
Porting over DSD7 to a new FPGA board isn’t going well. To begin with it almost worked, but the screen display was blank. Screen problems were expected because there was a conversion from VGA to HDMI output involved. Now after adding a couple of LED checkpoints there’s not even a screen display. The monitor reports ‘no signal’. The core is running to a point. The first couple of LED displays work, then nothing. The code first writes ‘AA’ to the LEDs, and then a bit later writes ‘55’. These displays work so the core must at least be able to fetch instructions and there must be a working clock.

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


Fri Feb 17, 2017 5:33 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 967
Location: Canada
2017/02/19
The screen display is almost working. A WXGA generator written in Verilog is interfaced to an rgb2dvi interface written in VHDL with generics. Assuming that somehow the generics might be off from their default values, values were specified for all the generic parameters. Voila, screen display is back, but is still blank. The system still hangs after the first few lines of code. One problem was found where there was no circuit select (cs) being generated to the RAM causing no ack back from the RAM, this would hang the system. There is obviously still another bug to work out. It took about 4.5 hours to build the system so turn-around time for testing out ideas is not great.

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


Tue Feb 21, 2017 5:53 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 102 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

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