Question about MAX7000 CPLDs

[TomS_]

Maybe CPLDs in general?

Im working on a design which is getting a little fiddly sometimes because if I make certain changes the design no longer fits despite having plenty of free macrocells.

I have an EPM7128S in my design, and this I understand has 8 LABs, each of which has 16 macrocells. I had a thought that maybe it is the way I have spread the inputs and outputs around the chip physically, and maybe things are just getting a bit difficult for the fitter to route in between LABs.

Is it considered "good design practice" to concentrate the inputs and outputs of any given "function" onto one or more adjacent LAB(s) where possible?

A function might be something like an address decoder where you have a bunch of address lines as inputs, and then a bunch of chip selects as outputs, or an interrupt controller which takes in IRQ sources and prioritises them towards the CPU. If the inputs/outputs are concentrated then very little has to cross between LABs which might help if signals from one function arent having to be routed through a LAB that is congested with some other function?

As it is my design looks like the attached image, and was largely chosen due to ease of routing signals. The "address decoder" function is really several to e.g. perform DRAM refreshes, decode chipselects, and do some muxing of some 8 bit busses to/from a 16 bit bus, and as you can see takes up quite a decent chunk of the CPLD but distributed through all of the LABs (orange bars, no particular relation to the clock function). But things like the interrupt controller and bus arbitrator are spread all over.

I have to do a second run of these PCBs due to some design errors on my part, so would it be worthwhile to try to, e.g. concentrate all of the address decoder pins to one half-ish of the CPLD, and move the interrupt controller and bus arbitrator to other corners all on their own, concentrating their inputs/outputs into a smaller number of LABs? Would this help to increase the chances of fitting success?

Any insight appreciated.

Thanks!

[BrianHG]

Hi TomS_,

     You actually hit my specialty with Altera, it's Quartus & components.  If your design doesn't clock at radical speed, say no more than 50MHz, first please read this thread completely through where I cut down an existing MAX7000 macrocell count by half:

https://www.eevblog.com/forum/fpga/why-does-my-macrocell-count-increase/msg4438126/#msg4438126

Read it completely and you will see a few smart coding techniques and which settings within Quartus which will cut down your macrocell usage at the expense of instead of having a 100MHz fmax, you would be left with only a ~50MHz FMAX.

If your code is in Verilog or AHDL and isn't too complex, and you are willing to share, I may also help there, though I'm only be available around 1 time a day to help.

Note that for your clock inputs, I did not check your clock pins, using a global clock input so long as it is used for clocking registers will minimize routing.

[MarginallyStable]

If possible, I typically compile and close timing without pin assignments. This allows the fitter maximum flexibility. Back annotate the fitter pin assignments, then if needed, make any changes needed for PCB routing and verify that the design still can fit and meet timing.

Product design flow doesn't always allow this flexibility (PCB and HDL developed in parallel), but I feel it does make FPGA/CPLD fitting much less difficult. In fact, sometimes pin assignments can block the fitter from being able to make a workable design requiring HDL and/or PCB rework.

[matrixofdynamism]

For these ancient devices, is not better to use schematic capture instead?

[TomS_]

Hi BrianHG,

