Suggestions/Opinions about Block Ram for buffering packets

[caio.mqo]

Dear All,

I am developing a design that requires one receiving and one transmitting buffer for Packets (probably 1.5kB AND 9kB).
Between these two buffers I will have a communication line (Which needs to be completely transparent using Aurora Protocol. This line is already built).

It will basically work like this:
Ethernet 125Mhz > Transmitting Buffer > 156.25Mhz Communication between 2 FPGAs > Receiving Buffer > 125Mhz Ethernet

For the trasmitting buffer, writing will have a 125Mhz clock, and for reading a 156.25Mhz clock.
For the receiving buffer it's the opposite, 156.25Mhz writing and 125Mhz reading.

I am thinking about using block rams for this. I've been reading the documents but still didn't get to a decision whether to use Single Port BRAM or Dual Port BRAM or how to do that (I am worried about crossing domains and all.) Should I use CoreGen or try Inferring?

If someone has opinions/suggestions/ideas to give me a light on the choice it would be great.

 

[TrickyDicky]

Dual port BRAM is the perfect way to cross a clock domain. Even better use a dual clock FIFO so you know when data is available (it will contain block rams). You will need to use coregen for the FIFO, but block rams can be inferrred.

 

[ads-ee]

As Tricky suggests use a dual clock (asynchronous) FIFO at least for the transmit buffer.

For the receive buffer you could use dual port BRAM and combine the buffering with store and forward logic to check the packets before forwarding them. You could also add the filtering logic for those Ethernet packets. For the RX buffer you can either have a circular queue structure (FIFO-like) or have fixed queue addresses, which can simplify the queue addressing logic at the expense of not maximizing the total queue depth (your choice of which method makes more sense in your design).

Regards

 

[ftsolutions]

+1 I have used the coregen asynch FIFO to cross clock domains between 1394 Firewire incoming data packets and a proprietary 32 MHz output serial bus. I initially tried to implement the Asynch FIFO myself, but would occasionally get a first byte glitch which the coregened one did not. Unless you need to do random access processing of received data, this makes memory management much simpler.

 

[caio.mqo]

Thank you very much for all the responses!

I have been looking for FIFOs and one question appeared...Is it possible to have an asynchronous FIFO (as I have 2 clocks) that deals with Packets?
As I saw in FIFO generator datasheet, it should only be possible to transmit packets using synchronous FIFO...

Also, can anyone suggest me a way to test how it should work?
I mean, is there a way to Generate a Frame, pass it through FIFO or BRAM and then read it again, to understand the mechanism.
I would like to understand it first, and then incorporate to my top level.
Do I need to use ISIM, Chipscope or something like that?

Thanks!

 

[ads-ee]

I have been looking for FIFOs and one question appeared...Is it possible to have an asynchronous FIFO (as I have 2 clocks) that deals with Packets?

yes, you use the FIFO flags, and if you need to transmit uninterrupted packets then you can add the almost empty flag and set it to the packet size.

As I saw in FIFO generator datasheet, it should only be possible to transmit packets using synchronous FIFO...

probably a misunderstanding of the datasheet, perhaps the datasheet was/is for a synchronous FIFO implementation?

Also, can anyone suggest me a way to test how it should work?
I mean, is there a way to Generate a Frame, pass it through FIFO or BRAM and then read it again, to understand the mechanism.

It's called a testbench. As you're using Xilinx, check the option to generate a testbench and it will generate a simple testbench to write and read from the FIFO. You can edit that testbench and add in packet generator code to write your packets into the FIFO.

I would like to understand it first, and then incorporate to my top level.

good for you, most would just add the untested code and then when it's broken ask the forum to fix it for them. ;-)

Do I need to use ISIM, Chipscope or something like that?

Yes to ISIM (or Modelsim if you have it). You should really get into the habit of testbenching and simulating your code before you implement it. It is much more difficult to find bugs in code after implementation using Chipscope as a crutch than using a good testbench.

Regards