Hi,

I bought the new ordb2a-ep4ce22 and now I have finally some time to play with (work on) it. The first steps went well but now I have problems going further with RTL development.

I plan to port my 1-wire master and SPI (dual/quad) master to the board, so I will have to edit the RTL, simulate, synthesize and later write Linux drivers (with help from a friend).


The steps from Get_Started.txt and Running_SW_on_FPGA_board.txt went well, I was able to load the FPGA, load the linux image over GDB, login into Linux, connect ethernet, ping around. I did not try to load the SPI flash.

Another thing I was able to do without much trouble was FPGA synthesis with Quartus. There were some problems installing Quartus on Ubuntu (I did not install into the virtual image I do not have enough RAM for this). The steps I had to take were something like this:
1. download Quartus web edition
2. start a terminal and:
$ cd Downloads
$ sh 11.1_173_quartus_free_linux.sh # setup fails to run
$ cd 11.1_173_quartus_free_linux
$ sudo bash setup
3. the suggested path for instalation is /opt/altera/11.1 for both Quartus and ModelSim, regardless of service pack (this paths should be added/updated inside ~/.bashrc)
4. repeat for Quartus service pack, and ModelSim (only the service pack is needed here)
5. run Quartus and open project
orpsocv2/boards/altera/ordb2a-ep4ce22/syn/quartus/ORDB2A.qpf
6. try to compile, there was a difference between the old and new megacore libraries, comment out a line in a source file (look at errors)
7. loaded the board and connected to the monitor over USB/UART

Then things stopped going fluently, I hope somebody helps me or at least places my complaints on a TODO list. I will be able to continue by myself, but slowly.

I will describe the next issues:
1. no ordb2a-ep4ce22 simulation environment out of the box
2. no update path, version control support,
3. no way to be sure what is loaded into the FPGA
4. outdated Verilog tools


1. no ordb2a-ep4ce22 simulation environment out of the box
-----------------------------------------------------------------------------
A simulation environment for the root top design is available but there is no environment for the board itself, by default it is configured to Modelsim, which is not installed. So I installed ModelSim, but there are further issues.


2. no update path, version control support, reference repository
---------------------------------------------------------------------------------
The RTL, bench source directories are without a link to SVN/GIT repositories. I was also not able to find such repositories online. The ordb2a-ep4ce22 repo is nowhere to be found! If I would like to make a patch for RTL/bench/environment I would have to first create a git repository (which is simple). There is also no way to update to the latest master, loading a new ISO image is not a good update path.
A simple way to fix this would be to use a git clone of the main repo, with only read permissions, the user would be later able to change git setting or just use the repo for local commits. It would also be possible to update to master.
I think most of you would agree that new users should be helped with learning version control tools from the beginning.
The best option for me would be to make a form on github.
For now an user wishing to follow his changes can create a git repo in each source directory, or for example on top:
$ cd ~/soc-design
$ git init .
$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com
$ git commit -m "initial commit of unmodified sources" .
From here on all modifications can be compared to the original.


3. no way to be sure what is loaded into the FPGA
-----------------------------------------------------------------
Usually FPGA boards have a programmable pin driven LED, so there is always a way to check if programming went right by writing some blinkenlights RTL.
I do not know, if it is possible to use Altera toos to access the board. For example to read the programmable ID, verify programming, use SignalTap, ...
I was not able to identify the build from the monitor, an RTL hard coded version register displayed by the monitor would help.


4. outdated Verilog tools
-------------------------------
This is not a big issue. The iverilog, gtkwave versions are outdated and verilator is not installed. The latest versions of this software can be copied from my PPA to an OpenCores PPA.
https://launchpad.net/~team-electronics/+archive/ppa
Verilator is without SystemC support, due to licensing issues (permission to distribute SystemC is not granted).


If somebody is interested into my SPI/dual/quad code, here it is:
https://github.com/jeras/sockit_spi


Regards,
Iztok Jeras

Further attempts to run simulation.

Based on the documented example I am trying to run:
$ cd ~/soc-design/orpsocv2/boards/altera/ordb2a-ep4ce22/sim/run
$ make rtl-test TEST=or1200-simple VCD=1

