A-Z80 soft core with Ice40 iceStick and APIO/Yosys tool chain. - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: July 04, 2025, 12:47:51 pm
content: Simulation: I have the Z80 fully running with a bunch of peripherals all is sweet. It's just too god damn slow.Synthesis: Yosys has 'issues' with tri-state logic. So it's extra cautious with multiple muxes driving anything.Current state: The softcore is held in reset for 12 T-cycles and released. The Z80 runs perfectly. If I assign the first 4 LEDs to Addr[3..0] and the 5th LED to clock (running at 10Hz) and I can see it counts.Problems: CPU is reading NOP from the ROM module. The ROM module has not got NOPs in it.Debug: Assign D bus to LEDs. BOOOM!I'm been up and down, around and around and it will not let me even glance at "D" without it giving me a 1000 line lecture in logic loops and conflicting mux drivers.I went around the houses with ChatGPT until I realised we were just pushing the conflict one more step closer and closer into the core.YoSys does NOT like birectional tri-state logic. No matter how tightly I couple the "drive selects" on D it won't sythesis the D bus wires.I told ChatGPT to stop following me down the same game of whackomole and give me something different and ... finally.It said, get rid of the "Z80 top level wrapper". It's there to make the FGPA software "look" like the real chip. Underneath is a set of 4 modules which map the real FPGA friendly registers of the core into "pin compatible" modules. If you remove the outer wrapper or adapt it, you can access the uni-directional data registers the actual core uses.So... should I explore that route? My first fat fingered attempt just resulted in conflicts on the uni-directional drives as well.The core claims Ice40 synthesis compatibility, but I don't think it claims, YoSys compat.What are my options?

author: cruff
author_rank: Regular Contributor
timestamp: July 04, 2025, 01:36:33 pm
content: Many sources say that FPGAs don't "like" bidirectional busses internally, so yes, pursue the suggestion.

author: asmi
author_rank: Super Contributor
timestamp: July 04, 2025, 03:16:00 pm
content: Quote from: cruff on July 04, 2025, 01:36:33 pmIt's not that they don't like them - they are simply impossible to implement internally because they don't have hardware for that.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 04, 2025, 03:34:28 pm
content: Yes, now you can always use tristate signals internally in your HDL, but it will just get synthesized as two different signals (IN/OUT) so there is nothing to gain and you'll get no internal tristate signal in hardware. Not something that I ever do, so I can't guarantee that some synthesis tools won't complain about it either, and I don't recommend doing it, even if it gets synthesized properly, as it gives a false sense of what happens in hardware.

author: asmi
author_rank: Super Contributor
timestamp: July 04, 2025, 03:41:25 pm
content: Many implementations of "legacy" hardware tend to use tristate busses because original silicon did actually have them implemented in hardware, and so a direct "naive" port to FPGA ends up having them too, despite of the fact that it's very problematic. Besides, modern CPUs and MCUs also avoid using tristate busses, even though it's possible to implement them in hardware, because they tend to cause all kinds of issues.

author: paulca
author_rank: Super Contributor
timestamp: July 04, 2025, 07:51:07 pm
content: So "Tri-state logic" require the following to be valid:moduleA:assign data = 8'bz;moduleB:assign data = 8'bz;I think the root of my problem is that Yosys disagrees.Does that some it up?

author: woofy
author_rank: Frequent Contributor
timestamp: July 05, 2025, 09:24:20 am
content: That does sound like an issue.You cannot have tris-tates wthin the FPGA, they do not have them. External pins are fine just not internally. Use separate in's and out's for your modules.One of the big gotcha's I found during verilog development is if a signal is missing, maybe you think it's there but you misspelled it in the PCF, then whole swathes of code will be optimised away. I found that one quite time consuming to deal with.

