CPLD mistery. Help.

L

lc

Guest
Hello,

I implemented in a CPLD a very simple 8bit output port
The CPLD connects to the microcontroller bus and this part
is simply a latch that is controlled by the address bus and /wr
signal. Couldn't be simpler.

I had a 'testpoint' out of the CPLD just to check when this latch
is gated.

All works fine.

When I sad to myself that I no longer need the testpoint, and removed
the VHDL line, the port stopped to work !!!
I changed nothing else !!!!
Put back the test point and the port worked again !!!

This is crazy !
Anyone has a clue about what is happening ?
Help is appreciated, I may leave the testpoint there
but I want to understand what is going on !


(using Max+Plus II 10.2BL and a MAX7128SQC100-15)

the relevant part of the VHDL code follows:
--------------------------------------------

....

-- this is the test point I'm talking about inspecting the
"write_to_the_port" signal
PF(0) <= ga_class_wr;
-- end of debug area


octnr <= conv_integer( unsigned( a(10 downto 8) ) );
ga_class_wr <= '1' WHEN ((a(15 downto 11) = GA_PORTS) AND nwr='0') ELSE '0';
ga_class_rd <= '1' WHEN ((a(15 downto 11) = GA_PORTS) AND nrd='0') ELSE '0';

PA<= par;
PB<= pbr;
PE<= per;
pcr<=PC;
pdr<=PD;

-- latching cpu bus writes

cpuio: PROCESS(ga_class_rd,ga_class_wr,d)
VARIABLE wrdata: STD_LOGIC_VECTOR (7 downto 0);

BEGIN
IF (ga_class_wr='1') THEN
CASE octnr IS
WHEN 0 => par<=d;
WHEN 1 => pbr<=d;
WHEN 4 => per<=d;
WHEN OTHERS =>
END CASE;
end if;

IF (ga_class_rd='1') THEN
CASE octnr IS
WHEN 2 => wrdata := pcr;
WHEN 3 => wrdata := pdr;
WHEN OTHERS =>
END CASE;
d <= wrdata;
ELSE
d <= "ZZZZZZZZ";

END IF;

END PROCESS cpuio;
 
"lc" <cupido@REMOVEmail.ua.pt> ha scritto:

This is crazy !
Anyone has a clue about what is happening ?
Click to expand...
Maybe it's an electrical problem in your board

--
Per rispondermi via email sostituisci il risultato
dell'operazione (in lettere) dall'indirizzo
 
lc wrote:
Hello,

I implemented in a CPLD a very simple 8bit output port
The CPLD connects to the microcontroller bus and this part
is simply a latch that is controlled by the address bus and /wr
signal. Couldn't be simpler.

I had a 'testpoint' out of the CPLD just to check when this latch
is gated.

All works fine.

When I sad to myself that I no longer need the testpoint, and removed
the VHDL line, the port stopped to work !!!
I changed nothing else !!!!
Put back the test point and the port worked again !!!

This is crazy !
Anyone has a clue about what is happening ?
Help is appreciated, I may leave the testpoint there
but I want to understand what is going on !
Click to expand...
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
15)="00000" and nwr='0' )


-- 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;
 
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).
Click to expand...
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.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
 
"lc" <cupido@REMOVEmail.ua.pt> wrote in message news:<newscache$gvpnzh$ys6$1@newsfront4.netvisao.pt>...
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.
Click to expand...
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.
 
lc wrote:

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

snip

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:)
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top