PicoBlaze

[nickagian]

Hi!

I am trying to port to Spartan6 a UART block originally designed for Spartan3, which uses the famous PicoBlaze UART cores. I have overcome the errors related with the "INIT" attributes during synthesis and then tried to debug the design through ChipScope Pro. What I have found is that probably the "valid_lut: LUT4" in kcuart_rx.vhd is not working as expected. What I see when I send a character from the PC is that the character appears correctly at the "kcuart/data_out" signal but the "kcuart/fifo_write" is never issued.

Debugging inside the kcuart block led me to the conclusion that the "valid_lut" never issues the correct output signal, although the correct combination at its inputs indeed appears. You can see the attached image, too. At the "X" pointer:

purge=lut4/I0=0

stop_bit=lut4/I1=1

start_edge=lut4/I2=1

edge_delay=lut4/I3=0

Which exactly corresponds to the correct input combination when the lut4 (INIT=>X"0040") should output "1". But it doesn't. In the waveform, the lut's output is the "decode_valid_char" signal.

I was wondering... is there by any chance possible that the timings are not correct? Is there any kind of setup delay restriction that should be respected? Because I see that after a while the "start_edge" signal goes to LOW and the correct combination at the lut is no longer valid.

Thanks,

Nikos

[gszakacs]

This just shows how you should not code for portability.  Why not just take the LUT4

and re-code it as the 4-input AND gate that it represents like:

decode_valid_char <= not purge_lut and stop_bit and start_edge and not edge_delay;

Another possibility, since LUT4 is not a native element in spartan 6 is that you could work

around this by using a LUT structure actually in the S6.

Also, this seems to be the kind of corner usage case that turns up bugs in the "new parsers"

of XST.  Try using the old parsers to see if the error goes away.

-- Gabor

[nickagian]

Hi Gabor,

thanks for your reply!

To be honest, I'm not that much experienced in FPGA's programming (I'm just doing my first steps); especially in porting designs to newer FPGAs. So, for sure I can substitute the LUT4 with the AND function it implements.

But first, I thought that since it was there I should keep it intact and second, the problem will appear probably with one of the other LUT's in this specific design. Is it possible to re-code the block so that the LUT's are removed completely? I'll have to see if that's possible.

Moreover, why are you saying that the LUT4 is not a native element in S6? I have seen the documentation and didn't see any such thing there. Could you give me a link of any document that contains a list of the native elements I can use in Spartan 6? Is it possible to find this list somewhere inside the ISE perhaps?

Thanks a lot for your help!

Nikos

[chapman]

I hope you already know that for Spartan-6, Virtex-6 and 7-Series devices you should be using the newer KCPSM6 version of PicoBlaze that is supplied with UART macros optimised to the LUT6 architecture.

I really don't want to start a debate here about the advantages and disadvantages of implementing designs by instantiating LUTs and other primitives. However, it is really a specialist task for special reasons and really not for you if you are just taking your first steps. I suggest you use the newer macros that are provided for Spartan-6 and focus on standard HDL design at a higher level of your design.

[gszakacs]

The native LUT in Spartan 6 has 6 inputs.  While you may still have LUT4 library elements

available, they are mapped into a 6-input LUT.  It's not clear why the library element for

LUT4 wouldn't behave the same as it did for Spartan 3, however.  This could be a bug in

the "new parsers."  I get the feeling that the updated parsers for XST were not particularly

well tested on corner cases.  It's likely that the use of older library elements slipped through

the verification cracks.  On the other hand I've noticed other "new parsers" bugs in 12.x

that were fixed in ISE 13.4 - the latest version.  This would happen especially for library elements

that are not listed in the Libraries Guide for Spartan 6 HDL designs.  Note that many

older library elements still map to the new hardware but aren't listed in the newest Library

Guides.

-- Gabor