>>If possible then how to do this ?I will elaborate on the subject, as I have some experience. The anwer is - Of course you can, somebody has to do it. Check out www.opencores.org (http://www.opencores.org) for a list of open-source IP. Of note is: 1) Most cores at opencores are designed to work with the openly specified wishbone bus, rather than Avalon. Creating a wrapper module to map Avalon signals to appropriate corresponding wishbone bus signals is usually straighforward. The code can be made into a SOPC component by using the SOPC component editor. This will take you some time to master all the details going on here. You should read and completely understand the Wishbone specification, and the Altera Avalon switch fabric specification. There is plenty documentation available. 2) If you don't have a solid (and I mean SOLID) Verilog or VHDL background, like any other programming language, expect a long time to master it. These do not operate like traditional programming languages, in that a large amount of functionality (lines of code) operate in parallel. You are best served if you think about the actual electrical circuits that are being described as you write your code, rather thinking about it as sequential operating code--it is not. You can make sections operate sequentially by using a state machine and case statements. Start with something simple, and use Quartus's RTL viewer to see the circuit your code created to verify it generated what you wanted. Sometimes a large part of your code will be optimized out (say perhaps because a clock signal input does not toggle). Using RTL Viewer can clue you in as to what got cut out, and from that you can speculate, along with the Quartus II compilation warnings, as to why, and fix it. It is somewhat helpful to read about the architecture of FGPA chips, although you don't need to master this. It's just another thing to keep in the back of your mind while writing. 3) You will also need to know how to use ModelSim, and how to write a test bench for debugging. The test bench simply instantiates your IP, and stimulates the inputs signals to your IP in a way that they would normally operate. For example, you might simulate the signals of the Avalon bus, to test your IP's Avalon slave interface. Test bench writing seems to be a subject that isn't well documented, so you will likely only get a small set of good ideas from a variety of places on the internet, and put them together to make a full-fledge test bench implementation. Typically, you can debug the great majority of your logic with a minimal test bench, and manually view the signal outputs of the oscilliscope-like graph to determine if your IP behaved as expected. If you wanted a test bench that actually tested many operations of your IP against expected results, say for example because your routinely enhance your IP code, the test bench would necessarily be much more extensive. Larger corporations that are providers of IP would likely have such a test bench for automated verification. 4) To use the IP effectively, you will need to master the ability of writing device drivers, unless it is really, really simple, like PIO. I see so many people manipulating an IP's registers from within their main code. This is simply BAD technique. Most all open-cores IPs don't have drivers, just the core itself, as it could be used for any imaginable OS. For example, currently, I just grabbed the 16550 UART from opencores, need to use it with TI's SYS/BIOS OS, and of course, there is not a driver. There isn't even a .h file that defines constants such as named register offsets, and bit masks. Altera provides pretty decent documentation for the OS it provides with NIOS II IDE, and how to develop a HAL driver. If developing for Linux, there is a very good free online book called something like Writing Linux Device Drivers 3. It is a little bit old, but most of the same principles apply. I haven't actually wrote a Linux device driver (yet!). Needless to say, writing a device driver is another topic that is not trivial, as you will need to understand the underlying operating system architecture to understand how to integrate the device driver the proper way. Perhaps now you can understand why people say it will be troublesome, or it will take a long time. They are correct Each of these 4 subjects could eaisily be a semester long, high-level college course. And after you took the courses, you still wouldn't be very proficient until you got a lot of experience under your belt putting everything together multiple times. But it CAN be done, and I have sucessfully created some pretty complicated IP components without any formal training (such as fixed-point 32.32 math custom instruction(s) co-processor of sorts, implementing add, subtract, multiply, divide, square-root, and sin/cos functions, a HDLC transmitter, a quadrature encoder tracker with position matching interrupt triggering, and others). I didn't get any on-the-job traning from anyone else either, as I haven't had a job in this field. It has just been an interest of mine and all self-learned, as I have a project I would eventually like to realize in a pcb someday. The key is to read, read, read......re-read, re-read, re-read, until all the pieces start to make perfect sense. All the documentation you need IS out there. You just need to research it.
Hi,I am trying to use the minsoc project in OpenCores site. I want to build a soc system include or1200, uart, lcd controller, ethernet controller and something others on the Cyclone II development board. After building this soc platform, I want to run linux on it. But it's a little difficult to me. Can you give me some tips? Can I use the Sopc Builder to build this platform? And how to run a linux? It's a great problem to me. Where can I get the boot-loader?