Author Topic: Elastic buffers, join and fork structures  (Read 293 times)

0 Members and 1 Guest are viewing this topic.

Online promach

  • Frequent Contributor
  • **
  • Posts: 338
  • Country: us
Elastic buffers, join and fork structures
« on: August 01, 2020, 03:04:55 am »
Could anyone comment on the working mechanism for elastic buffers (Figure 10), join and fork structures (Figure 11) ?


Note: Screenshots are taken from SELF: Specification and design of synchronous elastic circuits





 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3983
  • Country: ca
Re: Elastic buffers, join and fork structures
« Reply #1 on: August 01, 2020, 03:40:37 am »
Trick to understand, the colored vertical rectangle blocks inside the lower 3 yellow blocks are all clocked shift latches running on the same trigger signals as the top two vertical rectangles on the right.  IE, the use the same shift as the signal generated by the 2 input and gates feeding the rectangle's bottom.

You can replicate most of this using 2 or more of my 'Home made SystemVerilog 3 word, Zero latency FIFO, documented for beginners', though, the stop would be the fifo_full from each one which would be OR'ed together to stop the sender, unless your sender is directing the output to 1 or more multiple receivers where you can more efficiently use the each FIFO's memory.  The only advantage to my fifo would be the fall-through 0 latency feature, though using multiple units of mine may utilize additional registers.  Yet, my code is so simple, you could engineer multiple outputs utilizing the same register memory words it has recovering the excess bytes used with multiple separate units for multiple receivers just by adding additional 'read' pointers and additional data outputs tied to the single FIFO's memory registers.

https://www.eevblog.com/forum/fpga/home-made-systemverilog-3-word-zero-latency-fifo-documented-for-beginners/msg3123336/#msg3123336
« Last Edit: August 01, 2020, 03:43:54 am by BrianHG »
__________
BrianHG.
 

Online promach

  • Frequent Contributor
  • **
  • Posts: 338
  • Country: us
Re: Elastic buffers, join and fork structures
« Reply #2 on: August 02, 2020, 01:26:54 pm »
For Figure 10,

1) Why 'stop' signal from receiver is fed back to 'valid' signal for sender using OR gate ?

2) Why 'valid' signal from sender is fed back to 'stop' signal for receiver using AND gate ?

3) Why the AND gates on top of VS and VS' cells depend on 'valid' signal from sender while the AND gate on top of the first version does not ?
« Last Edit: August 02, 2020, 01:31:09 pm by promach »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3983
  • Country: ca
Re: Elastic buffers, join and fork structures
« Reply #3 on: August 02, 2020, 08:26:26 pm »
For Figure 10,

1) Why 'stop' signal from receiver is fed back to 'valid' signal for sender using OR gate ?

2) Why 'valid' signal from sender is fed back to 'stop' signal for receiver using AND gate ?

3) Why the AND gates on top of VS and VS' cells depend on 'valid' signal from sender while the AND gate on top of the first version does not ?

You must remember, each red and grey box is a clocked register which delays the signal by a clock before is passes through.  Those registers are clocked by the individual signals being sent by the vertical wire leaving each yellow 'VS' box directly into the huge red and grey boxes.  Yes, those tiny colored red and grey boxes are part of their master huge red and grey box at the top right in figure 10.

1) Where do you see that?  The valid signal in unidirectional from the sender.  Now, the valid is ored with the stop after it has traversed a red and grey register, meaning, if those 2 buffer registers are full and the sender should not be sending any more data until the stop it's anded with from the receiver has been releases meaning the receiver is reading the buffers.  Though the poor design of this is the lag involved with restarting that elastic chain once it has stopped.  In my FIFO code, it would be the equivalent to this line #71:
Code: [Select]
fifo_full                       =  fifo_full_r && !(shift_out && zero_latency) ;What's being said here if all the fifo words are full, and there is no 'shift_out' from the receiver, the fifo_full / IE 'stop' sent to sender will be seen by the receiver.  But if the FIFO has all 3 words full and the receiver is simultaneously shifting data out, the sender wont see the fifo_full / IE 'stop' condition, without any delay.  (Remember, with my FIFO, the receiver's 'stop' output is inverted feeding the FIFO' 'shift_out' control.  IE, stop=1, no shifting out, stop=0, shift out).

2) read my point #1.

3) remember, those are going through a red and grey register before the result is passed on to the other side.  Those registers are clocked by the individual signal being sent by the vertical wire leaving each yellow 'VS' box directly into the huge red and grey boxes.

