Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 133 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1130131133135136160

Comments

  • cgraceycgracey Posts: 14,134
    I just added 16-cog versions to the FPGA images at the top of this thread.
  • jmgjmg Posts: 15,161
    cgracey wrote: »
    .... So, we are missing 200MHz by something like 180ps. Timing will stretch out a little more in the final layout.

    What is the Vcc/Temp target for that -180ps miss ?
    It is common for MCU suppliers to give MHz/Vcc curves, and a tighter Vcc spec, gives higher clock speeds. (or a lower Max temp)
    Being Static RAM based, P2 should operate over quite a range of Vcc, including some quite low Ram-retention value.
  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    .... So, we are missing 200MHz by something like 180ps. Timing will stretch out a little more in the final layout.

    What is the Vcc/Temp target for that -180ps miss ?
    It is common for MCU suppliers to give MHz/Vcc curves, and a tighter Vcc spec, gives higher clock speeds. (or a lower Max temp)
    Being Static RAM based, P2 should operate over quite a range of Vcc, including some quite low Ram-retention value.

    180MHz at worst process corner, 90% voltages, 150 C temperature.
  • jmgjmg Posts: 15,161
    cgracey wrote: »
    ... I'll get into the ROM code. We need to have that ready by the 22nd, I believe.
    Not very long...
    When you get to that, have a quick look over here, at my suggested tweak to the SPI Flash preamble.

  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    ... I'll get into the ROM code. We need to have that ready by the 22nd, I believe.
    Not very long...
    When you get to that, have a quick look over here, at my suggested tweak to the SPI Flash preamble.

    Ok. Thanks.
  • Cluso99Cluso99 Posts: 18,069
    Just downloaded v32a.

    Wasn't there a way to compile with pnut without a P2 FPGA board present, including inspection of the label addresses? Tried Ctl-G without success :(
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-04-04 08:24
    Cluso99 wrote: »
    Just downloaded v32a.

    Wasn't there a way to compile with pnut without a P2 FPGA board present, including inspection of the label addresses? Tried Ctl-G without success :(

    Try ctrl+M

    It's under the FILE menu as "list toggle PASM" - the M in PASM is the shortcut.
  • Cluso99Cluso99 Posts: 18,069
    Thanks Peter. Was fairly sure it was available but missed it in File even tho' I looked.
  • evanhevanh Posts: 15,628
    I had to be told about that one too. Big improvement for me. I think the naming makes it look like it doesn't produce any downloadable files.

  • Cluso99Cluso99 Posts: 18,069
    Chip,
    May I mention again, that it would be nice if the SPI FLASH interface could use both a combined DI/DO (P59) pin and a separate DO (P59) and DI (P58). It should be simple enough to look for the reply on both P59 & P58, and if present on P58 then use separate pins from then on. This gives the designer a choice.

    The SD interface requires separate DI and DO pins.
  • cgraceycgracey Posts: 14,134
    Cluso99 wrote: »
    Chip,
    May I mention again, that it would be nice if the SPI FLASH interface could use both a combined DI/DO (P59) pin and a separate DO (P59) and DI (P58). It should be simple enough to look for the reply on both P59 & P58, and if present on P58 then use separate pins from then on. This gives the designer a choice.

    The SD interface requires separate DI and DO pins.

    Got it.. Thanks.
  • Chip
    Can you confirm a change in GETBRK D wc
    In particular the skipk[3:0] (skip CALL depth)
    On entry to a skip sequence in V32a the value starts at 1.
    On exit from the sequence the value is 0.
    In V32pre it starts at 0 on entry.
  • cgraceycgracey Posts: 14,134
    ozpropdev wrote: »
    Chip
    Can you confirm a change in GETBRK D wc
    In particular the skipk[3:0] (skip CALL depth)
    On entry to a skip sequence in V32a the value starts at 1.
    On exit from the sequence the value is 0.
    In V32pre it starts at 0 on entry.

    I will be in the office soon and I will get this debug stuff updated. I will start with the GETBRK instruction.
  • cgraceycgracey Posts: 14,134
    Here are the data returned by GETBRK:
    // getbrk
    
    wire [33:0] getbrk_czr	=
    
    	i[wc] ? i[wz]	? {	brk_isr ? !brk_pass[1] : int_stall,	// c	getbrk with wcz		(only show brk_pass in brk isr)
    				hubs,					// z
    				brk_code & {8{brk_isr}},		// r	(only show brk_code in brk isr)
    				!brk_pass[1] && brk_isr,		//	(only show brk_pass in brk isr)
    				csc_active,
    				xfr_active,
    				mem_mode,
    				int_select[3:1],
    				int_state[3:1],
    				int_stall,
    				hubs }
    
    			: {	skipb[0],				// c	getbrk with wc
    				1'b0,					// z
    				skipk[3:0],				// r
    				skipm,
    				lut_share,
    				stk_xbyte,
    				xbytet[8:0],
    				trap[15:0] }
    
    			: {	1'b0,					// c	getbrk with wz
    				~|skipb,				// z
    				skipb[31:0]	};			// r
    
    



  • cgraceycgracey Posts: 14,134
    edited 2018-04-04 13:24
    ozpropdev wrote: »
    Chip
    Can you confirm a change in GETBRK D wc
    In particular the skipk[3:0] (skip CALL depth)
    On entry to a skip sequence in V32a the value starts at 1.
    On exit from the sequence the value is 0.
    In V32pre it starts at 0 on entry.

    SKIP/SKIPF/EXECF/XBYTE all reset it to zero. It increments only on a CALL/CALLPA/CALLPB and decrements only on a RET/_RET_.

    See the new bit assignments in the post above. Things have changed from before.
  • cgraceycgracey Posts: 14,134
    A bug was discovered the other day in v32a, where writes to hub via SETQ(2)+WRLONG were sometimes writing incorrect data in the second long. This has been fixed and a new v32b is available at the top of this thread.
  • I'm trying to test the SD card slot in the DE2-115, but I can't get it to work. My understanding is that the CS, CLK, DO and DI are mapped to pins 61, 60, 59 and 58 when SW17 is up. Is that correct? I can't get my code or Cluso's test code to work.
  • cgraceycgracey Posts: 14,134
    Dave Hein wrote: »
    I'm trying to test the SD card slot in the DE2-115, but I can't get it to work. My understanding is that the CS, CLK, DO and DI are mapped to pins 61, 60, 59 and 58 when SW17 is up. Is that correct? I can't get my code or Cluso's test code to work.

    Let me check.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-04-10 21:12
    I tried various mappings of pins 58-61 with the SD pins, and with SW17 up and down, and with the flash chip removed, but none of that worked. So I'm assuming that the SD card holder isn't connected in v32a for the DE2-115.
  • cgraceycgracey Posts: 14,134
    Dave Hein wrote: »
    I tried various mappings of pins 58-61 with the SD pins, and with SW17 up and down, and with the flash chip removed, but none of that worked. So I'm assuming that the SD card holder isn't connected in v32a for the DE2-115.

    Sorry I dropped the ball here.

    Here is the AHDL code that connects the SD card on the DE2-115 board:
    	-- die i/o pins
    	
    	pinb_tri[].in		= h.pin_out[63..32];		-- pins 63..32
    	pinb_tri[].oe		= h.pin_dir[63..32];
    	tio[63..58]			= pinb_tri[63..58].out;
    
    	case (sw[17]) is
    		when b"0" => h.pin_in[63..32] = (tio[63..62], sd_data3_cs, sd_clk_sclk, sd_data0_do, sd_cmd_di, b"00000000", sw[17..0]);
    		when b"1" => h.pin_in[63..32] = (tio[63..58], b"00000000", sw[17..0]);
    	end case;
    
    	ledr[17..0]			= h.pin_out[49..32];		-- led outputs
    
    
    	pina_tri[].in		= h.pin_out[31..0];			-- pins 31..0
    	pina_tri[].oe		= h.pin_dir[31..0];
    	io[28..0]			= pina_tri[28..0].out;
    
    	h.pin_in[31..0]		= (key[3..1], io[]);
    
    
    	sd_tri[].in			= h.pin_out[61..58];		-- sd card
    	sd_tri[].oe			= h.pin_dir[61..58] & (!sw[17], !sw[17], !sw[17], !sw[17]);
    	sd_data3_cs			= sd_tri[61].out;
    	sd_clk_sclk			= sd_tri[60].out;
    	sd_data0_do			= sd_tri[59].out;
    	sd_cmd_di			= sd_tri[58].out;
    

    Here is the whole file. This is actually at 4 spaces per tab, so it looks weird here. It won't let me attach the .tdf file, so here it is:
    -------------
    -- DE2_115 --
    -------------
    
    include "sim.inc";
    include "plld.inc";
    
    subdesign top
    (
    	clock_50					: input;			-- clock input
    
    	inp_resn					: input;			-- reset
    
    	dac					[35..0]	: output;			-- dac outputs (9:9:9:9)
    
    	tio					[63..58]: bidir;			-- top digital I/Os [63..58]
    	io					[28..0]	: bidir;			-- bottom digital I/Os [28..0]
    
    	sw					[17..0]	: input;			-- switch inputs [43..32]
    	key					[3..1]	: input;			-- pushbutton inputs [31..29]
    
    	sd_data3_cs					: bidir;			-- sd card SPI pins
    	sd_clk_sclk					: bidir;
    	sd_data0_do					: bidir;
    	sd_cmd_di					: bidir;
    
    
    	ledg				[7..0]	: output;			-- green led outputs
    	ledr				[17..0]	: output;			-- red led outputs
    )
    
    variable
    
    	h							: sim;
    
    	pllx						: plld;
    
    	fclk						: node;
    
    	clkcfgi				[5..0]	: dff;
    	clkcfg				[5..0]	: dff;
    	clkadd				[7..0]	: dff;
    	clkacc				[7..0]	: dff;
    	clkbuf						: dff;
    	clk							: node;
    
    	resn_tmr			[16..0]	: dff;
    	reset						: node;
    
    	pinb_tri			[63..32]: tri;				-- pins
    	pina_tri			[31..0]	: tri;
    	sd_tri				[61..58]: tri;
    
    
    begin
    
    	-- clock
    
    	pllx.inclk0			= clock_50;
    	fclk				= pllx.c0;
    
    	clkcfgi[].clk		= clk;
    	clkcfgi[].d			= (h.cfg[7..4], h.cfg[1..0]);
    
    	clkcfg[].clk		= fclk;
    	clkcfg[].d			= clkcfgi[].q;
    
    	clkadd[].clk		= fclk;
    	case clkcfg[].q is
    		when b"1111_11"	=> clkadd[].d = h"80";	-- PLL16X 80    MHz
    		when b"1110_11"	=> clkadd[].d = h"78";	-- PLL15X 75    MHz
    		when b"1101_11"	=> clkadd[].d = h"70";	-- PLL14X 70    MHz
    		when b"1100_11"	=> clkadd[].d = h"68";	-- PLL13X 65    MHz
    		when b"1011_11"	=> clkadd[].d = h"60";	-- PLL12X 60    MHz
    		when b"1010_11"	=> clkadd[].d = h"58";	-- PLL11X 55    MHz
    		when b"1001_11"	=> clkadd[].d = h"50";	-- PLL10X 50    MHz
    		when b"1000_11"	=> clkadd[].d = h"48";	-- PLL9X  45    MHz
    		when b"0111_11"	=> clkadd[].d = h"40";	-- PLL8X  40    MHz
    		when b"0110_11"	=> clkadd[].d = h"38";	-- PLL7X  35    MHz
    		when b"0101_11"	=> clkadd[].d = h"30";	-- PLL6X  30    MHz
    		when b"0100_11"	=> clkadd[].d = h"28";	-- PLL5X  25    MHz
    		when b"0011_11"	=> clkadd[].d = h"20";	-- PLL4X  20    MHz
    		when b"0010_11"	=> clkadd[].d = h"18";	-- PLL3X  15    MHz
    		when b"0001_11"	=> clkadd[].d = h"10";	-- PLL2X  10    MHz
    		when b"0000_11"	=> clkadd[].d = h"08";	-- PLL1X  5     MHz		invalid mode, but overcomes 'others' case
    		when b"xxxx_10"	=> clkadd[].d = h"08";	-- XTAL   5     MHz
    		when b"xxxx_01"	=> clkadd[].d = h"01";	-- RCSLOW 625   KHz
    		when b"xxxx_00"	=> clkadd[].d = h"20";	-- RCFAST 20    MHz
    	end case;
    
    	clkacc[].clk		= fclk;
    	clkacc[].d			= clkacc[].q + clkadd[].q;
    
    	clkbuf.clk			= fclk;
    	clkbuf.d			= clkacc[7].q;
    
    	clk					= clkbuf.q;
    	h.clock				= clk;
    
    
    	-- reset/select
    
    	resn_tmr[].clk		= clk;
    
    	case (inp_resn & !h.rst) is
    		when b"0" => resn_tmr[].d = 0;
    		when b"1" => resn_tmr[].d = resn_tmr[].q + (b"0000000000000000", !resn_tmr[16].q);
    	end case;
    
    	reset				= !resn_tmr[16].q;
    
    	h.reset				= reset;
    
    
    	-- die dac outputs
    
        dac[35..0]			= (h.dac[31..24], b"0", h.dac[23..16], b"0", h.dac[15..8], b"0", h.dac[7..0], b"0");
    
    
    	-- die i/o pins
    	
    	pinb_tri[].in		= h.pin_out[63..32];		-- pins 63..32
    	pinb_tri[].oe		= h.pin_dir[63..32];
    	tio[63..58]			= pinb_tri[63..58].out;
    
    	case (sw[17]) is
    		when b"0" => h.pin_in[63..32] = (tio[63..62], sd_data3_cs, sd_clk_sclk, sd_data0_do, sd_cmd_di, b"00000000", sw[17..0]);
    		when b"1" => h.pin_in[63..32] = (tio[63..58], b"00000000", sw[17..0]);
    	end case;
    
    	ledr[17..0]			= h.pin_out[49..32];		-- led outputs
    
    
    	pina_tri[].in		= h.pin_out[31..0];			-- pins 31..0
    	pina_tri[].oe		= h.pin_dir[31..0];
    	io[28..0]			= pina_tri[28..0].out;
    
    	h.pin_in[31..0]		= (key[3..1], io[]);
    
    
    	sd_tri[].in			= h.pin_out[61..58];		-- sd card
    	sd_tri[].oe			= h.pin_dir[61..58] & (!sw[17], !sw[17], !sw[17], !sw[17]);
    	sd_data3_cs			= sd_tri[61].out;
    	sd_clk_sclk			= sd_tri[60].out;
    	sd_data0_do			= sd_tri[59].out;
    	sd_cmd_di			= sd_tri[58].out;
    
    
    	-- <DEBUGGING ONLY>
    
    	ledg[]				= h.led[7..0];
    
    end;
    

    It looks to me like this should work, but I've had some strange experiences where trying to make pins map-able hasn't worked in AHDL. I could compile a fixed DE2-115 version with the SD signals certainly attached. I'll start that now. Meanwhile, maybe you can see some error in this file.

  • cgraceycgracey Posts: 14,134
    Dave Hein,

    Here is a DE2-115 v32b image that connects directly to the SD pins. This may work.

  • Is XORO32 still the slowest instruction? Did our recent change make much difference?
  • cgraceycgracey Posts: 14,134
    TonyB_ wrote: »
    Is XORO32 still the slowest instruction? Did our recent change make much difference?

    It got sped up in two ways. First, I increased its priority in the result mux. Second, we compute the first 16-bit PRN prior to iteration. Those two changes pushed it way down.

    Currently, the critical paths in the design are all the big hub RAM instances' Q outputs, which go straight into registers. Not much we can do about that, but it's good to know that we've got everything else patted down.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-04-11 02:43
    cgracey wrote: »
    Here is a DE2-115 v32b image that connects directly to the SD pins. This may work.
    I got my code to work with that image. However, it appears the problem was with the SD card I was using. I could never get it to work with the SD card I was using, even though it works fine in my PC. I tried a different card, and it worked. I also tried the FPGA image in the v32b zip file, and it works OK when SW17 is in the lower position.

    I could not get Cluso's SD test program to work at all. I only have the binary for that program, and I'm guessing it's not compatible with V32.

    Chip, thanks for your help.

  • cgraceycgracey Posts: 14,134
    edited 2018-04-11 03:09
    Thanks for your interest, Dave!

    Does anyone have any idea why that card didn't work?
  • It's a 4GB SanDisk card that I bought several years ago. My SD driver is adapted from one that was used with FSRW. I added prints to the driver, and it times out in a loop where it sends a command of 55, and then a command of 41, and then waits for the response to be different than 1. It always returns a value of 1. I'm not sure what that means. It's been a while since I've looked at the SD protocol.
  • Cluso99Cluso99 Posts: 18,069
    Dave Hein wrote: »
    cgracey wrote: »
    Here is a DE2-115 v32b image that connects directly to the SD pins. This may work.
    I got my code to work with that image. However, it appears the problem was with the SD card I was using. I could never get it to work with the SD card I was using, even though it works fine in my PC. I tried a different card, and it worked. I also tried the FPGA image in the v32b zip file, and it works OK when SW17 is in the lower position.

    I could not get Cluso's SD test program to work at all. I only have the binary for that program, and I'm guessing it's not compatible with V32.

    Chip, thanks for your help.

    No, the code I last posted is not v32 object compatible. I will post the code when I get home tonight (as soon as I can). It has some nice debugging so I should be able to tell how far it gets in the boot sequence.

    Meanwhile, would you mind posting the cards brand, size, and any other info. Thanks.
    Is it SDHC or standard SD and Class?
    Formatted as FAT32 or FAT16?
    I presume microSD?
  • My FAT32 in Tachyon P1/P2 has a whole heap of debugging built-in if you want to try it. You can even issue the commands line by line and look at responses plus there is a utility that reads and lists the card information from cid and csd. Whatever the reason it would be good to know. You can try this out on a P1 or P2 but there is a binary image for P1 V5 in the Dropbox with EASYFILE or you can load P2 with TAQOZ and then paste TAQOZ.FTH into the terminal, type MOUNT and see what happens.
  • Cluso99Cluso99 Posts: 18,069
    I am home, but my laptop has been commandeered by the wife to play Netflix on our TV. We got interested in binge watching Continuim and a couple of nights ago I watched ahead so she's in catch-up mode ;)

    Will post SD code later tonight or the morning. It displays CSS, cid and the sectors read and the card type. It's not as detailed as older versions but they we're P1 versions only.
  • Ray, you need a chromecast dongle, then you only need a laptop or phone to start the netflix playing, and you can have the laptop back for things that really matter : )
Sign In or Register to comment.