First FPGA schematic/pcb critique?

[Unixon]

I would completely cut it off SPI interface with a 4-channel switch (and probably cut the power too) upon entering programming mode.

[paulca]

Programming the FPGA on a "held in reset" boot works perfectly.  There is something about that "Blinkie.bin" that Yosys/NexPtr or something that got garbaged into it somehow which is enabling the SPI block in slave mode.  Those do NOT reset at "CRESET" apparently.

It's late + wine.  Tomorrow I'm going to try a different approach.  I have an FTDI232 breakout board (AdaFruit) and iceprog supports it.  If i map the right GPIOs to the FPGA and it too gets "jammed" by a SPI Slave... its not my programmer.  If it works perfectly, it is.

Anyway.  Config under reset being the only issue is a win by far.

[paulca]

If I back feed the 3v3 with the programmer and the main 5V dead on the board, it will bring up the IO ports, but not the FPGA core.

That would allow me to program under "power down" effectively...  Excet, it's going to back feed the 3v3 reg and I have not checked the datashseet in that regard.

Any "cold held in reset" works, it's all  need.

[paulca]

Testing things is meant to happen with a solid reference.  But when you have a brand new to you FPGA, are  noob at HDL and want to see physical proof on a real PCB that it works.... it gets a bit wobbly for a while.

The first failure was that the HDL I had on the board "looked" like it worked.... at first.  But when I looked closer with the scope I found a whole ton of nasty 60Mhz ringing.  Turns out there was a whoopse in my Verilog which basically caused one signal to oscillate on propagation delay period.

Before I even got to fix that I got one too many "Breadboard surprises".  Binned one breadboard, but on a new one, even though all my signals were connected and pulled I could still make the thing unstable with finger pokes.

Basically accepted that FPGA with async logic is not going to work on a breadboard.  Spent the rest of the day soldering the FPGA board and am STM32 together on a protoboard.  Finally I had a stable circuit to work with that didn't get upset of you poked it.  There was a reason I bought a stack of protoboards and tiny gauge silicon wire.

With the circuit stable I spent today writing the test harness.  It's hard when  you are not always 100% sure if a "feature" is  test harness feature or a UUT feature.  Sometimes a "PASS" is not what it seems.  Sometimes a FAIL is a test harness failure.

However.  I believe I have a working "Address glue" and "DTACK Facade" HDL "circuit ready".

The FPGA is meanwhile offended with like 22 LUTs and 1 latch in use.

I have left it with no delays, no "prints" going as fast as the STM32 will go.  All state transitions are verified and if some slips it will halt the board... so I can soak test it for a few hours.

[asmi]

Testing things is meant to happen with a solid reference.  But when you have a brand new to you FPGA, are  noob at HDL and want to see physical proof on a real PCB that it works.... it gets a bit wobbly for a while.

The first failure was that the HDL I had on the board "looked" like it worked.... at first.  But when I looked closer with the scope I found a whole ton of nasty 60Mhz ringing.  Turns out there was a whoopse in my Verilog which basically caused one signal to oscillate on propagation delay period.

Before I even got to fix that I got one too many "Breadboard surprises".  Binned one breadboard, but on a new one, even though all my signals were connected and pulled I could still make the thing unstable with finger pokes.

Basically accepted that FPGA with async logic is not going to work on a breadboard.  Spent the rest of the day soldering the FPGA board and am STM32 together on a protoboard.  Finally I had a stable circuit to work with that didn't get upset of you poked it.  There was a reason I bought a stack of protoboards and tiny gauge silicon wire.

With the circuit stable I spent today writing the test harness.  It's hard when  you are not always 100% sure if a "feature" is  test harness feature or a UUT feature.  Sometimes a "PASS" is not what it seems.  Sometimes a FAIL is a test harness failure.

However.  I believe I have a working "Address glue" and "DTACK Facade" HDL "circuit ready".

The FPGA is meanwhile offended with like 22 LUTs and 1 latch in use.

I have left it with no delays, no "prints" going as fast as the STM32 will go.  All state transitions are verified and if some slips it will halt the board... so I can soak test it for a few hours.

This is what happens when software person tries to use the same approach for hardware. FPGA pros, and just about anybody who spent any significant amount of time with them, know the right incantation - "simulate, simulate, simulate". You have to make sure your circuit 100% works in simulation before you ever touch the real hardware. Every once in a while there are subtle discrepancies between results of functional simulation and reality, but post-P&R timing simulation is always 100% accurate. The only real downside of it is that it's slow, no - it's sloooooooow. Which is why most FPGA devs spend vast majority of their time doing functional simulations.

[paulca]

Testing things is meant to happen with a solid reference.  But when you have a brand new to you FPGA, are  noob at HDL and want to see physical proof on a real PCB that it works.... it gets a bit wobbly for a while.

