Page 3 of 4
Re: CPLD Driven color VGA
Posted: Sat Aug 18, 2018 3:25 pm
by Dr Jefyll
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.
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 12:26 am
by LIV2
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.
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?
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 1:41 am
by Dr Jefyll
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.)
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.
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 1:58 am
by LIV2
Awesome! I'll give it a try once the parts come in and update the thread
Thanks so much for the help!
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 2:09 am
by Dr Jefyll
You're welcome! And I hope you noticed a slight edit to my last post.
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 2:53 am
by LIV2
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.
Re: CPLD Driven color VGA
Posted: Mon Aug 20, 2018 3:33 am
by 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.
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.
Re: CPLD Driven color VGA
Posted: Mon Aug 27, 2018 2:58 am
by 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
Re: CPLD Driven color VGA
Posted: Mon Aug 27, 2018 3:40 am
by Dr Jefyll
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.
I wasn't able to find any 166's in AC logic
How about 'AHC166 or 'AHCT166?
Re: CPLD Driven color VGA
Posted: Mon Aug 27, 2018 4:00 am
by 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
Re: CPLD Driven color VGA
Posted: Mon Aug 27, 2018 4:47 am
by Dr Jefyll
'AC299 is a good idea. But my suggestion about unused '377 sections isn't. See the edit to my previous post.
Re: CPLD Driven color VGA
Posted: Mon Aug 27, 2018 11:49 pm
by 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.
Re: CPLD Driven color VGA
Posted: Tue Aug 28, 2018 12:05 am
by Dr Jefyll
Nice to hear about your success!
Are you using 'HC166, then? And did the CURSOR and BLANK signals get sorted out?
Re: CPLD Driven color VGA
Posted: Tue Aug 28, 2018 12:27 am
by 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
Re: CPLD Driven color VGA
Posted: Wed Aug 29, 2018 1:08 am
by 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