Running linux on Altera Stratix 5 - nios

I want to run linux on my Altera Stratix 5. One possible way is running uClinux using Nios 2. Will this approach work for the Stratix 5? Are there any other approaches to achieve this?


First of all, you can Run uClinux on Altera FPGAs easily in no time. I did it before using Altera DE2-70 and DE2-115. It will be exactly the same for Altera Stratix V.
For Altera FPGAs, the only approach to to run uClinux or other RTOS is NIOS II. However, you need to know how use Qsys or SOPC Builder in order to generate NIOS 2 based system.
To run uClinux faster in no time, download Altera university ip cores, because it contains all the required cores to develop your system in a very short time.

Related

Linux embedded sched_setscheduler workload

I am developing a testing approach for embedded software, and would like to test it on a POSIX based, real world application that uses scheduler Linux functions (e.g. sched_setscheduler).
It is relatively easy to find open source software that is using POSIX threads and locks (e.g. http://ctrace.sourceforge.net). However, I cannot find any real world application to use Linux scheduling as well. Google drives me in a direction of WCET calculation.
Does anyone know any open source, embedded, POSIX based software, that uses scheduling and affinity Linux functions?
Thank you.

Have a look here: https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/. and here: http://elinux.org/Realtime_Testing_Best_Practices These are artificial test sets for realtime testing Linux kernels. Basically they work on parallel and prioritized CPU load, scheduling and missing computation deadlines.

Simulating target on PC

I'm doing a project in C language that runs on a target with vxWorks operating system.
I would like to run my code on PC also for two reasons:
The HW of the target is not available yet, and i want to start testing my SW.
Even when the target will be ready it will be easier for me perform testing and simulations on a PC.
Is there some interesting way to do it?
Thanks.

You have three choices:
Use the VxWorks Simulator (vxsim) - it's part of the Workbench and can be accessed like a real target
Pros:
Easy to to use
Integrated into workbench
Debug functionality and good control of the system
Doesn't need any further hardware
Documentation (check Wind River VxWorks Simulator User's Guide)
Cons:
Not the real target system (but this is a con for all points here)
Use a x86 machine and boot eg. through ftp
Pros:
You can test booting via network and network
Cons:
The system may lack of drivers
Possible you have to change kernel
Debug is not as good as vxsim
The difference to your target may be realy big
Use a Virtual Maschine
Pros:
Runs on same pc - no further hardware required
Possible to test several bootloaders
Cons:
Not possible to simulate the target cpu etc.
A VM is not the best way for VxWorks testing
As Archie, I recommend you the VxWorks Simulator too.

A third way is to abstract the HW and OS in a separate layer in your application architecture, and provide both a PC and VxWorks versions of this layer.
This is rather costly, of course, but will have other advantages, i.e. insulation from vendor instability (like when pSos support was stopped years ago...) It might also nudge you in the direction of a nice, layered architecture.

High resolution timer on Coldfire (MCF5328)

I've inherited a embedded project that requires some simple, per-function performance profiling. It consists of a Coldfire (MCF5328) running uClinux (2.6.17.7-uc1).
I'm not an expert on either the Coldfire, or uClinux (or Linux for that matter), so excuse my ignorance.
In Windows I would simply use QueryPerformanceCounter to access the x86 high-resolution timer. Record the counter before and after and compare the difference.
I've learned that Linux has a number of variations on QueryPerformanceCounter:
clock_gettime/res
getnstimeofday
ktime_x
Or even access to the Time Stamp Counter via
get_cycles
None of these are available on the uClinux build this device is running. So it appears that the OS has no high-resolution timer access.
Does this mean that the Coldfire itself provides no such feature? Or did the author of the uClinux port leave them out? Is there something on the hardware that I can use, and how would go about using it?

Given how old your kernel is, you may not have support for high-resolution timers.
If you are writing a kernel driver, the APIs are different. If get_cycles() is stubbed out, it probably means your CPU architecture doesn't support a cycle counter. Since your kernel is very old, do_gettimeofday is probably the best you can do, short of writing a driver to directly query some timer hardware.

I ended up using one of the four DMA Timers on the Coldfire. It was a simple matter to enable the timer as a free-running, non-interrupt generating, counter. This provides a 12.5ns counter (at 80Mhz).

Is it possible to program Microblaze without EDK, on any Xilinx FPGA?

Is it possible to program Microblaze without EDK, on any Xilinx FPGA device ?
I am developping under Linux.
Is there advisable tutos/books about that ? Is there a stable open-source clone ?

For spartan 3, spartan 6, virtex 5, and virtex 6 family FPGAs you can use the simple microblaze design in xapp1141 from Xilinx without needing EDK.
http://www.xilinx.com/support/documentation/application_notes/xapp1141.pdf
https://secure.xilinx.com/webreg/clickthrough.do?cid=132893&license=RefDesLicense
It includes a netlist for a simple microblaze design. If you use this you do not need EDK at all.
You can instantiate the netlist in your FPGA design and build it using the normal ISE flow. Then you use the Xilinx SDK to write and compile software for it. You are very limited in the peripherals that the microblaze will have built in: simple data address bus, debug interface, and UART.
Any other peripherals you want (ie SPI, I2C, etc) you would have to write in HDL and connect to the simple address and data bus implemented by the simple microblaze. Your software also has to fit in and run out of the internal block ram (8KB) allocated by this microblaze netlist.
UPDATE:
In ISE 13.4 there is now a Microblaze MCS coregen core that allows you to instantiate a mircroblaze without EDK.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf
By the datasheet it appears to support everything from Spartan 3 to the new 7 series parts.

I you want to instantiate a Microblaze core in your design, then you need ISE EDK.
If you already have a design with Microblaze. Then you can program it (i.e. write software for it) without ISE EDK.

Multi core programming

I want to get into multi core programming (not language specific) and wondered what hardware could be recommended for exploring this field.
My aim is to upgrade my existing desktop.

If at all possible, I would suggest getting a dual-socket machine, preferably with quad-core chips. You can certainly get a single-socket machine, but dual-socket would let you start seeing some of the effects of NUMA memory that are going to be exacerbated as the core counts get higher and higher.
Why do you care? There are two huge problems facing multi-core developers right now:
The programming model Parallel programming is hard, and there is (currently) no getting around this. A quad-core system will let you start playing around with real concurrency and all of the popular paradigms (threads, UPC, MPI, OpenMP, etc).
Memory Whenever you start having multiple threads, there is going to be contention for resources, and the memory wall is growing larger and larger. A recent article at arstechnica outlines some (very preliminary) research at Sandia that shows just how bad this might become if current trends continue. Multicore machines are going to have to keep everything fed, and this will require that people be intimately familiar with their memory system. Dual-socket adds NUMA to the mix (at least on AMD machines), which should get you started down this difficult road.
If you're interested in more info on performance inconsistencies with multi-socket machines, you might also check out this technical report on the subject.
Also, others have suggested getting a system with a CUDA-capable GPU, which I think is also a great way to get into multithreaded programming. It's lower level than the stuff I mentioned above, but throw one of those on your machine if you can. The new Portland Group compilers have provisional support for optimizing loops with CUDA, so you could play around with your GPU even if you don't want to learn CUDA yourself.

Quad-core, because it'll permit you to do problems where the number of concurrent processes is > 2, which often non-trivializes problems.
I would also, for sheer geek squee, pick up a nice NVidia card and use the CUDA API. If you have the bucks, there's a stand-alone CUDA workstation that plugs into your main computer via a cable and an expansion slot.

It depends what you want to do.
If you want to learn the basics of multithreaded programming, then you can do that on your existing single-core PC. (If you have 2 threads, then the OS will switch between them on a single-core PC. Then when you move to a dual-core PC they should automatically run in parallel on separate cores, for a 2x speedup). This has the advantage of being free! The disadvantages are that you won't see a speedup (in fact a parallel implementation is probably slightly slower due to overheads), and that buggy code has a slightly higher chance of working.
However, although you can learn multithreaded programming on a single-core box, a dual-core (or even HyperThreading) CPU would be a great help.
If you want to really stress-test the code you're writing, then as "blue tuxedo" says, you should go for as many cores as you can easily afford, and if possible get hyperthreading too.
If you want to learn about algorithms for running on graphics cards - which is a very different area to x86 multicore - then get CUDA and buy a normal nVidia graphics card that supports it.

I'd recommend at least a quad-core processor.

You could try tinkering with CUDA. It's free, not that hard to use and will run on any recent NVIDIA card.
Alternatively, you could get a PlayStation 3 and the Linux SDK and work out how to program a Cell processor. Note that the next cheapest option for Cell BE development is an order of magnitude more expensive than a PS3.
Finally, any modern motherboard that will take a Core Quad or quad-core Opteron (get a good one from Asus or some other reputable manufacturer) will let you experiment with a multi-core PC system for a reasonable sum of money.

The difficult thing with multithreaded/core programming is that it opens a whole new can of worms. The bugs you'll be faced with are usually not the one you're used to. Race conditions can remain dormant for ages until they bite and your mainstream language compiler won't assist you in any way. You'll get random data and/or crashes that only happen once a day/week/month/year, usually under the most mysterious conditions...
One things remains true fortunately : the higher the concurrency exhibited by a computer, the more race conditions you'll unveil.
So if you're serious about multithreaded/core programming, then go for as many cpu cores as possible. Keep in mind that neither hyperthreading nor SMT allow for the level of concurrency that multiple cores provide.

I would agree that, depending on what you ultimately want to do, you can probably get by with just your current single-core system. Multi-core programming is basically multi-threaded programming, and you can certainly do that on a single-core chip.
When I was a student, one of our projects was to build a thread-safe implementation the malloc library for C. Even on a single core processor, that was more than enough to cure me of my desire to get into multi-threaded programming. I would try something small like that before you start thinking about spending lots of money.

I agree with the others where I would upgrade to a quad-core processor. I am also a BIG FAN of ASUS Motherboards (the P5Q Pro is excellent for Core2Quad and Core2Duo processors)!
The draw for multi-core programming is that you have more resources to get things done faster. If you are serious about multi-core programming, then I would absolutely get a quad-core processor. I don't believe that you should get the new i7 architecture from Intel to take advantage of multi-core processing because anything written to take advantage of the Core2Duo or Core2Quad will just run better on the newer architecture.
If you are going to dabble in multi-core programming, then I would get a good Core2Duo processor. Remember, it's not just how many cores you have, but also how FAST the cores are to process the jobs. My Core2Duo running at 4GHz routinely completes jobs faster than my Core2Quad running at 2.4GHz even with a multi-core program.
Let me know if this helps!
JFV