The purpose of this post is to try to get a discussion going
on various design tricks for severely limited devices like CPLDs.
On that note I'll pose the following challenges to the group:



Challenge 1 - Tetris in as few CPLDs as possible
------------------------------------------------

How would you design a Tetris game if you only had CPLDs
available? How many CPLDs would you use and of what kind?

Would you need any other kind of circuits to implement an
efficient solution? (External SRAMs or EPROMs for example?)

What kind of display would you use? (TV, Oscilloscope, Led matrix, etc?)
What kind of input device would you use? (Plain buttons or perhaps a
more advanced input device like a NES joypad?)


I believe that this is a rather nice problem with many
interesting optimization possibilities.


Personally I have an almost finished solution based on the XC95 series.
However, I will not tell you how many I need or the exact model number(s)
that I'm using right now. I do have a rather nice architecture which I
believe will be hard to improve on. I'll let you ponder this for a week
or so before I post my idea for a solution.




Challenge 2 - A digital watch with as few CPLDs as possible
-----------------------------------------------------------

This is an easier problem which should require fewer or smaller CPLDs
than the previous challenge.

Requirements:
* Time should be showed in HH:MM:SS format (preferably 24h format)
* It should be possible to set an alarm (HH:MM precision is good enough)
* Stop watch functionality in MM:SS:T   (That is, up to 59 minutes, 59
  seconds and 9 tenths of a second.)
* There should be a user interface of some kind (it should be possible to
  change the time that is)
* The time, alarm, and stop watch functionality shall work independently.
  (You don't want your watch to stop working just because you are setting
  your alarm or using the stop watch.)


What kind of display would you use here? (7 segment LEDs? LCD?, etc?)
What kind of input? (Plain buttons or something different?)
What clock frequency do you need?

This is a rather nice problem which will allow you to think about the
best way to do resource sharing in a CPLD.

As a baseline, the students I have supervised who do this kind of project
end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually
don't bother with any kind of resource sharing though...


Personally, I have a relatively small solution to this, but there are still
a few tricks I haven't used. In my solution I'm using a 7 segment LED driver
circuit with built in NBCD decoder (the 9368), so if you want to compare
your solution to mine you might want to output NBCD coded numbers out of your
CPLD.

I'll let you ponder this problem for a few days or so as well before
doing a small writeup on my solution.


/Andreas

On 2008-10-16, Herbert Kleebauer <klee@unibwm.de> wrote:
> Andreas Ehliar wrote:
>> 
>> The purpose of this post is to try to get a discussion going
>> on various design tricks for severely limited devices like CPLDs.
>> On that note I'll pose the following challenges to the group:
>> 
>> Challenge 1 - Tetris in as few CPLDs as possible
>  
>> Challenge 2 - A digital watch with as few CPLDs as possible
>
> Put a simple soft core CPU in a xc95 and add some ROM/RAM, then
> a single CPLD should be enough.

That is probably the easiest solution. A colleague and I have
investigated this approach a little bit to try to figure out the
optimal architecture. The goal would be to have both sound output
and tile based graphics in this case. We were aiming for a XC9572,
but we gave up on it since programming would be extremely cumbersome
as both audio and video would require cycle accurate code.

Some of the tricks we learned while doing this was to move around
our address register and the program counter so that one of them
always addressed the memory.

At first we considered the following architecture:

       +---+
PC --->|   |
       |MUX|---> Address to memory
AR --->|   |
       +---+

However, if we do it like this instead:

 +-------------------------------+
 |                               |
 |  +--+                 +--+    |
 |  |PC|    +-------+    |AR|    |
 +->|  |--->| Adder |--->|  |----+---> Address to memory
    |> |    +-------+    |> |
    +--+                 +--+

The adder adds either 1 or 0. If we always exchange PC and
AR two times during the execution of one instruction we will
both be able to address memory through the address register and
fetch the instruction. We will also get the operation AR++ for
free. But most importantly: As we no longer have the mux, we save
these macrocells for other uses. This is quite important since the 9572
only has 72 macrocells...


However, what about if you would like to avoid an SRAM and EPROM,
what kind of techniques would you use in that case?

/Andreas

On 2008-10-16, Frank Buss <fb@frank-buss.de> wrote:
> Andreas Ehliar wrote:
>
>> How would you design a Tetris game if you only had CPLDs
>> available? How many CPLDs would you use and of what kind?
>
> The question doesn't make sense. I would use a EPM2210/G with 2,210 LEs and
> could install Nios on it, so all I need is one CPLD.

