CPLD mistery. Help.

"lc" ha scritto:

Maybe it's an electrical problem in your board

-- Per rispondermi via email sostituisci il risultato dell'operazione (in lettere) dall'indirizzo

All fitters create a report file, showing what resource is mapped: create the two versions of this report file, and compare them. That should indicate what is happening.

-jg

Hi,

CPLDs don't have a latches. Synthesis tools implement these by using combinational cycles. These work for simple cases. For more complex cases timing problems may cause the latches behave incorrectly. Such problems are very hard to debug. Looking at your design it certainly falls in the complex category. You have two latches interacting with each other.

I would recommend you try to convert your design to a synchronous circuit. If that is not possible you might have to tweak the RTL or constraints to get around the problem. Try using "syn_keep" on the latch gate signals.

Cheers,

Ashish Kapoor

Many thanks for the tips, both direct and via the news group.

Not much of a progress understanding what is going on. Replying to some of the comments I've received I can tell:

- "octnr" was added in the sensitivity list but no effect.

- a full MUX was done on the input (save resources but that part was working ok already)

- The fitter produces a quite a different thing in the two situations it seems that to bring this signal out of the CPLD changes a lot of things.

- Used Quartus II instead and it doesn't work with or without testpoint. it behaves the same as MAX+II without testpoint.

- doesn't seem to be an electrical as all other bus operations work and most important of all, The SIMULATION produces the same strange behavior, so it is something I'm doing or the compiler/fitter doesn't like it ... but what ?!

Would somebody please let me know what would be your usual way of writing the VHDL to make an output port out of an 8bit bus? with ("address"(=something) and "data" bus and "write" signals only).

Maybe I'm doing it all wrong. Many Thanks.

Luis Cupido.

It looks very different to me ! any clue ?

------------ With testpoint at PF0 pin ( being PF0='0' when a(11 to

-- Equation name is 'PA0', type is output PA0 = LCELL( _EQ017 $ GND); _EQ017 = !a8 & !a9 & !a10 & d0 & PF0 # PA0 & !PF0 # a9 & PA0 # a10 & PA0 # _LC111;

------------ Without testpoint

-- Equation name is 'PA0', type is output PA0 = LCELL( _EQ017 $ PA0); _EQ017 = !a8 & !a9 & !a10 & !a11 & !a12 & !a13 & !a14 & !a15 & d0 & !nwr & !PA0 # !a8 & !a9 & !a10 & !a11 & !a12 & !a13 & !a14 & !a15 & !d0 & !nwr & PA0;

I think the important decision is latch vs edge-triggered.

I think the problem you described expects a latch. The hardware and software in most CPLDs and FPGAs prefer edge-triggered FFs.

Can you turn your problem into something that works well with edge-triggered FFs? Either using one edge of your write signal to do the work, or using another clock (which you didn't mention) to do the work and using write and address signals to decided what to do on each clock cycle.

Hi,

I have used latches to implement output ports in a couple of designs, without problems. Latches are a deviation from orthodox synchronous design but they are "cheaper" than flip-flops in some architectures....

I would suggest that you check the margins between address/data and the write control line from the CPU. Its essential to have sufficient setup and hold time. Probing the internal strobe will increase the loading on the net which may be the difference between a working and not working design, if margins are to small. A very good demonstration of the so called "probing effect".

/Peter

Thanks for all the comments (both on the list and direct email).

Many of you suggested the use of edge trigered instead of latches that really works fine in all situations and uses less resources. So, from a design point of view... problem solved. Thanks.

Now, for the inquisitive minds. Just to understand what was happening I was looking in detail into the reports to see what was happening. In fact the equation of a port output bit changed dramatically with and without test point.

As I had a recent design where I use latches without any problem I started to compare the sources to see what was different and the only fundamental difference found is the amount of signals used. On the my previous design (working fine) I used A8 A9 and nWR signals to control the latch while on this one I was using the full A8 to A15 byte plus nWR. So I cut the present design to use just A11 and nWR and bingo it worked always fine, then I added A8 and still works fine, then I added A9... still working fine. Then I added A10 and PUFF!!! stop working.

I looked into the fitter's report and the equations change dramatically, producing something that is clearly NOT A LATCH. I may conclude that I can only have 4 signals controlling the latch.

That is why when I used the testpoint all address lines and nWR were combined to form my test signal and the latch equation generated used this signal plus the A8,9,10 bits so it had only 4 inputs. Without the test point each cell was receiving 9 signals and the synthesised equation was quite different and therefore not working.

If this is a specific limitation of this particular CPLD or software tool an error report or a warning would be very welcome. The reason why only up to 4 signals produce the expected behavior, I think only Altera can tell... (would they bother to comment to this poor web licence user ?!)

I think I'll be another one saying to avoid latches on CPLD designs hi:)

Many thanks again for your help.

Luis Cupido.

It is not uncommon for tools to change their decision paths with logic depth : that's why you should routinely scan the RPT files. My most recent example was an Atmel fitter that misses XOR optimise once the eqns get past a certain logic width. That can be understandable, as digging for XOR with wider AND.OR flattened equations is not trivial. The fix was to create dummy nodes, so the fitter could easily see the XOR term - and the fitter IS smart enough to discard the dummy nodes, so the design still fits. Some PLDS have native support for latches, with .LE terms.

Ignoring the gotchas in tool flows, in the context of ALE usage, a latch gives longer access times, but can give more RFI as more transistions appear. A trailing edge register gives minimal transistions, but does have a small hit in access times.

-jg