PCB and FPGA versioning system

SparkyT Guest 2019-04-30 10:37 #5826117

Rate this post

•	▲ useful ▼ not useful

Hi all,
i can't figure out a good versioning system that ties a PCB version 
number (containing an fpga) and the fpga image version to be used on 
that board.

To explain a bit better, a pcb board version X with fpga image version A

 - pcb will go to version Y with a power supply component change (fpga 
image version A still compatible)
 - pcb will go to version Z with a new LED (fpga image version B needed 
to control the LED)
 - firmware upgrade, fpga version C with no board change

how to relate the two? i am using the fpga rom to store data like 
timestamps and device serials, but i am in need of a good versioning 
system to track compatibility between pcb and fpga firmware.
any suggestions?

Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post

Helmut S. (helmuts) 2019-04-30 12:04 #5826204

Rate this post

•	▲ useful ▼ not useful

Hello,
I would use a few I/O-pins (e.g. 4) of the FPGA which are tied to Vcc 
and GND with external pull-up and pull-down resistors. This allows you 
to define 16 hardware revisions by omitting resistors.

Reply Quote Edit Delete Report post

SparkyT Guest 2019-05-01 09:27 #5826965

Rate this post

•	▲ useful ▼ not useful

Hi
thanks for the reply,
let me see if i get it correctly,

very much like the idea of hardcoding a 4-bit number onto the board,
by defining it with populated resistors.

does this mean that as the board progresses through versions, the 
resistor 4-bit number will increment only when an fpga change is 
required?

pcb v1.00  works with image 0000
    v1.15
    v2.01
    v2.10  works with image 0001
and so on...(?)

that takes care of scenario A and B.
what about scenario C? no board change?

Reply Quote Edit Delete Report post

Wühlhase Guest 2019-05-01 10:09 #5827001

Rate this post

•	▲ useful ▼ not useful

You can define this by yourself.

If you need more versions or version paths, you can place a small and 
cheapy eeprom, and make it unwritable by hard wiring. Example: if your 
eeprom has an SPI, you does'nt connect the masters data out line. So 
your FPGA can read the eeprom, but not write.

For changing data, you can route an extra SPI link from the eeprom (pin 
header or something similar).

Reply Quote Edit Delete Report post

Helmut S. (helmuts) 2019-05-01 10:36 #5827032

Rate this post

•	▲ useful ▼ not useful

> does this mean that as the board progresses through versions, the
resistor 4-bit number will increment only when an fpga change is
required?

My idea was to code the hardware revision with these 4 inputs. If you 
spend more inputs, you can additionally code the FPGA revision, but I 
wouldn't do that, because often you have many FPGA versions for the same 
hardware revision. The FPGA revison can be easily coded within the FPGA.

Reply Quote Edit Delete Report post

SparkyT Guest 2019-05-02 19:05 #5828531

Rate this post

•	▲ useful ▼ not useful

I was also thinking of a 4bit number within the fpga,
and try to relate the resistor number to the fabric number,
in some way. There is something there but I can't see it yet.
Thanks for the discussion, really like the resistor idea.

Reply Quote Edit Delete Report post