Lattice Symplify:Help accessing signals in deep submodules for debug

[Berni]

Unfortunately i had an old FPGA project from a guy who no longer works here dropped in my lap. It has some stability issues with it that need fixing and some of it is quite a mess.

Its running on a Lattice MachXO2 (And its pretty full too) with Symplify Pro in VHDL2008

So so after a bit of timing tweaking didn't fix it i decided to take a deeper look using a logic analyzer. The juicy stuff is burred down in the hierarchy of submodules, so i needed a way to easily get one of those signals out to a IO pin. And so the adventure begins...

1) Just use a IDE tool:
Altera has this nice tool in the IDE where you just add signals to a list and it then muxes this big list of signals out to a set of IO pins by JTAG commands... bish bosh add a few signals to a list, compile it and away we go... well.... Lattice Diamond IDE has no such tool. It can only build a logic analyzer on the FPGA using memory blocks, but my FPGA is close to full already. And that tool sucks anyway even when it does work (Altera SignalTap works way better).

2) Do it in VHDL code:
I barely even know any VHDL (I always used Verilog) but how hard can it be?
Cool there is a thing called hierarchical references (just like in Verilog):

Code: [Select]

val <= <<signal .top.cpu.alu.val : busType>>;Well.. nope. The compiler throws its arms up as soon as it gets to the "<<" part even tho it is in VHDL2008 mode and this is a VHDL2008 feature. Turns out not everyone supports this

3) Fine i will do it in Verilog instead!
SystemVerilog is supported. Hierarchical references are also a pretty standard part of the feature set here in Verilog land so they do actually work in compilers. And i get to work with a language i actually know how to use. Perfect! So i add a new .sv source file, connect it up into the VHDL top level file, and now just wire the .sv file to my DUT.
Well... Noooope. Turns out Verilog hierarchical references only work on modules coded in Verilog.


At this point i have been at it for hours and am finding it rather ridiculous how hard it is to just simply get a random burried signal out to a pin. I can do it in Altera tools easy, i can do it in Verilog easy. But HOW does one do this in VHDL on Lattice Diamond + Synplify.

[Bassman59]

Doesn't the variant of Synplify Pro for Lattice support Synplicity's Identify debugger? It's basically the same thing as Xilinx ChipScope.

Before you get bogged down into debugging like this, have you considered:

a. Checking to make sure the timing constraints are correct and that the design meets them?
b. Simulating the logic to ensure that it's functionally correct?

[Berni]

Doesn't the variant of Synplify Pro for Lattice support Synplicity's Identify debugger? It's basically the same thing as Xilinx ChipScope.

Before you get bogged down into debugging like this, have you considered:

a. Checking to make sure the timing constraints are correct and that the design meets them?
b. Simulating the logic to ensure that it's functionally correct?

I can't seam to find the Synopsys Idenfity anywhere so guessing its not there, but im not surprised since the Lattice edition of Synplify is pretty cut down. I can't even do place and route on Lattice chips (It just does the synthesis step, the map place route export programming..etc is done by Lattices own tools)

I assumed the logic is correct since it worked on real hardware, but once they kicked off production they got a significant amount of boards that didn't work. Tracked it down to a FPGA issue. Went at it with the source code and i could get it to compile a more stable binary by massaging the compiler settings, but the timing analysis was not happy at all.

Looking trough the code i found some really long chains of logic. Such as a timer implemented by comparing its 32bit value using >= operation and feeding the output of that straight on into other logic like state machines (no registering, just direct combinational out) Then there are things like 120bit wide FIFOs with a bunch of big MUXes hanging off them even tho it could have been a 9bit fifo and bus with a bit of smarts (Its all going out of a 500Kbit UART in the end, so super slow). This particular problem i have narrowed down to the interaction of two state machines that run on different clocks (But at least divided down from the same clock source). I have found i can reduce the clock speed on one of the clocks (and updated the clock dividers/timers that run from that clock) and this got the timing analysis consistently in the green even if you mess with compiler settings. And it resulted in consistent behavior on the FPGA between compile iteractions, but its consistently wrong behavior.

So this is how i arrived to hooking up a logic analyzer and seeing what is actually going on. All i hopes of finding some easy fix that doesn't involve rewriting large parts of that VHDL (Even tho i should given how some of it looks, but i don't want to spend too much time on it)

So yeah for now im going to resort to the barbaric way of getting my signals out. Adding extra ports all the way up the chain of sub modules to get my signal back out to the top level and out to the pins.(it just feels so kludgy when i know doing this was always so easy with the FPGA tools i normally use)

[BrianHG]

Depending on the clock structure & source VHDL if it doesn't use lattice dedicated functions, if all else fails, you can do the dirty trick I use.  I would bring most third party designs into Quartus9.1, build and simulate a fairly similar FPGA with a simulator tool which allows for both simulation tb or use the nifty build in waveform editor to paint source signals.

I usually track down really dumb issues or poor coding style in hours to minutes.  And I have no issue tapping any internal net or register.

Though, that old Quartus is obsolete.  Too bad, cause it eats only a few megabytes of system memory and compiles & simulates in a few seconds for most code.

[Berni]

I already fixed it.

After some logic analyzer debugging i found that indeed it was the interaction of those two state machines running at two different clocks that was the issue. The faster state machine stops holding the data in the bus by the time it tells the other state machine to do stuff with it. This should have never worked in the first place, but the timing issues delayed the bus state for just long enough to make it work. My fix was to just keep driving the data on the bus, seams to work reliably now.

This code was originally written for a Xilinx chip and then ported over to Lattice and went trough a few revisions. It astounds me how the guy before me kept this thing working trough all of this. Tho i did see quite a few "syn_preserve" and "syn_keep" attributes around this part of the code, so it does suggest he was fighting it, but never discovered the root cause.

God how much of my time was sunk into this silly bug.

Depending on the clock structure & source VHDL if it doesn't use lattice dedicated functions, if all else fails, you can do the dirty trick I use.  I would bring most third party designs into Quartus9.1, build and simulate a fairly similar FPGA with a simulator tool which allows for both simulation tb or use the nifty build in waveform editor to paint source signals.

I usually track down really dumb issues or poor coding style in hours to minutes.  And I have no issue tapping any internal net or register.

Though, that old Quartus is obsolete.  Too bad, cause it eats only a few megabytes of system memory and compiles & simulates in a few seconds for most code.

Ah that's a good trick. I am more used to Alteras Quartus tools but i keep using newer ones with ModelSIM.

Tho to be fair the ActiveHDL simulator that comes with Lattice tools is not so bad. Sure it does looks like something straight from 1995 as most FPGA tools do, but it does the job, is fast and is reasonably easy to use. Alas the guy before me didn't leave me with any useful simulation testbenches of the part i was having problems with.