My intention was to challenge the group to use as few CPLDs
and as small CPLDs as possible.

Although I admit that you will be probably be finished with
your solution before I'm even finished with trying to figure
out the architecture of my solution :)

/Andreas

On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote:
> No mention of leading zero suppression ?

I haven't really thought about it, but that would make a nice addition :)

>> What kind of display would you use here? (7 segment LEDs? LCD?, etc?)
>
> MUX'd or Non MUX'd ?
> LCDs need a XOR backplane, and they also have MUX choices too.

I didn't use a mux'd solution, but as you point out further down I'm
cheating somewhat with my choice of LED drivers. MUX'd would probably
be better if using traditional driver circuits like the ULN2003.

> 50Hz, 60Hz and 32.768KHz are the common ones....

50 Hz and 60 Hz are quite hard if you want to do some kind of resource sharing.
If you use 32768 Hz it is much easier to move things around to only one
arithmetic block.

> You could get them to code direct 7 segment counters, for a non-mux 
> display. Nice to show there are non Bin/bcd counters possible too...

I haven't thought about that at all, that is a very interesting counter idea.
It is probably not going to be useful in many cases but you never know when
something similar will save your day :)


>> Personally, I have a relatively small solution to this, but there are still
>> a few tricks I haven't used. In my solution I'm using a 7 segment LED driver
>> circuit with built in NBCD decoder (the 9368), so if you want to compare
>> your solution to mine you might want to output NBCD coded numbers out of your
>> CPLD.
>
> Surely the 9368 should be part of the CPLD ?

Yes. But I had to use some sort of LED driving circuit, and we had lots of 9368
in the lab :) Perhaps I'll try to update my solution to use a more traditional
LED driver instead. Unfortunately that is probably going to mean that I have to
use a larger CPLD as the current version is filled to the limit. On the other
hand, that would also allow me to fit a clock prescaler into the CPLD to avoid
the very non-standard frequency the current solution needs :)

But I agree that I'm cheating a little bit here.

/Andreas

On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote:
> A nice small device for this, would be the new Serial SPI SRAM ?
> http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207
> SO8 or tssop8.

This kind of device could be rather nice in some situations, thanks
for mentioning it. It was fairly affordable on digi-key as well although
not extremely cheap.

> Perhaps add a SPI flash memory for the tiles
> (quite large flash comes now in SO8, so I'd load one up with thousands
> of next-tiles, and shift the random-tile decisons to the 
> flash-generation code :) - keeps the CPLD simpler...

Nice idea. Although I must admit that my current solution doesn't really
use any sort of tiles at all, just fully white or fully black (large)
pixels.

> all that assumes you stay in macrocell CPLDs, and do not move to
> a Lattice MachXO type device.

Exactly, this isn't very challenging in such a device, especially the
ones with built in block rams. I've looked into the MachXO devices a
little bit (I supervised a final year project which used such a device)
and they seem like rather nice devices. If you are used to optimizing
CPLD designs for the limitations of a traditional CPLD, the MachXO is
luxuriously large... :)

/AE

Andreas Ehliar wrote:
> 
> The purpose of this post is to try to get a discussion going
> on various design tricks for severely limited devices like CPLDs.
> On that note I'll pose the following challenges to the group:
> 
> Challenge 1 - Tetris in as few CPLDs as possible
 
> Challenge 2 - A digital watch with as few CPLDs as possible

Put a simple soft core CPU in a xc95 and add some ROM/RAM, then
a single CPLD should be enough.

Andreas Ehliar wrote:

> How would you design a Tetris game if you only had CPLDs
> available? How many CPLDs would you use and of what kind?

The question doesn't make sense. I would use a EPM2210/G with 2,210 LEs and
could install Nios on it, so all I need is one CPLD.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Andreas Ehliar wrote:

> Challenge 2 - A digital watch with as few CPLDs as possible
> -----------------------------------------------------------
> 
> This is an easier problem which should require fewer or smaller CPLDs
> than the previous challenge.
> 
> Requirements:
> * Time should be showed in HH:MM:SS format (preferably 24h format)
> * It should be possible to set an alarm (HH:MM precision is good enough)
> * Stop watch functionality in MM:SS:T   (That is, up to 59 minutes, 59
>   seconds and 9 tenths of a second.)

