I think I figured out what happened. I've been working on SD Card interfacing with a special bitstream, one that incorporated an extra ports for SPI bitbanging. BigEd must've received a copy of that bitstream. The bitstream had a problem that I just fixed.

The problem had to do with the fact that all input ports that carry asynchronous (to the main clock) data must be synchronized using 3 flip-flops. My SPI port's MISO line used an SRL16-based circuit that uses the LUT as a shift register. Apparently, the timing of an SRL16-based shift register is a little uncertain (the appnote recommends using a real flop for the last stage). And in fact, not using the flop results in a flaky bitstream. After adding the flop, everything works cleanly.

I will be posting the new bitstream with SD Card SPI port shortly. The bitstream is for the CHOCHI F, but works fine with all previous CHOCHIs. Some previously unused IO pins are now dedicated to the SD SPI port.

I also remembered why I moved the bootloader out of page 0 into page FF. I wanted to reset the 6502 using P96 into the bootloader. The bootloader in page 0 had little chance of still being around. Page FF makes more sense (even though I felt really smart about sticking the bootloader into page 0 originally).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The MISO signal is synchronous with the SPI clock, so as long as your SPI clock is divided from the main clock, there should be no reason for the extra synchronizer.

The clock signal is bitbanged by the 6502 core, so in some sense it is synchronized. However, I narrowed the problem to one line of verilog - without the final flop the entire IO subsystem failed. In particular, EhBASIC would not even start. Forth would work until any attempt to address the C0xx IO page, at which point it would lock up.

It's possible that the issue is something else, but I can't think of what would cause this. Originally I thought that IO muxing was the culprit - original CHOCHI had 4-way OR mux, and adding the fifth input could delay the result. But slowing down the clock did not help at all.

In the end it came down to one flop on the MISO pin. Weird, eh?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Strange. Even if the flop was necessary for synchronizing (which I don't think), it's hard to see how it would be related to the rest of the IO system. Are you running with proper timing constraints ?

Strange indeed. I've run across similar situations before, always having to do with an external input. I am certain that adding that flop makes the circuit not lock up, but I am not sure of the mechanics of the problem. All I know so far is that without the flop Forth works until I try to do 'hex C000 c@', at which point it locks up. Actually, the serial port works so it's not just any IO access. Earlier EhBASIC was locking up on startup, while printing the free space like this: "... bytes frc" instead of free!

So the system gets very funky without that flop. Why, I don't quite understand yet.

What is the proper way to specify timing constraints, and which signals should be constrained? I have none currently and have a rather limited understanding of how to do that, even after reading the CDG several times over the last couple of years...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

A simple start with timing constraints is just to add a TIMESPEC in the .ucf file for your clock net.

Using that, the tools will make sure the internal design meets all timing specifications, or give you an error when it fails.

Right now the 60MHz clock goes into the FPGA via P90, but I don't think we are interested in that. The internal DCM generates a 45MHz CPU_CLK as it's CLKFX_OUT. So my attempt to convert the above example results in:



But it is syntactically wrong and I get an error:


What am I doing wrong?

Also, as I see it there are three symbols - net CPU_CLK, TNM_NET CPU_CLK, and timespec TS_CPU_CLK. Does the PERIOD refer to the TNM_NET CPU_CLK? This has always confused me.

EDIT: this also fails the same way

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I'm guessing, but as you only have one property perhaps you don't need the pipe separator:

(and maybe you need a space, so "20 ns" ?)

Yes, just specify what goes in P90. The tools understand what the DCM does, and will automatically propagate the correct timing.

This results in the same 'missing semicolon' error... I'll keep looking.

EDIT: so does this:

Error is at line 6, saying that the previous constraint should be terminated with a ; WTF?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

There should be an '=' between TNM_NET and "clk"

Duh. Yes, there should be. It now compiles without complaints.

Now I have to find the logfile that shows timing issues in the megabytes of output...

EDIT: top.srp!

Shows it as passing. I will now try to re-create the failure and check timing.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hmm. I am unable to exactly replicate the problem. I should've saved the bad bitstream source in a separate directory.

I eliminated the last flop on SD_MISO. Now EhBASIC fails to load with
, but in Forth, doing 'hex C000 c@' does not lock up. Hmm. Well, EhBASIC fails anyway, which is significant.

So the problematic case shows:


At 45MHz the clock period is 22ns, so it seems ok. The longest path delay shown is:


That seems OK.

There is this to consider


I haven't found the post-place-and-route report yet. I may have to fiddle with switches somewhere to enable it.

EDIT: trying the same thing with the final flop enabled.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Added the flop to SD_MISO, and everything works like a charm again.

The timing report seems identical, with 13.312ns clock default (why 13.312 anyway if the longest path is 17.75ns?) etc.

That did not help much. The only thing I know is that the problem somehow has to do with that flop, as unrelated as it seems.

The other possibility is that the whole thing is teetering on the edge, and that flop pushes it over, as would other changes... I shudder at the thought.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

In ISE, open Design Summary. It has a section "Detailed Reports", and one of them is the "Post-PAR Static Timing Report"

If you have timing errors, you can open the Tools/Timing Analyzer from the main menu.

Also, you can check the Design Overview Summary for errors.