Ok, let's be honest: XST error reporting stinks like week old roadkill.
To break the stalemate on clock distribution in my discrete component recreation of the i4004 CPU, I decided the first step would be to take a hard look at the rise-time of the clock signals on the Instruction Pointer board I've already completed. To do this, I need to put together a running system.
A couple of years ago (has it been that long??) I created an MCS-4 Clock using my Spartan-3E Starter reference board. The i4004 emulation could be configured to use either an emulated Instruction Pointer or the physical IP board. However, this was done before I realized what a disaster the transparent latch version was and switched the chip emulation back to using clocked flip-flops, so I knew I'd need to do some tweaking of the top level modules to work with the latest emulation code.
Mostly what was needed was adding back the module ports for the 50 MHz system clock ("sysclk"). However, after doing so I still got synthesis errors from XST complaining that the data bus was driven by multiple outputs. Well, of course it's driven by multiple outputs: it's a bidirectional bus! This worked before; why did I get errors now?
After literally hours and hours of trying this and that, I found Xilinx tech note 14264 that indicated that this error sometimes can result from another net that was not driven and thus tied to ground during synthesis, causing a cascade of unexpected errors. This led me to discover that sysclk wasn't properly wired into one of the emulated chips in the top clock module. Wouldn't it have been better to generate an error for the unconnected input port?
Fixing this resolved the error, but by then it was too late to try it on hardware. Maybe tomorrow I'll have pretty pictures of the clock line rise and fall timing.
Have you thought about using the open source fpga toolchain? I'm wondering if the entire design is small enough to fit on a Lattice UP5K or if only the Lattice ECP5 woulf be big enough.
ReplyDeleteNo, I haven't tried the open-source toolchains for the Lattice FPGAs. I did some of my early experiments with the iCE40 HX1K using the iCEcube2 toolchain.
DeleteI don't believe there's anything in the i4004 CPU Verilog that is incompatible with the iCE40 FPGAs. The i4001 and i4002 emulations might require some tweaking, though nothing that couldn't be worked around. IIRC, the entire Busicom calculator re-creation used fewer than 800 Spartan-6 LUTs, so I'd think the Lattice iCE40-UP5K would be plenty big enough.
Why not clone the repo from OpenCores (don't use the download link, it's broken) and run it through the open-source toolchain? Let me know how well it works!