JOP as SOPC component
in [FPGA]
|
Prev: Embedded clocks
Next: CPU design
From: Martin Schoeberl on 11 Aug 2006 18:26 The last days I played around with the Quartus SOPC builder [1]. Although I'm more a batch/make guy, I'm impressed by the easy to use tool. In order to scratch a little bit on the dominance of the NIOS II in the SOPC world I wrapped JOP [2] into an Avalon component ;-) So if you are interested to give a Java processor in the SOPC environment a try... There is are two ready to use Quartus projects available: a generic version for a 256Kx16 SRAM and a version for the Altera DE2 board [3]. If you have the DE2 board follow the steps to build JOP: 1. check out the actual sources from opencores cvs -d :pserver:anonymous(a)cvs.opencores.org:/cvsroot/anonymous -z9 co -P jop 2. Open the Quartus project .../quartus/altde2/jop.qpf 3. Start Tools - SOPC Builder... 4. Press Generate 5. Press Exit and close Quartus 6. Edit the following lines in the Makefile: BLASTER_TYPE=USB-Blaster QPROJ=altde2 7. and then run the usual make .... and it should run the Java/JOP Hello World ;-) A detailed design flow document (without the SOPC builder part) is available at [4]. What's cool for me: I get the SDRAM controller for free and have a JOP system with 8 MB! Now it's time to write some 'big' embedded Java applications ;-) However, of course there is some drawback. The performance of the Avalon system is lower than a 'native' connection (or in my case via SimpCon [5]) of the main memory to the CPU. I can provide some numbers if there is interest... BTW: The Cyclone II FPGA cannot be clocked really faster than the Cyclone (just a few %). I hoped to get some speed-up for free due to a new generation FPGA :-( So, happy JOP SOPC building, Martin [1] http://www.altera.com/products/software/products/dsp/dsp-builder.html [2] http://www.jopdesign.com/ [3] http://www.altera.com/education/univ/materials/boards/unv-de2-board.html [4] http://www.jopdesign.com/doc/build.pdf [5] http://www.opencores.org/projects.cgi/web/simpcon/overview
From: Tommy Thorn on 11 Aug 2006 19:44 Martin Schoeberl wrote: > The last days I played around with the Quartus SOPC builder [1]. > Although I'm more a batch/make guy, I'm impressed by the easy to use > tool. In order to scratch a little bit on the dominance of the NIOS II > in the SOPC world I wrapped JOP [2] into an Avalon component ;-) Kudos, that is excellent. Any lessons/gotchas about turning JOP into an SOPC components should someone else fancy a similar undertaking? > However, of course there is some drawback. The performance of the > Avalon system is lower than a 'native' connection (or in my case > via SimpCon [5]) of the main memory to the CPU. I can provide some > numbers if there is interest... Care to elaborate? I'd expect going over Avalon could add latency, but if you can exploit multiple outstanding transactions (aka "posted reads") and/or bust transfers, the bandwidth should be the same as "native". > BTW: The Cyclone II FPGA cannot be clocked really faster than the > Cyclone (just a few %). I hoped to get some speed-up for free due > to a new generation FPGA :-( I was surprised too when I saw that. I gather the only way the Cyclone II can gain you speed over Cyclone I is when you can use the embedded multipliers. Makes me wonder about the upcoming Cyclone III. Tommy
From: Martin Schoeberl on 12 Aug 2006 06:52 >> The last days I played around with the Quartus SOPC builder [1]. >> Although I'm more a batch/make guy, I'm impressed by the easy to use >> tool. In order to scratch a little bit on the dominance of the NIOS II >> in the SOPC world I wrapped JOP [2] into an Avalon component ;-) > > Kudos, that is excellent. Any lessons/gotchas about turning JOP into an > SOPC components should someone else fancy a similar undertaking? The Avalon bus is very flexible. Therefore, writing a slave or master (SOPC component) is not that hard. The magic is in the Avalon switch fabric generated by the builder. However, an example would have helped (Altera listening?). I didn't find anything on Altera's website or with Google. Now a very simple slave can be found at [1]. One thing to take care: When you (like me) like to avoid VHDL files in the Quartus directory you can easily end up with three copies of your design files. Can get confusing which one to edit. When you edit your VHDL file in the component directory (the source for the SOPC builder) don't forget to rebuild your system. The build process copies it to your Quartus project directory. When you want to start over with a clean project the only files needed for the project are: .qpf, .qsf, .ptf The master is also ease: just address, read and write data, read/write and you have to react to waitrequest. See as example the SimpCon/Avalon bridge at [2]. The Avalon interconnect fabric handles all bus multiplexing, bus resizing, and control signal translation. >> However, of course there is some drawback. The performance of the >> Avalon system is lower than a 'native' connection (or in my case >> via SimpCon [5]) of the main memory to the CPU. I can provide some >> numbers if there is interest... > > Care to elaborate? I'd expect going over Avalon could add latency, but > if you can exploit multiple outstanding transactions (aka "posted > reads") and/or bust transfers, the bandwidth should be the same as > "native". Yes, the latency is the issue for JOP. JOP does not trigger several read or write transactions. However, it can trigger one transaction and than continue to execute microcode. When the (read) result is needed, the JOP pipeline is stopped till the result is available. What helps is to know in advance (one or two cycles) when the result will be available. That's the trick with the SimpCon interface. There is not a single ack or waitrequest signal, but a counter that will say how many cycles it will take to provide the result. In this case I can restart the pipeline earlier. Another point is, in my opinion, the wrong role who has to hold data for more than one cycle. This is true for several busses (e.g. also Wishbone). For these busses the master has to hold address and write data till the slave is ready. This is a result from the backplane bus thinking. In an SoC the slave can easily register those signals when needed longer and the master can continue. On the other hand, as JOP continues to execute and it is not so clear when the result is read, the slave should hold the data when available. That is easy to implement, but Wishbone and Avalon specify just a single cycle data valid. >> BTW: The Cyclone II FPGA cannot be clocked really faster than the >> Cyclone (just a few %). I hoped to get some speed-up for free due >> to a new generation FPGA :-( > > I was surprised too when I saw that. I gather the only way the Cyclone > II can gain you speed over Cyclone I is when you can use the embedded > multipliers. Makes me wonder about the upcoming Cyclone III. Are there any other data available on that. I did not find many comments in this group on experiences with Cyclone I and II. Looks like the CII was more optimized for cost than speed. Yes, waiting for III ;-) Martin [1] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/sopc/components/avalon_test_slave/hdl/avalon_test_slave.vhd [2] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhd
From: Antti Lukats on 12 Aug 2006 07:03 "Martin Schoeberl" <mschoebe(a)mail.tuwien.ac.at> schrieb im Newsbeitrag news:44ddb2d4$0$8024$3b214f66(a)tunews.univie.ac.at... >>> The last days I played around with the Quartus SOPC builder [1]. >>> Although I'm more a batch/make guy, I'm impressed by the easy to use >>> tool. In order to scratch a little bit on the dominance of the NIOS II >>> in the SOPC world I wrapped JOP [2] into an Avalon component ;-) >> >> Kudos, that is excellent. Any lessons/gotchas about turning JOP into an >> SOPC components should someone else fancy a similar undertaking? > > The Avalon bus is very flexible. Therefore, writing a slave or > master (SOPC component) is not that hard. The magic is in the Avalon > switch fabric generated by the builder. However, an example would > have helped (Altera listening?). I didn't find anything on Altera's > website or with Google. Now a very simple slave can be found at [1]. > > One thing to take care: When you (like me) like to avoid VHDL files > in the Quartus directory you can easily end up with three copies of > your design files. Can get confusing which one to edit. When you > edit your VHDL file in the component directory (the source for the > SOPC builder) don't forget to rebuild your system. The build process > copies it to your Quartus project directory. Hi Martin, most of the SOPC magin happens in the perl package "Europe" ASFAIK. dont expect a lot of information about the internals of the package. as very simple example for avalon master-slave type of peripherals there is on free avalon IP core for SD-card support the core can be found at some russian forum and later it was also added to the user ip section of the microtronix forums. the avalon master is really as simple as the slave. Antti
From: Martin Schoeberl on 12 Aug 2006 08:10
Hi Antti, > most of the SOPC magin happens in the perl package "Europe" ASFAIK. > dont expect a lot of information about the internals of the package. That's fine for me. When the connection magic happens and I don't have to care it's fine. OK, one exception: Perhaps I would like to know more details on the latency. The switch fabric is 'plain' VHdL or Verilog. However, generated code is very hard to read. > as very simple example for avalon master-slave type of peripherals there > is on free avalon IP core for SD-card support the core can be found > at some russian forum and later it was also added to the user ip > section of the microtronix forums. Any link handy for this example? > the avalon master is really as simple as the slave. Almost, you have to hold address, data and read/write active as long as waitrequest is pending. I don't like this, see above. In my case e.g. the address from JOP (= top of stack) is valid only for a single cycle. To avoid one more cycle latency I present in the first cycle the TOS and register it. For additional wait cycles a MUX switches from TOS to the address register. I know this is a slight violation of the Avalon specification. There can be some glitches on the MUX switch. For synchronous on-chip peripherals this is absolute not issue. However, this signals are also used for off-chip asynchronous peripherals (SRAM). However, I assume that this possible switching glitches are not really seen on the output pins (or at the SRAM input). Martin |