I can share the code (System Verilog) as its just a personal project. Im away from home now, but if youre able to take a look I could share it once Im back in a couple of days time (or I'll see if I can do it on the road, but Im out camping so coverage is often spotty at best).

The maximum clock input is 40MHz, and actually I didnt say it in my first post, but the orange clock pins are all outputs from a simple divider. The 40MHz signal comes in on one of the global clock pins.

Complexity - I dont really think I can judge that with the little experience that I have. Theres a bit of a mixture of combinatorial logic, state machines etc.

Im not a native xHDL developer, so Im sure there are things that Im doing that are just plain wrong or suboptimal, so any guidance on that kind of stuff would be very much appreciated!

[PCB.Wiz]

Maybe CPLDs in general?

Im working on a design which is getting a little fiddly sometimes because if I make certain changes the design no longer fits despite having plenty of free macrocells.

Did you look into the fitter report file ?
I've not used the EPM7128, but I think the Atmel/Microchip ATF1508 is a clone/superset of that, and they have a very good fitter report that shows fan in and head room.
You could feed your design into their fitter and see what that reports, if you cannot find enough under the hood info from Altera.
The preferred package for ATF1508 is TQFP100, the PQFP100 has a go-away price.

https://www.microchip.com/en-us/products/fpgas-and-plds/spld-cplds/pld-design-resources

[TomS_]

For these ancient devices, is not better to use schematic capture instead?

I don't know whether it's any better to do it one way vs the other, but I honestly wouldn't like to try to implement this design via schematic capture.

[BrianHG]

Doing your project in system verilog is fine.  It's good to begin here as it will give you experience tackling the larger projects in the future.

Depending on the complexity of your code, we may end up using Modelsim to simulate your design.

If so, make sure it is installed as a free version is available with Quartus & I'll teach you how to script & command line it directly allowing you to develop outside Quartus for speed.  (Quartus compile and sim are slow and garbage for debugging.)

[TomS_]

Doing your project in system verilog is fine.  It's good to begin here as it will give you experience tackling the larger projects in the future.

Depending on the complexity of your code, we may end up using Modelsim to simulate your design.

If so, make sure it is installed as a free version is available with Quartus & I'll teach you how to script & command line it directly allowing you to develop outside Quartus for speed.  (Quartus compile and sim are slow and garbage for debugging.)

Hi Brian,

Thanks for the offers for help, this is much appreciated. 

Side note, I have used ModelSim to simulate a lot of the design, but my experience so far has been a little inconsistent at times. Sometimes it seems I can write some code in ModelSim that works perfectly in simulation, but then when I compile it and load it into the CPLD it doesnt seem to function the same. But maybe that is just a result of not understanding how to "properly" write Verilog, or not considering certain things that apply in the real world but not so much in simulation. Usually I can have it working perfectly with a little fiddling. From the sounds of it you'll most likely be able to point out silly stuff that Im doing.

Heres a link to my currently known and (mostly) working code. The only thing that is not currently working 100% is to do with the interrupt controller module, and I probably need some more simulation (something I am particularly interested in learning how to do better).

https://gist.github.com/tomstorey/f3d79d536837f7eca634522d3546270b

FYI the CPLD is used in a Motorola 68000 computer system, if that helps with your understanding of what some of the signals are meant to be doing. :-)

I read through the other thread that you linked and tried switching optimisation to area. This reduced my current design from 102 to 98 macrocells, although I havent tried to program the CPLD with this yet.

[TomS_]

Did you look into the fitter report file ?
I've not used the EPM7128, but I think the Atmel/Microchip ATF1508 is a clone/superset of that, and they have a very good fitter report that shows fan in and head room.
You could feed your design into their fitter and see what that reports, if you cannot find enough under the hood info from Altera.

Interesting idea, since I do have some Atmel ATF150x parts as well, although I chose to go with the Altera part for this design since at the time I couldnt find Atmel parts to save my life.

How would you suggest loading the Altera design into the Atmel tools to view its fitter report? Ive got all of the tools like pof2jed, WinCUPL and what not installed as I used these with some other projects, but I wouldnt think that the Atmel tools would be able to give me any information about a design that was fitted with the Altera tools?

Thanks

[PCB.Wiz]

How would you suggest loading the Altera design into the Atmel tools to view its fitter report? Ive got all of the tools like pof2jed, WinCUPL and what not installed as I used these with some other projects, but I wouldnt think that the Atmel tools would be able to give me any information about a design that was fitted with the Altera tools?

The Altera tools should generate a fitter report file .RPT  (the winCUPL fitter report files are .FIT) which may be enough info for your problem.
The Atmel fitters would not take a JED file, but they can accept interim files.
The Altera tools may also generate files like the .TT2  PLA file that WinCUPL generates and that PLA file can be fed into the Atmel fitter.

[BrianHG]

