2
\$\begingroup\$

When making any prototype PCB it is always a great idea to have features within it that can be used to aid in debug of the design.

A few examples are:

  1. Use the largest FPGA available that has migration path to the one we expect to use in the final product. This means we can have a lot of logic to implement debug modes and internal logic analyzer like signal-tap. This does mean that our power dissipation measurements won't be accurate since a larger FPGA will have higher static power dissipation.

  2. Embed features into the board that makes it possible to connect certain signal paths to a scope. These could be analogue signals or digital signals. I am not talking about the signals that directly connect to the FPGA. There are different ways to do this, and I am not sure about the best way to do this.

  3. Have 8 or 16 pins exposed via header, that connect to the extra general purpose I/O on the FPGA. These can be used to output internal FPGA signals to the pins which can then be connected to a scope or logic analyzer. The question that arises here is, what type of connector to use since high speed signals require signal integrity to be kept in mind. Certainly we must choose a connector that a scope or logic analyzer can easily connect to.

  4. Have 1ohm resistors on the power supply rails that can be used to accurately measure the power dissipation on all the supply rails, especially the ones connected to the FPGA.

  5. Put in an FTDI chip that can be used to implement USB-UART.

  6. Have an easy method for the prototype to be connected to another FPGA or microcontroller board in case the need arises. One way to do this is to have Arduino shield connectors on the board but then we must be sure that what we intend to connect is compatible before we make the PCB.

I am sure that people that have made many prototype PCBs and then gone to production can give their opinion on this list and suggest some improvements. It is true that the features also depend on what the board actually has been designed to do, so the same techniques can be applicable to every project. So now my questions are:

  1. Is there any improvement over what I have recommended above?
  2. Are there some features further to what I have mentioned that should be utilized?
  3. Having lots of capability to aid in debug is a great idea but, it creates an issue when we come to production level tests. The path to go from the prototype board to the production level PCB for alpha testing e.t.c must be simple.

I would be grateful if someone can put in their two cents. This question is VERY specific and not broad or off topic. I think I have covered most things already.

Thanks.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Is this supposed to be a devboard? Or a module? Or an actual prototype of a production board? \$\endgroup\$ – DKNguyen Jul 20 '20 at 22:19
  • \$\begingroup\$ Actual prototype for a final product to be sold \$\endgroup\$ – Quantum0xE7 Jul 20 '20 at 22:43
  • \$\begingroup\$ The only reason for having the header pins is to help us get certain signals onto the scope. Sometimes the signal tap may not be good enough. \$\endgroup\$ – Quantum0xE7 Jul 20 '20 at 22:46
  • \$\begingroup\$ You can't add test points to hook onto? \$\endgroup\$ – DKNguyen Jul 20 '20 at 22:47
  • 3
    \$\begingroup\$ 1 ohm resistors would be disastrous at several amps. You also need a variety of configuration mechanisms, e.g. flash EPROM, and JTAG to both Flash and FPGA. \$\endgroup\$ – user16324 Jul 21 '20 at 12:05
2
\$\begingroup\$

Your prototype should have these features too 8in no order):

  • embedded USB to JTAG module
    like SMT3 from Digilent
  • 2 port or 4 port USB-UART (I also like FTDI like you mentioned)
    note: a modern FPGA or FPGA+SoC needs one UARTs per operating system and FPGA part
    • 1 => Linux
    • 2 => RTOS
    • 3 => FPGA
  • tiny USB 2.0 hub and a USB-C connector used as USB 2 as service port
    (mechanically more stable then micro-USB)
  • more complex boards might need a board management controller like MSP430 or similar. this IC can have USB (see USB hub) and 2x I²C to control PMBus to control temperature, voltages, fan speeds, ... it can also serve to configure the board before powering the FPGA
  • control power with PMBus controllers like from Linear. Measure voltage, current, power, temperature and control power staging or savings.
  • EEPROM or better F-RAM so save versions (at best Git hashes, production dates, serial numbers, board configurations, modes, last power state, ...)
  • 1 yellow LED (low-active) + one RGB led that can drive any color and blinking code :)
  • 2 (micro) push buttons
  • 3-pin header for I²C bus (PMBus)
  • 3-pin header for main UART
  • test points for all power rails (at best on top-side)
  • ground pin or place for a ground clamp - used by osziloscope
  • Fan connector, while you board is not in the final chassis while testing
  • temperature sensors distributed over the board to get heat distribution
  • like you want to upsize/downsize your FPGA in the same footprint, you can do the same with DC/DC converters.
  • design your additional pin headers as Pmod 2x6 headers (8-bit data + 3v3 + GND) so you can use extension boards with OLED display, additional puttons, WiFi, Bluetooth, Flash, EEPROM, ...
\$\endgroup\$
1
  • \$\begingroup\$ I had an idea, DIP switches should be there as well to give a discrete input to the FPGA. \$\endgroup\$ – Quantum0xE7 Jul 27 '20 at 13:14
3
\$\begingroup\$

If the memory chip is connected with FPGA, like SDRAM or DDR or others, I'd like to allocate some extra sampling memory space for debugging. This is especially useful when you want to sample a large chunk of data, like a frame or a package, which is larger than signaltap's sample capacity. Some more advanced features can also be designed based on this sample memory like sampling only the packages whose header match a specific value.

\$\endgroup\$
1
  • \$\begingroup\$ hmm, yes a memory device is also important, an SDRAM should be sufficient \$\endgroup\$ – Quantum0xE7 Jul 21 '20 at 10:12
2
\$\begingroup\$

I would actually advise against using the largest FPGA available simply due to the extraordinary device cost and implementation challenge of the largest FPGAs.

Don't forget adding some LEDs for debug output indicators.

You might also want to add jumpers to various places (like disconnecting power from certain sections) for debugging in case something goes wrong.

I see little point in an exposed GPIO header for a board that already has a set purpose.

\$\endgroup\$
2
  • \$\begingroup\$ Oh, I did not mean to use the largest FPGA :) What I mean is that e.g we design to use a 10M40 series FPGA in the final product. In the prototype we should use the largest FPGA that has the same pinout as the one we want to use in the final version of our design. \$\endgroup\$ – Quantum0xE7 Jul 20 '20 at 22:45
  • \$\begingroup\$ @Quantum0xE7 Oh, so the largest capacity for the same footprint. That is a bit more reasonable. \$\endgroup\$ – DKNguyen Jul 20 '20 at 22:46
1
\$\begingroup\$

Always LEDs.

A 3 pin UART header for TTL-232R-RPI.

I usually adds an Ethernet port for debug and programming. FPGA Cores provides an easy way for the customer to update the firmware with the remote programmer tool. If you want there are also an embedded scope that you can use. I really appreciate these cores.

You can find the cores here: https://www.fpga-cores.com/cores/

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.