CHOCHI - an inexpensive FPGA board with 128K SRAM

[GARTHWILSON]

If there's nothing driving it at that voltage, the capacitance would have held it at the last driven voltage.

[enso]

Curious. Perhaps more decoupling is a good idea. However, I have many of these boards running without obvious problems. Perhaps that issue causes the 45MHz speed limit...

It looks very suspiciously steady at 2V after the initial transient. Definitely slowing down the works...

[Arlet]

GARTHWILSON wrote:

If there's nothing driving it at that voltage, the capacitance would have held it at the last driven voltage.

Yes, but the last driven voltage is either 0V or 3.3V, and then you'd expect a slow (dis)charge curve away from that. Now, I get this rather abrupt and stable transition to 2V.

[Arlet]

I suspect what happens is that the output driver is switched off during the transition.

Code: Select all

assign xdb[7:0]     = we ? di[7:0]   : 8'bZ; //on write, let data out  

This is a combinatorial output, so there's unpredictable timing between the 'di' and 'we' changes. I don't think it's affecting performance.

Generally, you should use registered outputs so all your outputs change cleanly and synchronously.

[GARTHWILSON]

Arlet wrote:

GARTHWILSON wrote:

If there's nothing driving it at that voltage, the capacitance would have held it at the last driven voltage.

Yes, but the last driven voltage is either 0V or 3.3V, and then you'd expect a slow (dis)charge curve away from that. Now, I get this rather abrupt and stable transition to 2V.

which is why I don't think it's a high-impedance phenomenon. There's probably bus contention.

[Arlet]

If it's a bus contention, it wouldn't change so dramatically when I touch the pin with my finger (see capture)

[GARTHWILSON]

Ah yes, that's definitely different.

[enso]

I've seen this crazy pattern before, but I can't remember what it's related to. It looks like an artifact (produced by the scope), as it is a chopped up sine (or similar) wave, much like a Fresnel lens. Definitely seen it before...

I'll take a look. DI bus is a large OR gate that ors in a bunch of inputs that are generally registered, but in case of the SRAM I suppose they are not. I am not sure how to register SRAM output without incurring further slowdowns.

Could it be some kind of metastability that resolves itself? I should probably enable pulldowns on the SRAM input pins.

There are a couple of other possibilities I will check into.

[barrym95838]

Arlet wrote:

If it's a bus contention, it wouldn't change so dramatically when I touch the pin with my finger (see capture)

That's one of the coolest-looking scope waveforms I've ever seen! I forgot to look before posting ... is this a
'working' circuit?

Mike

[Arlet]

My take on this: the short discontinuities are the real action where the 6502 core is writing to the data bus. The intermediate wavy parts are when the bus is in hi-Z state, and my finger charges/discharges the bus capacitance.

The fact that it doesn't look the same is because the bus driver is switched off just in the middle of a transition (because it's mixing a bunch of combinatorial outputs together)

[enso]

The SRAM module does flop in the data:

Code: Select all

  wire [7:0] xin = we ? 8'bZ : xdb[7:0] ; //on read, let data in    
  assign xdb[7:0]     = we ? di[7:0]   : 8'bZ; //on write, let data out  
  //
  // Return read result next cycle
  always @ (posedge sclk)
    if(en & ~we)  //on write, output 0 - for some reason it's FF
      do[7:0] <= xin[7:0];
    else
      do[7:0] <= 8'h00;

The initial 'xin' combinational assignment simply activates the tri-state circuit inside the BUFG. The 'always' clause afterward flops in either 'xin' or 0 (to allow final OR circuit to work). Oh, wait, the output is not flopped, but it goes to the SRAM, which is asynchronous...


The SRAM data lines in the .ucf files do not pull down, and they should. I am sure that is the issue. I don't have a scope fast enough to check, but I will create a new bitstream and post it ASAP.

I am working on cleaning up the build environment (it is somewhat convoluted) and will post a buildable verilog system with a Makefile as soon as I can. The intent is a completely open system, of course.

[Arlet]

I'm talking about this part, that drives the databus:

Code: Select all

assign xdb[7:0]     = we ? di[7:0]   : 8'bZ; //on write, let data out  

di = CPU_DO, and we = CPU_WE. Both DO and WE enable signals are combinatorial outputs of the CPU module.

[enso]

Here is the new bitstream, same as 003 but with pulldowns enabled on the SRAM databus interface.

6502_45_004.mcs.zip

(25.41 KiB) Downloaded 173 times

Arlet, if you have a few minutes, could you check if this bitstream exhibits the same behaviour against 003? My scope is way too slow.

Thanks for your help.

[enso]

Funny thing - I had certainly meant to pull down the lines, the comment even says so... Lost in the shuffle.

EDITED I thought it ran at 60MHz, but no.

[Arlet]

This is what it looks like now. It's getting pulled down, as you'd expect. But it's only a cosmetic thing. There's no problem with weird voltages if nobody's reading the data.

LED is blinking faster too.