Elastic buffers, join and fork structures - Page 1
Forum section: electronics / general

author: promach
author_rank: Frequent Contributor
timestamp: August 01, 2020, 03:04:55 am
content: Could anyone comment on the working mechanism for elastic buffers (Figure 10), join and fork structures (Figure 11) ?Note: Screenshots are taken fromSELF: Specification and design of synchronous elastic circuits

author: BrianHG
author_rank: Super Contributor
timestamp: August 01, 2020, 03:40:37 am
content: 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

author: promach
author_rank: Frequent Contributor
timestamp: August 02, 2020, 01:26:54 pm
content: 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 ?

author: BrianHG
author_rank: Super Contributor
timestamp: August 02, 2020, 08:26:26 pm
content: Quote from: promach on August 02, 2020, 01:26:54 pmYou 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: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:if (reset) begin.......fifo_position <= 8'b11100001; // The fifo empty locationend else beginif ( shift_in_protect && ~shift_out_protect ) fifo_position[7:0] <= {fifo_position[6:0],fifo_position}; // Rotate the FIFO position leftelse if ( ~shift_in_protect && shift_out_protect ) fifo_position[7:0] <= {fifo_position,fifo_position[7:1]}; // Rotate the FIFO position rightThis 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:if ( shift_in && ~shift_out ) fifo_size <= fifo_size + 1'b1; // Calculate the number of words stored in the FIFOelse 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.

author: BrianHG
author_rank: Super Contributor
timestamp: August 02, 2020, 08:53:37 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: August 03, 2020, 12:12:07 pm
content: QuoteThe 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"

author: BrianHG
author_rank: Super Contributor
timestamp: August 03, 2020, 03:50:56 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: August 05, 2020, 05:52:30 am
content: QuoteSomeone told me the above.What do you think about thequoted statement above?

author: BrianHG
author_rank: Super Contributor
timestamp: August 05, 2020, 09:06:09 am
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: August 12, 2020, 09:45:00 am
content: Have a look atImplementing Latency-Insensitive Dataflow Blocks1. How is "Hold" action different from "Buffer" action ?2. Why is the '1' pin of the second multiplexer inside the input buffer block fed a symbol of ⊥ ?

author: BrianHG
author_rank: Super Contributor
timestamp: August 13, 2020, 06:26:14 am
content: 1 )Buffer takes in and latches a word into the storage register.Hold freezes everything in place, do nothing at all. The storage register retains it's previous value.2 ) This clears the buffer and also assigns 1'bxxxxxx to the latch (IE: set reg as dont care bits). This is useful when simulating where in your resulting waveform, the simulator will report an XX/or/ZZ value instead of an old value or a 0 which may be mistaken for a buffer which was just written a 0 value to it. This really helps when debugging code, however, it wont effect the functionality as you can see the case of this example the buffer being emptied instead of being cleared to 0.Note that the illustrations are feeding the register word are correct functionally, but should have been presented with as a clock enable/load enable for the register as the way the code is written.This 'Latency-Insensitive Dataflow Blocks' is better presented & explained than you first elastic buffer. It is also basically an almost identical implemented 1.5 word version of my 3 word 0 latency fifo, except, the full & empty tracking is stuffed in the highest bit of the ireg reg and odata reg where I made a parallel shifting register called 'fifo_position' which almost does the same thing.

author: promach
author_rank: Frequent Contributor
timestamp: August 13, 2020, 09:32:28 am
content: 2) Will assigning value of unknown 'x' not affecting verilog code synthesis ?Besides, using 'x' still does not explain why is the '1' pin of the second multiplexer inside the input buffer block fed a symbol of ⊥ ?Note: symbol ⊥ literally means absence of token pair (data, valid) which means that 'valid' is low, while 'data' is don't care.

author: BrianHG
author_rank: Super Contributor
timestamp: August 13, 2020, 02:29:38 pm
content: That symbol 'Note: symbol ⊥ ' is the selection line:ireg <= {1'b0, W{1'bx}}};Which was chosen to make ireg = that mux selection by the previous line's 'IF' command.It would have been just as valid to say:ireg <= 1'b0; // don't bother with the ireg[W-1:0], just clear ireg's MSB status flag.While the rest of ireg[W-1:0] would never change it's value. However, when debugging during simulation, you could not tell the difference between a 'Core stop, empty?' and a 'Will core consume?' as they would both appear to have the same end result in the ireg buffer and ireg would have a 0 already in both cases.When running the IC/FPGA, the 2 'ireg <=' I listed are function identically in the silicon. But when simulating, in the first case, the simulated viewed vector waveform will report that the lower bits of ireg[W-1:0] have reported a value of XX instead of still holding it's previous data.Read up on Verilog 'don't care bits', both Z and X. How to use them in if A==B and what how simulation results change when assigning a register to them compared to actual function.

