Page 5 of 7
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 7:11 am
by GARTHWILSON
If there's nothing driving it at that voltage, the capacitance would have held it at the last driven voltage.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 7:17 am
by 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...
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 7:49 am
by Arlet
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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 7:57 am
by 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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 7:58 am
by GARTHWILSON
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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 8:02 am
by Arlet
If it's a bus contention, it wouldn't change so dramatically when I touch the pin with my finger (see capture)
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 8:07 am
by GARTHWILSON
Ah yes, that's definitely different.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 3:13 pm
by 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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 3:20 pm
by barrym95838
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
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 3:30 pm
by 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)
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 4:02 pm
by 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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 4:08 pm
by 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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 4:17 pm
by enso
Here is the new bitstream, same as 003 but with pulldowns enabled on the SRAM databus interface.
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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 4:27 pm
by 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.
Re: CHOCHI - an inexpensive FPGA board with 128K SRAM
Posted: Sat Sep 28, 2013 4:33 pm
by 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.