The first failure was that the HDL I had on the board "looked" like it worked.... at first.  But when I looked closer with the scope I found a whole ton of nasty 60Mhz ringing.  Turns out there was a whoopse in my Verilog which basically caused one signal to oscillate on propagation delay period.

Before I even got to fix that I got one too many "Breadboard surprises".  Binned one breadboard, but on a new one, even though all my signals were connected and pulled I could still make the thing unstable with finger pokes.

Basically accepted that FPGA with async logic is not going to work on a breadboard.  Spent the rest of the day soldering the FPGA board and am STM32 together on a protoboard.  Finally I had a stable circuit to work with that didn't get upset of you poked it.  There was a reason I bought a stack of protoboards and tiny gauge silicon wire.

With the circuit stable I spent today writing the test harness.  It's hard when  you are not always 100% sure if a "feature" is  test harness feature or a UUT feature.  Sometimes a "PASS" is not what it seems.  Sometimes a FAIL is a test harness failure.

However.  I believe I have a working "Address glue" and "DTACK Facade" HDL "circuit ready".

The FPGA is meanwhile offended with like 22 LUTs and 1 latch in use.

I have left it with no delays, no "prints" going as fast as the STM32 will go.  All state transitions are verified and if some slips it will halt the board... so I can soak test it for a few hours.

This is what happens when software person tries to use the same approach for hardware. FPGA pros, and just about anybody who spent any significant amount of time with them, know the right incantation - "simulate, simulate, simulate". You have to make sure your circuit 100% works in simulation before you ever touch the real hardware. Every once in a while there are subtle discrepancies between results of functional simulation and reality, but post-P&R timing simulation is always 100% accurate. The only real downside of it is that it's slow, no - it's sloooooooow. Which is why most FPGA devs spend vast majority of their time doing functional simulations.

Do you mean "test_bench" or "simulation"?  I am only famlar with the former and it was 100% green, but it does not simulate simultaneous gate loops.. in fact it refuses to run if it sees one, but my always block had a #1 for that reason so t was apparently okay with that as it only sees one state per step.  The FPGA sees Maxwell.

[paulca]

So the board has an issue somewhere.... or issues.

When programming it (the SPIFlash IC) via the SPI pins, it will only entertain programming from an FPGA cold boot into RESET.  If the FPGA configures at all it will no longer let go of it's own SPI drivers.  The datasheet is confusing and split into multiple parts, but I can't find this particular behaviour spelt out.  One long shot is that as I enable the RGB LED drivers, which co-exist on the IP block with the SPI IP that enabling it, enables the SPI block too.  Because that SPI block (in Slave) can be used during programming it is not reset with cRESET.  Thus, that bit stream when flashed can only be programmed "dark" and not "POR".  Long shot though.

Thats not all though.  It has some signal integrity issues.  The worst offender is the SPI_SS line.  When SPI is idle and SS falls it's clean.  ~10mV noise.  Nice sharp 10ns edge on the fall.  The moment SPI starts clocking though and the SS line comes alive with high frequency noise and ringing.  Like up to 1Vpp around 0V.  That is a 10cm steel pin jump lead to a breadbard straight to an STM32 pin.  So there will be some breadboard foolery in there, I expect the ringing.  But the "block" of noise on the SS line is cross talk and I think I know why.

The SPI clock signal itself is fine.  Clear, sharp, a bit of noise on the over/undershoot but tame and fine.

The SS line as it is in my schematic and layout is a dead end track with nothing at all on it.  There is no pull up, both "pins" it points at will be HiZ.  No resistance on it at all.  So the MCU holding it at 0V there is no current going anywhere.  Its subjected to the whims of the electromagnetic fields and as it runs straight under the SPI flash chip, then for another centimeter to the HiZ FPGA pin, it's an anntenna for all that SPI digital clocking noise.  Thats just a theory.

For now it doesn't matter.  I can program it, it just has "moods". "Moods" where it just won't verify.  Moods where it will. 

I spent a few hours debugging at it last night when it was in a "No program me mood" and I went through the scope in decode both reads, writes, busy polls and nothing was out of place....except that persistent noise.

I got the logic analyser out and recorded a full flash write of a bin file 10 25Mhz.  Everything was again "fine".... except when I compress the capture down to just the CSV "Events" file and opened it.... I spotted every few thousand events or so there was "??" inserted before the value.  I hunted down 6 of these at random and ALL of them said the same thing.  "The SS line glitched high here!"

A "random", "noise induced" transition on the SS line is more than enough to cause "Im not in the mood to program today".

The fact it has already started to verify again by the time I got there suggests there will be a tolerance of just how high and how long that glitch is before it actually aborts the operation in progress in the flash IC. 

