fpga what uses less space FIFO or shift registers

[fengels]

What is the most efficient for space on the FPGA, FIFO or shift registers in a SCTL

Regards

Frank 

Message Edited by fengels on 04-18-2008 10:05 AM

[Wiebe@CARYA]

FIFO's use RAM and slices, shift registers only slices. It's hard to tell
which one uses most slices, since there is no reliable way to benchmark. But
if you intend to use it for a scalar (i.s.o. an array), I'd use a shift
register.

Btw. A FIFO might not even work, because you need to set it to Never
Arbitrate for it to work in a SCTL. But if you intend to use it as a shift
register, you need to read and write from/to it. This might not work
correctly, because the arbitration is off.

I can't imagine an application where the use of shift registers will become
significant for the space used on the FPGA. Can you explain why this is
important for your application?

Regards,

Wiebe.

[fengels]

My program does not fit on the FPGA (3Mgate) and I use a lot of fifo's.

I use  the FIFO's in a for loop with N=6. For every Index in the for loop I have a  FIFO, so in this case 6 FIFO of one kind

An example of a subvi that is place in this for loop is attached "fifo example.gif" (this one can not be replaced with shift registers)

(I do not know if the SCTL is used correct here, I did not use it this way yet. But I used it with the FIFO's out side the SCTL)

I have 5 of these kind of FIFO's in a for loop. and I use 107% of slices. so is there a more efficient way to program this.

the attache file "replaced with SR.gif" is the fifo I could replace with a shift register

[fengels]

the attache file "replaced with SR.gif" in the prevous message will not work,  the local variables must be placed outside the SCTL)

Regards

Frank

[Wiebe@CARYA]

If your code doesn't fit, it is probably not just because the FIFO's take
much space. Still, if each subVI has a case with 6 FIFO's in it it will add
up. Looks to me that FIFO's are not the best solution to your problem. It's
hard to judge by just seeing this single VI what will work for you.

The SCTL might be in place here. Again, hard to say. It will take longer to
compile, but the result will be smaller and faster.

Some advice:

If the FIFO's are only used to pass values, use globals instead (or even a
wire might work). On PC's that is not accepted as good programming practice,
but on FPGA it is very usefull. FIFO's are usefull to pass data to the host
and back, and if one loop runs seperated from another. Hard to say how you
use them.

Lose the case structures in the middle of the first picture (and from the
rest of the code)!!! Replace them with simple selectors. In normal
programing, the case selectors will execute only the selected case, and this
is faster. On FPGA, the case selector is an additional forced
synchronisation, and will very likelly cost additional slices! The fact that
the code of both 'cases' is executed doesn't matter, because it happens in
parallel. Only good reason to use a case structure on FPGA is to execute a
FIFO, memory or IO opperation. Event then I've send dummy FIFO values to the
host, just to save a few slices.

If timing isn't critilat, you might want to put the FIFO read case in a sub
vi, and the FIFO write case in another, if this is used a lot. It might not
work in a SCTL anymore if the FIFO's use arbitration.

Using subVI's can save lots of slices on an FPGA, even if the subVI's are
set to reeentrant execution. It will save some compile time as well.

Don't use locals on your main VI's diagram, just to communicate values! The
locals will have indicators or controls on your front panel, and each of
them will have communication code automatically compiled around them! This
might save a lot if you use this thoughout the application. I even combined
some I32 host communication controls to U64's just to save slices on the
communication code (or 4 U16's to one U64).

Regards,

Wiebe.

[tartan5]

Hi Wiebe,

Lots of good points.  It would be nice to see a Labview FPGA "best practices" guide, since a lot of "standard" labview ways of doing things are not necessarily optimal for FPGA.

Just a comment about case structures - Other times to use them in FPGA are state machines in SCTL (which I use heavily), and to put indicators inside to control when the indicator value is updated.....

I second your comment about combining controls and indicators - On one project I had 8 FP bool inputs and outputs, which reduced nicely to one U8 each.....  Another good reason to combine values is that it makes them inherently synchronous.  Let's say you have two 16 bit values that must be correlated with respect to each other.....As separate variables, you can't guarantee that when you read one, by the time you read the other it hasn't updated.  Combining the two into one 32 bit value, then splitting it apart at the Host ensures that they remain correlated....  This could also be done using a cluster or array......

Regards,

Howard 

[Wiebe@CARYA]

You are right about the use of cases for state machines. If you don't want
to update a indicators value, I'd try to simply put the old value in it
instead of using a case.

If you implement a state machine, will each case take as long as the longest
case? I've done some small tesing, that shows it does (one case with a x ms
wait, one without. The loop will take x ms to execute even if the other case
is selected). Just something to keep in mind when you use a case for a state
machine. Although a case is the most logical way to implement a state
machine, you could make the same functionality with two FIFO's, or queues.