This is something like the shift I used in V2.0 of my FIFO to keep track of how much of the buffers were full with how much data.  IE:
Code: [Select]
if (reset) begin
.......
fifo_position     <= 8'b11100001;      // The fifo empty location
end else begin

            if (  shift_in_protect && ~shift_out_protect ) fifo_position[7:0] <= {fifo_position[6:0],fifo_position[7]}; // Rotate the FIFO position left
       else if ( ~shift_in_protect &&  shift_out_protect ) fifo_position[7:0] <= {fifo_position[0],fifo_position[7:1]}; // Rotate the FIFO position right

     This shifts left and right a bit pattern where I would tap the appropriate  fifo_position[ # ] to generate the full/empty flags.  IE stop to sender.  My original Version 1.0 and final version 3.1 said it much better with a counter which just kept track of the number of registers difference between the in and out:

Code: [Select]
            if (  shift_in && ~shift_out ) fifo_size <= fifo_size + 1'b1; // Calculate the number of words stored in the FIFO
       else if ( ~shift_in &&  shift_out ) fifo_size <= fifo_size - 1'b1;

     In this case, the receiver's 'stop' output would be inverted and tied to the FIFO's shift_out.  The fifo's fifo_full output would be generated based on the quantity of the fifo_size and the total numbers of memory words the FIFO has.
« Last Edit: August 02, 2020, 09:24:58 pm by BrianHG »
__________
BrianHG.
 
The following users thanked this post: promach

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3983
  • Country: ca
Re: Elastic buffers, join and fork structures
« Reply #4 on: August 02, 2020, 08:53:37 pm »
My short analysis was for 1 sender and 1 receiver shown in figure 10.  Figure 11 shows what logic to add if you have 2 senders and 1 receiver, or, 1 sender and 2 receivers.

To best accommodate 2 senders and 1 receiver, you would need 2 of my zero latency fifos wired together unless you want a ZIPPER together the 2 source streams (IE output will always read S1,S2,S1,S2,...), then 1 fifo with 2 input ports will do.  For 1 sender and 2 receivers, you would need 1 of my zero latency fifos with an added output read port and a second read pointer and fifo_size calculation in the main block.  The rest of the coding is trivial stuff and it can still retain zero latency functionality if needed.
« Last Edit: August 02, 2020, 08:56:55 pm by BrianHG »
__________
BrianHG.
 

Online promach

  • Frequent Contributor
  • **
  • Posts: 338
  • Country: us
Re: Elastic buffers, join and fork structures
« Reply #5 on: August 03, 2020, 12:12:07 pm »
Quote
The valid signal in unidirectional from the sender.  Now, the valid is ored with the stop after it has traversed a red and grey register, meaning, if those 2 buffer registers are full and the sender should not be sending any more data until the stop it's anded with from the receiver has been releases meaning the receiver is reading the buffers.

The explanation above might not reflect actual situation especially the AND gate.

What if the receiver is (not ready) to receive the "valid" signal and its corresponding data ?

Note: "not ready" is equivalent to "STOP = 1"
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3983
  • Country: ca
Re: Elastic buffers, join and fork structures
« Reply #6 on: August 03, 2020, 03:50:56 pm »
See the cyan structures above the first yellow box, there are 2 clocked registers +1 mux where the second output register either receives 1 word immediately from the sender bus, or, it get 1 extra latched clock delay meaning even if the receiver is sending a stop, but hasn't yet reached the sender, the gate structure inserts an additional 1 register delay extending the width of the elastic by 1 for that 1 cyan block.  I'm assuming the red and grey boxes are basic interpretations of the illustrated cyan structure at the top left.

Once the elastic of all those structures at a width or 2 and full, by that time the stop has finally propagated to the sender.

I guess the idea of this elastic system is to have a 1 or 2 width at each stage with a simple glue logic rule between them.  No central overarching flow control system.  The flow control status is being shifted through the latch blocks.

Even I'm having difficulty wrapping my head around the design decision and functionality.  The illustration for what they are trying to achieve is poor and doesn't illustrate the proper intentional mechanics of their desired function.

I'd say, google search for additional third party designs as there may be errors in their illustration.
« Last Edit: August 03, 2020, 03:58:23 pm by BrianHG »
__________
BrianHG.
 

Online promach

  • Frequent Contributor
  • **
  • Posts: 338
  • Country: us
Re: Elastic buffers, join and fork structures
« Reply #7 on: August 05, 2020, 05:52:30 am »
Quote
Because the state machines in Fig. 8 are slightly different, so the controllers in Fig. 9 are slightly different (and so are their copies in Fig. 10). Note that the bottom of Fig. 10 is essentially Fig. 9 with the left and right flipped (and one of them also split).

Someone told me the above.

What do you think about the quoted statement above ?


« Last Edit: August 05, 2020, 05:59:24 am by promach »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3983
  • Country: ca
Re: Elastic buffers, join and fork structures
« Reply #8 on: August 05, 2020, 09:06:09 am »
Are you asking me to comment on the author's different approaches design philosophy and implementation strategy?

Remember, I designed my own which goes down to transparency 0 clock pass through when empty and can stretch to 1 extra word above it's set size 3/7 without corruption, so I am biased and I would say ignore a design where as you add stages, your elastic goes from 1 or 2  with a single stage, then 2 to 4 with 2 sequential stages, then 3 to 6 with 3 sequential stages, then 4 to 8 with 4 sequential stages instead of mine which can go from 0 through 8.

However, they are talking about creating that join/fork function.  In my case, it is similar to adding a second read/empty/full pointer generator and 'OR'ing the that second port's full flag with the first full flag to stop the sender while that second port's empty flag and read data will be used for receiver #2's port.  Deciphering those state machines and verifying those gates driving the latch and AB mux control to add or eliminate a single elastic step, daisy changed among many if you want an elastic with some give and stretch above +/-1 will make my head go numb.
__________
BrianHG.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf