



CAN Protocol Controller to niosII
by Unknown on Jun 9, 2005 |
Not available! | ||
Hey!
Could anyone give me good advices how to get CAN protocol Controller IP from opencores to work in the Altera's cyclone and niosII processor. Which one is the right way to use this IP, should I use SOPC to do the interface to the NiosII or should I connect the IP to the niosII in the QuartusII using blockdiagram tool? All the advices are welcome. Thank You. |
CAN Protocol Controller to niosII
by Unknown on Jun 9, 2005 |
Not available! | ||
Aloha!
Which one is the right way to use this IP, should I use SOPC to do the
interface to the NiosII or should I connect the IP to the niosII in the QuartusII using blockdiagram tool? Well, either you use the SOPC builder to "Add new component" and add the CAN-controller as an Avalon peripherial to the Nios II platform. For the CAN-controller this should be an easy task (though I haven't tried to connect a wishbone device to Avalon fabric). This integration makes for a nice, seamless access to the CAN-controller and you get the driver generated for you by SOPC-builder. A possible downside/risk is that you might bump into problems when trying to add the core as an Avalon device. One problem I have bumped into lately is that there is a different HDL parser in SOPC (for creating ned components) than the regular parser in Quartus-II. In turns out that in the newly released Q2 5.0, the parser in SOPC builder chokes when seeing VHDL std_ulogic types. But AFAIK the CAN-controller is in Verilog so this specifik problem should not affect you. The other way to do this would be to instead use existing or add extra PIO peripherials to the Nios II platform (in SOPC builder). And then in Quartus, either using HDL och schematic entry connect the PIO ports to the CAN core. The benefit with this solution is that you might be able to use an unmodified Nios II platform (standard, compact, low cost etc). The drawback is that you will have to write a small driver that internally uses the PIO to access the CAN core. This is actually very easy. You basically use the IOWR_ALTERA_AVALON_PIO_DATA and IORD_ALTERA_AVALON_PIO_DATA macros to create a few functions for read and write access. Took me most of five minutes for the last design. ;-) Performance-wise the latter solution is slower (since the device is not tightly coupled to the Avalon switch fabric), but for the CAN-core this will not be a problem anyway. If you don't want to generate a new Nios-II platform or feel that adding the CAN-core as a component is too much for you I suggest you choose connecting it to the standard PIO ports. Side note: There is a third way to connect the CAN-core. You could add it as a new custom instruction. With Nios-II you have the ability to add instructions that are very complex and takes multiple cycles to complete. My hunch is that this is not the best solution for you. But it's possible. ;-) Good luck. -- Med vänlig hälsning Joachim Strömbergson ----------------------------------------------- |