The use case you describe for combining the controls (to make the update
synchrone), is exactly how I use them. Although it seemed to work withouth
joining the numbers, joining them feld a lot more secure.. Good point.

Regards,

Wiebe.

[tartan5]

I can attest that they are definitely NOT synchronous, unless you combine them either as one data element or cluster them.  As a test, take a single counter and feed to two FP indicators.  Now on your Host program, subtract the two and run the result to a graph..... I'll bet you'll see occasional glitches where the two number were not identical.  I actually was using a 34 bit signed FXP, and split it into two U32's (since I was using DMA FIFO as well).  On my host it was most obvious as my readback was cycling about zero, and one value was still a signed negative value while the other was showing a portion that was positive, causing large data variations.....

I agree, that if the old value is still around, putting the old value into the indicator can actually consume fewer resources, since you don't need the logic to gate the update.  However, in some cases, to do so would mean you would need a shift register to hold the old value.  I am not sure which would be fewer resources, the shift register (which in my case was for a 34 bit signed FXP), or the gating logic?  It seems like the gating logic would be "cheaper", but I'm not sure.....

I implement my state machines inside a SCTL.  For my purposes, this was required, since I was controlling a digital bus and needed deterministic timing for each 25 nS period.  Using a loop outside a SCTL introduces a 2 cycle penalty PER LOOP, which would not allow the timing I needed.  So, Inside the SCTL,  each case takes the same amount of time, one clock cycle.  If I need variable timing, I use a WAIT case.  My previous case shoves into a SR (shift register) the number of waits required and stuffs into another SR the NEXT STATE when the wait is done, enter (and keep entering) the WAIT state, decrementing the wait each time until zero , then loads the NEXT STATE as the next state to enter..... 

I'm a little concerned about your experience with the longest state issue......If that were true I think it would be a severe bug.  I am assuming that this must have NOT been inside a SCTL?  Could this be easily proved by examining the tick counter values at the completion of each case?

[Wiebe@CARYA]

On FPGA every think you should normally do has cases where doing it is very
bad... It's a though target if you need to get the most out of it.

> I'm a little concerned about your experience with the longest state
issue......If that were true I think it would be a severe bug.  I am
assuming that this must have NOT been inside a SCTL? 

Yes, this was tested in a normal loop. In a SCTL all code together can only
take one tick, so there is no way to measure how long a single case would
take. I think I used a wait with a constant wired to it.

> Could this be easily proved by examining the tick counter values at the
completion of each case?

That's basically how I did the test. I put the case in a loop, and measured
the time between two cycles.

I'm not sure if it is possible to avoid this. I'm also not sure if my test
was conclusive. Since even a simple test takes 8 minuets to compile, it's
not something to do for fun... I'll try it agian, I might very well be
wrong.

Regards,

Wiebe.

[fengels]

HI all,

 sorry for the late reply, I was on a holiday for a week.

Thanks for all the answers.

I use my FIFO for the values of the previous calculaton.

Meanwhile I changed my code. All the FIFO that I are now combined into  6 main fifo's, I put the code of the subvi in the main vi (did not read the replys at that moment) And the code now fits on the FPGA. So I think that the "overhead" for all those fifo's was to much.

 will use the tip to replace the case structs where possible by slect block and try to comin some FP indicators.

Regards Frank