Cold boot code question

Comments

• evanh Posts: 15,214

  2015-09-29 05:06

  The egg-beating crosspoint switch is the only interface to HubRAM. That said, like the Prop1, a lone RDLONG is still going to take something like 3 to 19 clocks to complete. I think the CORDIC is always a once per rotation affair for each Cog.
  
• cgracey Posts: 14,133

  2015-09-29 06:50 edited 2015-09-29 06:58

  Seairth wrote: »

  (moved from "Prop2 FPGA files!!!")
  
  Chip,
  
  Assuming your cold boot code has not changed, I have a few questions:
  
  * During cold boot, is the hub egg-beater disabled?
  
  * It looks like you are skipping the first ROM byte (it never gets written to hub ram). What's the intention?
  
  * Also, is this mode of clkset only available during cold boot? Or can it be used to extract the ROM at any time?
  
  * What's the purpose of the repeated coginit? Is this just to satisfy the pipeline instruction fetch?
  
  Also, I think I see why you don't want to load the boot ROM at $1000. With only 8 instructions to initialize a cold boot, it's not possible to set up ptra, copy the ROM bytes, and restart. I have an idea on how to make that happen, but it depends on the answers to the above questions.
  
  

  
  Like Evanh said, the eggbeater is the only way to hub RAM, so it's always on.
  
  I think you are referring to the boot ROM that is realized in Verilog:
  

  wire [15:0][31:0] booti	=
  {
  // warm boot code - via coginit
  32'b1111_1010101_000_000000000_000000111,	// 7 = (calld	ina,ptrb)
  32'b1111_1010101_000_000000000_000000111,	// 6 = (calld	ina,ptrb)
  32'b1111_1010101_000_000000000_000000111,	// 5 = (calld	ina,ptrb)
  32'b1111_1010101_000_000000000_000000111,	// 4 =	calld	ina,ptrb
  32'b1111_0110000_001_000000101_000000000,	// 3 =	mov	dirb,#0
  32'b1111_0110000_001_000000100_000000000,	// 2 =	mov	dira,#0
  32'b1111_0110000_001_000000011_000000000,	// 1 =	mov	outb,#0
  32'b1111_0110000_001_000000010_000000000,	// 0 =	mov	outa,#0
  
  // cold boot code - only cog0 on startup
  32'b1111_1100111_011_000000000_000000001,	// 7 = (coginit	#0,#1)
  32'b1111_1100111_011_000000000_000000001,	// 6 = (coginit	#0,#1)
  32'b1111_1100111_011_000000000_000000001,	// 5 =	coginit	#0,#1
  32'b1111_1100010_001_000000000_101100001,	// 4 =	wrbyte	0,ptra++	(write it to hub ram)
  32'b1111_1101011_101_000000000_000000000,	// 3 =	clkset	#0 wc		(read Nth+1 rom byte, get Nth) 
  32'b1111_1100110_111_000000001_000000000,	// 2 =	rep	#1,##$4000
  32'b1111_1111000_000_000000000_000100000,	// 1 =	augs	#$4000
  32'b1111_1101011_101_000000000_000000000	// 0 =	clkset	#0 wc		(read 1st rom byte)
  };
  

  
  In the cold boot code, the first CLKSET reads the first address so that the next CLKSET can capture the data and read the next. There's one-CLKSET delay before the data comes out. So, the first location is not being skipped. You can always read this ROM during runtime, but no other cog can be executing CLKSET instructions, or else you'll be skipping addresses. Also, you'll have to know what the beginning of the ROM looks like, as it just wraps around and around, and it's not going to be at the start when you start reading it. For CLKSET to write the 8-bit ROM value, you'll need to use 'WC'.
  
  The reason that I repeated trailing instructions in the booti code was to simplify the synthesized logic. For example in the warm boot code, as long as bit2 of the selector is high, it will always read 'CALLD INA,PTRB'. To put 0's in the unused locations would have taken more logic, as they would be unique values.
  
  That's right about instructions being tight in the cold boot code. I could get around this by having
  PTRA reset to $1000. I kind of like things starting at the beginning, though.
  
  P.S. I just looked at that code and noticed that 'CLKSET #0' + 'WRBYTE 0,PTRA++' doesn't look like it should work because 0 is now INA. It's the data-forwarding circuitry that's making this function properly, despite a read-only location being used as the hub ROM recipient. I used to have data-forwarding turned off for INA/INB, because it wasn't needed, though it wouldn't hurt anything, because nobody writes INA/INB with any intent. I turned the data-forwarding back on, though, when INA/INB's shadow RAM registers got used for the debug interrupt vector set. This might have taken me a long time to debug if that data-forwarding was still shut off.