Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorTrouble interfacing FLASH pins to GPIO (retro game related)
Hey all,
Just got an Altera DE1 dev board using the Cyclone II, and I'm working on a simple test that is literally just connecting the FLASH chip to the GPIO_0 bus. I'm not performing any logic, but the FLASH does have code I wrote to it using the DE Control panel, and I've verified my code is correct. This is a test to send a small test ROM file from the DE1 to the GPIO ports which are connected to a Super Nintendo cartridge. I've done similar tests with Xilinx CPLD before (data lines ran direct to system, but address and control lines ran to CPLD), but this is my first foray into sending all pins through a FPGA. My problem is that the game will not boot! I've double and triple checked my wiring, and that's good. Each pin on the SNES just connects to one of the corresponding GPIO pins, which is routed to the FLASH pins through the FPGA. I've never run data lines through a PLD before, so I don't know if there is something special that they need in contrast to a regular address line? Or is there something glaringly obvious that I'm missing? I've attached my code in hopes someone can help me out. Also, I've already added FL_CE_N into my pin assignments as I noticed that it was missing originally.library ieee;use ieee.std_logic_1164.all;
entity mapper is
port(
FL_ADDR : out std_logic_vector(21 downto 0) ;
FL_DQ : out std_logic_vector(7 downto 0) ;
FL_CE_N : out std_logic;
FL_OE_N : out std_logic;
FL_RST_N : out std_logic;
FL_WE_N : out std_logic;
GPIO_0 : inout std_logic_vector(35 downto 0)
);
end mapper;
architecture arch of mapper is
begin
--CONTROL LINES
FL_CE_N <= '0';
FL_OE_N <= '0';
FL_RST_N <= '1';
FL_WE_N <= '1';
--DATA LINES
FL_DQ(7 downto 0) <= GPIO_0(21 downto 14);
-- ADDRESS LINES
FL_ADDR(17) <= GPIO_0(2);
FL_ADDR(16) <= GPIO_0(24);
FL_ADDR(15) <= GPIO_0(4);
FL_ADDR(14) <= GPIO_0(29);
FL_ADDR(13) <= GPIO_0(28);
FL_ADDR(12) <= GPIO_0(5);
FL_ADDR(11) <= GPIO_0(25);
FL_ADDR(10) <= GPIO_0(23);
FL_ADDR(9) <= GPIO_0(26);
FL_ADDR(8) <= GPIO_0(27);
FL_ADDR(7) <= GPIO_0(6);
FL_ADDR(6) <= GPIO_0(7);
FL_ADDR(5) <= GPIO_0(8);
FL_ADDR(4) <= GPIO_0(9);
FL_ADDR(3) <= GPIO_0(10);
FL_ADDR(2) <= GPIO_0(11);
FL_ADDR(1) <= GPIO_0(12);
FL_ADDR(0) <= GPIO_0(13);
end arch;17 Replies
Altera_Forum--- Quote Start --- Well, that explains why you had GPIO_0 as inout in the original code! Did you change SNES_DATA to inout? I'm guessing yes since you can't make an assignment to a port if it's an input. --- Quote End --- No it's set as an Out only. I don't need to read from it right now, so implementation as an Out seemed easier anyways.- Altera_Forum
Well, that explains why you had GPIO_0 as inout in the original code! Did you change SNES_DATA to inout? I'm guessing yes since you can't make an assignment to a port if it's an input.
- Altera_Forum
Fixed it.
Didn't have the Data pins set to 'Z' when not being accessed. SNES_DATA <= FL_DQ when (SNES_ROMSEL = '0') else "ZZZZZZZZ"; That works properly. - Altera_Forum
Well, then we have to start getting into I/O related stuff. What I/O standards have you set in the Pin Planner? What voltage are you using? Is anything working correctly at all?
- Altera_Forum
The test game won't boot onto the console. When I tie the LEDs to the FL_DQ lines I don't see any indication that they're going hi or low.
I haven't tried signaltap or sims yet, no. I've done this sort of thing with CPLD chips before with no trouble, but only controlling address and control pins - never with data pins. So that's why I'm hung up. It looks like it SHOULD work, but it doesn't. Any chance I need to things to high Z until the console boots? I tried that with using SNES_RST as an enable on all the FL pins but that didn't seem to do anything different either... - Altera_Forum
OK, so what's the behavior right now? What's not working correctly? Have you thought about adding SignalTap to verify functionality or performing a simulation? Your code looks fine.
- Altera_Forum
The HIROM mode isn't the concern here. I know that works, but you're right in the future I could add an IF on A15. The system does have an A22 but it's not needed for this implementation. I don't think we need to delve into that more right now as it's not important to my original problem.
My concern is just getting data actually read out to the console from the flash. - Altera_Forum--- Quote Start --- This instead routes FLASH pins A15-A21 to SNES pins A16-A22, which is needed for my test game to work. This also answers your last part, this address information is handled by the software in the ROM file. --- Quote End --- Your code uses flash address pins A15-20, not 21 (21 is pulled low) and SNES address A16-21 (you don't have addr 22 on the SNES side). Minor, but could this be the issue? You could also have an IF assignment on SNES_ADDR(15) to route the address pins appropriately depending on whether it's high or low.
- Altera_Forum--- Quote Start --- You have SNES_RST as an input to the FPGA and you're not doing anything with it. Should this be an output to the cart and set low (assuming it's active high)? What does SNES_ADDR(15) do? And what actually sets SNES_ADDR on your board/cart? Is there software somewhere else that does this? --- Quote End --- The RST line I was trying with different code versions, to try and use it as a output_enable on the SNES lines. It didn't make a difference, so I commented it out (not shown in the code I pasted, my mistake). SNES_ADDR(15) is a variable address that is only used (for the most part) when a game is accessed via HIROM mode. My test game is not HIROM, so A15 is not used. This instead routes FLASH pins A15-A21 to SNES pins A16-A22, which is needed for my test game to work. This also answers your last part, this address information is handled by the software in the ROM file.
- Altera_Forum
You have SNES_RST as an input to the FPGA and you're not doing anything with it. Should this be an output to the cart and set low (assuming it's active high)?
What does SNES_ADDR(15) do? And what actually sets SNES_ADDR on your board/cart? Is there software somewhere else that does this?
