Programmable logic

[ppppenguin]

Many of us have the occasional temptation to build small digital systems. Ordinary TTL and CMOS is a PITA and encourages poor design practice. PLDs are the answer but modern SM packages don't encourage the amateur user.

In my pro design work of course there are multilayer PCBs and specialist assembly but if I want to hack for fun then I'll use a cast off board from a pro job because I can't solder tiny things like that.

A friend has just pointed out this little gadget: http://cgi.ebay.co.uk/Xilinx-CPLD-core-m...0601166190 With the 2C64A, or possibly the earlier 9572XL this looks dead easy to use. Proramming is usually done in VHDL with free Xilinx tools. VHDL is a not a nice language but it does the job. As soon as youhave done your first bit of programmable logic design you will wonder why you ever tediously assmbled CMOS/TTL prototypes.

[AlanBeckett]

Jeffrey,
I don't see why conventional logic should 'encourage poor design practice'. In fact I'd go so far as to say that poor/dreadful/horrible/mangled/unreadable designs belong much more in the realms of software. A few hundred lines of uncommented code is virtually useless, whereas you can always reverse engineer a chunk of TTL.
It looks like an interesting gadget. How does one program it? How much does the programmer cost? It still needs to be interfaced to the outside world and I'm not certain that I'm up to 40 pin DIL sockets these days.
Alan

[ppppenguin]

Standard 74 and 4000 logic parts for the most part don't have CE inputs. The 377 and 161 being notable exceptions. This makes it very hard to do decent synchronous logic design. The usual result is poor quality design, complete with runt pulses, race hazards etc. I know, I've been there.

Programming software for all the smaller Xilinx devices is free from the Xilinx website. That includes all the Coolrunner and 95 series, also many of the Spartan 3 FPGAs and other parts. Even in my professional work I've rarely used devices that were not covered by the free software. The software takes you all the way from VHDL editor to JEDEC or binary file output. The programmng hardware can be built from a few odd components to run from an ordinary parallel port. I've got the Xilinx official programming hardware pods (both parallel port and USB) but then I'm doing this for a living.

[Pamphonica]

I wonder what sort of "digital systems" this sort of Xilinx device is best for.
I have used many variants of the Microchip PIC devices in the past, including a design (for a local amateur radio club) of a 50MHz DFM. I have also designed Midi/DMX monitors and converters, a digitally controlled PSU and a few other devices. The DFM was not simple, but the code was easy to comment and follow, and the result has been taken up and improved by others. The circuit was tiny and easy to build. The PICs are simple to programme as Microchip sell programmers that allow in-circuit programming.
Maybe I am down at the "simple" end of things with only 1000 lines of code in assembler (not C as execution speed was an issue), and I know nothing about these chips but I can't quite see what they do better than PICs (or indeed for a simple circuit, a few TTL/CMOS chips.
Jeffrey, please enlighten we heathens!
Jeremy

[ppppenguin]

It's a bit garbled by the formatting in the forum but here's a fragment of VHDL from a current project. It's all synchronous, with a clock enable (CE) covering everything so that it will run from a common 148.5MHz clock for all digital TV standards, whether they need 148.5MHz, 74.25MHz or 13.5MHz. I haven't put in all the declarations for signals, IO etc. I've put in some extra bold comments for illustration. If you are coming to this from a software background remember that all statements on the same clock execute concurrently, not sequentially as you would expect in C, Basic etc. The order of statements in many cases is irrelevant in VHDL. The VHDL compiler does a lot of optimising to give efficient usage. If your VHDL style is good, this helps the compiler to get a nice looking answer. Poor VHDL style can use more logic than needed, low maximum clokc speeds and other woes even if the logic is actually technically correct.

Code:

process (CK) begin
    if rising_edge(CK) then    
        if CE='1' then

[b]-- This is a JK (strictly RS) flipflop[/b]
-- Define H inner window (1 pixel wide), H outer window (variable) and half line
-- Probable HLOCK_POINT is 26, probable outer window 24/27 to give 3 pix wide around lock point
            if       HBLANK_END(HLOCK_OUTER_WINDOW_START) = '1' then OUTER_H_WINDOW <= true;
                elsif HBLANK_END(HLOCK_OUTER_WINDOW_END)   = '1' then OUTER_H_WINDOW <= false;
                else                                                  OUTER_H_WINDOW <= OUTER_H_WINDOW;
            end if;
            
            INNER_H_WINDOW <= HBLANK_END(HLOCK_POINT) = '1';    -- Not really a window, just 1 pixel wide
            
-- Half line goes low at lock point, goes high halfway through line            
            if         HBLANK_END(HLOCK_POINT) = '1' then HALF_LINE <= false;
                elsif (HCOUNT = HLOCK_MID_LINE)       then HALF_LINE <= true;
                else                                       HALF_LINE <= HALF_LINE;
            end if;
            
-- Some operations happen at the timing reference. Windows etc are sampled, decisions about HMAX/VMAX are made.
            if DELAYED_SELECTED_TIMING_REF then

-- Determine H lock status    by sampling inner and outer H windows    
                if INNER_H_WINDOW                    then H_LOCKED <= true;        -- Within inner window hence locked
                    elsif H_LOCKED and OUTER_H_WINDOW then H_LOCKED <= true;        -- Already locked but strayed into outer window so stay locked
                    else                                   H_LOCKED <= false;    -- Outside windows so not locked
                end if;
-- H_ALMOST_LOCKED occurs when approaching lock                
                if OUTER_H_WINDOW and not H_LOCKED then H_ALMOST_LOCKED <= true;    -- Within outer window but not locked
                    else                                 H_ALMOST_LOCKED <= false;    -- Totally unlocked
                end if;
                
