Prev: FIFO Depth Calculation
Next: Unecessary simulation paths
From: Symon on 5 May 2010 10:16
On 5/4/2010 7:29 AM, Vips wrote:
> Hi All
>
> What could be the optimal buffer for an asynchronous FIFO with the
> Write clock at 50 MHz and the Read clock is 25 MHz
>
>
> Data is coming as 8 bits with each clock write . There is no idle
> cycle. We have to keep the synchronization latency also into account.
>
>
> Thanks
>
> Vips

You could have the read side running at 87% of light speed. Then,
special relativity time dilation effects mean that you will have enough
time to get the data out with a 25MHz clock, for an observer traveling
with the read side.

Was the job at CERN?

HTH., Syms.
From: Curt Johnson on 5 May 2010 11:26
On 5/4/2010 2:19 PM, Jonathan Bromley wrote:
> On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote:
>
>> I was also thinking the same. I was asked this question in an
>> interview and wanted to know the answers from the experts. Though I
>> also answered as infinite but the guy said there could be an "OPTIMAL"
>> buffer to make sure there is no OVER RUN.
>>
>> When I asked him to answer and proof he simply declined.
>
> That sounds like an employer you're better off not workiing for.
> If what you told us is an accurate reflection of the way the
> question was posed, it is evidence of sloppy thinking, poor
> use of language as a communication tool, and ambiguous
> specification. None of these are good attributes when
> you're trying to design products :-)
<snip>
>The result is that a truly
> smart candidate will have no choice but to ask
> a load of questions that the interviewer thinks
> are stupid, but in fact are just a reflection of
> the interviewer's poor communication. Great
> selection skills, eh?

When interviewing candidates, I almost always ask an impossible question
or two. It is a test of character, not of knowledge. I don't want
someone who just gives up, nor do I want one who guesses at the missing
information. I want someone who is not afraid to question authority
until he is sure he can solve the problem correctly.
Very little in many interviews is as it seems.

Curt

From: glen herrmannsfeldt on 5 May 2010 13:58
Symon <symon_brewer(a)hotmail.com> wrote:
(snip on ethernet collision resolution)

> That sounds like nonsense. I don't recall seeing that in the backoff
> algorithm for half duplex ethernet. Do you have a source to back up the
> apparently preposterous claim that users should deliberately force a
> collision?

Not deliberately force, but if two stations compute the same
backoff delay, proper resolution requires that the collision occur.
That is true, even if the signal from one arrives at the other
before the latter starts sending. I will have to see about a
reference.

-- glen
From: glen herrmannsfeldt on 5 May 2010 17:03
Symon <symon_brewer(a)hotmail.com> wrote:

>> The interesting one comes when transmitting after a collision.
>> Because of possible variations in the clock (crystal), some
>> stations will have a slightly faster clock. To avoid giving an
>> advantage to those with a faster clock, there is a point at which
>> one will transmit, even if a signal arrives from another station
>> before transmission actually begins. The crystal variation goes
>> into calculating that time.

> That sounds like nonsense. I don't recall seeing that in the backoff
> algorithm for half duplex ethernet. Do you have a source to back up the
> apparently preposterous claim that users should deliberately force a
> collision?

Actually, I believe the one I was thinking about is in the inter-frame
gap algorithm. In both the IFG and collision resolution case it
is required that when stations are scheduled to send that they
actually do so. If carrier sense is active, a station waits until
it goes inactive, waits the appropriate IFG delay, and transmits.
There is a point during the inter-frame gap time that the station
makes an irrevocable decision to transmit, even if carrier sense
goes active. That is necessary for fair access to the medium
within the tolerance of the crystal oscillators, and other possible
delays.

Also, the RS232 asynchronous communication stop bit is needed
to allow for possible clock differences between two stations.

-- glen
From: Symon on 5 May 2010 20:38
On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote:
> Symon<symon_brewer(a)hotmail.com> wrote:
>
>>> The interesting one comes when transmitting after a collision.
>>> Because of possible variations in the clock (crystal), some
>>> stations will have a slightly faster clock. To avoid giving an
>>> advantage to those with a faster clock, there is a point at which
>>> one will transmit, even if a signal arrives from another station
>>> before transmission actually begins. The crystal variation goes
>>> into calculating that time.
>
>> That sounds like nonsense. I don't recall seeing that in the backoff
>> algorithm for half duplex ethernet. Do you have a source to back up the
>> apparently preposterous claim that users should deliberately force a
>> collision?
>
> Actually, I believe the one I was thinking about is in the inter-frame
> gap algorithm. In both the IFG and collision resolution case it
> is required that when stations are scheduled to send that they
> actually do so. If carrier sense is active, a station waits until
> it goes inactive, waits the appropriate IFG delay, and transmits.
> There is a point during the inter-frame gap time that the station
> makes an irrevocable decision to transmit, even if carrier sense
> goes active. That is necessary for fair access to the medium
> within the tolerance of the crystal oscillators, and other possible
> delays.
>
> Also, the RS232 asynchronous communication stop bit is needed
> to allow for possible clock differences between two stations.
>
> -- glen
Dear Glen,

Thanks for the clarification. I wonder, could you point me to a
'inter-frame gap algorithm' specification which proposes that a user
should send despite the channel being busy?

Also, I am interested in your concluding statement about RS232 stop
bits. I gather you live in a world of half-duplex.

How would you propose to eradicate the stop bit in a world where we are
all synchronised?

How would we synchronise ourselves?

Would we need to be adjacent?

Thanks, Syms.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: FIFO Depth Calculation
Next: Unecessary simulation paths