.... 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.
.... 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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 : )
Comments
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.
When you get to that, have a quick look over here, at my suggested tweak to the SPI Flash preamble.
Ok. Thanks.
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.
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.
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.
// 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] }; // rSKIP/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.
Let me check.
Sorry I dropped the ball here.
Here is the AHDL code that connects the SD card on the DE2-115 board:
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.
Here is a DE2-115 v32b image that connects directly to the SD pins. This may work.
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.
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.
Does anyone have any idea why that card didn't work?
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?
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.