What to do about it though.  As I said it isn't an issue, the circuit was made as a "tutorial ice breaker" kind of project.  The board its going into for real will be flashed once, hopefully and never again.  It also has a 4k7 pull up on SS/CS line.  Shorter traces from pull ups to SPI chip and to FPGA as well.

Oh.  Important detail.  The SPI clock I am using is a "modest" 6Mhz.  I'm not trying to push 30Mhz over jumpers!  Maybe I should halve that.  Its not like it takes long to write a bit stream for it.

[Unixon]

I don't see a pull-up resistor on CS. Maybe it just floats when not explicitly driven or has a very weak built-in pull-up somewhere?

[paulca]

I don't see a pull-up resistor on CS. Maybe it just floats when not explicitly driven or has a very weak built-in pull-up somewhere?

Yes thats the problem.  However, even with a pull up added externally it still has lots of noise.

An SPI byte looks like this:

[Ice-Tea]

Oh.  Important detail.  The SPI clock I am using is a "modest" 6Mhz.  I'm not trying to push 30Mhz over jumpers!  Maybe I should halve that.  Its not like it takes long to write a bit stream for it.

Not commenting on the scope traces you added, but this seems like a good time to highlight something important. Perhaps you know this already in which case ignore but..

Frequency is far less important than people think and this is even more the case for FPGAs. It's rise time that matters. If you use an FPGA to create a UART that runs at 11kbps, that driver is still going to drive that line like it needs to achieve 200MHz or something like that. (yes, I know some FPGAS have slow and fast options and whatever). This will create reflections and non-monotuous signals. So if the "other side" has edge triggered logic, it may double trigger and things like that.

Same for your SPI bus. If your clock has something like this

Then that very fast FPGA IO will see 2 clocks if you're unlucky.

[nctnico]

I don't see a pull-up resistor on CS. Maybe it just floats when not explicitly driven or has a very weak built-in pull-up somewhere?

Yes thats the problem.  However, even with a pull up added externally it still has lots of noise.

That noise is not going to give problems. Likely this comes from your probing setup. What you need to check is the clock and data polarity of what the FPGA expects. Intermittent SPI operation typically is due to the clock polarity being wrong.

[nctnico]

I don't see a pull-up resistor on CS. Maybe it just floats when not explicitly driven or has a very weak built-in pull-up somewhere?

Yes thats the problem.  However, even with a pull up added externally it still has lots of noise.

That noise is not going to give problems. Likely this comes from your probing setup. What you need to check is the clock and data polarity of what the FPGA expects. Intermittent SPI operation typically is due to the clock polarity being wrong.

Interesting.  That scope trace shows the data (MOSI) transition during the clock rising edge, but the datasheet says:

Standard SPI instructions use the DI
input pin to serially write instructions, addresses or data to the device on the rising edge of CLK. The DO
output pin is used to read data or status from the device on the falling edge of CLK.

That settles it. The MOSI needs to present valid data to the FPGA (DI) before the rising edge of CLK. And the output data from DO needs to be sampled by the microcontroller on the rising edge of CLK. This is an explaination of clock polarity and phase settings for SPI:
https://www.analog.com/en/resources/analog-dialogue/articles/introduction-to-spi-interface.html

[paulca]

I don't see a pull-up resistor on CS. Maybe it just floats when not explicitly driven or has a very weak built-in pull-up somewhere?

Yes thats the problem.  However, even with a pull up added externally it still has lots of noise.

That noise is not going to give problems. Likely this comes from your probing setup. What you need to check is the clock and data polarity of what the FPGA expects. Intermittent SPI operation typically is due to the clock polarity being wrong.

Interesting.  That scope trace shows the data (MOSI) transition during the clock rising edge, but the datasheet says:

Standard SPI instructions use the DI
input pin to serially write instructions, addresses or data to the device on the rising edge of CLK. The DO
output pin is used to read data or status from the device on the falling edge of CLK.

That settles it. The MOSI needs to present valid data to the FPGA (DI) before the rising edge of CLK. And the output data from DO needs to be sampled by the microcontroller on the rising edge of CLK. This is an explaination of clock polarity and phase settings for SPI:
https://www.analog.com/en/resources/analog-dialogue/articles/introduction-to-spi-interface.html

Wait... I deleted my post because ... the trace shows the data change on the falling edge.  I no idea.  Coffee isn't working or doing too many things at once again.

It's sending 3.  00000011 MSB first.  It goes from low to high on the 6th clock falling edge ready for the IC to sample it on the rising edge.

[nctnico]

Your setup can still violate data hold requirements. Try to set it up so MOSI changes half way the clock cycle.

[paulca]

I feel like I'm chasing ghosts now.  I hooked it back and I can't get it to fail once now.

