I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx Spartan3E and PicoBlaze. I need a soft core processor and I think PicoBlaze would be enough. SOPC and Nios-II is very powerful but the learning curve looks like a potential nightmare to me. In order to use SOPC I might have to get involved writing custom components to do the job and then one has to master the Avalon interface. That looks like a lot of potential debugging time.
The Xilinx solution seems more direct, and under my control, since PicoBlaze is stand alone and does not depend on so many bus interrelated components and SOPC infrastructure. Easier and quicker to write direct interfaces. Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to work.
Also, it seems like the Nios/SOPC solution is likely to require far more gates than a Xilinx/PicoBlaze implementation.
I would be curious to know any of your experiences with SOPC/Nios-II. I have very limited R&D time for this project.
I guess it depends on *what* you want to interface to the NIOS.
Avalon is compatible with Wishbone, so if you're going to be interfacing wishbone components then it's a no-brainer. Otherwise, it's no more difficult than writing wishbone wrappers for your non-wishbone component.
Of course some components already exist, such as an SDRAM controller for example. You also get I/O blocks such as registers and GPIO that can have associated NIOS interrupts, UARTS, etc.
Putting it all together is quite straight-forward in the SOPC interface. You get a visual representation of the bus interconnects and can massage the memory map as you see fit. Arbitration for multiple bus-masters is automagically taken care of. You also get to choose the size/complexity of the NIOS itself - IIRC the smallest is 600-700 LEs?!?
Once you've decided on your architecture, you 'generate' the system which produces a mass of HDL files in your main project directory. Then instantiate the top level in your Quartus design and you're good to go.
The software is written from within the NIOS-II IDE. You simply build a 'system library' for your design and then start on your application. Personally I hate Eclipse with a passion so I do all my editing outside the IDE, and use it solely for the big red 'RUN' button.
uCOS is also an option, or you can go bare-bones with the HAL library. You get drivers for all system components and isr hooks etc. If you actually already know what you're looking for, you can usually find it in the doco! ;)
There's also nice things like a JTAG UART which allows you to spit debug messages directly to the IDE console. During development you can target your CODE sections to (SD)RAM and download/run everything via JTAG so there's no need for ROM emulators etc. I haven't used the debugger extensively, but it kinda works.
Overall, it's relatively "painless" once you get the hang of things. That certainly can't be said for a lot of embedded systems, let-alone soft-cores running in FPGAs....
I can't comment on Xilinx/PicoBlaze...
Regards,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd,
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
The Picoblaze is a very small 8-bit microcontroller while the NIOS is a
32-bit general purpose CPU (by most accounts). Both Altera and Xilinx provide an easy way to build a base-system using any of their processors (NIOS and/or Microblaze) however there is no base system builder for Picoblazes, so getting output from the processor into the real-world may be harder (unless you like looking at LEDs, and trying to hook up a UART to a picoblaze).
Additionally, NIOS and Microblaze come with quite a few software libraries that you can use to your advantage. What exactly are you planning on doing with your system? Do you really need an FPGA or could you just buy a gumstix? The reason I ask is that the toolsets from both Xilinx and Altera have a learning curve, and it may be easier to bypass the need to build a base system, synthesize, place-and-route, etc. etc.
I've written Verilog for over 10 years and the design for the logic portion is already done. However this is the first time using a soft core CPU. Basically this is a backplane bus interface. Address decode and 32 bit porting. But I need RAM for a fast buffer and also a little CPU for converting serial I2C DACs and ADCs into parallel data. So a little embedded CPU with I2C core would probably do it. Perhaps SPI so I can update calibration constants in config Flash.
PicoBlaze seems very easy to hook your own logic to. Nios seems much more involved since you have to go through the SOPC arch. It also appears the size of the gates will be 2X higher using Nios than PicoBlaze. The chip size could be twice the price.
if you only need i2c and spi, then any small cpu would do, and there is no need for the i2c or spi to be present in hardware, software bitbang is almost always as efficient
If time is limited, go for the Picoblaze. Even though it needs to be programmed in assembly. The assembly language it uses is very straightforward and easy to learn.
Be aware though that the design around a Picoblaze may not meet timing when a lot of datasources are connected to it and / or the Picoblaze is running at high clock speeds. You may need one or more extra registers to split paths (this is explained in the Picoblaze documentation).
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
you can also take a look at our ERIC5. It is more powerful than Picoblaze (esp. size of code-space) at about the same resource-usage. And it is vendor-indepent, so you do not have to base your FPGA-decision on the processer-choice. For larger projects (with sufficient code-ROM) there is also a C-compiler available. If you want something for free, maybe also Lattice Mico8 can do the job.
Regards,
Thomas
formatting link
"Chris" schrieb im Newsbeitrag news:ysmdnTmSee0P56DYnZ2dnUVZ snipped-for-privacy@comcast.com...
Glad I posted the question. You guys are great. So much info.
I think the 8 bit micro is the right approach level: PicoBlaze, Micro8. There is another PacoBlaze that looks interesting. Probably others too. Waiting for info on ERIC5.
The LatticeXP approach is attractive from a couple standpoints. Being NV and single supply, if I can use the config clock in user mode, and keep some of my own extra data in the internal flash, than it becomes possible to do the whole implementation with a single part. No regulators, no external flash, no xtal/osc. Great for PCB routing and space. Very slick and clean. One single part. Might be able to use a double sided board.
Need to talk to Lattice about a couple points there. I think I can keep the config osc running by setting the PERSISTENT flag ON, but not sure about flash usage. Otherwise Xilinx 3E-100 is probably best choice.
in XP the config oscillator is NOT accessible. but that is not a big deal at all, you can use in fabric oscillator as well, works great I have tested with lattice XP as well
I have seen that you have requested the ERIC5-datasheets & eval-kit on our homepage, you should have received it automatically via e-mail. Maybe the supplied e-mail address was incorrect (althought it looks plausible), or the mail was blocked by a firewall / spam-filter? If it really did not arrive, you can send me an e-mail.
According to their sysCONFIG pdf, the CCLK is brought out to a pin. If you set the PERSISTENT flag to ON, then the config is suppose to keep alive. Doesn't that mean that the CCLK will keep going?
I assume you mean the sysClock. I saw that PLL but assumed it needed an external input.
What about using the internal flash for read/write during user mode. Any experience with XP parts on that?
no, I did mean the CCLK "inside" the FPGA, the config osc primitive is visible in devive viewer but the primitive cant be used in XP, it can used in ECP and some other lattice fpgas
there is no user flash, but if you mean the flash config that is rewriteable but you need to wire loop jtag pins to user io
Exactly. PERSISTENT=ON keeps the pins alive. If I wire those around to other IO pins, then I should be able to read/write to the Flash while running and use the CCLK to run the CPU.
Nope won't work. I talked to Lattice today. There is no internal osc to use, and they did not recommend using a bunch of gates. Moreover there is no extra flash space either - zip. This is not the first time. Overall I am very disappointed with what they put out in their MachXO and XP NV families. They lack a lot of little features that would make them so much more powerful. I guess they have heard that from others too, he told me that they were coming out with a 'revised' new XP line next year. XP-II I think he said.
If you don't need very tight integration between the processor and the FPGA, you might save yourself a great deal of time and effort by using an external small microcontroller. Choose the right part, and things like I2C are a no-brainer.
I spoke with our Director of Applications, Bertrand Leigh on this topic and confirmed that the application will work.
Antti is correct, you CAN build an internal ring oscillator based on stacked inverters for a coarse frequency oscillator inside the XP or EC/ECP type devices. This is a proven method that has worked at Lattice and at other users. XO and ECP2/M device families have built-in oscillator based on the configuration oscillator that is accessable from the FPGA fabric after configuration.
For Flash write back both options are available -- PERSISTENT=ON for sysConfig port and through JTAG.
We will follow up with the person you spoke to on our technical support line and let them know about this application. Sorry if they caused any confusion.
Hope this helps. Bart Borosky, Lattice Semiconductor
there are many ways to make a ring-oscillator, depends on the needs I have one version that I call fgpa_safe it is basd on 4 FF that use only set reset pins. This thing always delivers an "useable" clock for given FPGA and works any synthesis tool, eg does not get optimized away.
there can different other methods, which may be better but may require special trick to fool the optimizer and may require LOC contraints to get better repeated frequency. invertor chain may run too high simetimes, as example for V4 special care has to be taken to get the inverter chain frequency to be low enough to be useable.
in most cases the fgpa_safe oscillator is sufficient, is sure has large difference in frequency as it will be routed by different paths each time.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.