author: xvr
author_rank: Frequent Contributor
timestamp: July 05, 2025, 08:14:27 pm
content: QuoteYes, but`default_nettype nonedirective in each Verilog source file will help a lot.

author: zapta
author_rank: Super Contributor
timestamp: July 05, 2025, 08:17:53 pm
content: Apropos Apio, the docs and the installation guide of the upcoming 1.0.x release is stable here:https://fpgawars.github.io/apio/https://fpgawars.github.io/apio/installing-apio/And daily builds of standalone installers (python not needed) are available here:https://github.com/zapta/apio-dev-builds/releases

author: paulca
author_rank: Super Contributor
timestamp: July 06, 2025, 11:35:20 am
content: To summarise.1. I got early wins from FPGA land using the simulator as a logic/digital circuit designer using replicated 74 series style modules to design out and prove bus designs, memory maps, IO address decodes, etc. etc.2. Wanted to move some of that down into hardware and interface with the real Z80. ERRR: 5V!3. Spend a few evenings trying to schematic out an "in circuit" supervisor to split the buses into 5V and 3.3V with bi-directional bus arb and DMA. Ended up with 5 level shifter ICs before I caught on that it was even more complicated than I'd thought. Some of those control signals have odd rules. There are open drains, high drivers and a whoopsy means blue smoke and expensive board reworks.4. Can I move the whole Z80 into the FPGA? This thread is how that went. Short answer. No.5. Retreat, regroup, advance and hold a shorter reach. Take a smaller bite. Forget "in circuit", forget DMA, forget "supervisor". Leave the core Z80 board as it is, stay out of the RAM/ROM bus area entirely. Interface with the "IO Bus" only. Write a peripheral in the FGPA. You will need much less bus arb, the bus arb is no where near as critical, especially if you can find an IO spare for the WAIT line.So. New target. Hardware SPI. 8x16 FIFO. Clock divided to something sane for a Z80 from the master clock. Standard "OUT (C),A" mechanics.If I split off my existing breadboard IO router I only need 1 enable and 1 address line to switch between 2 registers (for now). 8 data. _IOREQ, _M1/_INT (for interrupts), read and write are not essential as a pair if the peripheral has "M1" routed it can infer from M1 and RD XOR WR like the Z80 family do and I have already done in gates for custom IO devices. Im probably forgetting a few important likes. I have 22 or 24 IO, I count 24, but some references say 22. So I expect 2 of those exposed IO have something "special" about them.I need one or two 74HC244s CPU->BUS only for control signals and address lines/enables this can be powered from 3.3v rail (after I make sure the ones I have are the wide V range variants) and one 74xLCV8T245 bi-directional dual supply bus trans for the databus.The direction and output enable on the databus from the timing diagrams I am familiar with are WIDE as can be. The CPU HighZ's the databus almost straight away for "READ" and only completes it's signals some time later. It reads on a clock edge in a tiny window and then gives you a bunch of entire clock cycles to "let go" again.The only slight twist is that the 74series are async. The FPGA is probably better off not being implemented that way. However, if the FPGA is running on a 12 or 16MHz clock or faster, even though I will "clk" everything internally, it will still be fast enough for the Z80 to appear as "async". The Z80 clock may be handy, but it will not give me a synchronous single clock domain if I expect that. SPI can be asyncrhronous to the CPU that is the whole point of hardware SPI, no?Start with an even smaller bite. Make the 5 LEDs on the iceStick a Z80 output device port. Sythnesis, flash, wire it up on a breadboard. Use something to intergration test it like an MCU or just give it the level shifters and connect it to the real Z80.

author: zapta
author_rank: Super Contributor
timestamp: July 06, 2025, 04:32:53 pm
content: Quote from: paulca on July 06, 2025, 11:35:20 amHave you considered an FPGA board that plug nicely into a breadboard? I have had good experience with Upduiono 3.1, IceFun, and Gowin/Tang, all are low cost and compatible with Apio. IceFun has 32 leds which is an advantage.E.g. Upduino:https://tinyvision.ai/products/fpga-development-board-upduino-v3-1

author: paulca
author_rank: Super Contributor
timestamp: July 06, 2025, 05:12:39 pm
content: I have an official iceStick, it has 2 ten pin breadboard headers giving 16 IO and another dual PMOD with another 8.It's this I'm going to try the hardware SPI with.I bought an Olimex setup and am still struggling through bugs, issues and so far I have their progruino software running, but it only partially reads the flash ID and just gets worse. The Arduino Leonardo 32u4 I bought from them as it has "pre-tested" programmer for their devboard.... came with the wrong crystal tombstoned on the footprint. A 2 pin crystal on a 4 pin foot print.Having fixed that by botching in a 16Mhz THT crystal the board works, the firmware is so badly corrupted on it my USB host on the PC bans it for spam if I'm too slow. It tries to enumerate as a keyboard, then as a mouse, then as a keyboard again until after it registers as 60 different devices the kernel blacklists it.Even after hard erasing it, reseting fuses and installing a brand leo leonardo bootloader it's still as daft as a brush. The microwave might be the best place for it. If I hold it in reset long enough to get the programmer connected before it start into its random enumeration fit, it read half the flash ID of the board and then lets go of RESET, then tries to access the flash, then bombs out, repeats forever.I find these stuff increasingly amateur. It's not OpenSource is't shit.

author: zapta
author_rank: Super Contributor
timestamp: July 06, 2025, 07:27:20 pm
content: The icestick's size 1K and cost $150. Is it so expensive because it's Lattice 'official' product?https://www.digikey.com/en/product-highlight/l/lattice/icestick-evaluation-kitThe ones I mentioned are only a fraction of the price, significantly larger, fit in solderless breadboard, and should work out of the box with the latest apio. The tang/gowin may also be faster but I didn't test. I just placeed ordered a Tang nano 20K, it costs less than $40. Will test it with apio.As for Olymex, never used their product but got an impressions that they are low cost and somewhat 'rough'.

author: paulca
author_rank: Super Contributor
timestamp: July 07, 2025, 08:57:02 am
content: I didn't pay that much for my IceStick. Think it's was £70 delivered.The Upduino looks nice, however this happens. I'll see if anyone else distributes them.

author: zapta
author_rank: Super Contributor
timestamp: July 08, 2025, 04:51:35 pm
content: Quote from: paulca on July 07, 2025, 08:57:02 amCan you have this one?https://www.robot-electronics.co.uk/icefun.html. I have one and it works out of the box with the latest Apio, including examples.The Tank nano 20K (gowin) arrived yesterday. Costs about $40 and is very fast. For example, with a 32 bit adder I get 390Mhz.https://github.com/FPGAwars/apio-examples/tree/master/examples/sipeed-tang-nano-20k/speed-test(apio report -e width-32).