Loading SRAM,SDRAM or FLASH on DE1, using Linux, without Qsys, SOPC or NIOS

Hi Andy,

Since you are a beginner, it would be useful for you to describe what you are trying to do, and what needs to be initialized. That way others can offer alternative solutions.

For example, it looks like the DE1 has Flash and an SD card. Flash is probably the easiest to use, since your logic in the FPGA can read it after power-on. However, perhaps the SD card would be more useful, since you can plug it into your PC and write data to it there.

But then again, perhaps you don't really need either of these. What you may really need is a connection between your PC and the DE1 so that you can transfer data to on-board memory, and then 'enable' your FPGA logic.

Cheers,

Dave

Dave,

I am (slowly) recreating an 8-bit computer from the late 80s.

As I can't post links yet, Google for "nyangau" and "memotech", and follow the link to REMEMOTECH.

I need quite a lot of ROM data persisted somewhere, so I am thinking Flash.

I need much more RAM than will fit on-chip, so I am thinking SRAM.

I am also thinking of using SDRAM as "Silicon disc".

As the flash has 70ns access time, I may need to add wait states to the CPU,

and perhaps arrange that the bootstrap code copy from flash to SRAM, make it read-only, so as to speed up future accesses.

In the interim before working out the above paragraph, I was planning to pre-load SRAM directly.

Being able to preload SDRAM is for bonus points really, as it would give me a way to preload much larger "disc" content.

But I'm actually wondering how practical this might be, due to the need for continual refresh.

{{{ Andy

Hi Andy,

The way a processor normally deals with this boot-strapping issue is;

1) The processor has a memory map. The memory map can contain; on-board RAM/ROM, external Flash, SRAM, SDRAM, etc.

2) When the processor boots, it fetches its first instructions from the reset vector. In your case, the reset vector could be located in on-chip ROM or off-chip flash.

3) The power-on or bootloader, or crt0.s (c runtime setup), code then sets up the system. On a microcontroller, this might mean setting up PLLs and peripherals, but with an FPGA, these can be designed to power-up in sane states. For you, its mainly setting up the processor registers, and relocating code from Flash to SRAM/SDRAM.

Your processor would copy code and data from Flash over to on-board SRAM, or external SRAM or external SDRAM.

Once the code is copied over, the boot code can setup the stack pointer (if your 8-bit micro has one), and then jump into your 'main' application.

Your micro's code will have a linker map telling it where to place read-only variables, read/write variables and data. You compiler will generate assembly instructions with relative offsets referencing the addresses in those locations. This is how the code looks after you have copied it from flash.

--- Quote Start ---

As the flash has 70ns access time, I may need to add wait states to the CPU

--- Quote End ---

The processor core most definitely needs some way to force wait-states

(unless you plan on running it at a few kHz clock rate).

The simplest system for you to design would be to create a wrapper to convert the processor into an Avalon-MM master. Then you can drop it into an SOPC or Qsys System. I know, it looks like a daunting amount of information to absorb, but the benefit is that you get the Flash, SRAM, and DDR controllers provided to you. You can also drop a NIOS or OpenRISC processor into your system and check that it works. That'll help in debugging.

--- Quote Start ---

Being able to preload SDRAM is for bonus points really, as it would give me a way to preload much larger "disc" content.

But I'm actually wondering how practical this might be, due to the need for continual refresh.

--- Quote End ---

Refreshing the DDR is the job of the DDR controller, not your CPU. So, as long as you use a provided DDR controller, you don't have to think about it (once you've figured out how to get it working).

Cheers,

Dave

Hey Andy,

http://www.nyangau.org/rememotech/rememotech.htm

I don't see any mention of Modelsim here.

If you really want to make sure things work, then I'd recommend getting a simulation of your core working under Modelsim first.

Don't even bother trying to debug in hardware until you can boot your processor under Modelsim.

Something as simple as a toggling I/O pin would be a major milestone. From there, it should be trivial to get it working in hardware.

In fact, its only an 8-bit micro, so it can almost certainly be designed to boot from an on-chip RAM.

Cheers,

Dave

Yes, I totally get the whole overview 2 posts above.

But I have no plan to use SOPC or Avalon, partly because I don't want to be tied to them, and partly because there are implementations out there I can model on that don't pre-req any or all of that.

If I had been designing a new system from scratch, for a real commercial purpose, then perhaps I'd be more inclined to use these tools, which seem to be step up a level in productivity.

My problem is as was originally stated, how to pre-load various forms of memory on the DE1 card, as simply as possible, given my current tooling.

Once, its in there, given the pre-existing success of others, I think my design should work fine.

Yes, I may need some wait state logic if I am to use Flash, but the Z80 (and thus T80) should support that fine.

I do appreciate that ModelSim etc are important.

Although its an 8-bit micro, the ROM+RAM requirements are non-trivial in terms of size.

So although I could put a small boot ROM into M4K, and although that could copy from Flash to SRAM, I would still need a lot of content initially loaded to Flash.

The SDRAM controller thought I had was this:

The mechanism to load SDRAM might involve a special .pof downloaded to the FPGA (isn't that how Control Panel works?), and this could include refresh logic.

But then I'd need to download my real .pof, also with refresh, and I'm wondering how long the SDRAM lasts before losing content, in the period in which the new .pof is being programmed into the FPGA.

Anyway, this aspect is less important.

{{{ Andy

--- Quote Start ---

Yes, I totally get the whole overview 2 posts above.

--- Quote End ---

Ok.

--- Quote Start ---

But I have no plan to use SOPC or Avalon, partly because I don't want to be tied to them, and partly because there are implementations out there I can model on that don't pre-req any or all of that.

--- Quote End ---

The recommendation is more from the standpoint of being able to leverage the existing, working infrastructure. Then you can incrementally remove the Avalon logic.

--- Quote Start ---

If I had been designing a new system from scratch, for a real commercial purpose, then perhaps I'd be more inclined to use these tools, which seem to be step up a level in productivity.

--- Quote End ---

Its not so much the tool we're interested in here, its the logic. The Flash interface, the SRAM interface, and the DDR controller. Altera/Terasic will supply those controllers with an Avalon interface. So to use them, its easier to bite the bullet and use them they way they were intended.

Here's another way to look at this; create an SOPC system containing a Flash, SRAM, and DDR controller, and an Avalon-MM master interface. Your Z80 external bus then just needs to map onto that Avalon-MM master interface. That Z80-to-Avalon-MM bridge can be part of the SOPC system, or can be external to it.

The SOPC system is just a means-to-an-ends.

--- Quote Start ---

My problem is as was originally stated, how to pre-load various forms of memory on the DE1 card, as simply as possible, given my current tooling.

--- Quote End ---

There's probably a Flash programmer for the board. That'll be based on something like an SOPC System containing a JTAG-to-Avalon-MM slave, or a PFL slave, and that design would be loaded into the FPGA, and then used to access and program the Flash. You could use that blindly to program the flash contents.

--- Quote Start ---

Once, its in there, given the pre-existing success of others, I think my design should work fine.

--- Quote End ---

That is true, assuming you have some logic to access the flash and copy it to SRAM or SDRAM.

--- Quote Start ---

The SDRAM controller thought I had was this:

The mechanism to load SDRAM might involve a special .pof downloaded to the FPGA (isn't that how Control Panel works?), and this could include refresh logic.

But then I'd need to download my real .pof, also with refresh, and I'm wondering how long the SDRAM lasts before losing content, in the period in which the new .pof is being programmed into the FPGA.

--- Quote End ---

It would not survive the reprogramming of the .pof.

You can load the SDRAM from your PC, however, you need to know how to use the JTAG interface. You can use a JTAG-to-Avalon-MM master inside an SOPC system, or you can just use the master directly, and interface to its Avalon-MM master interface (I'm sure its no more complicated than a Z80 external bus). Or you can use the SLD Virtual JTAG component directly.

The complicated part is that your JTAG interface and Z80 will both want to access the SDRAM, and so you need an arbiter. Its not hard to design, but its the kind of thing you get in SOPC Builder 'for free' so to speak.

So, you could build an SOPC system with the 'standard' memory interfaces provided by the DE1 examples, add a JTAG-to-Avalon-MM master to that, and use it to write to the memory on the board. Once you've convinced yourself that all works, you could add another Avalon-MM master interface and map your Z80 onto that. Then you can decide whether you want to replace the DE1 memory controllers with your own designs.

Cheers,

Dave

My DE1 has a S29AL032D70TFI04 4Mx8bit 70ns Flash.

I believe this must be hard wired into byte mode, as there is no such thing as a FL_BYTE_N pin in the DE1 pin map import file.

I have a T80 (Z80 clone) in my design, and I have mapped the Flash into its memory space.

I run the clock real slow, so as to avoid needing wait states, and so as not to violate the Flash timings.

FL_RST_N <= '1'; FL_CE_N <= '0';

FL_OE_N is lowered when I need to read from it.

FL_ADDR(12 downto 0) <= A(12 downto 0); -- so I'm not screwing up the addresses

FL_ADDR(21 downto 13) <= (others => '0'); -- well, it is effectively fixed tduring the test

FL_DQ is driven on a write, but 'Z' when a read, allowing the Flash to drive it.

When I read back (I've never written), the each byte returned is the negation of the bottom byte of the address.

This suggests to me I am reading something other than random static.

Can anyone confirm the factory default content of the Flash?

I have delayed the falling_edge of FL_WE_N signal to 40ns after the clock upon which the T80 asserts the address, data and WR_n signal, so as to be sure the address and data is stable before FL_WE_N falls, so that when the Flash reads the address, it is good.

I've tried erasing sectors, programming bytes and even something as simple as reading the device ID.

I can't seem to get the unlock sequence to work.

I'm using the byte command sequences in the datasheet, eg: for reading device ID, in Z80 assembler I have

LD A,0AAH

LD (8AAAH),A

LD A,055H

LD (8555H),A

LD A,090H

LD (8AAAH),A

LD A,(8002H)

This returns 0FEH, ie: -02H, rather than 0F9H as expected in the Flash datasheet.

I've tried using other sectors (in case it ships with the top and bottom ones locked).

Can anyone confirm other aspects of the factory shipped configuration of the Flash?

What could I have missed?

{{{ Andy

Does the DE1 come with a board test system (BTS) GUI? Most Terasic boards do. Start it up and use it to read the Flash.

Altera also has some flash programmer tools. Perhaps you could use one of those to simply read the flash to confirm contents.

You can also use SignalTap II to probe what is on the flash interface. That'll allow you to see the flash address, control signals, and finally the data. If its not what you see in your Z80, then you'll know the problem is not with the flash, but with the Z80.

Cheers,

Dave

Thanks for the tips.

SignalTap in particular looks promising.

{{{ Andy