Why stop at :T, push the students a little :)
ask for :TT - easy at 50Hz AC, a little harder at 60Hz and 32.768KHz
- or even :TTT, and make a precision sports timer, with optical gates.

Pass that to the Physics teachers and sports teams...


> * There should be a user interface of some kind (it should be possible to
>   change the time that is)
> * The time, alarm, and stop watch functionality shall work independently.
>   (You don't want your watch to stop working just because you are setting
>   your alarm or using the stop watch.)

No mention of leading zero suppression ?

> 
> What kind of display would you use here? (7 segment LEDs? LCD?, etc?)

MUX'd or Non MUX'd ?
LCDs need a XOR backplane, and they also have MUX choices too.

> What kind of input? (Plain buttons or something different?)

This opens up a large range of complexity/user-friendly trade offs:
Up/Dn buttons are more friendly, but make more complex counters.
Rotary encoders are even nicer, and a rate-sensistive rotary encoder
nicer still.

> What clock frequency do you need?

50Hz, 60Hz and 32.768KHz are the common ones....

> 
> This is a rather nice problem which will allow you to think about the
> best way to do resource sharing in a CPLD.
> 
> As a baseline, the students I have supervised who do this kind of project
> end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually
> don't bother with any kind of resource sharing though...

You could get them to code direct 7 segment counters, for a non-mux 
display. Nice to show there are non Bin/bcd counters possible too...

> Personally, I have a relatively small solution to this, but there are still
> a few tricks I haven't used. In my solution I'm using a 7 segment LED driver
> circuit with built in NBCD decoder (the 9368), so if you want to compare
> your solution to mine you might want to output NBCD coded numbers out of your
> CPLD.

Surely the 9368 should be part of the CPLD ?

-jg

Andreas Ehliar wrote:

> The purpose of this post is to try to get a discussion going
> on various design tricks for severely limited devices like CPLDs.
> On that note I'll pose the following challenges to the group:
> 
> 
> 
> Challenge 1 - Tetris in as few CPLDs as possible
> ------------------------------------------------
> 
> How would you design a Tetris game if you only had CPLDs
> available? How many CPLDs would you use and of what kind?
> 
> Would you need any other kind of circuits to implement an
> efficient solution? (External SRAMs or EPROMs for example?)

You need to define the Pixels and tile-sets.

A nice small device for this, would be the new Serial SPI SRAM ?
http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207
SO8 or tssop8.

Perhaps add a SPI flash memory for the tiles
(quite large flash comes now in SO8, so I'd load one up with thousands
of next-tiles, and shift the random-tile decisons to the 
flash-generation code :) - keeps the CPLD simpler...

all that assumes you stay in macrocell CPLDs, and do not move to
a Lattice MachXO type device.

> 
> What kind of display would you use? (TV, Oscilloscope, Led matrix, etc?)

Depends on the desired resolution. LED matrix is going to be a bit coarse.
TV is the most widely available.  (PAL or NTSC)

> What kind of input device would you use? (Plain buttons or perhaps a
> more advanced input device like a NES joypad?)

Rotary encoder perhaps ?

-jg

Andreas Ehliar wrote:
> On 2008-10-16, Herbert Kleebauer <klee@unibwm.de> wrote:

> > Put a simple soft core CPU in a xc95 and add some ROM/RAM, then
> > a single CPLD should be enough.
> 
> That is probably the easiest solution. A colleague and I have
 
> However, what about if you would like to avoid an SRAM and EPROM,
> what kind of techniques would you use in that case?

I would use a FPGA instead of CPLD. With a xc3s1200e you can use 
32 kbyte internal program/data memory an then have all the IO pins
available for other purpose and with a simple CPU you also have
nearly all the logic in the FPGA available for additional hardware.
Here a CPU which uses 72 of 17344 Slice Flip Flops and 142 of
17344 4 input LUT's of xc3s1200e-4fg400.

ftp://137.193.64.130/pub/mproz/mproz3_e.pdf

