CHOCHI E with USB Power

[enso]

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).

[Arlet]

enso wrote:

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.

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.

[enso]

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?

[Arlet]

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 ?

[enso]

Arlet wrote:

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...

[Arlet]

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

Code: Select all

NET "clk50"  LOC = P95 | IOSTANDARD = LVCMOS33 | TNM_NET = "clk50";
TIMESPEC "TS_clk50" = PERIOD "clk50" 20 ns high 50%;

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

[enso]

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:

Code: Select all

NET "CPU_CLK" | TNM_NET "CPU_CLK";
TIMESPEC "TS_CPU_CLK" = PERIOD "CPU_CLK" 22ns high 50%;

But it is syntactically wrong and I get an error:

Code: Select all

ERROR:ConstraintSystem:300 - In file: ../hardware/top.ucf(110): Syntax error. 
   Ensure that the previous constraint specification was terminated with ';'.

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

Code: Select all

TNM_NET "CPU_CLK";
TIMESPEC "TS_CPU_CLK" = PERIOD "CPU_CLK" 22ns high 50%;

[BigEd]

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

Code: Select all

NET "CPU_CLK" TNM_NET "CPU_CLK";
TIMESPEC "TS_CPU_CLK" = PERIOD "CPU_CLK" 22ns high 50%;

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

[Arlet]

enso wrote:

Right now the 60MHz clock goes into the FPGA via P90, but I don't think we are interested in that.

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

[enso]

Code: Select all

NET "clk"  LOC = P90  | IOSTANDARD = LVCMOS33  | TNM_NET "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 17ns high 50%;

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

EDIT: so does this:

Code: Select all

5 NET "clk"  LOC = P90  | IOSTANDARD = LVCMOS33 ;
6 TNM_NET "clk";
7 TIMESPEC "TS_clk" = PERIOD "clk" 17ns high 50%;

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

[Arlet]

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

[enso]

Arlet wrote:

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.

[enso]

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

Code: Select all

Memory siz

, but in Forth, doing 'hex C000 c@' does not lock up. Hmm. Well, EhBASIC fails anyway, which is significant.

So the problematic case shows:

Code: Select all

Timing Summary:
---------------
Speed Grade: -5

   Minimum period: 13.312ns (Maximum Frequency: 75.118MHz)
   Minimum input arrival time before clock: 2.288ns
   Maximum output required time after clock: 15.964ns
   Maximum combinational path delay: No path found

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

Code: Select all

Timing Detail:
--------------
All values displayed in nanoseconds (ns)

=========================================================================
Timing constraint: Default period analysis for Clock 'clk'
  Clock period: 13.312ns (frequency: 75.118MHz)
  Total number of paths / destination ports: 200508 / 569
-------------------------------------------------------------------------
Delay:               17.750ns (Levels of Logic = 17)
  Source:            mycpu/state_FSM_FFd12 (FF)
  Destination:       mycpu/ALU/CO (FF)
  Source Clock:      clk rising 0.8X
  Destination Clock: clk rising 0.8X
...

That seems OK.

There is this to consider

Code: Select all

NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
      FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
      GENERATED AFTER PLACE-and-ROUTE.

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.

[enso]

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.

[Arlet]

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.