Concept & Design of 3.3V Parallel 16-bit VGA Boards

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

That was it! I put IBUF back in too.

Now how do I get a nice clean pic from your testbench like you've shown earlier? There are some interesting video artifacts I need some clues on how to get rid of.
I ran ISim, after I commented out $recordfile, $recordvars. ISE didn't like those.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

Does it also complain about '$fwrite()' and friends ? If not, check if there's a 0000.ppm made somewhere. If so, that should be an image of the first frame. It's in .ppm (portable pixmap format), but any decent graphics viewer should be able to open it.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

I don't see $fwrite anywhere in the tb.v file...
I forgot this is reading from RAM too, so it's not going to work unless the verilog model takes into account the random nature of data after power-up?
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

$fwrite is on line 51 and 58, and SRAM modules don't usually randomize the contents. You can do this yourself, though. Either read the SRAM from a file, or write the contents in 'initial' block from the test bench.

Here's what I did for the Micron SDRAM on the previous board:

Code: Select all

mt48lc16m16a2 micron(
           .Dq( sdram_dq ),
           .Addr( sdram_addr ),
           .Ba( sdram_ba ),
           .Cs_n( sdram_cs ),
           .Clk( sdram_clock ),
           .Cke( 1'b1 ),
           .Ras_n( sdram_ras ),
           .Cas_n( sdram_cas ),
           .We_n( sdram_we ),
           .Dqm( {sdram_dqm, sdram_dqm} )
       );

initial begin
         $readmemh( "bank0.bin", micron.Bank0 );
         $readmemh( "bank1.bin", micron.Bank1 );
         $readmemh( "bank2.bin", micron.Bank2 );
         $readmemh( "bank3.bin", micron.Bank3 );
    end
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

Arlet wrote:
Hmm.. I think my FPGA died. I can't program it any more...
I forgot to ask, since one is able to program the FPGA with/without any of the 2 PROMs present. Were you programming the FPGA direct?
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

Yes, I always programmed it directly. I'll try programming a PROM later, and see if that works. Did you already verify that it works ? Without a jumper, does it load the first or second ?

Edit: tried programming both PROMs, and pushing the button. Nothing happens.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

One of the first things I did was to make sure I got the numbering of the PROMs correct.
After reading the datasheet of the tinylogic 2x1 MUX, it says all inputs have Schmitt triggers so I would assume if you don't have a jumper to pull-up or pull-down the select pin it would naturally/reliably go to GND which selects the #2 PROM. I tried it and it seems this is so.
User avatar
Dr Jefyll
Posts: 3526
Joined: 11 Dec 2009
Location: Ontario, Canada
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Dr Jefyll »

Quote:
all inputs have Schmitt triggers so I would assume if you don't have a jumper to pull-up or pull-down the select pin it would naturally/reliably go to GND
Unfortunately you've sllghtly misinterpreted what a Schmitt trigger does, EE. It can resolve a noisey or slowly-changing input into a crisp, valid 1 or 0 result, but it doesn't replace a pullup/pulldown. Sounds like you need to add a pulldown; otherwise you have a high-impedance input that's left floating.

If there's some contamination or other stray resistance on the PCB then the input might float high (or low) by itself. It's not reliable, of course. A floating input can also turn your circuit into something resembling a Random Number Generator :D

http://en.wikipedia.org/wiki/Schmitt_trigger

cheers
Jeff
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

Thanks for clarifying Dr.Jeff. :) I think I've read about using one as a random number generator in another thread in the hardware section. PaulF's comment there...
I guess the jumper is mandatory then. I think Arlet was trying to get away with a working board, using absolute minimum parts.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

ElEctric_EyE wrote:
I think Arlet was trying to get away with a working board, using absolute minimum parts.
It's more like I just didn't know how the board is supposed to work, so I'm just guessing.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

Oh ok... I thought I did a good job explaining the workings in the head post. Check where the word 'design' is in boldface. I do need to update it though, because it does not talk about the 4 programmable switches that's been added but it's accurate.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

You're using something like fig 2-2 from UG380, but with the two PROMs chained together, and the two DO outputs going into a mux to the FPGA DIN ?

I just checked, and I don't even see a clock.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

Arlet wrote:
You're using something like fig 2-2 from UG380, but with the two PROMs chained together, and the two DO outputs going into a mux to the FPGA DIN ?
Correct, similar. Except my setup goes Connector->PROM1->PROM2->FPGA.
Arlet wrote:
...I just checked, and I don't even see a clock.
You don't mean TCK? That's there...
EDIT: Sec, I see what you mean...

It's there. Pin 70 of the FPGA to pin 3 of PROM1, then it snakes through/around the JTAG connector before it goes to PROM2.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by Arlet »

I mean, I don't see it wiggle on the scope when I press the button or power up the board.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

I see 2MHz square wave for just about 1sec.

I guess that's the part of the FPGA that's cooked or the pin isn't soldered? Strange. You don't even need that signal when you're programming the FPGA direct without a PROM. I would think it should still output the clock though...
Post Reply