Andreas Ehliar wrote:
> On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote:
> 
>>No mention of leading zero suppression ?
> 
> 
> I haven't really thought about it, but that would make a nice addition :)
> 
> 
>>>What kind of display would you use here? (7 segment LEDs? LCD?, etc?)
>>
>>MUX'd or Non MUX'd ?
>>LCDs need a XOR backplane, and they also have MUX choices too.
> 
> 
> I didn't use a mux'd solution, but as you point out further down I'm
> cheating somewhat with my choice of LED drivers. MUX'd would probably
> be better if using traditional driver circuits like the ULN2003.

You can direct drive LEDs from CPLDs, and I'd tend to pull the LED block
into its own PLD, so students can partition the tasks more easily.

It could manage a 5 wire nibble Mux bus for example: rising edge Digit, 
falling  edge Data and give you the choice of MUX or De-Nux-Static or 
even LCD Display Blocks.
With a little care, this could even be two-way, and read-back 
buttons/IDs from the display block in a couple of 16 address slots

... or a TV block ?  a while ago I recall working a 7 segment
TV display into a CPLD - it's really just a time-gymnastic special case
of a normal MUX (but with fewer output pins ;) .


> 
>>50Hz, 60Hz and 32.768KHz are the common ones....
> 
> 
> 50 Hz and 60 Hz are quite hard if you want to do some kind of resource sharing.
> If you use 32768 Hz it is much easier to move things around to only one
> arithmetic block.

a good system should be able to use any of these clock sources... :)

> 
>>You could get them to code direct 7 segment counters, for a non-mux 
>>display. Nice to show there are non Bin/bcd counters possible too...
> 
> 
> I haven't thought about that at all, that is a very interesting counter idea.
> It is probably not going to be useful in many cases but you never know when
> something similar will save your day :)

We did an ATF22V10 direct 7 seg counter, and managed Up/Dn/RippleBlank 
and Async RST. These mounted one behind each largish LED digit, and IIRC 
did 8-9 digits for a Quadrature display readout.

> 
>>>Personally, I have a relatively small solution to this, but there are still
>>>a few tricks I haven't used. In my solution I'm using a 7 segment LED driver
>>>circuit with built in NBCD decoder (the 9368), so if you want to compare
>>>your solution to mine you might want to output NBCD coded numbers out of your
>>>CPLD.
>>
>>Surely the 9368 should be part of the CPLD ?
> 
> 
> Yes. But I had to use some sort of LED driving circuit, and we had lots of 9368
> in the lab :) Perhaps I'll try to update my solution to use a more traditional
> LED driver instead. Unfortunately that is probably going to mean that I have to
> use a larger CPLD as the current version is filled to the limit. On the other
> hand, that would also allow me to fit a clock prescaler into the CPLD to avoid
> the very non-standard frequency the current solution needs :)

See above, I would move the 'display-block' into a separate CPLD and 
split the task for students.

Gets them used to interfacing with someone else's design block.

-jg

Andreas Ehliar wrote:

> The purpose of this post is to try to get a discussion going
> on various design tricks for severely limited devices like CPLDs.
> On that note I'll pose the following challenges to the group:
> Challenge 2 - A digital watch with as few CPLDs as possible
> -----------------------------------------------------------
> 
> This is an easier problem which should require fewer or smaller CPLDs
> than the previous challenge.
> 
> As a baseline, the students I have supervised who do this kind of project
> end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually
> don't bother with any kind of resource sharing though...

I've dug into the corners of the harddrive :)... and found a CarClock 
PLD - this is slightly simpler, using HH:MM and uses FastMin and FastHrs
set buttons.  (no alarm., no stop watch)

It has non-mux 7 seg LED drive, and accepts 50Hz/60Hz/4Hz (32.768+HC4060)

Fits into the smallest CPLD (32 macrocell) ATF1502ASL (or ATF1502BE) as 
LED or bumps into ATF1504ASL with LCD display option.

Resource map is below

-jg



Atmel ATF1502 Fitter Version 1919 ,running Fri Oct 17 09:35:32 2008
MCell Pin# Oe   PinDrive  DCERP  FBDrive    DCERP  Foldback 
CascadeOut     TotPT SO
MC1   4    on   HourL0    C----  Div0       Dg---  --          -- 
       3     f-
MC2   5    on   HourL1    C----  nFastHour  L----  --          -- 
       3     f-
MC3   6    on   HourL2    C----  nFastMin   L----  ClkEHUnits  -- 
       3     f-
MC4   7    on   HourL4    C----  MUnits2    Dgeg-  NA          -- 
       5     f-