Hi TomS_,

     No, I didn't forget about you.  I looked at your code and it is huge.  So, what I would like to do is attack your problem with optimization techniques with tiny code changes here and there.

1.  First, make sure your 'osc_40mhz' is wired to a global clock input on the CPLD.

2. Your clock output pins.
    output logic eth_clk,
    output logic cpu_clk,
    output logic timer_clk,

    Because they come from 1 counter, make sure all 3 are located on 3 adjacent IOs on the CPLD.  Make sure those 3 come from 1 block inside the CPLD.  This will minimize routing the output LCELL across the CPLD fuse map.

3.  Ok, everywhere you used a single negedge for the 40MHz in your code.  Some you have a 'or negedge n_reset'.  Note that only if your reset pulse will be less than 1/40millionth of a second, you can comment this out saving some routing.  If you want the async reset to be wired as such in the CPLD, you need to tell quartus to use your reset signal as a global reset signal. With a CPLD, you may be forced to use a specific dedicated input for this functionality.  Specifying in code and using a global reset input line uses a dedicated net on the CPLD fabric saving on the logic fuse map.  (Note that if you do this wrong with, Quartus will still compile and somewhere hiding in the compilation report it will say something like 'Could not use dedicated reset line for n_reset input.  Global lowered to a standard net')

4.  Since output 'n_berr_drv' is so closely tied to:
    output logic eth_clk,
    output logic cpu_clk,
    output logic timer_clk,
it's output should be adjacent to them.

(Do not touch this for now if it works, this will only save 1-4 cells it you truly need that)
5.  Line 373 - 'always_ff @(posedge cpu_clk) begin'
     Line 374 - 383 (your clocked logic block)
(Do not touch this for now if it works, this will only save 1-4 cells it you truly need that)
You can change lines 373 to @(negedge osc_40mhz) and stuff lines 374 through 383 inside this 'if'.
if (!cpu_clk && eth_clk) begin
lines 374-383
end

All I have done here is place your entire project on the (negedge 40Mhz), and use the cpu_clk and eth_clk as an enable for that timeout counter.  You may need to fiddle with the '!'.  This one is to prevent Quartus from having to route a new custom clock line for the clock's output LCELL to your 2 bit timeout counter.  Also having everything in a single clock domain really helps Quartus optimize and minimize you code.


     With these changes, Quartus compiling with setting  'Optimize Area' mode, you will still get a good FMAX and minimal size.  The only way to further shrink the size is to ask Quartus to generate a custom pin map for you.  But, that pin map will be kinda random.

[TomS_]

Hi Brian,

No problem. Work has also kept me busy the last few days so I havent had much time to play with it, and I cant complain when the price is $0.

It is rather large, and seems impossible that so much can fit into 128 macrocells...

1 & 3: osc_40mhz comes in on GCLK1, so that should be all good. n_reset also comes in on GCLR, so I think that should also be good, but I suppose I dont strictly need async reset. I'll have a play with this and see what it does.

4: I presume this is because n_berr_drv is driven by the watchdog counter, which is derived from cpu_clk, placing those two functions adjacent to each other means all of that related logic is packed together?

5: I'll have a play with this and see what I get as a result, although yes, it does currently work, Im still curious.

2: I suppose this comes back to my original question about how I should lay out the pins around the package, and grouping everything that is related into the same LABs rather than spreading it out as I have currently. My original PCB design has some issues, so I am intending to spin another one with fixes, therefore I am open to the idea of rearranging the CPLD pins.

I suppose now that I seem to have a design that is functional and is doing everything that I want (even if it only just fits), the pinout that Quartus can provide me after a compilation is something I could actually try to route on my board (although I suspect it will feel a lot like a dogs breakfast). That or I can take what it gives me a shuffle the odd pin here and there to try and "tidy" things up potentially at the cost of a couple of MCs?

Much appreciated.

[TomS_]

So, unfortunately #5 didnt seem to do much. All it seemed to do was add another mux which uses "!cpu_clk && eth_clk" to select either the output of the registers or the adder. The clock enable to the registers appears untouched. MC usage doesnt change from 111 in either design.

