Hello everyone!

First, here:

https://www.intel.com/content/www/us/en ... tch_sr.htm

So I'm trying to generate VGA sync signals using a Altera EPM7064S CPLD, programming in Quartus. Attached is a picture of this part in Quartus on my CPLD. Using Ben Eater's design, I'm going with SR latches.

The Horizontal sync signal works great with 2 NAND's. The Vertical sync does not. I put that funny SRFF device in there, with a BOR and well, it worked.

When I try to switch them around (horizontal using SRFF and vertical using the NANDs), I get wonky stuff. Looney land. If I use the same type for both, I still get crazy results on the scope. So far as I can see, it ONLY works like this, and I don't know exactly why.

I triple checked the incoming signals and they are spot on. The results (when in this particular configuration) are spot on.

If I'm going to continue using Quartus and CPLD's, how can I tell when the NAND's will work, or when the SRFF's will work? Is there some hidden rule that I'm missing? Is there something easier than all of this?

[ Lastly, just to let you know, though I got these sync signals correct down to the pico-second, my monitor STILL is not picking up what I'm laying down. I blame the monitor at this point. ]

Thanks everyone, for your help and insight.

Chad

Chad,
Like the appnote said, it is not a good idea to use cross-coupled NAND gates in CPLD. The fitter may pick an particular logic implementation that has more delay and worse yet, as design changes, the fitter may pick different implementation with different characteristics. The self-clocking SRFF is also not a good idea because you are creating a race condition between falling edge or S or R to rising edge of clock which clock in the S or R signal. That race is also implementation dependent and can vary depending on where the fitter places the logic cell.

You have the right idea using SR flipflop, but its clock should be the same clock that generated the horizontal and vertical signals (~H656, ~H752, ~V490, ~V492).

Refer to the CPLD schematic (Chad_12_29_design.pdf) I posted on Jan 2 2022 in your "VGA and Dual Port RAM" topic.

Bill

I was using that as a guide for sure. Problem is, when I do configuration on the SRFF I get this:

Error (12014): Net "CLK", which fans out to "inst", cannot be assigned more than one value
Error (12015): Net is fed by "pin_name1"
Error (12015): Net is fed by "VCC"

I mean, it looks JUST like what you have. And I'm using the same clock that I was using for the 161's earlier.

You have a better Quartus than me

I'll try other things. Thank you.

Chad

EDIT:

Yep, I connected CLK to VCC somewhere. Just as it said. That was a waste of an hour! Moving on.

Ok, so that all worked. Again, perfect signals, perfect timing. NOTHING on my monitor, nothing at all. I had more success with the breadboard at this point.

Moving on. Thanks.

My monitor will also display a dark screen when there are no RGB signals. When I powered off the Hsync and Vsync generator, it will display "video signal lost". When I power up the Hsync and Vsync generator again without RGB signals, it will display a dark screen again. Have you try applying a small signal (<0.7V) on one of the RGB input?
Bill

Adding to this in case you do send a voltage through one of the colour lines and still see nothing: Some monitors refuse to display anything at all if any of the colour signals are above ground level at all during any of the blanking intervals. I found this out the hard way with my vintage Dell LCD display…

Does your monitor have any kind of OSD? With mine, if you push one of the buttons, it shows a menu with information on how the signal you're sending is being interpreted; if you send something that the monitor doesn't recognize, the OSD just doesn't come up.

Attached are pictures, it finally works! Praise God It has been a month and a half of work up to this point. So thank you guys for your help and support.

Let me reply first:

My monitor seems to show black when no RGB is applied. I have just learned this. I've been sitting with the "self test" floating in my face for so long I didn't realize much else. Likewise it seems this particular monitor will accept 5V colors and make them very bright!

Likewise, if there's no ground during the blanking times it seems to not work. And lastly yes it does have an OSD, but it hadn't been working at all up until just now, so it's been quite useless to me.

Ok, so, what was wrong? I was driving this morning and thought: the board is fine, the oscillator, the signals, everything is fine. The monitor is stock, but I tried another last night and it was doing the exact same thing. But, what I didn't check was the CABLE. Yep, the cable. When I was shoving wires into this thing about 3 months ago, I apparently looked at the pinout for the male end, not the female end. <insert "Big Dummy" here>

As soon as I switched things horizontally there, it immediately worked! How many hours of messing with this thing have been wasted??? Well, not much really because I found my power supply was bad, and I found this SR instability in Quartus.

Going forward: As you can see on the monitor, I chose H512 and V256 as logic for visible or not. I would *like* use the typical H640 and V480 with some SR Latches, BUT it's still not working right for me! I do not know what the heck is going on, but I cannot get an H-BLANK or V-BLANK signal to work out. The scope says those particular values are fine. Likewise the reset values of H800 and V525 must be fine because I'm able to display something on the screen. Though when I put those to the scope, I get nothing. And the monitor shuts down (for some reason??).

So something is unstable. I don't know how or what. It's a Quartus / CPLD thing at this point, not necessarily a logic thing.

Lastly, you can see in the monitor some lines going on. Not sure what that is, my guess is the lack of capacitors make things jumpy. Digital vs analog. Also, I took a picture of the ProtoRC board Bill sent me, and all the wires going too and fro. I have about 1 sq ft of workspace on my desk to work with, it's been un-fun. Will need a larger desk sometime soon

tl;dr, it works mostly.

A very special thanks to Bill, for your unwavering support, and for the tools to make this work at all. I literally could not have done it without you.

Unless y'all have more thoughts on these mysterious SR Latches in Quartus that I still can't get right, or how to make them more reliable, I guess that might be it!

Thanks again everyone. It works, yay!

Chad

Congrats—looks great!



If I had a dollar for every time something like that has happened to me…

Well, small update, no pictures.

I found why my some of SRFF latches were not working in Quartus! Timing.

I was assuming CPLD's work kind of like 74' logic chips. You jump from this chip to the next to the next, some amount of time between them (even if it was small), etc.

Nope! Well, kind of nope. The reason I wasn't able to get a blanking signal, though I was ok with sync signals, was because H800 and V525 are also are connected to the reset signals. For some reason, H800 was able to reset the counters, but not able to reach the SRFF latch in time. That's also why the scope was basically showing a flat line when I displayed H800. After zooming in, I saw it jittered where it should have been square.

So, I changed from async reset to sync reset, and I got nice square waves now! This concept ties in nicely with the discussion we had here:

viewtopic.php?f=12&t=6914

Alright, nothing else to comment about, just a CPLD discovery, hopefully someone can find this helpful one day. Thanks!

Chad

For the record, it's not just CPLDs. Even designs using discrete logic can run into trouble with asynchronous loads and resets.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Might as well add to the list some more:

Today I discovered that level-triggered latches are not really good with CPLD! I was having major issues for about 2 days, and it was just *not working*. Certainly not as expected.

I changed some latches to edge-triggered flip-flops and boom, it worked right off the bat. I think what was going on was timing yet again. Something like my enable signal for the latch was just not reaching there in time, or something.

Now I also see why the SRFF components use a CLK, and why everything should use a clock on a CPLD.

Much learning still to come. BTW, I discovered how to make the 640x480 VGA turn into 320x200, while not overscanning any RAM: First I store the value of the address counters in flip flops. After 320 pixels are drawn horizontally, and if it's an even row (starting at 0), I load that stored address back into the counters. It ends up counting like this:

save, 0, 1, 2, ... 319, load,
save, 0, 1, 2, ... 319, no-load,
save, 320, 321, 322, ... 639, load,
save, 320, 321, 322, ... 639, no-load,
save, 640, ...

320 x 200 = 64K exactly, but if I use 4-bit color with a 74HC244, I can get away with only using 32K of RAM. Attached are some pictures of my testing this, no RAM connected yet.

Hopefully this will be meaningful to somebody at some point, because I'm learning the hard way. By making lots of mistakes!

Chad

YES!!
Furthermore, you should use the global signals (pins 43,44,1,2) as clocks, especially pin 43 and pin 2. This is because the global signals have dedicated distribution networks so signals arrived at each LAB at the same time. The CLK inputs (43, 2) have balanced network for both clock and clock-inverted so you can use both edges of clock signal without worrying about race condition between various stages of logic.

Power of CPLD is allow you to make mistakes and learn quickly from them.
Bill