Fifo Simulation Error

Jul 15, 2008 11 Replies

I've initiated the component and the instance according to the .vho files created along when I created my FIFO with the core generator.



I've copied all the files into the same directories, but i just get the below error:



# ** Warning: (vsim-3473) Component instance "inst_fifo_generator_v4_2_16k : fifo_generator_v4_2_16k" is not bound.


how?



thanks


It means that there is no source file that you have compiled with Modelsim that has any entity/architecture called 'fifo_generator_v4_2_16k'.

KJ

thanks I forgot to add it into my ISE

I'm sampling some stuffs at 33Mhz, and feeding into my FIFO at 33Mhz continuously.

On the other side of my FIFO, I have it clocked at 50Mhz, sending the output to UART which transmit at 115200baud rate.

It seems that my FIFO gets full quite often. Is there anything I can do?

I tried using up all of my block rams and lowering the data width, but it doesnt help much

.

Send less data or send it slower.

Communication paths are always limited by the slowest element, in this case it is the 115,200 baud serial link. Basic math suggests that ~11KB/sec is the best that any UART could possibly handle (8 data, 1 start, 1 stop bit). Since you're putting stuff in at 33MB/sec (assuming that you're putting a byte in every 33MHz clock...not sure from your description) this means that your system is producing data at 3x the rate that you can pull it out.

The choice of using a UART to send your data is fundamentally flawed, so you need to

- Drastically cut down on the amount of data sent to the UART

- Run the UART at a non-standard 3x (minimum) higher rate, which presumes that whatever is on the other end of the serial link can also run at that higher rate.

- Use a different interface that can run faster (USB as an example).

- Buffer the data in memory and transmit data from memory to the UART.

None of the above solutions are necessarily possible for your particular situation, they are meant to get you thinking. Now you've got to sit down and figure out a solution based on whatever your actual constraints and functional requirements are.

Unless the overall amount of data is limited (many times it is) than no amount of memory will work because the input rate is 3x the available transmission rate. Many times though data comes in in a burst and then there is dead time before the next burst. If that's the case in your situation AND the dead time is at least 2x of the data time then the absolute minimum amount of memory you'd need would be on the order of 2/3 the maximum total amount received.

For example, if you'll be receiving at most 3.3MB of data at 33 MHz then the data will be coming in for ~0.1 seconds and it will take you approximately 0.3 seconds to send it out the UART. If the next 3.3 MB starts coming in 0.3 sec after the first then you'll need a memory buffer that is at least 2.2 MB in size and you should be able to just squeak it out. You'd be running right on the edge, but if you know your data rates and sizes such a system can be designed.

Good luck

Kevin Jennings

O.K. so data comes in continuously at 33 MHz and ?? bits wide.

O.K. so data goes out at 115.2 KHz or 0.1152 MHz and one bit wide using at best 8 of every 10 clock cycles at that frequency.

1) Decide how long you need this "continuous" data to run and make the FIFO deep enough to handle that much data. 2) Add about 286 more UARTs per input bit.

3) Raise the UART bandwidth to 33 MHz times the input bit width.

4) Consider a job in the food-service industry :)

It had to help some... How much it helps depends on how much data you really need to collect. If you want megabytes of continuous data, you either need to find a higher-bandwidth output channel or use external memory like SDRAM. You realize that even with one input bit at 33 MHz, your output bandwidth will limit you to your FIFO depth plus about 0.3% (the amount drained in the time it takes the FIFO to fill up).

Regards, Gabor

Woops, failed basic mathematics myself on the previous post. 115200 baud will translate to ~11KB/sec which is 3000x slower than the implied input rate of 33 MB/sec...not 3x. Replace all 3x with 3000x in the previous post...get a reeeeeally big memory buffer

KJ

:( im trying to sample the LPC bus though... I've already reduced to the minimal that I think I need...and with what I have now, there are weird extra cycles appearing at places where they shuoldnt be. Without these samples, I cant determine if those weird cycles are relevant or not.

hmmm I guess I can give up on usb.. I cant find a VHDL usb core to use anyway ~_~

Maybe you could build a module to look for a condition on the bus that is interesting to you, and store everything just before and after that event? Then you could transmit the stored data out the UART. You just need to figure out how to detect your error on-the-fly.

Dave

200
00x
t
m
?

ya im sort of trying to do it now but it's either my condition aint met

or the bus go crazy =3DP

A B C C D

It's supposed to be A,B,C,D,E, but sometimes it has repeats like ABCCD or ABBCDE o_o!!

If I was you i'd go back to pen and paper and carefully think about and plan the design. Then probably start again with the coding.

=A0115200

h 3000x

the

thout

t or

ogram

t to

usb?

t
t

Im having a small problem now. I tried to edit my tbw... but every signal that I try to set takes up to 1min for the changes to take place. It's very slow =3D( I've increased my vram and ram...but it doesnt help at all.

I'm simulating up to 8000ns...

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required