MC5   8    on   HourL3    C----  Div2       Dge--  NA          -- 
       5     f-
MC6   9    on   HourL5    C----  MUnits1    Dgeg-  NA          -- 
       5     f-
MC7   11   on   HourL6    C----  Div1       Dge--  nClkEHUnits -- 
       5     f-
MC8   12   on   MinL0     C----  MTens1     Dgeg-  nNettTC     -- 
       5     f-
MC9   13   on   MinL1     C----  MTens0     Dgeg-  TC_TenMin   -- 
       5     f-
MC10  14   on   MinL2     C----  MTens2     Dgeg-  nTC_ThreeHr -- 
       4     f-
MC11  16   on   MinL3     C----  HUnits0    Dgeg-  NA          -- 
       5     f-
MC12  17        --               HUnits3.CE C----  TC_TenHr    -- 
       3     f-
MC13  18   on   MinL5     C----  HUnits1    Dgeg-  NA          -- 
       5     f-
MC14  19   on   MinL4     C----  HUnits2    Dgeg-  NA          -- 
       5     f-
MC15  20   on   MinL6     C----  HTens0     Dgeg-  nTC_HalfSec -- 
       5     f-
MC16  21   on   HourU6    Dge-p  --                nTC_TenMin  -- 
       4     f-
MC17  41        --               --                --          -- 
       0     f-
MC18  40   on   HourU5    C----  --                --          -- 
       2     f-
MC19  39   on   MinU0     C----  ClkEMins   L----  --          -- 
       3     f-
MC20  38   on   MinU1     C----  nClkEMins  L----  --          -- 
       2     f-
MC21  37   on   MinU2     C----  MUnits0    Dgeg-  --          -- 
       3     f-
MC22  36   on   MinU3     C----  HUnits3    Dgeg-  --          -- 
       4     f-
MC23  34   on   MinU5     C----  MUnits3    Dgeg-  --          -- 
       4     f-
MC24  33   on   MinU4     C----  Div3       Dge--  NA          -- 
       5     f-
MC25  32   on   Colon     C----  Div4       Dge--  --          -- 
       3     f-
MC26  31   on   MinU6     C----  Div5       Dge--  --          -- 
       3     f-
MC27  29   on   HourU1    C----  Secs0      Dgeg-  --          -- 
       3     f-
MC28  28   on   HourU0    C----  Secs3      Dgeg-  --          -- 
       3     f-
MC29  27   on   HourU2    C----  Secs1      Dgeg-  --          -- 
       3     f-
MC30  26   on   HourU4    C----  Secs4      Dgeg-  --          -- 
       3     f-
MC31  25   on   HourU3    C----  Secs5      Dgeg-  TC_OneMin   -- 
       4     f-
MC32  24        --               Secs2      Dgeg-  nTC_OneMin  -- 
       3     f-
MC0   2         FastHourB INPUT  --                --          -- 
       0     f-
MC0   1         ClrAll    INPUT  --                --          -- 
       0     f-
MC0   44        FastMinB  INPUT  --                --          -- 
       0     f-
MC0   43        CLK       INPUT  --                --          -- 
       0     f-

Logic Array Block			Macro Cells	I/O Pins	Foldbacks	TotalPT	FanIN		Cascades
A: MC1	- MC16		30/16(187%)	15/16(93%)	8/16(50%)	70/80(87%)	23/40(57%)	0
B: MC17	- MC32		28/16(175%)	14/16(87%)	2/16(12%)	48/80(60%)	26/40(65%)	0

Total dedicated input used:	4/4 	(100%)
Total I/O pins used		29/32 	(90%)
Total Macro cells used 		58/32 	(181%)
Total Flip-Flop used 		29/32 	(90%)
Total Foldback logic used 	10/32 	(31%)
Total Nodes+FB/MCells 		68/32 	(212%)
Total cascade used 		0
Total input pins 			4
Total output pins 		29
Total Pts 				118
----------------  End fitter, Design FITS
$Device PLCC44 fits; JTAG OFF; Secure OFF

CPLD design can be quite challenging due to the restricted logic ressources, 
especially flipflops.

However in real life, your mentioned projects should be done in FPGA's, a 
small 50k Spartan3/A/AN should fit plenty of tetris games and clocks, since 
during a real project, nobody has the time to think about partitioning or 
saving logic ressources like flipflops etc.

