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

[Altera_Forum]

I have a design which needs data preloaded into one or more of NVRAM and/or SRAM and/or SDRAM on a DE1. 

 I am using Quartus II Web Edition 11.1 sp1. I am not using Qsys, SOPC or NIOS, as the design is very simple, doesn't use NIOS etc. I am running on Linux.  The amount of data I want to preload is too much to pre-initialise onboard in the FGPA design itself (ie: in M4K or LE constructed memory).  Whats the simplest way I can do this?  (I am a beginner, and at the moment am getting to grips with Quartus, I'm rather hoping I don't have to learn Qsys, SOPC or NIOS to do this).  The Windows DE1 Control Panel doesn't seem to be available for Linux.  Thanks  {{{ Andy

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

I am so glad I have found the answers to the problems I was experiencing at last. You have been a godsend.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

Thanks for the tips. 

SignalTap in particular looks promising.  {{{ Andy

[Altera_Forum]

--- Quote Start ---   SignalTap in particular looks promising.   --- Quote End ---  Here's a quick getting started guide for you.  1) Bring up the SignalTap GUI.  2) Click on the setup tab (you'll see it near the bottom left, its probably selected by default).  3) Double click in the blank area. This will bring up the Node Finder GUI.  4) On the 'Filter:' menu, select 'SignalTap II: pre-synthesis'. Then click on the list button.  5) Double click on signals in the list on the left side of the GUI to add them to your signaltap signal list (they appear on the right). When you're done, click ok.  6) Select a sampling clock. On the right side of the GUI click on the button next to the clock source. It brings up the Node Finder GUI again. Select pre-synthesis again, and then select a clock source, eg., clkin_50MHz (or whatever your external clock is called).  7) Select a sample capture depth, eg., 2k (its on the right, under the clock selection)  8) Save the SignalTap setup (click yes when it asks you if it should add the setup to the current design), and resynthesize your design.  9) Download the new design and SignalTap should detect it (if not, on the right hand side of the Signaltap GUI, select the USB-Blaster and scan for the design).  Have fun!  Cheers, Dave

[Altera_Forum]

Have set up SignalTap. 

However, the jtag side of it seems unreliable, at least for me. After downloading a new .pof, I need to stop Quartus, kill jtagd, start up Quartus, and then start SignalTap. This kinda breaks the edit, compile, debug cycle, which is not nice. If I don't do this, when I click on "Run Analysis" the "Status" reports as "Invalid data received". If I then click on "Read Data" data does come back, and it looks kinda believable, but it can be very misleading, because it doesn't know where the sample begins and ends - the end of the sample can be to the left of the start of the sample. This caused me to (incorrectly) think my program counter had magically jumped backwards for no reason!  As I'm on 64 bit Fedora 14, to get Quartus working at all, I needed to put symlinks in for missing libraries, some of which support running jtagd - so my problems could be related to that. Having Quartus (including jtagd and SignalTap) work out of the box on more Linux flavours would be nice.  I also get 10 lines of warnings when the USB blaster stuff is loaded at boot time like this: udevd[470]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/51-usbblaster.rules:8  All in all, a great tool - shame about the jtagd problems.  {{{ Andy

[Altera_Forum]

--- Quote Start ---  Have set up SignalTap. However, the jtag side of it seems unreliable, at least for me.   --- Quote End ---    Yeah, I've noticed a few annoying things too.   For example, if working with system-console, I need to make sure I close any JTAG connections before starting signal tap (the GUI), and then open a JTAG connection in system-console before starting signaltap acquire.  Once I figured out the sequence that works, then its been ok.    --- Quote Start ---   I'm on 64 bit Fedora 14   --- Quote End ---    I have been doing my development under WinXP and Win7. I have got Quartus installed under VirtualBox + Ubuntu and Centos 6.2. Though I haven't played much with signaltap, so I don't know if the same sequence is required.    --- Quote Start ---   Having Quartus (including jtagd and SignalTap) work out of the box on more Linux flavours would be nice.   --- Quote End ---    From Altera's perspective, I'm sure they're thinking "Having less flavors of Linux to choose from would be nice ... " :)    --- Quote Start ---    I also get 10 lines of warnings when the USB blaster stuff is loaded at boot time like this: udevd[470]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/51-usbblaster.rules:8  All in all, a great tool - shame about the jtagd problems.   --- Quote End ---    I haven't noticed those errors ... I'll have to keep an eye out for them.  Cheers, Dave

[Altera_Forum]

FYI, problem solved now. 

Flash mapped into CPU memory space. SPI interface to SD card constructed and mapped into CPU IO space. Tiny on-chip ROM contains code to read SD and write flash. Really not that hard to do in the end. SPI is really quite straightforward, thanks to Wikipedia article and sample code on an Arduino site.  {{{ Andy

[Altera_Forum]

--- Quote Start ---  FYI, problem solved now. Flash mapped into CPU memory space. SPI interface to SD card constructed and mapped into CPU IO space. Tiny on-chip ROM contains code to read SD and write flash. Really not that hard to do in the end. SPI is really quite straightforward, thanks to Wikipedia article and sample code on an Arduino site.   --- Quote End ---    So your Z80 processor boots now? Cool! :)  Cheers, Dave

[Altera_Forum]

Actually its been booting and been doing lots of stuff for quite a while. 

For example, driving (testing) the text mode video adapter I built. The T80, combined with z80soc, gives a good model to start from. Its just until now, all the code had to fit in on-chip (FPGA M4K or LE) memory. In my design, I will eventually have >=72KB of ROM, which is too much to do this way.  {{{ Andy

[Altera_Forum]

Guys, 

 I have some doubts.  I'm building a system based on another one that I have (DE2_NET - it is in DE2 CD ROM), so I'm trying to understand what the function of each memory element.  We find these in the project (one of each):  Avalon MM Tristate Bridge Flash Memory EPCS Serial Flash Controller SDRAM  The Resect_vector is pointing to Flash Memory and the exception_vector to SDRAM.   My doubts:  I think that the the .elf is being downloaded to the flash memory, I'm correct? 1. What's the function of each one? 2. Why I need to use EPCS? 3. I only can use flash memory whe I'm using a Avalon MM Tristate Bridge?  Ps.: I'm reding some documentations but the differences are still not clear.  Thanks

[Altera_Forum]

Flash memory is probably a parallel memory chip while the EPCS is a serial configuration device for the FPGA. Both are able to contain the .elf file. Do you really have both memories on the board? Do you intend to use one for the FPGA configuration and another one for the software? 

With the EPCS there is a bootloader in the controller that copies the .elf contents to main RAM and runs the application there. With a parallel flash you have the choice between using a bootloader that would also copy the application to main memory, or execute the software directly from the flash.

[Altera_Forum]

Thanks, now I understand! 

 The flash memory is a paralel memory. I won't use the EPCS serial configuration. I'm storing the .elf into the flash and the library provides to me a software to copy the code and run over SDRAM.