-- Determine V lock status by sampling V window which is exactly one line long
                if V_WINDOW then V_LOCKED <= true;    -- Within  window hence locked
                    else          V_LOCKED <= false;    -- Outside window so not locked
                end if;
                
            end if; --DELAYED_SELECTED_TIMING_REF

[b]-- A load of "random" logic, expressed in a comprehensible way[/b]
-- Determine H lock direction and speed
            if       MANUAL_H_LOCK_UP                                                                         then HMAX_OFFSET <=   H_LOCK_RATE;
                elsif MANUAL_H_LOCK_DOWN                                                                       then HMAX_OFFSET <= - H_LOCK_RATE;
                elsif LOCK_ENABLE and H_LOCK_ENABLE and not H_LOCKED and     H_ALMOST_LOCKED and not HALF_LINE then HMAX_OFFSET <=   1;    -- Slow approach when almost locked
                elsif LOCK_ENABLE and H_LOCK_ENABLE and not H_LOCKED and     H_ALMOST_LOCKED and     HALF_LINE then HMAX_OFFSET <=  -1;
                elsif LOCK_ENABLE and H_LOCK_ENABLE and not H_LOCKED and not H_ALMOST_LOCKED and not HALF_LINE then HMAX_OFFSET <=   H_LOCK_RATE; -- Otherwise fast approach
                elsif LOCK_ENABLE and H_LOCK_ENABLE and not H_LOCKED and not H_ALMOST_LOCKED and     HALF_LINE then HMAX_OFFSET <= - H_LOCK_RATE;
                else                                                                                                HMAX_OFFSET <= 0;
            end if;
-- Only do H correction on specified line            
            if VERT_CE then    -- These run with vertical CE
                if (VCOUNT = HLOCK_CORRECTION_LINE) then OFFSET_HMAX_VALUE <= HMAX_VALUE + HMAX_OFFSET mod 8192;
                    else                                  OFFSET_HMAX_VALUE <= HMAX_VALUE;
                end if;
            end if; -- VERT_CE
        
-- Determine V lock direction
            if       MANUAL_V_LOCK_UP                                                  then VMAX_OFFSET <=  1;
                elsif MANUAL_V_LOCK_DOWN                                                then VMAX_OFFSET <= -1;
                elsif LOCK_ENABLE and V_LOCK_ENABLE and not V_LOCKED and not HALF_FRAME then VMAX_OFFSET <=  1;
                elsif LOCK_ENABLE and V_LOCK_ENABLE and not V_LOCKED and     HALF_FRAME then VMAX_OFFSET <= -1;
                else                                                                         VMAX_OFFSET <= 0;
            end if;
            OFFSET_VMAX_VALUE <= VMAX_VALUE + VMAX_OFFSET mod 2048;
        
        end if; --CE            
    end if; --CK    
end process;
--====================================================================================================================

------------------------------------ Horizontal    count ----------------------------------------------------------------
process (CK) begin
    if rising_edge(CK) then    
        if CE='1' then    --These run with standard CE (13.5MHz/74.25MHz/1)

[b]-- A 13 bit counter with sync reset    [/b]
--Central horizontal 13 bit counter. Line length up to 4125 pixels
            if HRESET then HCOUNT <= 0;                            -- Reset at terminal count
                else             HCOUNT <= HCOUNT + 1 MOD 8192;    -- MOD not essential for symthesis but vital for simulation
            end if;

-- H counter reset with double pipeline
            EARLY_HRESET <= (HCOUNT = OFFSET_HMAX_VALUE);    -- EARLY_HRESET used for 3GHz VERT_CE
            HRESET       <= EARLY_HRESET;                            -- HRESET used for SD/HD VERT_CE

[AlanBeckett]

Standard 74 and 4000 logic parts for the most part don't have CE inputs. The 377 and 161 being notable exceptions. This makes it very hard to do decent synchronous logic design. The usual result is poor quality design, complete with runt pulses, race hazards etc. I know, I've been there.

What an odd comment. I've been there, done that and designed it for a living, and I never had any problems with fully synchronos designs. After all, the likes of PDP-11s were designed and buit with it, and I don't rememebr them suffering from any such problems.
I also used to use Altera FPGAs - very swish in their day. I don't know what they're like these days.
Finally, I've done a lot of designs with PICs, for the same reasons as above. They work fine, and the languages available appear to me to be much more readable.
Alan

[ppppenguin]

Typical problem in logic design in my own field of TV. Part of system at pixel clock rate, part at line rate. To be fully synch all the registers and counters in the parts that work at line rate need to have CE pulse once per line. This restricts the choice of registers and counters severely, unless you use the old trick of extra gating on registers to give a "hold" function.

Before PLDs and FPGAs skilled designers recognised the limitations of available parts and worked within them. I'm sure the PDP11 designers were in that category. Others just did the best they could which in some cases meant capacitors hung in odd places to suppress runt pulses.

If I want something as simple as (say) a 20 bit counter addressing a memory containing a literal TV image, clock rate around 13.5MHz, I have 2 plausible approaches. Either 5 off '161 counters or a PLD. The PLD programming is just a few lines of VHDL and can easily include reset when a top limit is reached. It's also nice and fast, so the delays won't eat into the timing budget too much. It's possible with '161 counters, if you get the carry lookahead right but they are still on the slow side unless you use one of the faster families.

I've never used PICs but understand that they execute instructions serially like most other CPUs. Not so useful if you want fast logic or stuff that's meant to run in parallel. I believe they are excellent for many applications and are easy to use and program, just that I haven't used them.