However using CPLD's can be fun, and a student can learn a lot about logic 
optimisation (speed versus area).
Since CPLD's (as FPGA's) can be clocked with high frequency (100MHz-300MHz), 
nested and multiplexed logic can improve ressource efficiency.
Also the available produkt term pool and the array inputs can be used up to 
100%, if some nodes in every array are used for different purposes, which 
are not needed concurrently.
However this design practice is very error prone, but it's a game, isn't it 
?

In general bitserial processing is the way to go in low ressource CPLD's.
A small serial CPU can be built with the mentioned SPI SRAM, but FRAM would 
be more suitable.
Since flipflops are rare in CPLD's, external shift regs like HCT595 or 
HCT165 can be used to hold CPU registers.
Also ancient 64kx1 or 256kx1 DRAMs can be used as CPU memory.
The 74HCT7731 is also still available (yet not cheap), a 4x64bit shift 
register, which can be used as a ring buffer for various CPU registers.

I often connect 7-segment leds to HC595 without a decoder, a cheap and 
intersting spi led display.

If efficiency is not important, also parallel CPU's can be implemented with 
CPLD's.
An 8bit PIC or similar architecture is a nice student project.
The ROM (Flash) can be implemented in a separate CPLD.
The SRAM can also be swapped out to a CPLD (built from flipflops), but as in 
the ROM example, only a few bytes can be stored.
This demonstrates quite good, that separate memory chips are often required 
in modern embedded systems.

MIKE

-- 
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310

On 2008-10-16, M.Randelzhofer <techseller@gmx.de> wrote:
> However using CPLD's can be fun, and a student can learn a lot about logic 
> optimisation (speed versus area).

Since this is their first time using any sort of hardware description language,
we believe that it is good to use small CPLDs instead of large FPGAs. While
there are certainly some students who would benefit from FPGAs, most of our
students are satisfied with the designs they can do in a CPLD. Giving a large
FPGA to a person who is not used to logic design is just an invitation to start
programming in VHDL instead of designing hardware in VHDL if you understand
what I mean...



> In general bitserial processing is the way to go in low ressource CPLD's.

This is the approach I'm using in my approach. This approach can really make
a huge difference...


> An 8bit PIC or similar architecture is a nice student project.
Most of our students do some small microcoded CPU as their project in this
course. Typically at least two CPLDs are used. One CPLD for the microcode and
one for the ALU plus some registers like an accumulator and a program counter.

/Andreas

Andreas Ehliar wrote:
> Most of our students do some small microcoded CPU as their project in this
> course. Typically at least two CPLDs are used. One CPLD for the microcode and
> one for the ALU plus some registers like an accumulator and a program counter.

Depending on how far you push them, one pathway we looked at for
CPLD education etc was to start with the venerable MC14500, which
was a boolean CPU from Motorola, and the core alone fits in ~8 
macrocells. [Did anyone ever see a commercial design using this?]

This naturally leads onto IEC61131 Instruction List (IL).
Full-blown IL is rather type agnostic, and has an inferred stack,
but you can chose a single type to keep the HW simpler.

The Maxim MAX1464 is a Sensor interface, with a very simple CPU
which closely models IEC61131-IL, mapped onto 16 registers.
Has a 4 bit OpcodeID field, and a 4 bit register field, in a 8 bit
opcode. I think Maxim have assemblers for this simple core.

-jg

Jim Granville wrote:
(snip)

>> circuit with built in NBCD decoder (the 9368), so if you want to compare
>> your solution to mine you might want to output NBCD coded numbers out 
>> of your
>> CPLD.

> Surely the 9368 should be part of the CPLD ?

If I remember the 9368, it has constant current outputs
for direct drive to LED displays.  If you can get them, it
is probably easier than other ways to drive LEDs.

Well, another choice is the 75491 and 75492, which still
requires current limiting resistors, and I believe
something like a 12V power supply.

I still have a clock based on the NS5311 that I built
many years ago.  Six digit clocks are rare these days.

-- glen

On 2008-10-16, Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote:
> Personally I have an almost finished solution based on the XC95 series.
> However, I will not tell you how many I need or the exact model number(s)
> that I'm using right now. I do have a rather nice architecture which I
> believe will be hard to improve on. I'll let you ponder this for a week
> or so before I post my idea for a solution.

