Implement CAN protocol on FPGA

[kosist90]

I'm just wondering whether it is feasible to implement CAN protocol using FPGA (some FPGA PXI module), or efforts spent on that will be comparable with buying ready-to-use solution?

Point is that now there is need to communicate with 32 CAN nodes, using different ports - and NI has devices maximum with 2 ports. Having 16 such modules will be quite expensive, and in case of future copy of the system will require the same (or even higher) costs.

In case of FPGA, price of FPGA module will be cheaper than price of 16 CAN modules for sure, just there should be spent some time (I guess a lot of time) to implement software for that.

Does anyone has experience with that, or could recommend something on this topic?

Thanks a lot in advance!

[GerdW]

Hi kosist,

the PCIe8510 offers 4 ports!

How many ports do you need for your 32 nodes? Right now I'm using 4 ports to control up to 16 nodes, using different protocols and baudrates…

But I agree: CAN ports are quite expensive from NI. When you need so many ports then a different vendor might be able to help…

[kosist90]

Thank you - I was not aware about that module.

I need 32 ports, because each node (DUT) has same address...

[GerdW]

Hi kosist,

---

@kosist90 wrote:

I need 32 ports, because each node (DUT) has same address...

---

Oh, I understand…

For LIN bus devices I used a CAN-LIN converter. This device has the option to add an arbitrary offset to each CAN address when sending CAN/LIN messages back and forth, so I could add several LIN devices (all using the same LIN address) to a single CAN bus.

Maybe you can find similar devices for "CAN bus extension"?

[kosist90]

Hello GerdW,

thanks a lot for pointing out those devices! Going to check something similar...

Unfortunately I have CAN FD with 2Mbit/s rate, so can't use those devices from peak-system, but maybe for some future projects that would be usable...

Thank you very much!

[Hooovahh]

I don't think the FPGA route is really an option.  I mean it is theoretically possible, but the amount of time and energy that would be needed to recreate the CAN-FD protocol would be quite large. 

Option 1 Custom Test App

This is likely not a solution for you but here is how we handled this in the past.

We had to test 9 DUTs at once, each with 3 CAN buses so possibly 27 CAN ports.  Our tests were not production tests, but instead Validation.  So we weren't running production firmware but instead a "Test App".  Basically an application that would just turn on and off IO on a single command to test the functionality and endurance under various environmental conditions.  Because of this our Test App could be changed to suite our testing needs, and not the needs of the end customer.  CAN 2 and CAN 3 were there for functionality only and had a single purpose and that was to double a value it saw and send it back.  If it saw CAN ID 0x101 with a payload of 0x01 it would send back CAN ID 0x202 with a payload of 0x02.  Because there was so little traffic we realized we could put all 9 devices on the bus at once, if we configured each DUT to use a different CAN ID.  So on first power up we would power the first DUT and send it a special command that said "You are now a 1" and it would work like normal.  Then we would power up only the second DUT only and say "You are now a 2", and go through all 9 DUTs.  Once configured we could send a 0x101 and if we saw the doubled value we knew the first DUT was working, sending 0x102 for the second all through 9.  CAN 1 was a bit different due to it actually being used for things but it has the same principal with the addition of being able to set all 9 DUTs output with a single command.  So you could say "DUT turn on output 1" or you could send a single command of "All DUTs listening need to turn on output 1"

The point of this exercise was that we were able to use just 3 CAN ports for all 9 DUTs because they all were set to different addresses.  The wiring of this wasn't standard to what CAN should be since there was only one terminating resistor, and the wiring was a star pattern instead of being a line but it worked.  This grew into needing about 6 testers all running just 3 CAN ports each (18 total), instead of 27 each (162 total).

Option 2 One At a Time

Depending on your testing needs you could also try to mux the CAN lines.  We've used this technique in the past with a switch matrix card where we had the ability to switch in one DUT at a time and test it then go to the next one.

Option 3 Gateway

This one you could possibly do but is a lot of work.  Intrepid sells some somewhat affordable CAN hardware which could be used as a gateway.  It can run custom code on it that takes in multiple CAN buses, then indexes the CAN IDs, and sends them out on a single bus.  It could then work the opposite way too, receiving a single CAN message from the tester, and then spitting that out on one or more CAN bus.  This might only work if you don't have fully loaded CAN buses, or can get away with filtering out messages you don't need.

Option 4 Lots of Cards

As stated you can get 4 channel PCIe or PXI XNet cards.  This would mean having a PC with 8 PCIe ports.  This is doable but might be a pain.  There are motherboards that support bifurcation, allowing to turn a single 16x PCIe slot into multiple other slots which I think could be 16 1x PCIe slots.  You'd need a large chassis to support this and it might be an option.  If it isn't you could get an 8 slot PXI chassis, and then have either MXI, or now it seems Thunderbolt back to the PC.  This is the most expensive of the options, but probably the one that needs the least amount of engineering.