Maybe needs some different syntax?

edit 1: #1/3: This made a difference, MC usage down from 111 to 107! Intriguing...

edit 2: And I just found another major improvement. I removed "|| n_as" from lines 479-483 and this has dropped me down to 95 MCs. This was a bit redundant because many of the x_decoded signals already take n_as into account via mem_cycle.  

[dietert1]

I am more familiar with XILINX parts, but there i can leave the pinout free to be decided by the fitter. Also i can select a bigger part in order to verify the design by simulation. Anyway, if a design consumes more than 80 % if the resources, it may be a good idea to use a bigger part. It happened more than once to me, so i know what a shame it is to use this technology with a part that is near full. Like a highway with traffic jam.
Sometimes one can add standard logic, like one 74HC595, to save 16 cells, so the CPLD fits better. In your design it may be another ready made function block.

Regards, Dieter

[TomS_]

Sometimes one can add standard logic, like one 74HC595, to save 16 cells, so the CPLD fits better. In your design it may be another ready made function block.

Indeed, something I could do is e.g. add in a simple counter chip externally to derive my clocks, rather than using up a bunch of CPLD resources to do this. At most I just need some input pins if I really need to use those clocks internally. It is kind of convenient to have it done inside the CPLD though.

Unfortunately these parts are kind of "retro" now, and they can be hard to come across, especially in greater than 128 MC counts. I keep my eye out for them, but they are often also very expensive. Perhaps my only better option is to go to a much more modern part and deal with the level shifting that is inevitable with that.

[BrianHG]

So, unfortunately #5 didnt seem to do much. All it seemed to do was add another mux which uses "!cpu_clk && eth_clk" to select either the output of the registers or the adder. The clock enable to the registers appears untouched. MC usage doesnt change from 111 in either design.

Maybe needs some different syntax?

edit 1: #1/3: This made a difference, MC usage down from 111 to 107! Intriguing...

edit 2: And I just found another major improvement. I removed "|| n_as" from lines 479-483 and this has dropped me down to 95 MCs. This was a bit redundant because many of the x_decoded signals already take n_as into account via mem_cycle.  

These are among the things we may do when trying to save some LCs.

Sometimes one can add standard logic, like one 74HC595, to save 16 cells, so the CPLD fits better. In your design it may be another ready made function block.

Indeed, something I could do is e.g. add in a simple counter chip externally to derive my clocks, rather than using up a bunch of CPLD resources to do this. At most I just need some input pins if I really need to use those clocks internally. It is kind of convenient to have it done inside the CPLD though.

Unfortunately these parts are kind of "retro" now, and they can be hard to come across, especially in greater than 128 MC counts. I keep my eye out for them, but they are often also very expensive. Perhaps my only better option is to go to a much more modern part and deal with the level shifting that is inevitable with that.

Your 'timer_clk' clock with it's CPU clock generated derivatives are 6 bits.  That means 6 LCs saves if you make all of it external.
If you just loose that 1 output  'timer_clk', you will save 4 LCs.

I do not think you can shrink this design into a 64 LC CPLD as things stand.
Though, if your provide a .zip of a compiling Quartus 13.0sp1 project, I can try fiddling with a few of the compiler controls to try to pack it a little tighter.

To pull off some 'wonder tricks' if possible would mean diving deep into your code, a much larger code than I thought it would be.

[BrianHG]

So, unfortunately #5 didnt seem to do much. All it seemed to do was add another mux which uses "!cpu_clk && eth_clk" to select either the output of the registers or the adder. The clock enable to the registers appears untouched. MC usage doesnt change from 111 in either design.

This recommendation wasn't designed to help MC count.  It was designed to help the top FMAX and internal timing skew cross clock domain metastability.

At times, this may help Quartus shave a MC here and there, but not always.

[mmprestine]

Check out the Lattice parts, MachXO/MachXO2.  The port would be simple as getting a new I/O map laid out since you did it in Verilog.