Processor in CPLD

"Andreas Ehliar" <ehliar-nospam@isy.liu.se> wrote in message 
news:slrnfo6obf.luh.ehliar-nospam@sabor.isy.liu.se...
> On 2008-01-07, Rgr <rgrworking@hotmail.com> wrote:
>> Hi.
>>
>> I would like to hear your opinion on the possibility of implementing a
>> processor in a CPLD?
>> The functionality does not have to be greater than the old 8051 CPU, but 
>> I
>> would like the flexibility and the possibility of adding additional logic 
>> to
>> my design.
>>
>> Has someone worked on this issue, or have an opinion on how to complete 
>> this
>> task?
>
> We are actually doing this all the time in a course we are giving here 
> called
> Digital project laboratory. The CPLDs we are using are the XC9572 and 
> XC95108.
> (They are old, but they operate on 5V which is a huge advantage for us 
> since
> we have many other 5V components.)
>
> Our students commonly use two XC95108 for a complete microcoded processor.
> One mostly used for microcode and one mostly used for ALU stuff. Some 
> students
> use many more CPLDs to implement graphics and audio as well but that is
> not so common.
>
> A few students manage to fit a complete RISC-like processor into a single
> XC9572.
>
> Some things to keep in mind when designing a processor (or any logic for
> that matter for a XC95xx-CPLD:
>
> * Budget your design for the number of macroblocks. One macroblock ==
>  one flip-flop plus some logic in front of it.
>
> * Avoid complex expressions. You will notice that especially adders can
>  be very expensive (or constructs that infer an adder like less than
>  or greater than). An example:
>
>    reg [7:0] counter;
>    always @(posedge clk) begin
>      counter <= counter + 1;
>      if((counter > 13) && (counter < 131)) begin
>        outsignal <= 1;
>      end else begin
>        outsignal <= 0;
>      end
>    end
>
>    // Refactor this as:
>    always @(posedge clk) begin
>      counter <= counter + 1;
>      if(counter == 13) begin
>        outsignal <= 1;
>      end
>      if(counter == 130) begin
>        outsignal <= 0;
>      end
>    end
>
>  The later version can sometimes reduce the number of macrocells although
>  there is no guarantee for it. (If we didn't use 13 and 131 but something
>  like 63 and 192 instead it is likely that the first version is more
>  optimal than the second version for example)
>
>
>
> * Reuse logic (macrocells) if possible
>  An example of commonly used logic in a simple (non pipelined) processor:
>
>    reg [15:0] pc;
>    reg [15:0] address_reg;
>    reg [15:0] external_addr;
>    // Resets not shown for clarity
>    always @(posedge clk) begin
>        if(incpc) pc <= pc + 1;
>        else if(resetpc) pc <= 0;
>        else if(jump)    pc <= jumpaddr;
>    end
>
>    always @(posedge clk) begin
>        if(loadaddr) address_reg <= accumulator;
>
>    always @* begin
>        if (fetch) external_addr <= pc;
>        else external_addr <= address_reg;
>    end
>
>   Assuming address_reg and pc are the same width:
>   This code will use at least 16 macrocells for pc (actually more
>   due to the adder), 16 macrocells for address_reg and 16 macrocells
>   for the MUX in front of external_addr which is going out to the memory.
>   This code can be changed to something like this:
>
>   reg [15:0] reg1;
>   reg [15:0] reg2;
>   always @* external_addr <= reg1;
>
>   always @(posedge clk) begin
>        if(swap) begin
>            reg1 <= reg2;
>            reg2 <= reg1;
>        end else begin
>            if(inc1) reg1 <= reg1 + 1;
>            if(load2_pc) reg2 <= jumpaddr;
>            else if(load2_addr) reg2 <= accumulator;
>            else if(zero2) reg2 <= 0;
>        end
>   end
>
>   By reorganizing the code as above you will complicate your control
>   path by quite a lot, but you will save the 16 macrocells caused by
>   the MUX since reg1 is directly connected to external memory. We also
>   make sure that we don't complicate the macrocells used in the adder
>   by putting all other operations into the reg2 macrocells. As a bonus
>   we get address_reg++ for free...
>
> *  Bit serial arithmetics can be good in CPLDs in some situations. As
>   an example, I have a small hobby project running where I have fitted
>   an entire digital watch into a single XC9572 (although it requires a
>   very non-standard clock frequency to work as I didn't have enough space
>   left to fit a clock divider). The watch can both show time (hours,
>   minutes and seconds) and be used as a timer (minutes,seconds,tenths).
>   There is also an alarm which functions on (hours,minutes). These units
>   can be used independently (i.e., the watch still ticks in the background
>   if I'm setting the alarm or using the timer and the alarm will work even
>   though I'm using the timer). (Actually, I haven't wired up any circuit
>   yet, but it is working in simulation and the design fits into a
>   XC9572.) The time is presented on a display driven by 9368 7-segment
>   decoders so my design don't need to worry about decimal to 7-segment
>   decoders inside my design. (Although depending on this is a bit of
>   a cheat...)
>
>   I'm using bit serial arithmetics in order to fit everything into the
>   XC9572. I do not believe a more parallel solution would work in this
>   very constrained space although digit-serial might work as well.
>
>   At some point I'm planning to write a small web page to detail this
>   project, unfortunately I don't have time to describe it in more detail
>   in this already long post.
>
>
> It is rare that students do anything of the above though, but this is what
> I've learned while supervising students and thinking about (and sometimes
> exploring) the limits of the hardware we are using.
>
> /Andreas


Thanks for the tips, there are some nice views among them.
And thank you all for the answers - I have searched the web sites and come 
up with some possible solutions.

Best Regards 

Rgr wrote:
> "John_H" <newsgroup@johnhandwork.com> wrote in message
> news:lt6dncs0fYiIrx_anZ2dnUVZ_j-dnZ2d@comcast.com...
> > Rgr wrote:
> >> Hi.
> >>
> >> I would like to hear your opinion on the possibility of implementing a
> >> processor in a CPLD?
> >> The functionality does not have to be greater than the old 8051 CPU, but
> >> I would like the flexibility and the possibility of adding additional
> >> logic to my design.
> >>
> >> Has someone worked on this issue, or have an opinion on how to complete
> >> this task?
> >>
> >> Looking forward to your replies
> >> Best Regards
> >
> > The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both be
> > achievable in a CPLD but most CPLDs don't have memory.
> >
> > While it's more of a simple FPGA than an ASIC, the Altera Max-II series of
> > "CPLDs" has some user Flash memory available on-chip.  Most CPLDs will
> > require external memory.
> >
> > - John_H
>
> Thank you both for your very useful replies.
> I can see the benefits in utilizing the Max-II series, but have they made a
> soft-core processor usable for these CPLD's? Like the PicoBlaze?

You can probably find example of Mico8 on Lattice MachXO series.
However, if you want low power, using a CPLD is not a good path,
and you have to add external code storage in
projects of any reasonable size.

That's more power, cost, and EMC hits...

- much better to choose a small uC that has Code memory on-chip,
already
power-optimised, and EMC minimised!.

Use the FPGA when you have a problem you cannot solve with std
devices.

-jg