Cheap 10cm Dupoint, FPGA board pin to MCU (Blackpill) board pin.  Dupoint cRESET->GND (due to the SPI lock out issue if it ever boots).

No pull up on CS.

Flashes and verifies fine now.  I didn't "fix" anything.

I almost bet you, it will start failing again and exactly when I need it to not fail.

Code: [Select]

paul@linux-dev-vm:~/devel/fpga/SPIFlashUtil$ python3 programmer.py --verify ../../68000/fpga/minimal_pcb_address_glue/address_glue.bin
File opened ok (71260 bytes)
Serial opened ok
Synced: protocol v1.0, max_read=256, max_write=256
Synced with programmer
Erasing chip ... way too late to hit CTRL_C now.
Waiting on erasure...
OK
Writing... - (0x1165c)
Wrote 71260 bytes in 7.68 seconds = 9.28 kBytes per second.
Verifying... 0x1165c
verify OK

It's deliberately slow after all this pissing around, but it takes it 10 times longer to erase the chip as to write it and thats 10 times slower than the read back.

If I can get it stable I want to make it do "Sector ahead" or just "Calculate and erase sectors you need" as it's far fast than a full erase.

EDIT:  The FT232 breakout board I'm excluding from results as ... I recall I previously spent an evening trying to force it into I2C mode to read an ADC for me over USB and ... I may have tortured it to death.

[paulca]

Future problems now look like this - send to fab:
Same circuit.  Plus pull ups on RESET and CS this time.

[paulca]

Oh....  I might regret this.  The "no input side cap" is a "copy paste" because in the OG schematic it was right beside another output decup cap and it was silly.  Now it's a good few cm from the nearest cap.

[paulca]

The peak of the testing in the recent thread looked like this - all the toys:



And... yes... the more things you add at once the less reliable each is.

Amusing.... When it's "in circuit" or the test delays lifted even, the RBG led shows 3 very dim red, green, blue dots.  The brighter the longer it spends "bus active".  The "hue" tells me which bus cycle portion is dominant.

[NexusCompute]

There are some power supply issues. AMS1117 linear regulator, which is widely criticized as old and prone to severe oscillation when paired only with modern ceramic capacitors. The use of a diode dropper to step down 3.3V to 2.5V was highly discouraged. I agree with missing bypass capacitors. Also add power sequencing for long term reliability.

[asmi]

One issue I encountered with UP4K device was that after power on it began requesting data from flash memory before it completed internal initialization and was ready to accept commands, which lead to failure to boot. Had to add an RC circuit to delay startup so that flash will have enough time to become ready.

[paulca]

One issue I encountered with UP4K device was that after power on it began requesting data from flash memory before it completed internal initialization and was ready to accept commands, which lead to failure to boot. Had to add an RC circuit to delay startup so that flash will have enough time to become ready.

The inability for it to POR program was reproduced in another board I put this circuit in.  When it was fresh and flashed with a basic bitstream which didn't powerup the RGB_LED IP block, it was able to be CRESET' and reprogrammed.  THe moment that RGB led bitstream touch it... have to boot it into reset to program.

EDIT:  On voltage regulators I didn't put the AMS in it.  I replaced with with MCP parts... but after I bit of searching I think I might settle on a more modern part like the MCP1700?  I don't want specialist I want well behaved jelly bean.

The diode drop for the 2.5V rail.  The datasheet specifies 2 or 3 different tolerance ranges.  If you are not going to do an NVRAM flash, the tolerance is up to 3.2V!  Its only if you want the NVRAM programming it needs to be in closer tolerance.  Some people hav e reported not bothering with anything and putting 3v3 on that pin and it works (according to a bot mind).

[Ice-Tea]

One issue I encountered with UP4K device was that after power on it began requesting data from flash memory before it completed internal initialization and was ready to accept commands, which lead to failure to boot. Had to add an RC circuit to delay startup so that flash will have enough time to become ready.

The inability for it to POR program was reproduced in another board I put this circuit in.  When it was fresh and flashed with a basic bitstream which didn't powerup the RGB_LED IP block, it was able to be CRESET' and reprogrammed.  THe moment that RGB led bitstream touch it... have to boot it into reset to program.

So, you're saying that for proof-of-life/blinky a LED on a regular IO would have been better? 

[korrenh]

The cleanest discriminator is an A/B test with a minimal bitstream that leaves the RGB LED and suspected SPI pins unused. If the flash still becomes inaccessible after reset, the problem is more likely in reset timing, bus handoff, or flash readiness than in the LED logic itself.

Scope CS, SCK, MISO, MOSI, and FPGA reset across programming and the later reset. In particular, check whether CS is ever driven low or MISO sees two drivers immediately after configuration. The pin constraints and the device’s configuration-pin behavior after DONE/configuration are what would decide whether that contention is plausible.