CPLD Driven color VGA

[Dr Jefyll]

LIV2 wrote:

I could do that in the CPLD but the timing would be slightly different to the output '547 so I may as well pass them through the same latch as the video output.

No doubt there are several different ways that'll work. Any chance you could get the CPLD to update CURSOR and BLANK on the rising edge of clock (to match the '166 shift reg etc)? Adding external flipflops is an alternative solution.

Either way, you need to be mindful of the pipeline. Earlier I mentioned the color and pixel data that's loaded in the reg's, and the color and pixel data that's waiting to get loaded in the reg's. That's incomplete; really there are four things that occupy each stage: the color data, pixel data, CURSOR and BLANK. The obvious choice is to give them all identical delays in reaching the output. OTOH, I'm guessing CURSOR and BLANK simply indicate detection of a certain value in a counter. So, rather than altering the number of flipflops in the CURSOR and BLANK output path you could instead detect a different counter value.

[LIV2]

Dr Jefyll wrote:

No doubt there are several different ways that'll work. Any chance you could get the CPLD to update CURSOR and BLANK on the rising edge of clock (to match the '166 shift reg etc)? Adding external flipflops is an alternative solution.

Yep for those I've changed it so they update on the rising edge of CLK whenever the LATCH signal is asserted, so that it is updated at the same time as the latch and shift register as cursor match & horizontal timings are all measured in character widths.

Quote:

Either way, you need to be mindful of the pipeline. Earlier I mentioned the color and pixel data that's loaded in the reg's, and the color and pixel data that's waiting to get loaded in the reg's. That's incomplete; really there are four things that occupy each stage: the color data, pixel data, CURSOR and BLANK. The obvious choice is to give them all identical delays in reaching the output. OTOH, I'm guessing CURSOR and BLANK simply indicate detection of a certain value in a counter. So, rather than altering the number of flipflops in the CURSOR and BLANK output path you could instead detect a different counter value.

That's correct, CURSOR & BLANK are just matches against counters inside the CPLD so they can easily be fixed easily

So presuming I do that, the best option for an output latch is the counter as it'll use less board space?

I was also wondering what the difference between using another '377 vs a '574? I can see the 574 can be tristated which might come in handy for blanking, is that why?

[Dr Jefyll]

LIV2 wrote:

So presuming I do that, the best option for an output latch is the counter as it'll use less board space?