I did not check exactly why, but ModelSim shell code was searching for executable binaries in "/opt/altera/11.1/modelsim_ase/bin/../linux_rh60/*" so I created a synbolic link
$ cd /opt/altera/11.1/modelsim_ase/
ln -s linux linux_rh60

Than there is a bug in /home/openrisc/soc-design/orpsocv2/boards/altera/ordb2a-ep4ce22/sim/run/../../bench/verilog/include/eth_stim.v (and probably other eth_stim.v files)
doubled ;; at the end of some lines. Some define macros at the beginning of the file should have semicolon at the end removed.

Than make tried to run an optimization tool, that is probably only available in the paid version of ModelSim /opt/altera/11.1/modelsim_ase/bin/../linux_rh60/vopt, so based on a suggestion from a Makefine I added the MGC_NO_VOPT option to the make call:
$ make rtl-test TEST=or1200-simple VCD=1 MGC_NO_VOPT=1

The system still does not compile, complaining, orpsoc_top module can not be found in the library.

I will continue tomorrow.

Regards,
Iztok Jeras

Hi Iztok,

Thank you for the feedback, and it's nice to hear that there are people interested in extending and improving the ecosystem around the board. To address some of your issues

The errors from the megacore libraries seem to have been introduced in Quartus 11.1 which was released right after we released the boards. This will have to be updated in the next release.

1. Unfortunately, we need modelsim to simulate with the Altera primitives, unless someone reverse-engineer all the used primitives and supply them in a library. I haven't installed ModelSim myself, so I don't know what problems you are seeing. Could you please add some details and we can see if we can fix it.

2. The ordb2a port will be included in the main ORPSoC tree in the future, but it could need some polishing before that, and we wanted the VM to be available along with the board. When it is included, it will be easier to send patches and get updates from the main repository

3. I've been thinking about that too, and I think we should provide a small blinking light program, either in the bootrom, or as a separate program. Regarding the version register, there is an ongoing project to identify SoCs in the planning stage. In the meantime, an arbitary identification register could be placed on an empty address on the wishbone bus.

4. Thanks. It's good to know that there are more updated tools for those who need it. You are always welcome to host your cores on opencores too if you would like that.

Hopefully someone can help sort out the simulation issues. I haven't had time myself to look into it, but I think others can help you

--
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design

Hi there,

Using the provided Virtualbox image, everything in the Get_Started.txt and Running_SW_on_FPGA_board.txt worked great for me as well, except for programming external SPI flash. After following the SPI flash instructions in the latter text file and bringing up picocom, I see no output and am not presented with a prompt -- I'm not too sure if the FPGA isn't loaded, or if it's a problem with the flash contents.

I first performed steps 1, 2, 3, and 4a (boot Linux from flash). After reconnecting the board and starting up picocom, I found that the board was unresponsive. (No output, no prompt in response to Enter.)

In an attempt to revert back to the "out of the box" state with the bootloader, I then unplugged and reconnected the board, and then performed steps 1, 2, 3, and 4b. Again, after power cycling and bringing up picocom (/dev/ttyUSB2), the board still appears unresponsive.

Anyone else have similar issues or advice on gathering some more helpful debugging information? I've attached a log from attempting to reflash the FPGA and bootloader -- nothing seemed odd to me, but this my first dive into the OpenRISC world, so I certainly could be missing something. :)

Thank you for your time and help,
Jon

It seems I managed to forget to attach the mentioned log...should be attached to this post.

Yes,
same with me. Thought could be my fault, for everything worked so great till I came to that point. Further investigation make me believe that the write command (spiflash-program -p) isn't that reliable it should be. The erase command (spiflash-program -e) works for sure, because issued once the spi-flash is zeroed. You can prove that issuing the read command (spiflash-program -l). That's the reason why there is no way back, once you issues the command. I think the read command also works ok, because if you read back twice and compare the results, you get no difference. But if you program the flash and read back the contents you never get the same result (though the readback bears a resemblance to what you tried to write). Since I've bought two boards I can eliminate any possibility of an individual hardware problem.
I tried to investigate what could be the problem, but �
Hopefully someone else knows how to solve.

