View unanswered posts | View active topics It is currently Fri Mar 22, 2019 12:05 am



Reply to topic  [ 395 posts ]  Go to page Previous  1 ... 23, 24, 25, 26, 27
 Thor Core / FT64 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 757
Location: Canada
The poll for interrupt instruction should be a 16-bit compressed instruction format as it’s anticipated it would be used a lot in some codes. However, it is really just another form of software interrupt, this time the interrupt is conditional. It is desired therefore to reuse the BRK instruction logic by giving it a conditional execution option. However, BRK processing takes place in the ifetch stage before instructions are decompressed. A significant portion of the ifetch stage would have to be re-written to support a 16-bit compressed version. So a 32 bit instruction version is what’s supported. Specifying a cause code of 255 in the BRK indicates a PFI instruction.
As a trial I added this mux in the fetch stage which forces the PFI instruction to either the appropriate interrupt or a NOP.
Code:
      insn0 <= insn0a;   // Move instruction forward
      if (insn0a[15:0]==16'hFF00) begin   // BRK #255 (PFI)
         if (~|irq_i)   // If no interrupt
            insn0 <= {8'h00,`NOP_INSN};
         else
            insn0[20:0] <= {irq_i,1'b0,vec_i,2'b00,`BRK};
      end

In program code PFI may be coded as just PFI or a BRK #255.
Code:
BRK #255
RET

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


Thu Mar 07, 2019 7:55 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 757
Location: Canada
I’ve done something to the system that causes it to no longer get to the main menu. It does the 2 second delay loop then causes the text screen to disappear from sight and it’s hung. Recently I’ve been trying to get the system to run with variables located in the text controller’s memory. It’s as if it’s overwriting the controller regs instead of the display ram.
So, I’ve tried disabling all access to the text controller registers and doing so doesn’t seem to have any effect. Somehow the text screen is being disabled and it's looking like a hardware problem of some sort.

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


Sat Mar 16, 2019 3:53 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 757
Location: Canada
The following is executed during boot-up: it gets all the way into _DBGClearScreen because the screen is being cleared. Also LED status $26 is displayed on the LEDS. But it doesn’t reach LED status $27. It appears to be using the correct debug display attribute which is stored in the text controller memory. It appears the memsetW() function is failing to finish properly.
Code:
 start:
   ; This seems stupid but maybe necessary. Writes to r0 always cause it to
   ; be loaded with the value zero regardless of the value written. Readback
   ; should then always be a zero. The only case it might not be is at power
   ; on. At power on the reg should be zero, but let's not assume that and
   ; write a zero to it.
      and      r0,r0,#0      ; cannot use LDI which does an or operation
      ldi      $sp,#SCRATCHPAD+$B7F8   ; set stack pointer

      call   _Delay2s
;      call   _CopyPreinitData
      call   _SetTrapVector
ifdef SUPPORT_DCI
      call   _InitCompressedInsns
endif
+}
start4:
      ldi      r1,#$FFFF000F0000
      sw      r1,_DBGAttr
      call   _DBGClearScreen
start5:
      bra      start5


Code:
 void DBGClearScreen()
{
   int *p;
   int vc;

   __asm {
      ldi   r1,#$26
      sb   r1,LEDS
   }     
   p = DBGScreen;
   //vc = AsciiToScreen(' ') | DBGAttr;
   vc = ' ' | DBGAttr;
   memsetW(p, vc, DBGROWS*DBGCOLS); //2604);
   __asm {
      ldi   r1,#$27
      sb   r1,LEDS
   }     
}

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


Sat Mar 16, 2019 4:15 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 757
Location: Canada
Readback of values across the video bridge and two input multiplexors appears not to work reliably. Right now, a bridge is a generic component. All three bridges in the system are instances of a common module. Using a generic module allows different peripheral cores to be moved around between bridges to optimize the system. The bridges and multiplexors with registered outputs are necessary to keep the system’s fmax high. It would be simpler to just use about a 20-to-one multiplexor on the cpu data bus, but that would entail a number of gate delays and also result in a lot of congested routing.
Attached is a block diagram of the v7 test system. Looks like I’m going to have to write some software for testing out the access to the text controller via the system bus network.
Text controller ram has a three-cycle read latency, plus an additional cycle for output multiplexing within the controller. That makes four cycles combined with two levels of registered multiplexors and the bridge component adding three more for a total of about seven cycles to read the controller’s memory.
The controller has about two cycles of latency for write operations, but the latency is hidden by the bridge component which acknowledges a write within a single cycle provided the bridge isn’t busy. Writes seem to be working.
The registered input multiplexors feature a bus hold so that the bus retains the previous value during dead cycles between peripheral address switches. This means that hold times for the data read-back should easily be met. An ack signal is sent back synchronous to valid data being placed on the bus. Since data is latched at the start of the next cycle there should be plenty of setup time.
Read transactions are synchronous bus transactions. The cpu core spits out a read request then sits and waits for an ack back. The text controller memory is in the un-cached address space.
Attachment:
File comment: FT64v7 Test system diagram
V7TestSystem.png
V7TestSystem.png [ 37.25 KiB | Viewed 52 times ]

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


Sun Mar 17, 2019 4:44 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 757
Location: Canada
And today’s bug was the system bitmap controller (frame generator) was sending back an acknowledge for all writes in the system, instead of filtering to just it’s own ack. I’ve hit this kind of an error before. It has to do with using an ack generator component rather than discrete logic. When the component was substituted in place of discrete logic the write line input was not being qualified with a circuit select, resulting in unneeded acks back to the system.
The component is handy to use because it’s parameterized. One has only to specify proper parameters for the number of cycles to wait during a read or write operation before generating a WISBHBONE compatible ack. It saves having to re-write the same code in module after module.
Having fixed this bug and a couple of other minor things, presto, the system doesn’t even get to displaying the first $AA on the leds. Obviously I’ve upset something else somewhere.

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


Thu Mar 21, 2019 8:47 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 395 posts ]  Go to page Previous  1 ... 23, 24, 25, 26, 27

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