It seems that way to me, but remember this is driveby advice I'm offering you. I haven't studied all the details, nor thought things through as carefully as I'd do if the project were my own. If you want the extra space and you're certain 4 bits will be enough then yeah, use the counter. (Or a '173.)

Quote:

I was also wondering what the difference between using another '377 vs a '574? I can see the 574 can be tristated which might come in handy for blanking, is that why?

No, '377 would be fine. I only mentioned '574 because it's a little easier to obtain -- especially if you want a fast part such as 74AC. I wouldn't recommend using tri-state for blanking, because the VGA cable that connects to the monitor is a transmission line and should ideally be terminated at both ends to avoid ringing and reflections.

OTOH, the '163 counter we just mentioned *is* good for blanking because, in addition to synchronous load, it also offers synchronous clear.

[LIV2]

Awesome! I'll give it a try once the parts come in and update the thread

Thanks so much for the help!

[Dr Jefyll]

You're welcome! And I hope you noticed a slight edit to my last post.

[LIV2]

Dr Jefyll wrote:

OTOH, the '163 counter we just mentioned *is* good for blanking because, in addition to synchronous load, it also offers synchronous clear.

Nice, I can only find this in HC though is that a problem with a pixel clock of 25MHz? the mux is a 74AC157 so it'd respond much faster to BLANK.

[Dr Jefyll]

Because we decided to add that final register downstream you don't need to worry about the '157 result being asynchronous. The XOR and blanking and the whole schmear will get run through the mill and will come out nice & tidy. So, my remark was superfluous -- sorry. In other circumstances it would be relevant, though. If the '157 weren't there you'd need some other way of doing blanking. And a 163 is good for that.

Quote:

Nice, I can only find this in HC though is that a problem with a pixel clock of 25MHz?

There used to be such a thing as 'AC163, but I haven't checked lately. 'HC may be marginal, timing-wise. Here's what needs to happen in 40 ns (one pixel-clock period):

- after a rising clock edge there's a propagation delay before the '166 Qh output updates
- the XOR then the '157 process that result, each adding propagation delay
- the output of the 157 must be valid in advance of the subsequent rising clock edge in order to satisfy the input setup time required by the final register.

If the '166, XOR and '157 are AC parts then maybe it's OK if the final register is only HC. If you need certainty then get the relevant figures and see if their sum exceeds 40 ns. Otherwise you can seat-of-the-pants it! Try whatever's easy (like HC) first -- it'll probably be OK. If not, you'll need AC for the final register.

[LIV2]

The AC '377s have come in today so I'm going to try them out soon, since I don't have any 163s etc on hand I'll just try another 377 at the output
Since I could only get the 377 in SOIC-20 space is no huge concern
Does this look right?

I think BLANK and CURSOR will need to go through a flop in the cpld as they would otherwise come almost 1 character-time early, of course another option is to change the counter match values but the good thing about the CPLD is that I can change that quickly and easily.
:edit: Corrected the diagram, the '157 is AC and the 166 is unfortunately HC as I wasn't able to find any 166's in AC logic

[Dr Jefyll]

LIV2 wrote:

I think BLANK and CURSOR will need to go through a flop in the cpld as they would otherwise come almost 1 character-time early, of course another option is to change the counter match values

Looks good!

Yet another option for BLANK and CURSOR is to delay them using the unused sections of the new '377.
Edit: oops, bad idea That '377 updates once per pixel. You want BLANK and CURSOR to update once per character.

Probably the best choice is to change the counter match values, as you say.

Quote:

I wasn't able to find any 166's in AC logic

How about 'AHC166 or 'AHCT166?

[LIV2]

Yeah actually I might route BLANK and CURSOR through the '377 because it'll use less resources in the CPLD and those flip-flops are free

I had a look for AHC,ACT etc on element14, mouser & Digikey but didn't find anything. I suppose if the HC isn't fast enough I can probably use a '299 which is available in AC but we will see how I go I guess

[Dr Jefyll]

'AC299 is a good idea. But my suggestion about unused '377 sections isn't. See the edit to my previous post.

[LIV2]

It works! Looks really good too!
I had to swap the A/B inputs on the mux (I was using the inverted Q on the old shift register because it made for a cleaner schematic) but that's cool.

[Dr Jefyll]

Nice to hear about your success!

Are you using 'HC166, then? And did the CURSOR and BLANK signals get sorted out?

[LIV2]

Yeah using a HC166 and it looks good so far. I'll create some test characters with one pixel on the left/right etc to be sure but it's noticeably sharper and no edge artefacts like I was seeing before

CURSOR and BLANK are run through a flip-flop inside the cpld now as follows:

Code: Select all

M_BLANK  <= (V_BLANK OR H_BLANK);
M_CURSOR <= '1' when (unsigned(REG_CURSORLOCATION) = unsigned(MA)) else '0';

FF:
process(clk)
begin
  if rising_edge(clk) then
    if LATCH = '0' then
        FF_CURSOR <= M_CURSOR;
        FF_BLANK <= M_BLANK;
    else
        FF_CURSOR <= FF_CURSOR;
        FF_BLANK <= FF_BLANK;
    end if;
  end if;
end process;
CURSOR <= FF_CURSOR;
BLANK <= FF_BLANK;

I'll be cleaning up the code to make the variable naming more consistent and uploading it to github soon

[LIV2]

Yep after doing some tests it appears to be working perfectly

Here's some shots from the monitor. I wish I had a CRT hanging around as I'm sure it'd look better without LCD scaling