author: promach
author_rank: Frequent Contributor
timestamp: August 14, 2020, 03:41:02 am
content: WHY the variableiregdoes not have theelsepart ??Code:always @(posedge clk)if(!cstop && ireg ) // Will core consume?ireg < = { 1'b0, { W { 1'bx }}} ; // Yes: empty bufferelse if ( cstop && !ireg) // Core stop, empty?ireg < = idata; // Yes: load bufferQuoteWait, I am confused with your quoted sentence above.

author: BrianHG
author_rank: Super Contributor
timestamp: August 14, 2020, 07:04:36 pm
content: Quote from: promach on August 14, 2020, 03:41:02 amDuring the second 'else if':ireg < = idata; // Yes: load bufferIt is possible to load a '0' or a '1' into the ireg bit as idata input contains a the bulk data [W-1:0] and the  bit input as well coming from the source. This is the source data status bit.This is why it is useful during a simulation to know the difference between the first 'IF' clearing the ireg to a 0, or, if the second 'IF''s 'ireg < = idata' was the one who set the ireg to 0 with the rest of the bulk data coming in as ireg[W-1:0].In the drawing illustration, the  in the data in, out and through the logic is that really thin black line in parallel, always the same offset from the thick black data bus.

author: promach
author_rank: Frequent Contributor
timestamp: August 15, 2020, 03:08:37 am
content: Code:assign istop = ireg ; // Stop if bufferingWhy does 'istop' need to depend onpreviousvalue of 'idata' ?

author: BrianHG
author_rank: Super Contributor
timestamp: August 15, 2020, 03:15:32 am
content: Because if you fill that buffer's  with a 1 and the rest with data, there are no other buffers. This is a 1 word FIFO. You'll loose the word inside that buffer waiting to leave if you try to send data again before it is told to empty/feed out.

author: promach
author_rank: Frequent Contributor
timestamp: August 15, 2020, 06:04:07 am
content: but according to the hardware diagram, why 'istop' does not depend on 'cstop' ?

author: BrianHG
author_rank: Super Contributor
timestamp: August 15, 2020, 09:40:02 am
content: Because it should not. istop only depends on the 1 storage buffer ireg being full and the output buffer not sending out data at the same time.This is what is meant by an elastic buffer.Like my fifo, your transmitter can keep on transmitting even though the output side is stopped, that is until all the storage registers fill up, then I tell my sender to stop, if, storage buffer is full.

author: promach
author_rank: Frequent Contributor
timestamp: August 15, 2020, 09:57:31 am
content: Quotecstop is the signal describing the above quoted condition.

author: BrianHG
author_rank: Super Contributor
timestamp: August 15, 2020, 02:41:14 pm
content: Do not confuse the output buffer being halted with the input buffer having 1 spare word of room or not to decide if the stop condition needs to be sent to the sender.We have thoroughly gone through the pieces of this design. It is time for you to either manually simulate on paper or in a simulator and work out step by step what is happening & when so you can figure out when and why each stage operates the way it does.

author: BrianHG
author_rank: Super Contributor
timestamp: August 16, 2020, 05:49:44 pm
content: Here, I created a 'FIFO' style System Verilog module of you latest elastic buffer here:https://www.eevblog.com/forum/fpga/2-word-first-word-fall-through-(fwft)-fifo-fifo-style-elastic-buffer-for-speed/msg3191352/#msg3191352The rules are different where the internal functioning of the output clocks/advances and will stop automatically once a valid word becomes present until the receiver request a shift_out.

author: promach
author_rank: Frequent Contributor
timestamp: August 17, 2020, 11:36:05 am
content: QuoteThat's kind of the whole point of that buffer: to break the combinational path from cstop to istop. They do depend on each other, but only through a register. The idea of that buffer is to make it so things upstream from it can know whether there's buffer space available (istop) without having to know whether there's downstream space available (cstop).

author: BrianHG
author_rank: Super Contributor
timestamp: August 17, 2020, 06:09:10 pm
content: Quote from: promach on August 17, 2020, 11:36:05 amYes, you got it.Though it seems we are thinking about these things little differently as our case usages are different, that is a very useful function of these elastic buffers.It is also the reason why I made that 2 word fifo. My 3/4 word fifo still works great, but, if you have 2 or 3 gigantic set of functions all dependent on a single 'ENABLE', and your FPGA fabric & compiler just cant use a global bus for the enable, (eg: clk line is usually a dedicated global bus with specific buffers throughout the FPGA), sticking 1 or more of these 2 word elastic fifo's in between those modules regenerates a whole new 'enable' & 'stop' condition between them to drive the next bundle of logic.

author: promach
author_rank: Frequent Contributor
timestamp: September 21, 2020, 01:39:46 pm
content: In Figure 2 of thereply #9, why are there some table entries highlighted in yellow ?What are those for ?