Xilinx IPCore CIC decimating filter

[Intaris]

I'm seeing some unexpected behaviour which I was hoping someone could help me with.

I have a design where multiple "modules" in my FPGA code are each running in separate timed loops and communicating with each other via Registers.  The timed loops all multiplex usage of hardware resources with fixed allocation of which registers are being read and written to in each iteration.  As such the correlation between input and output parameters is maintained.

A problem seems to occur with the use of a decimating CIC filter (4-fold decimation, 4 channel).  Although I am inputting values for iteration 0,1,2,3,0,1,2,3 and so on, the results are coming out as 1,2,3,0,1,2,3,0 (the first value seems to be "forgotten").  I AM using the "Channel" output of the CIC filter, so I'm unsure as to where the mixup of the channels is coming from.

I was wondering if anyone has experienced something like this or if there are any additional tips in this regard.....

Shane

[T-REX$]

Well, my first thought is the handshaking signal 'rfd' (ready for data) isn't being monitored. If the core gets backed up for a cycle, and you put in new data anyway, I could see a potential for mixup. To test, you could simply add an inverted latch of some kind to see if 'rfd' is ever false... might have to ignore the first couple of iterations, depending on if there is start-up latency associated with the IP Core.

[Intaris]

I tried monitoring the RFD signal but the mixup remained the same.

I can try it again.....

If RFD is TRUE, then on the NEXT iteration, data can be passed in right?

Shane

[T-REX$]

Actually, with a lot of Xilinx IP, RFD is true when it's ready for data this cycle. Or that's the default behavior anyway. Check out this thread: https://decibel.ni.com/content/message/49703

EDIT: Hang on, may have jumped to conclusions here. It may depend on if your IP uses the AXI interface for handshaking or not. http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgaconcepts/xilinxip_using/

[T-REX$]

ok, looking at the timing diagram for  the CIC Decimator:

The ND (New Data) and RFD lines seem to operate on the same clock period, which implies to me that an RFD means ready for data this cycle, at least by default. I don't see an ND signal exposed in your IP Block, so I'm guessing you have it wired to true in the configuration? If that's true, you only have to worry about RFD if it can ever be false... which I think will depend on how you have the block configured.

[Intaris]

I also saw that timing diagram with the RFD and ND ont he same clock cycle.  This makes no sense to me if one assumes that this diagram is supposed to demonstrate handshaking because there's no way to interpret the RFD bit in the same cycle as the ND bit.  That is to say, I can't decide whether to set ND to TRUE or FALSE based ont he value of the RFD bit.  As such, I have to assume this example simply shows how it CAN be done, but it surely does not indicate the situation where the RFD bit is used in determining the timing for the ND bit to be set.

In any case where the RFD bit is being monitored, the ND bit must be int he following clock cycle, not the same cycle (Even though it is trivially possible to see how this could be used).

Another thing I have not been able to find out is the behaviour of the IPCore when a reset is implemented.  I have made attempts to reset the IPCore so that I can force the inputs and outputs to by synchronised as I want but I did not observe the RFD or RDY bits changing status at all when I asserted the reset bit.  Is there any documentation on how the IPCore behaves when a reset (synchronous) is executed?

Shane

PS I think there's a translation difficulty when thinking in G and reading these timing diagrams....  Am I right in assuming the cycle assignment varies depending on whether we interpret it as LabVIEW logic or VHDL Logic?

[Intaris]

Aah, I think I have it.

I have made a small test VI to investigate how the IPCore behaves and I have realised something when I have started creating my own timing diagrams by displaying the different inputs and outputs per clock cycle.

I need to incorporate the "RDY" output to essentially reset my INPUT channel index.  The RDY signal changes phase during a reset whereas the RFD signal is always TRUE.  As such I need to use the RDY signal after any reset to re-align my input channel multiplexer to ensure that the input and output channel indices remain synchronised.  Cool, I just need to test this in actual compiled code instead of in simulation mode.

In this example I'm simply feeding the values 0,1,2,3 into the CIC (which represent the indices of my real channels).  Before and after any given reset, the channels remain synchronised (whereas the didn't before).  Signal CLR is the reset signal.

Shane.

[Intaris]

OK, Instead of using hte RDY signal, I need to incorporate the "Channel Sync" output signal and use this instead, otherwise the code readability suffers.  In my current cofiguration, RDY and Channel Sync are always identical.....

Shane.

[Intaris]

Actually, they're not identical.  With my configurationt hey're at least in-phase with each other.  I've tried both and both seem to work.  I'm compiling to test on "real" code.  I had seen differences between simulated and compiled code before with the CIC filter..... (regarding the indexing).