Learning FPGA

Does anyone know of any good learning resources about how to start learning FPGA? I've been a software engineer for several years and the FPGA world is quite new to me. I'm trying to implement RMII but have been struggling a lot. I purchased a logic analyzer but I don't know what I'm looking at. I need something that will tell me how to properly understand and read datasheets, know how to debug signals, how to understand what VHDL is good and what is bad. How to read RTL generations..Etc

I'm starting from the beginning. Any resources or materials are greatly appreciated.

Parents

Moussa1492 1 month ago

A good path would be:

1. Start with FPGA fundamentals

For a software engineer, the biggest mindset shift is:

VHDL/Verilog is not “code that runs.”
It describes hardware that exists all the time.

Good beginner resources:

Resource	Why it helps
Nandland FPGA / VHDL / Verilog tutorials	Very beginner-friendly, especially if you are coming from software. It has FPGA-101, VHDL, and Verilog sections. (Nandland)
VHDLwhiz Basic VHDL Course	Good if you want VHDL specifically. It starts in simulation, so you can learn without fighting hardware first. (VHDLwhiz)
MIT 6.111 Introductory Digital Systems Lab	More academic, but excellent for understanding digital systems, timing, state machines, and hardware design thinking.
Digilent FPGA digital design materials	Good if you use common dev boards like Basys, Nexys, Arty, etc. Their material focuses on hands-on FPGA projects. (Digilent)

Start with small designs:

LED blink
button debounce
counter
UART transmitter
UART receiver
FIFO
simple SPI master
simple packet parser

Do not start with Ethernet.

2. Learn simulation before hardware debugging

Before using a logic analyzer, learn to use a simulator:

GHDL / Questa / ModelSim for VHDL
Verilator / Icarus / Questa for Verilog/SystemVerilog
GTKWave for waveform viewing

You should be able to answer:

What signal changed?
On which clock edge?
Was reset active?
Was this register updated now or next cycle?
Is this combinational or sequential logic?

A very good FPGA workflow is:

Write RTL
↓
Write testbench
↓
Simulate
↓
Check waveforms
↓
Synthesize
↓
Check RTL/netlist schematic
↓
Constrain timing
↓
Program FPGA
↓
Debug with internal logic analyzer

For “how to read RTL generation,” use the vendor schematic/netlist viewer after synthesis. In Vivado, for example, design analysis is specifically meant to inspect optimized netlists and timing results. (Xilinx)

3. Learn what “good RTL” means

Good FPGA RTL usually means:

-- Good mental model
one clock
synchronous reset or controlled reset
registered outputs
clear state machines
no accidental latches
no gated clocks
no random delays
clean clock-domain crossing

Bad beginner RTL usually has:

multiple unrelated clocks everywhere
using delays like wait for 10 ns in synthesizable logic
incomplete if/case statements causing latches
combinational feedback
gated clocks
async signals used directly
ignoring timing constraints

Clock-domain crossing is especially important. Xilinx-style HDL guidelines warn against asynchronous design techniques and recommend proper methods such as FIFOs when crossing clock domains. (Wiki des Electroniciens du CNRS)

For timing and CDC, read:

Topic	Resource
Clock-domain crossing	01signal CDC articles (01signal)
Timing closure	01signal timing closure series (01signal)
Debug/formal later	ZipCPU tutorials — very good after you know the basics, especially for debugging and formal verification. (ZipCPU)

4. For RMII specifically: learn the interface first

RMII is not just “some pins.” It is a synchronous interface around a 50 MHz reference clock.

Typical RMII signals:

Signal	Direction	Meaning
`REF_CLK`	clock	50 MHz reference clock
`TX_EN`	MAC → PHY	transmit data valid
`TXD[1:0]`	MAC → PHY	2-bit transmit data
`CRS_DV`	PHY → MAC	carrier sense / receive data valid
`RXD[1:0]`	PHY → MAC	2-bit receive data
`RX_ER`	PHY → MAC	receive error, sometimes optional
`MDC/MDIO`	management	PHY register access

Microchip’s KSZ8081 datasheet states that REF_CLK is a continuous 50 MHz clock used as the timing reference for TXEN, TXD[1:0], CRS_DV, RXD[1:0], and RX_ER. (Microchip)

So the first question is not “is my VHDL correct?” The first questions are:

Is the PHY strapped into RMII mode?
Is the 50 MHz REF_CLK present?
Who generates REF_CLK: FPGA, PHY, or oscillator?
Can I read the PHY ID over MDIO?
Does the PHY report link up?
Is reset released correctly?
Are the I/O voltages correct?

TI’s DP83848 RMII application note also says RMII mode requires a 50 MHz external CMOS oscillator source and correct strap configuration at reset. (Texas Instruments)

5. Your logic analyzer may not be enough

RMII runs at 50 MHz. If your logic analyzer is a cheap 24 MHz or 50 MHz USB analyzer, it will not reliably show RMII data.

For RMII, use:

External logic analyzer:
- reset
- strap pins
- MDC/MDIO
- link LEDs
- slow control signals

FPGA internal logic analyzer:
- RMII RXD/TXD
- TX_EN
- CRS_DV
- state machines
- FIFOs
- packet parser signals

For Xilinx, use ILA.
For Intel/Altera, use SignalTap.
For Lattice, use the available internal debug flow depending on the toolchain.

A practical RMII capture should trigger on:

TX_EN rising edge
or
CRS_DV rising edge

Then inspect:

REF_CLK stable at 50 MHz
TX_EN high during transmit frame
TXD[1:0] changing only relative to REF_CLK
CRS_DV high during received frame
RXD[1:0] changing during CRS_DV

6. Debug RMII in layers

Do not debug the whole Ethernet stack at once.

Use this order:

Layer 1 — PHY alive

Check:

PHY reset pin
PHY clock
PHY straps
PHY address
MDIO read works
PHY ID registers readable
link status readable

If MDIO does not work, stop. Do not debug RMII yet.

Layer 2 — transmit only

Make FPGA send a simple Ethernet frame repeatedly.

Look for:

TX_EN goes high
TXD[1:0] toggles
PHY shows activity
PC/Wireshark sees something

Layer 3 — receive only

Send broadcast traffic from a PC:

ARP
ping
broadcast packet

Look for:

CRS_DV goes high
RXD[1:0] toggles
your RX state machine detects preamble/SFD

Layer 4 — MAC framing

Only after the electrical/interface side works, worry about:

preamble
SFD
destination MAC
source MAC
EtherType
payload
CRC/FCS
inter-frame gap

7. Suggested learning order for your case

Given that you are already trying RMII, I would follow this path:

Week 1:
Learn VHDL simulation, clocked processes, testbenches, GTKWave.

Week 2:
Build UART TX/RX in simulation and on FPGA.

Week 3:
Learn FIFOs, valid/ready handshakes, simple packet streams.

Week 4:
Read PHY datasheet carefully: reset, straps, clocking, MDIO, RMII timing.

Week 5:
Implement MDIO read/write first.

Week 6:
Implement RMII TX only.

Week 7:
Implement RMII RX only.

Week 8:
Build a minimal Ethernet MAC: ARP or UDP only.

Best immediate advice

For your RMII struggle, focus on these three things first:

Can you read the PHY ID over MDIO?
If no, your hardware/configuration is not ready.
Is REF_CLK definitely correct?
RMII depends on a continuous 50 MHz clock. Wrong clock source or wrong PHY strap will break everything.
Use internal FPGA logic analyzer, not only external LA.
RMII is fast enough that many hobby logic analyzers will mislead you.

A very good first goal is:

Read PHY ID over MDIO
↓
Confirm link up
↓
Transmit one repeated raw Ethernet frame
↓
See it in Wireshark

Once that works, then build RX and higher-level protocol handling.

Reply

Moussa1492 1 month ago

A good path would be:

1. Start with FPGA fundamentals

For a software engineer, the biggest mindset shift is:

VHDL/Verilog is not “code that runs.”
It describes hardware that exists all the time.

Good beginner resources:

Resource	Why it helps
Nandland FPGA / VHDL / Verilog tutorials	Very beginner-friendly, especially if you are coming from software. It has FPGA-101, VHDL, and Verilog sections. (Nandland)
VHDLwhiz Basic VHDL Course	Good if you want VHDL specifically. It starts in simulation, so you can learn without fighting hardware first. (VHDLwhiz)
MIT 6.111 Introductory Digital Systems Lab	More academic, but excellent for understanding digital systems, timing, state machines, and hardware design thinking.
Digilent FPGA digital design materials	Good if you use common dev boards like Basys, Nexys, Arty, etc. Their material focuses on hands-on FPGA projects. (Digilent)

Start with small designs:

LED blink
button debounce
counter
UART transmitter
UART receiver
FIFO
simple SPI master
simple packet parser

Do not start with Ethernet.

2. Learn simulation before hardware debugging

Before using a logic analyzer, learn to use a simulator:

GHDL / Questa / ModelSim for VHDL
Verilator / Icarus / Questa for Verilog/SystemVerilog
GTKWave for waveform viewing

You should be able to answer:

What signal changed?
On which clock edge?
Was reset active?
Was this register updated now or next cycle?
Is this combinational or sequential logic?

A very good FPGA workflow is:

Write RTL
↓
Write testbench
↓
Simulate
↓
Check waveforms
↓
Synthesize
↓
Check RTL/netlist schematic
↓
Constrain timing
↓
Program FPGA
↓
Debug with internal logic analyzer

3. Learn what “good RTL” means

Good FPGA RTL usually means:

-- Good mental model
one clock
synchronous reset or controlled reset
registered outputs
clear state machines
no accidental latches
no gated clocks
no random delays
clean clock-domain crossing

Bad beginner RTL usually has:

multiple unrelated clocks everywhere
using delays like wait for 10 ns in synthesizable logic
incomplete if/case statements causing latches
combinational feedback
gated clocks
async signals used directly
ignoring timing constraints

For timing and CDC, read:

Topic	Resource
Clock-domain crossing	01signal CDC articles (01signal)
Timing closure	01signal timing closure series (01signal)
Debug/formal later	ZipCPU tutorials — very good after you know the basics, especially for debugging and formal verification. (ZipCPU)

4. For RMII specifically: learn the interface first

RMII is not just “some pins.” It is a synchronous interface around a 50 MHz reference clock.

Typical RMII signals:

Signal	Direction	Meaning
`REF_CLK`	clock	50 MHz reference clock
`TX_EN`	MAC → PHY	transmit data valid
`TXD[1:0]`	MAC → PHY	2-bit transmit data
`CRS_DV`	PHY → MAC	carrier sense / receive data valid
`RXD[1:0]`	PHY → MAC	2-bit receive data
`RX_ER`	PHY → MAC	receive error, sometimes optional
`MDC/MDIO`	management	PHY register access

Microchip’s KSZ8081 datasheet states that REF_CLK is a continuous 50 MHz clock used as the timing reference for TXEN, TXD[1:0], CRS_DV, RXD[1:0], and RX_ER. (Microchip)

So the first question is not “is my VHDL correct?” The first questions are:

Is the PHY strapped into RMII mode?
Is the 50 MHz REF_CLK present?
Who generates REF_CLK: FPGA, PHY, or oscillator?
Can I read the PHY ID over MDIO?
Does the PHY report link up?
Is reset released correctly?
Are the I/O voltages correct?

TI’s DP83848 RMII application note also says RMII mode requires a 50 MHz external CMOS oscillator source and correct strap configuration at reset. (Texas Instruments)

5. Your logic analyzer may not be enough

RMII runs at 50 MHz. If your logic analyzer is a cheap 24 MHz or 50 MHz USB analyzer, it will not reliably show RMII data.

For RMII, use:

External logic analyzer:
- reset
- strap pins
- MDC/MDIO
- link LEDs
- slow control signals

FPGA internal logic analyzer:
- RMII RXD/TXD
- TX_EN
- CRS_DV
- state machines
- FIFOs
- packet parser signals

For Xilinx, use ILA.
For Intel/Altera, use SignalTap.
For Lattice, use the available internal debug flow depending on the toolchain.

A practical RMII capture should trigger on:

TX_EN rising edge
or
CRS_DV rising edge

Then inspect:

REF_CLK stable at 50 MHz
TX_EN high during transmit frame
TXD[1:0] changing only relative to REF_CLK
CRS_DV high during received frame
RXD[1:0] changing during CRS_DV

6. Debug RMII in layers

Do not debug the whole Ethernet stack at once.

Use this order:

Layer 1 — PHY alive

Check:

PHY reset pin
PHY clock
PHY straps
PHY address
MDIO read works
PHY ID registers readable
link status readable

If MDIO does not work, stop. Do not debug RMII yet.

Layer 2 — transmit only

Make FPGA send a simple Ethernet frame repeatedly.

Look for:

TX_EN goes high
TXD[1:0] toggles
PHY shows activity
PC/Wireshark sees something

Layer 3 — receive only

Send broadcast traffic from a PC:

ARP
ping
broadcast packet

Look for:

CRS_DV goes high
RXD[1:0] toggles
your RX state machine detects preamble/SFD

Layer 4 — MAC framing

Only after the electrical/interface side works, worry about:

preamble
SFD
destination MAC
source MAC
EtherType
payload
CRC/FCS
inter-frame gap

7. Suggested learning order for your case

Given that you are already trying RMII, I would follow this path:

Week 1:
Learn VHDL simulation, clocked processes, testbenches, GTKWave.

Week 2:
Build UART TX/RX in simulation and on FPGA.

Week 3:
Learn FIFOs, valid/ready handshakes, simple packet streams.

Week 4:
Read PHY datasheet carefully: reset, straps, clocking, MDIO, RMII timing.

Week 5:
Implement MDIO read/write first.

Week 6:
Implement RMII TX only.

Week 7:
Implement RMII RX only.

Week 8:
Build a minimal Ethernet MAC: ARP or UDP only.

Best immediate advice

For your RMII struggle, focus on these three things first:

Can you read the PHY ID over MDIO?
If no, your hardware/configuration is not ready.
Is REF_CLK definitely correct?
RMII depends on a continuous 50 MHz clock. Wrong clock source or wrong PHY strap will break everything.
Use internal FPGA logic analyzer, not only external LA.
RMII is fast enough that many hobby logic analyzers will mislead you.

A very good first goal is:

Read PHY ID over MDIO
↓
Confirm link up
↓
Transmit one repeated raw Ethernet frame
↓
See it in Wireshark

Once that works, then build RX and higher-level protocol handling.

Children

No Data