A demo long ago made me think things were messed up and the FAE couldn't
explain things at that demo. It occurred to him later that there was a
separate step to associate the original signal name database with the
chipscope signal order. He thought it *should* be part of the normal tool
flow for just his reason but it's still a separate step. Look back through
your GUI menu items and see if anything makes sense along these lines. I've
been using Synplicity's Identify tool myself so I can't supply much more
guidance for chipscope outside this one memory.
"Nju Njoroge" <
[email protected]> wrote in message
news:
[email protected] oups.com...
> Hello,
>
> I have a ChipScope ILA and ICON instantiated on the top-level MHS file
> like this:
>
> BEGIN chipscope_icon
> PARAMETER INSTANCE = chipscope_icon_0
> PARAMETER HW_VER = 1.00.a
> PORT control0 = control0
> END
>
> BEGIN chipscope_ila
> PARAMETER INSTANCE = chipscope_ila_0
> PARAMETER HW_VER = 1.00.a
> PARAMETER C_DATA_SAME_AS_TRIGGER = 0
> PARAMETER C_DATA_IN_WIDTH = 256
> PARAMETER C_NUM_DATA_SAMPLES = 2048
> PARAMETER C_TRIG0_TRIGGER_IN_WIDTH = 32
> PARAMETER C_TRIG0_UNIT_MATCH_TYPE = "range with edges"
> PORT CHIPSCOPE_ILA_CONTROL = control0
> PORT TRIG0 = chipscope_ila_0_TRIG0
> PORT CLK = sys_clk_s
> PORT DATA = chipscope_ila_0_DATA
> END
>
> BEGIN my_pcore
> ...
> PORT debug_port = chipscope_ila_0_DATA
> ...
> END
>
> The issue I'm having is with how the ILA is interpreting the
> bit-ordering of the DATA input. chipscope_ila_0_DATA is a 256-bit bus
> declared as [255:0] inside my pcore and in its MPD file as well.
> Because the waveform output are not making any sense, I set 4 bits in
> the bus high. These bits are [157:154] in my debug_port. In the
> ChipScope wave viewer, they are bits [221:218]. Now, I suspected that
> maybe the ILA is reversing the ordering, but when you switch the order
> (bit 255 becomes 0), [157:154] should be [98:102]...What could
> ChipScope be doing with the ordering of the bits?
>
> Thanks,
>
> NN
>