Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 143 replies
  • Subscribers 682 subscribers
  • Views 21433 views
  • Users 0 members are here
Related

Role for FPGA or CPLD with Raspberry Pi

michaelkellett

Interesting - we obviously move in rather different circles despite being in the same business:

 

Take the current project:

 

One master processor (ARM Cortex M4 with ARM serial debugging port and 4 wire trace, Ethernet, USB and serial for debugging)

One supervisor processor (ARM Cortext M0 with ARM serial debugging port)

FPGA with JTAG port

Up to 6 slave processors (ARM Cortex M4s with ARM serial debugging ports)

All in one little box about 25cm x 160cm x 5cm

 

Now to bring up the Ethernet on the master processor I can use its serial port for "printf" error messages (from the Ethernet/TCP/IP library) and the ARM debugging port to load/run/trace the processor. The ARM trace interace box (Keil Ulink Pro) is a USB interface to the development PC.

The superivisor processor is connected via another Ulink to another PC.

The FPGA JTAG interface is USB to yet another PC.

The fourth PC runs Wiresharc and is connected by Ethernet to see what's coming out.

 

It would be nice if the debug tools had Ethernet rather than USB interfaces but they don't.

I could isolate the serial debug port but since I must have three other non-isolated connections it's not worth the effort.

 

This system is all quite low power - so certainly safe to humans and fairly safe to computers. (The really exposed parts are the debug interfaces and there is nothing to be done about that since they need fast conenctions to the hardware.)

In the last 10 years I've lost one debugger and one PC due to my mistakes and in the same time at least 10 PCs have just died (as they do) so it's a cost effective approach.

 

Of course when these things connect to external systems handling real power different rules apply.

 

(AFIK most Ethernet interfaces are not specifically tested for mains safety - either during qualification or as part of normal regular safety checks (and the flash test requirement for Ethernet magnetics is 1500V AC which is OK for some equipment but not for all)).

 

Michael Kellett

Parents

  • Yes indeed.

     

    > So I don't see a lot of people using ready-made cores as a springboard to designing their own programmable logic.

     

    Well let's see what happens with the Guzunty Pi open hardware CPLD board. If even a few percent of the people who like the idea of ready made cores go on the learn to program their own cores from HDL, schematic or tables thats a Good Thing.

     

    Totally agreed on the remote tools idea. Xilinx used to have a web interface themselves did they not?

  • in reply to guzunty

    Derek Campbell wrote:

     

    Totally agreed on the remote tools idea. Xilinx used to have a web interface themselves did they not?

    I believe they did, but I don't remember the details.  I never used it myself.  I can't remember what they charged to use it, or if it was free for smaller devices like WebPACK.  I also don't know why they discontinued it, but I suspect that:

     

    1.  Companies didn't want to send their designs over the Internet for security reasons.

    2.  Difficulty in choosing which versions(s) of the Xilinx software to provide.  As I said earlier, my experience has been that it's best to match the software version to the part you're using.  Also, switching to a different version can result in unexpected changes to design implementation as defaults are handled differently.  For example, I had some logic that was implemented in distributed RAM and when I switched to a newer version of the tools it got assigned to a block RAM.  You don't want these kinds of surprises in the midst of a design.

    3.  Turn-around time was maybe too long or variable.  If running locally, you know how long it's going to take to re-run the tools after a design change, so you can check e-mail, get a cup of coffee, have lunch, write a novel, or whatever.  If it takes a random amount of time, it's hard to plan.  Plus, there are features like ChipScope that let you route an FPGA internal node to a test pin almost immediately.  (At least I think that's what you can do -- I've never used it since it's not in WebPACK.)  That feature might be a bummer over the Internet.

Reply
  • in reply to guzunty

    Derek Campbell wrote:

     

    Totally agreed on the remote tools idea. Xilinx used to have a web interface themselves did they not?

    I believe they did, but I don't remember the details.  I never used it myself.  I can't remember what they charged to use it, or if it was free for smaller devices like WebPACK.  I also don't know why they discontinued it, but I suspect that:

     

    1.  Companies didn't want to send their designs over the Internet for security reasons.

    2.  Difficulty in choosing which versions(s) of the Xilinx software to provide.  As I said earlier, my experience has been that it's best to match the software version to the part you're using.  Also, switching to a different version can result in unexpected changes to design implementation as defaults are handled differently.  For example, I had some logic that was implemented in distributed RAM and when I switched to a newer version of the tools it got assigned to a block RAM.  You don't want these kinds of surprises in the midst of a design.

    3.  Turn-around time was maybe too long or variable.  If running locally, you know how long it's going to take to re-run the tools after a design change, so you can check e-mail, get a cup of coffee, have lunch, write a novel, or whatever.  If it takes a random amount of time, it's hard to plan.  Plus, there are features like ChipScope that let you route an FPGA internal node to a test pin almost immediately.  (At least I think that's what you can do -- I've never used it since it's not in WebPACK.)  That feature might be a bummer over the Internet.

Children
No Data