Thanks a lot everybody spending time and sharing knowledge with this forum/group
Martin

Hi, we will investigate this and get back to you.

I think I have figured out out what the problem is with your SPI flash programming. The hint is in your programming log, where it says "Manufacturer 20 type 20 capacity 14". We have had two different SPI flash chips, and they have different chip erase commands available; unfortunately, spiflash-program used the one only available on the Winbond chip, and the one you have is an ST/Numonyx device. They both comply with a JEDEC standard for SPI flashes, but I haven't found it so couldn't tell which command to use at first.

This issue has been remedied in a more recent release of spiflash-program, currently in our updated VM image; if you recompile spiflash-program you could do this change yourself, just change chiperase from 0x60 to 0xc7. A workaround is to erase using the region erase command instead, which requires specifying a size to erase (for instance, "spiflash-program -l 1048576 -e" should erase the entire chip, albeit slowly). When successfully erased, the data should read out as all FF, not 00.

The reason your board is not configuring is that the flash is effectively programmed with the bitwise AND of both configurations; naturally, the checksum for that will be wrong, and it retries in perpetuity. Really sorry for the trouble, and let me know how it goes!

Hi there,

Rebuilding spiflash-program with the correct chip erase command did the trick -- I'm now back to the default FPGA + bootloader setup. Thank you for the quick response and taking the time to explain what the underlying issue was! :)

Just a couple more questions/comments:

(1) I tried step 4a, but my board does not appear to be booting Linux. However, I see that this step "requires a large SPI flash." According to http://opencores.org/or1k/Ordb2a-ep4ce22 I see that the on board SPI flash is 1MB (looks like a ST W25P80VP, as you pointed out), but vmlinux.sizebin is 4MB. So I take it I'm writing only a quarter of the kernel to flash...well, that could certainly yield a bad CRC calculation at boot. :P

As far as booting Linux from flash on this board, should I just fetch myself a different pin-compatible chip, or is booting Linux off the SDHC (via orpmon or U-boot perhaps?) supported/ongoing/planned? Admittedly, I still have to spend time familiarizing myself with the project and documetation...just curious what the "preferred" method is.

(2) Just for completeness (or a trail of breadcrumbs for anyone that might run across this forum thread...) I am using OpenRISC_Ubuntu_2011-12-15.vdi.bz2. Line 183 of spiflash-program.c contains the erase code definition.

Thanks again!
Jon

That is correct, the 5MB Linux image won't fit in a 1MB chip (ST/Numonyx M25P80). The 8MB chip we've used (Winbond W25Q64BV) is in fact not pin compatible, but has an overlapping footprint so occupies the same spot.

With the SD controller enabled, orpmon can boot Linux from a microSD, but it is a bit finicky (incorrect card type identification, slightly off filesystem code, and memory management that breaks serial output). I'm working as time and energy allows on an updated controller with u-boot support, intended to also provide enough functionality for use from Linux.

As for #2, thanks. Hopefully we'll get the next image update sorted.

The ordb2a-ep4ce22 looks good so far. A few teething troubles getting it working on suse 12.1
but it seems to work.

Im now about to program it. The schematic shows two spi eeproms U6 and U7 are W25Q64BV, but I have U6 fitted with a 93C66 device.

if I swap U7 for the larger winbond W25Q64BV. Do I need to program it before soldering to the board?
or can I do it once soldered?

As I understand it the bootloader, RTL and linux are programmed into U7
What is programmed into the U6 eeprom?

Thanks Chris

The 93LC66 is U9 and it is used for configuration for the USB interface FT4232.
On the board you could mount either an SO16 wide or a SO8 package for the SPI FLASH.
These share the same PCB space so only one can be mounted.

If you need larger capacity FLASH SO16W is a good choice. For example
http://search.digikey.com/scripts/dksearch/dksus.dll?vendor=0&keywords=w25q64bvsfig-nd

You can program the device on board.

/Michael Unneback
ORSoC