I'm almost finished with my Tetris implementation though it has been
put on hold for lack of time at the moment. I believe it should be
doable using only one XC95108.

This is a pretty bold claim as a normal playing field in Tetris
consists of 10 columns and 20 rows and there are only 108 macroblocks
in the XC95108. However, there are actually many more flip-flops
available in the XC95108 if you only know where to look. In my
solution I'm connecting a couple of pins on the CPLD to the JTAG port
which allows me to access the 324 flip-flops in the boundary scan
chain. By putting the JTAG FSM into SAMPLE mode it is possible to
access the boundary scan chain like a shift register with 324
flip-flops.

This means that I have to read the playing field in a bit serial
fashion, but as we have discussed earlier, bit serial processing is
usually resource efficient in a CPLD. I also have a short shift
register inside the CPLD so that I can fit one row of the playing
field so that I can duplicate it a couple of times when showing it on
a TV.

I have a couple of other tricks I had to use to make this fit into the
device, but nothing very interesting. By using KEEP attributes on a
couple of signals I could get the synthesizer to do a better
job. Initially I used a separate FSM to put the JTAG FSM into boundary
scan mode, but I ended up driving that from the X position counter to
save some macroblocks.

The inputs are just plain pushbuttons and debounced using an SR based
debouncer inside the FPGA. The video output is created by mixing a
video signal output and a sync signal output from the CPLD using a
transistor and some resistors.

My current implementation has this resource utilization:

*************************  Mapped Resource Summary  **************************

Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
86 /108 ( 80%) 494 /540  ( 91%) 215/216 ( 99%)   81 /108 ( 75%) 14 /69  ( 20%)

This version has been tested on real hardware and it is actually
working. It was a little weird to hookup the JTAG connection to the
CPLD itself though. Initially I also sent the EXTEST command to the
CPLD by mistake, which basically meant that the CPLD tristated all
outputs. Not a good idea when you are trying to drive the JTAG machine
from inside the CPLD :)

However, a few features are missing: Currently rows are not being
removed once they fill up. It shouldn't be that hard to fix it I hope,
but I haven't had time to do it. (I'm hoping here that this could be
added without adding more than one function block input...)
If I remember correctly I am also missing one tetris block.

While I don't believe that many people would like to use this trick in
production, I hope that you at least enjoyed reading about it :)



> Challenge 2 - A digital watch with as few CPLDs as possible
> -----------------------------------------------------------
>
> Personally, I have a relatively small solution to this, but there are still
> a few tricks I haven't used. In my solution I'm using a 7 segment LED driver
> circuit with built in NBCD decoder (the 9368), so if you want to compare
> your solution to mine you might want to output NBCD coded numbers out of your
> CPLD.


My design for this is fairly straight forward. I'm storing the current
time, current timer and current alarm in a long shift register in NBCD
coded format. I'm using bit serial arithmetic to increase the time to
minimize the cost of the arithmetic unit. A special comparator is used
to generate the carry to handle rollovers like 9 -> 0 and 5 -> 0.
Since a shift register is wasting a lot of combinational logic in a
CPLD I am also trying to distribute some of the logic into different
parts of the shift register. For example, the rollover from 23 -> 00
is not done directly adjacent to the CPU but further down the shift
register. The arithmetic unit would actually increase the time to
24:00:00:0 which will be corrected a little bit later in the shift
register.

Since I am using a long shift register for all values I don't have to
have any sort of mux to get any output to the 9368 LED drivers, I just
have to activate the latch enable input to these drivers at the
appropriate time.


As for the interface I am using one button to adjust the minutes and
one button to adjust the hours. (When holding down the button, the
minutes and hours will increase.)

Two other buttons are used to select wether to view the timer mode or
alarm mode. (And likewise modify these modes.)

A final button is used to start/stop the timer.


All in all, this fits into one XC9572. Unfortunately there is not
enough room for a prescaler which means that I will have to drive this
circuit using a 540 Hz input signal. This is not very impressive
unfortunately. If a XC95108 is used instead there is plenty of space
left for a prescaler so that almost any input frequency could be used.
This would also allow us to eliminate the 9368 drivers and move the
NBCD -> 7 segment decoding to the CPLD.

However, if someone is feeling like he or she has too much spare time
available I challenge you to use my JTAG boundary scan trick and fit
all of this into a XC9536 instead :)

/Andreas