Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Statistics are no substitute for judgement. -- Henry Clay


devel / comp.arch / Re: Petahertz, femtosecond logic gates

SubjectAuthor
* Petahertz, femtosecond logic gatesEricP
+* Re: Petahertz, femtosecond logic gatesMitchAlsup
|`* Re: Petahertz, femtosecond logic gatesQuadibloc
| +- Re: Petahertz, femtosecond logic gatesMitchAlsup
| `- Re: Petahertz, femtosecond logic gatesBGB
`* Re: Petahertz, femtosecond logic gatesBGB
 `* Re: Petahertz, femtosecond logic gatesMitchAlsup
  +* Re: Petahertz, femtosecond logic gatesBGB
  |`* Re: Petahertz, femtosecond logic gatesMitchAlsup
  | `- Re: Petahertz, femtosecond logic gatesBGB
  `* Re: Petahertz, femtosecond logic gatesAndy Valencia
   +* Re: Petahertz, femtosecond logic gatesBGB
   |`* Re: Petahertz, femtosecond logic gatesDavid Schultz
   | `- Re: Petahertz, femtosecond logic gatesBGB
   `* Re: Petahertz, femtosecond logic gatesTerje Mathisen
    `- Re: Petahertz, femtosecond logic gatesBGB

1
Petahertz, femtosecond logic gates

<K1VeK.7$XhAf.6@fx39.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25207&group=comp.arch#25207

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Petahertz, femtosecond logic gates
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 13
Message-ID: <K1VeK.7$XhAf.6@fx39.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Wed, 11 May 2022 20:30:34 UTC
Date: Wed, 11 May 2022 16:30:19 -0400
X-Received-Bytes: 941
 by: EricP - Wed, 11 May 2022 20:30 UTC

A group has created petahertz (10^15 Hz), femtosecond logic gates.
In a lab, and it needs lasers to drive it,
and it's really more like 10's of femtoseconds,
but still... neet.

Laser bursts drive fastest-ever logic gates 2022-May-11
https://phys.org/news/2022-05-laser-fastest-ever-logic-gates.html

[open access]
Light-field control of real and virtual charge carriers, 2022
https://arxiv.org/abs/2203.03509

Re: Petahertz, femtosecond logic gates

<fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25208&group=comp.arch#25208

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:2b09:b0:45b:59b:5df6 with SMTP id jx9-20020a0562142b0900b0045b059b5df6mr16428718qvb.22.1652306038897;
Wed, 11 May 2022 14:53:58 -0700 (PDT)
X-Received: by 2002:a05:6808:1453:b0:328:ad39:c88b with SMTP id
x19-20020a056808145300b00328ad39c88bmr2895045oiv.103.1652306038656; Wed, 11
May 2022 14:53:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 11 May 2022 14:53:58 -0700 (PDT)
In-Reply-To: <K1VeK.7$XhAf.6@fx39.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:cd3e:bc77:963e:ac4c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:cd3e:bc77:963e:ac4c
References: <K1VeK.7$XhAf.6@fx39.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>
Subject: Re: Petahertz, femtosecond logic gates
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 11 May 2022 21:53:58 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2205
 by: MitchAlsup - Wed, 11 May 2022 21:53 UTC

On Wednesday, May 11, 2022 at 3:30:38 PM UTC-5, EricP wrote:
> A group has created petahertz (10^15 Hz), femtosecond logic gates.
> In a lab, and it needs lasers to drive it,
> and it's really more like 10's of femtoseconds,
> but still... neet.
<
Back in 2004-ish, AMD was predicting 6ps inverter delays in 65nm process.
At these edge speeds, one needs to model Amperé's law in simulation (above
and beyond simple skin effect stuff).
<
But to temper expectations: If you took the current fast chips and snapped
your finger to make logic delays take zero time, the chips would not reach
2× current frequencies. Wire is the problem, not logic.
<
But perhaps we will soon get cell phones which can also be used as microwave
ovens.
>
> Laser bursts drive fastest-ever logic gates 2022-May-11
> https://phys.org/news/2022-05-laser-fastest-ever-logic-gates.html
>
> [open access]
> Light-field control of real and virtual charge carriers, 2022
> https://arxiv.org/abs/2203.03509

Re: Petahertz, femtosecond logic gates

<t5hbkl$qos$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25209&group=comp.arch#25209

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Wed, 11 May 2022 16:58:34 -0500
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <t5hbkl$qos$1@dont-email.me>
References: <K1VeK.7$XhAf.6@fx39.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 May 2022 21:59:49 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f31823a7ff4141da8c06d2342394f1d9";
logging-data="27420"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/pJgZlZjJspZ3UP2KRtUpY"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:MOQFv8bQuLVSggTm8xnTQfBictc=
In-Reply-To: <K1VeK.7$XhAf.6@fx39.iad>
Content-Language: en-US
 by: BGB - Wed, 11 May 2022 21:58 UTC

On 5/11/2022 3:30 PM, EricP wrote:
> A group has created petahertz (10^15 Hz), femtosecond logic gates.
> In a lab, and it needs lasers to drive it,
> and it's really more like 10's of femtoseconds,
> but still... neet.
>
> Laser bursts drive fastest-ever logic gates 2022-May-11
> https://phys.org/news/2022-05-laser-fastest-ever-logic-gates.html
>
> [open access]
> Light-field control of real and virtual charge carriers, 2022
> https://arxiv.org/abs/2203.03509
>
>

I have my doubts here as to how useful this could be "in general".

Even if one can make the laser pulses fast, and the switching fast,
unless the whole system is very compact, it seems like things like wire
propagation delays and similar would still ruin ones' day.

Say, much past a few GHz, one can no longer as easily switch a wire
between on and off states, and the bits can no longer be assumed to
travel "instantly" from one end to the wire to the other.

So, switch the state of the wire, and some-odd picoseconds later, the
other end still hasn't switched yet.

Likewise, one ends up needing to drive the pulses at one end of the wire
at a higher voltage than they arrive at the other end, because
apparently the capacitance of the wire absorbs a lot of the input
voltage when switching direction, ...

Move to femtosecond timescales, and these sorts of issues are just going
to get worse...

I am not sure how quickly people would jump into designing their digital
logic around the propagation delays within the circuit.

Then again, does bring up one possibility that I had overlooked in one
of my Sci-Fi stories, namely that rather than going over to massively
parallel RAM interfaces, people started using a bunch of RAM modules
effectively connected by a large number of serial links.

....

So, say, each RAM module has a TX/RX line and uses 8/10b, ... So then
one no longer needs to care as much about clock-skew or similar.

Then one sends a command-byte and some-odd bytes (say, 8B or 16B) of
burst data (for writes), or listens for a response (for reads). Probably
still using row/column addressing.

Then each RAM module is accessed in parallel by the CPU.
Say, it performs a read from 64 such RAM modules all at the same time.

Well, or maybe instead of bit-serial, they use QAM signaling?...

Then again, I guess a big factor is how cheaply this could be done, one
other premise of the story was that this is a world where Moore's law
basically died in the 2020s. So their transistor density and similar
isn't that much higher than it is already, and it is more a question of
cost-effectiveness. Say, while faster technologies could exist, it never
being cost-effective to move away from the CMOS process; pretty much
everything that happens, how it happens, etc, being driven by the
"universal truth" of "how it effects the bottom line", at least until
sentient AIs start having it their way, but even AIs are still somewhat
limited by these sorts of constraints, much as it is the primary
determining factor as to the lives and relationships of the people
living within this system, ... However, the AIs differ slightly from the
humans characters in that their decisions are often more driven by
things like existential concerns and similar, rather than necessarily
seeing the world in terms of profit for profit sake (so, say, decision
making from a sentient AI is more of a wildcard, and thus considered
more dangerous, compared with humans, who can more be more reliably
expected to use their interactions and relationships with others in a
way to minimax their own self-interests and similar, which in turn tends
to help uphold the existing status quo).

....

Re: Petahertz, femtosecond logic gates

<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25210&group=comp.arch#25210

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:5008:b0:45b:82:6ef with SMTP id jo8-20020a056214500800b0045b008206efmr18397694qvb.87.1652307847206;
Wed, 11 May 2022 15:24:07 -0700 (PDT)
X-Received: by 2002:a05:6870:b383:b0:e9:2fea:2148 with SMTP id
w3-20020a056870b38300b000e92fea2148mr3782302oap.103.1652307846971; Wed, 11
May 2022 15:24:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 11 May 2022 15:24:06 -0700 (PDT)
In-Reply-To: <t5hbkl$qos$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:cd3e:bc77:963e:ac4c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:cd3e:bc77:963e:ac4c
References: <K1VeK.7$XhAf.6@fx39.iad> <t5hbkl$qos$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
Subject: Re: Petahertz, femtosecond logic gates
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 11 May 2022 22:24:07 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Wed, 11 May 2022 22:24 UTC

On Wednesday, May 11, 2022 at 4:59:52 PM UTC-5, BGB wrote:
> On 5/11/2022 3:30 PM, EricP wrote:
> > A group has created petahertz (10^15 Hz), femtosecond logic gates.
> > In a lab, and it needs lasers to drive it,
> > and it's really more like 10's of femtoseconds,
> > but still... neet.
> >
> > Laser bursts drive fastest-ever logic gates 2022-May-11
> > https://phys.org/news/2022-05-laser-fastest-ever-logic-gates.html
> >
> > [open access]
> > Light-field control of real and virtual charge carriers, 2022
> > https://arxiv.org/abs/2203.03509
> >
> >
> I have my doubts here as to how useful this could be "in general".
>
>
> Even if one can make the laser pulses fast, and the switching fast,
> unless the whole system is very compact, it seems like things like wire
> propagation delays and similar would still ruin ones' day.
>
>
> Say, much past a few GHz, one can no longer as easily switch a wire
> between on and off states, and the bits can no longer be assumed to
> travel "instantly" from one end to the wire to the other.
<
There was significant and measurable wire delay at 20 MHz............
>
> So, switch the state of the wire, and some-odd picoseconds later, the
> other end still hasn't switched yet.
>
> Likewise, one ends up needing to drive the pulses at one end of the wire
> at a higher voltage than they arrive at the other end, because
> apparently the capacitance of the wire absorbs a lot of the input
> voltage when switching direction, ...
<
Capacitance (and resistance) only slow the edge speed (FET logic) by
themselves, they do not eat voltage.
>
>
> Move to femtosecond timescales, and these sorts of issues are just going
> to get worse...
<
Yes, wire is the problem.
>
> I am not sure how quickly people would jump into designing their digital
> logic around the propagation delays within the circuit.
>
>
>
> Then again, does bring up one possibility that I had overlooked in one
> of my Sci-Fi stories, namely that rather than going over to massively
> parallel RAM interfaces, people started using a bunch of RAM modules
> effectively connected by a large number of serial links.
<
Like mercury delay lines ?
>
> ...
>
> So, say, each RAM module has a TX/RX line and uses 8/10b, ... So then
> one no longer needs to care as much about clock-skew or similar.
>
> Then one sends a command-byte and some-odd bytes (say, 8B or 16B) of
> burst data (for writes), or listens for a response (for reads). Probably
> still using row/column addressing.
>
> Then each RAM module is accessed in parallel by the CPU.
> Say, it performs a read from 64 such RAM modules all at the same time.
<
Sounds like a great way to consume a lot of power........
>
> Well, or maybe instead of bit-serial, they use QAM signaling?...
>
PAM4
>

Re: Petahertz, femtosecond logic gates

<t5hijc$4mr$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25211&group=comp.arch#25211

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Wed, 11 May 2022 18:57:20 -0500
Organization: A noiseless patient Spider
Lines: 202
Message-ID: <t5hijc$4mr$1@dont-email.me>
References: <K1VeK.7$XhAf.6@fx39.iad> <t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 May 2022 23:58:36 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2e9d2cc2fcbb135808be39a64bf51e4c";
logging-data="4827"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/M5+w7ZQgj6ZRbcsPfcDXi"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:Z3kfetzo56RsDqgZtR/YeSbXUu8=
In-Reply-To: <d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
Content-Language: en-US
 by: BGB - Wed, 11 May 2022 23:57 UTC

On 5/11/2022 5:24 PM, MitchAlsup wrote:
> On Wednesday, May 11, 2022 at 4:59:52 PM UTC-5, BGB wrote:
>> On 5/11/2022 3:30 PM, EricP wrote:
>>> A group has created petahertz (10^15 Hz), femtosecond logic gates.
>>> In a lab, and it needs lasers to drive it,
>>> and it's really more like 10's of femtoseconds,
>>> but still... neet.
>>>
>>> Laser bursts drive fastest-ever logic gates 2022-May-11
>>> https://phys.org/news/2022-05-laser-fastest-ever-logic-gates.html
>>>
>>> [open access]
>>> Light-field control of real and virtual charge carriers, 2022
>>> https://arxiv.org/abs/2203.03509
>>>
>>>
>> I have my doubts here as to how useful this could be "in general".
>>
>>
>> Even if one can make the laser pulses fast, and the switching fast,
>> unless the whole system is very compact, it seems like things like wire
>> propagation delays and similar would still ruin ones' day.
>>
>>
>> Say, much past a few GHz, one can no longer as easily switch a wire
>> between on and off states, and the bits can no longer be assumed to
>> travel "instantly" from one end to the wire to the other.
> <
> There was significant and measurable wire delay at 20 MHz............

Possibly.

When hand wiring stuff, it seems like a lot of MHz level stuff, some
amount of variability is acceptable.

Though, one might still need to care about the wires being approximately
the same length for things like SPI links.

But, other than this, one can just sorta pretend that the bits move
instantly.

Had noted things, like seemingly using an SDcard extender cable means I
can no longer clock the SDcard at 25 MHz. Still works OK at 13 MHz
though, and 16MHz sorta works but is unreliable.

Not sure exact reason, the extender is basically a small PCB (around the
same size as a MicroSD), which connects up to around 8 inches of ribbon
cable, then through what appears to be repurposed USB-A connectors
(seemingly permanently fused together somehow), onto another PCB (inside
of a plastic shell), with a full-size SDcard slot. Mostly used because
full-sized SDcards are easier to handle.

Would have preferred had they just stuck a full-sized SDcard slot onto
the FPGA board, but alas...

Had also noted before, mostly when wiring up things like motor
controllers, that one needs to avoid things like stepper-motor or power
wires getting too close to signal wires (such as limit-switch or
step/direction wires), as "noise" from the motor wires was enough to
adversely effect the signal wires.

Could sorta reduce this issue by putting aluminum foil (or foil tape) on
some of the offending wires and then connecting the foil to ground (with
a few "safety resistors" in the mix). This seemingly almost makes a case
for "maybe it would be better if these stepper motors were using
shielded cabling?..." (say, with the shielding connected up to the motor
housing, which is then presumably in contact with ground).

But, of the stepper motors that come with cables already on them, pretty
much no one seems to do this.

Can also sorta hack over it by putting capacitors on inputs, or
filtering signals through a 2n3904 transistor or similar before using
them (such as for limit switches), or through a LED+photodiode, ...
(Mostly because the wire-to-wire interference is much less able to
"flip" the state of a LED or 2n3904).

Well, and/or throwing 1uF or 4.7uF capacitors or similar at the problem
(this seems to be a bit more hit/miss though).

Well, much like a machine I had built, where I ended up needing to hook
up an old soldering iron to serve as a ballast resistor for the power
supply, because otherwise (with little or no load) the voltage would
spike to unsafe levels (say, it only stays at 48V when pulling at least
a few watts, otherwise it might jump up to 80 or 100 volts).

Well, and, not like I had a 500 ohm 10W resistor or something (and it
would have been "kinda impractical" with 1/2W resistors, but an old 25W
soldering iron just so happened to be about the right resistance for the
required ballast).

Nevermind if it doesn't exactly seem like they couldn't have just
included a big ceramic resistor inside the power supply or something?...

(Looks like the going price for these on Amazon being around $1 each; I
guess I could buy some if this turns into a recurring issue).

....

>>
>> So, switch the state of the wire, and some-odd picoseconds later, the
>> other end still hasn't switched yet.
>>
>> Likewise, one ends up needing to drive the pulses at one end of the wire
>> at a higher voltage than they arrive at the other end, because
>> apparently the capacitance of the wire absorbs a lot of the input
>> voltage when switching direction, ...
> <
> Capacitance (and resistance) only slow the edge speed (FET logic) by
> themselves, they do not eat voltage.

AFAIK, the issue is that the edges (in fast signaling) can happen fast
enough that the capacitance in the wire eats the signal voltage (by the
time the wire has "charged up" in one direction, the bit has already
flipped in the other).

Apparently, the driver electronics will then drive an increased voltage,
but then drop towards the nominal voltage if there are no bit-flips.
Apparently also they use 8/10b to try to keep the wire DC biased near
zero, as this also helps with signaling (helps keep signal bits from
getting eaten by residual voltage in the wire).

But, at lower speeds, one doesn't need to care as much.

>>
>>
>> Move to femtosecond timescales, and these sorts of issues are just going
>> to get worse...
> <
> Yes, wire is the problem.
>>
>> I am not sure how quickly people would jump into designing their digital
>> logic around the propagation delays within the circuit.
>>
>>
>>
>> Then again, does bring up one possibility that I had overlooked in one
>> of my Sci-Fi stories, namely that rather than going over to massively
>> parallel RAM interfaces, people started using a bunch of RAM modules
>> effectively connected by a large number of serial links.
> <
> Like mercury delay lines ?

I wasn't thinking like delay lines, more just like each RAM module has a
serial connection or similar, and there are a whole lot of these modules
running in parallel.

>>
>> ...
>>
>> So, say, each RAM module has a TX/RX line and uses 8/10b, ... So then
>> one no longer needs to care as much about clock-skew or similar.
>>
>> Then one sends a command-byte and some-odd bytes (say, 8B or 16B) of
>> burst data (for writes), or listens for a response (for reads). Probably
>> still using row/column addressing.
>>
>> Then each RAM module is accessed in parallel by the CPU.
>> Say, it performs a read from 64 such RAM modules all at the same time.
> <
> Sounds like a great way to consume a lot of power........

Could be.

It one ran 64 modules at a time, and transferred 8B to/from each
sub-module, this would be 64B.

I guess if one did 20Gbps to each module, this would be ~ 1280 Gbps (or
~ 160 GB/s).

This would need around 128 differential data pins, plus some pins for DC
power.

But, yeah, would likely be less energy efficient than using a larger
number of slower connections (as in more traditional DDR modules).

>>
>> Well, or maybe instead of bit-serial, they use QAM signaling?...
>>
> PAM4

Looks, yeah, this could work well...

Makes a lot more sense for a point-to-point serial links than QAM at least.

Also avoids DC biasing issues, and is (implicitly) self-clocking.

Re: Petahertz, femtosecond logic gates

<89d45367-b1c3-4de2-9e19-99e7a0221d55n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25212&group=comp.arch#25212

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:188a:b0:2f3:f4a8:ac9b with SMTP id v10-20020a05622a188a00b002f3f4a8ac9bmr3505466qtc.396.1652317790325;
Wed, 11 May 2022 18:09:50 -0700 (PDT)
X-Received: by 2002:a05:6870:969e:b0:ed:9e77:8eba with SMTP id
o30-20020a056870969e00b000ed9e778ebamr4497613oaq.269.1652317790088; Wed, 11
May 2022 18:09:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 11 May 2022 18:09:49 -0700 (PDT)
In-Reply-To: <t5hijc$4mr$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:cd3e:bc77:963e:ac4c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:cd3e:bc77:963e:ac4c
References: <K1VeK.7$XhAf.6@fx39.iad> <t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com> <t5hijc$4mr$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <89d45367-b1c3-4de2-9e19-99e7a0221d55n@googlegroups.com>
Subject: Re: Petahertz, femtosecond logic gates
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 12 May 2022 01:09:50 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 5840
 by: MitchAlsup - Thu, 12 May 2022 01:09 UTC

On Wednesday, May 11, 2022 at 6:58:40 PM UTC-5, BGB wrote:
> On 5/11/2022 5:24 PM, MitchAlsup wrote:

> >> Say, much past a few GHz, one can no longer as easily switch a wire
> >> between on and off states, and the bits can no longer be assumed to
> >> travel "instantly" from one end to the wire to the other.
> > <
> > There was significant and measurable wire delay at 20 MHz............
> Possibly.
>
> When hand wiring stuff, it seems like a lot of MHz level stuff, some
> amount of variability is acceptable.
<
With a 50ns clock, 5ns was in the staging flip-flops, 3ns in clock jitter and skew
leaving 42ns of logic. One could get 400 microns in a single clock on unbuffered
wire--this was the width of the chip.
<
With a 1ns clock, 100ps was in the flip-flops, 100ps was in the clock jitter and
skew, leaving only 800ps for logic. One could get 5 microns in a single clock
on buffered wires--this was twice the width of the data path.
>
> Though, one might still need to care about the wires being approximately
> the same length for things like SPI links.
>
> But, other than this, one can just sorta pretend that the bits move
> instantly.
<
Maybe in an FPGA.
>
Modern chips (5GHz) can't even "jump" over more than a 64-bit data path in a
single cycle.
>
> Had also noted before, mostly when wiring up things like motor
> controllers, that one needs to avoid things like stepper-motor or power
> wires getting too close to signal wires (such as limit-switch or
> step/direction wires), as "noise" from the motor wires was enough to
> adversely effect the signal wires.
<
Higher speed chips use a grid of wires at all metal layers. One layer
would run N-S and be composed of ...GND S1 S2 S3 PWR S4 S5 S6 GND...
When signals were "really important" you would remove S2 and S5 so
that the 4 remaining wires had stable reference voltages (and impeadence)
>
> Could sorta reduce this issue by putting aluminum foil (or foil tape) on
> some of the offending wires and then connecting the foil to ground (with
> a few "safety resistors" in the mix). This seemingly almost makes a case
> for "maybe it would be better if these stepper motors were using
> shielded cabling?..." (say, with the shielding connected up to the motor
> housing, which is then presumably in contact with ground).
<
All unused wire slots are converted into 1 of 3 things::
a) More capacitance (by getting attached to unused polysilicon)
b) more Gnd
c) more Pwr

> > Capacitance (and resistance) only slow the edge speed (FET logic) by
> > themselves, they do not eat voltage.
<
> AFAIK, the issue is that the edges (in fast signaling) can happen fast
> enough that the capacitance in the wire eats the signal voltage (by the
> time the wire has "charged up" in one direction, the bit has already
> flipped in the other).
<
Yes, but this is edge speed deterioration not voltage deterioration.
>

> > <
> > Like mercury delay lines ?
> I wasn't thinking like delay lines, more just like each RAM module has a
> serial connection or similar, and there are a whole lot of these modules
> running in parallel.
> >>
> >> ...
> >>
> >> So, say, each RAM module has a TX/RX line and uses 8/10b, ... So then
> >> one no longer needs to care as much about clock-skew or similar.
> >>
> >> Then one sends a command-byte and some-odd bytes (say, 8B or 16B) of
> >> burst data (for writes), or listens for a response (for reads). Probably
> >> still using row/column addressing.
> >>
> >> Then each RAM module is accessed in parallel by the CPU.
> >> Say, it performs a read from 64 such RAM modules all at the same time.
> > <
> > Sounds like a great way to consume a lot of power........
> Could be.
>
> It one ran 64 modules at a time, and transferred 8B to/from each
> sub-module, this would be 64B.
>
> I guess if one did 20Gbps to each module, this would be ~ 1280 Gbps (or
> ~ 160 GB/s).
>
> This would need around 128 differential data pins, plus some pins for DC
> power.
<
Pwr+Gnd pins should be close to 1/3rd of all the pins.
>
>
> But, yeah, would likely be less energy efficient than using a larger
> number of slower connections (as in more traditional DDR modules).
> >>
> >> Well, or maybe instead of bit-serial, they use QAM signaling?...
> >>
> > PAM4
> Looks, yeah, this could work well...
>
> Makes a lot more sense for a point-to-point serial links than QAM at least.
>
> Also avoids DC biasing issues, and is (implicitly) self-clocking.

Re: Petahertz, femtosecond logic gates

<t5i0rn$h1l$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25213&group=comp.arch#25213

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Wed, 11 May 2022 23:00:22 -0500
Organization: A noiseless patient Spider
Lines: 286
Message-ID: <t5i0rn$h1l$1@dont-email.me>
References: <K1VeK.7$XhAf.6@fx39.iad> <t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<t5hijc$4mr$1@dont-email.me>
<89d45367-b1c3-4de2-9e19-99e7a0221d55n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 May 2022 04:01:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dbc53fa5058c2db5d642f16029d50020";
logging-data="17461"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190BYbt9ygFBJwdvAafm/jF"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:QHRlxegEmfs2rlajhlRERj1lF8g=
In-Reply-To: <89d45367-b1c3-4de2-9e19-99e7a0221d55n@googlegroups.com>
Content-Language: en-US
 by: BGB - Thu, 12 May 2022 04:00 UTC

On 5/11/2022 8:09 PM, MitchAlsup wrote:
> On Wednesday, May 11, 2022 at 6:58:40 PM UTC-5, BGB wrote:
>> On 5/11/2022 5:24 PM, MitchAlsup wrote:
>
>>>> Say, much past a few GHz, one can no longer as easily switch a wire
>>>> between on and off states, and the bits can no longer be assumed to
>>>> travel "instantly" from one end to the wire to the other.
>>> <
>>> There was significant and measurable wire delay at 20 MHz............
>> Possibly.
>>
>> When hand wiring stuff, it seems like a lot of MHz level stuff, some
>> amount of variability is acceptable.
> <
> With a 50ns clock, 5ns was in the staging flip-flops, 3ns in clock jitter and skew
> leaving 42ns of logic. One could get 400 microns in a single clock on unbuffered
> wire--this was the width of the chip.
> <
> With a 1ns clock, 100ps was in the flip-flops, 100ps was in the clock jitter and
> skew, leaving only 800ps for logic. One could get 5 microns in a single clock
> on buffered wires--this was twice the width of the data path.

I was more meaning with things like running MHz on a bread-board or over
repurposed 24 AWG solid-core wire from CAT5e wires or similar.

One can almost get along assuming that signals move instantly, but wire
lengths need to be kept even roughly even for data wiring.

Say, if one has one wire being 2 inch, and another 5 inch, and they are
supposed to stay in sync, then stuff might get mangled.

Things may also decide to work or not work depending on the distance
between the holes on the breadboard. Have also noted that repurposed 24
AWG wire works pretty well here (for low-current power transmission, and
for signal transmission, it seems to be pretty well behaved compared
with some other types of wire; such as 24 AWG stranded wire, ...).

Well, and for sending power over a breadboard, it tends to drops pretty
rapidly with distance (so for more than a few mA, the rails at the
top/bottom of the board are often borderline useless unless one runs
some bits of 24 AWG or similar from one end to the other, or next to any
"higher load" connections).

Though, this has been pretty much all for things in the low MHz range
(such as wiring up stuff over via a SPI interface). Or, multiple devices
with shared MOSI/MISO/CLK lines, and separate CS lines.

Then say, one needs to make sure that for each point-to-point
connection, the various wires (MOSI/MISO/CLK) are approximately the same
length.

Even if at low speeds (say, 5 or 10 MHz), it seems intuitively like one
could ignore this stuff and just casually "free hand it" with whatever
random bits of wire they have handy at the moment.

Communication with something like a motor driver is generally kHz, so
one can basically "do whatever" with this (apart from the issue of
power-carrying wires messing stuff up).

For limit switches, these are plain DC, but interference might cause the
input bit to flip randomly.

For this, a simple way to wire it up might be to have a pull-up resistor
(say, to the +3.3v rail), and a 4.7uF cap (relative to 0v), connected
via a resistor to a normally-open switch (other end connected to 0v).
Hitting the switch then pulls the signal to 0v.

Say, one uses a 1kOhm resistor for the switch, and some 10kOhm or 25kOhm
or similar resistors as pull-ups.

But, doing it this way, if the wires cross paths (such as a motor wire
leaning against a limit switch wire, or even coming within a close
proximity). Then the microcontroller might start see the bit value read
from the limit switch "freaking out".

So, instead of connecting the limit switch directly to the
microcontroller, an option is to instead connect it to the Base of a
2n3904 (Emitter to GND, collector via a pull-up resistor to the 3.3v
rail), then the transistors collector pin is used as the input to the
microcontroller.

Not entirely sure the specifics, but a transistor or similar here seems
able to mostly filter out the noise.

Say, in this scenario, the crossing-path wires are 48V and running
between a NEMA23 stepper via a micro-stepping driver.

Then these sorts of motor wires been a major noise source for anything
they cross paths with.

Or, at least, this is how it seemed to be working in a past project of mine.

>>
>> Though, one might still need to care about the wires being approximately
>> the same length for things like SPI links.
>>
>> But, other than this, one can just sorta pretend that the bits move
>> instantly.
> <
> Maybe in an FPGA.

Possibly, for FPGA programming, it either gets to where it needs to go
within the cycle, or timing fails.

It is pretty much all abstracted away behind the Verilog.

But, yeah, I meant in external wiring as well.

Not sure how actually EE types deal with stuff, but in any case they are
presumably not just sticking a bunch of crap onto solderless breadboards
and/or perfboard and hoping it works acceptably.

Though, between these two, perfboard is a lot better in many regards if
compared with a breadboard.

>>
> Modern chips (5GHz) can't even "jump" over more than a 64-bit data path in a
> single cycle.
>>
>> Had also noted before, mostly when wiring up things like motor
>> controllers, that one needs to avoid things like stepper-motor or power
>> wires getting too close to signal wires (such as limit-switch or
>> step/direction wires), as "noise" from the motor wires was enough to
>> adversely effect the signal wires.
> <
> Higher speed chips use a grid of wires at all metal layers. One layer
> would run N-S and be composed of ...GND S1 S2 S3 PWR S4 S5 S6 GND...
> When signals were "really important" you would remove S2 and S5 so
> that the 4 remaining wires had stable reference voltages (and impeadence)

OK.

Apparently, people also do similar things with PCBs, putting ground
traces between signal traces.

For free-spanning wires, one is mostly left with options like shielded
cabling and/or putting foil tape on stuff. But, wrapping a cables in
foil tape is kinda tacky.

>>
>> Could sorta reduce this issue by putting aluminum foil (or foil tape) on
>> some of the offending wires and then connecting the foil to ground (with
>> a few "safety resistors" in the mix). This seemingly almost makes a case
>> for "maybe it would be better if these stepper motors were using
>> shielded cabling?..." (say, with the shielding connected up to the motor
>> housing, which is then presumably in contact with ground).
> <
> All unused wire slots are converted into 1 of 3 things::
> a) More capacitance (by getting attached to unused polysilicon)
> b) more Gnd
> c) more Pwr
>

OK.

>>> Capacitance (and resistance) only slow the edge speed (FET logic) by
>>> themselves, they do not eat voltage.
> <
>> AFAIK, the issue is that the edges (in fast signaling) can happen fast
>> enough that the capacitance in the wire eats the signal voltage (by the
>> time the wire has "charged up" in one direction, the bit has already
>> flipped in the other).
> <
> Yes, but this is edge speed deterioration not voltage deterioration.

OK.

>>
>
>>> <
>>> Like mercury delay lines ?
>> I wasn't thinking like delay lines, more just like each RAM module has a
>> serial connection or similar, and there are a whole lot of these modules
>> running in parallel.
>>>>
>>>> ...
>>>>
>>>> So, say, each RAM module has a TX/RX line and uses 8/10b, ... So then
>>>> one no longer needs to care as much about clock-skew or similar.
>>>>
>>>> Then one sends a command-byte and some-odd bytes (say, 8B or 16B) of
>>>> burst data (for writes), or listens for a response (for reads). Probably
>>>> still using row/column addressing.
>>>>
>>>> Then each RAM module is accessed in parallel by the CPU.
>>>> Say, it performs a read from 64 such RAM modules all at the same time.
>>> <
>>> Sounds like a great way to consume a lot of power........
>> Could be.
>>
>> It one ran 64 modules at a time, and transferred 8B to/from each
>> sub-module, this would be 64B.
>>
>> I guess if one did 20Gbps to each module, this would be ~ 1280 Gbps (or
>> ~ 160 GB/s).
>>
>> This would need around 128 differential data pins, plus some pins for DC
>> power.
> <
> Pwr+Gnd pins should be close to 1/3rd of all the pins.

I am guessing for signaling reasons, rather than for current-carrying
capacity?...

I guess, maybe one could devise a RAM chip interface where all the pin
connections were tiny waveguides rather than pad/trace connections.


Click here to read the complete article
Re: Petahertz, femtosecond logic gates

<165236809836.5231.10460308342880170620@media.vsta.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25218&group=comp.arch#25218

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Thu, 12 May 2022 08:08:18 -0700
Lines: 15
Message-ID: <165236809836.5231.10460308342880170620@media.vsta.org>
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad> <t5hbkl$qos$1@dont-email.me> <d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
X-Trace: individual.net FwOAx9la88ygWMGQ+oU4wgAdZVbo/KM6GoQSWZp/S6/IN7BgNg
X-Orig-Path: media
Cancel-Lock: sha1:P44Ys8Km+1Rxsbj5DFr5fgFNHWw=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Thu, 12 May 2022 15:08 UTC

BGB <cr88192@gmail.com> writes:
> When hand wiring stuff, it seems like a lot of MHz level stuff, some
> amount of variability is acceptable.

I remember my eyes widening with astonishment, the first time I opened up a
SuperPET 9000 and saw how they wired the 6809 companion processor into the
unit.

https://vintagecomputer.ca/wp-content/uploads/2015/10/SuperPET-internals-close-up-1024x576.jpg

(Yes, those are CPU signals running up that wiring harness.)

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: Petahertz, femtosecond logic gates

<t5jogv$pnf$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25222&group=comp.arch#25222

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Thu, 12 May 2022 14:50:42 -0500
Organization: A noiseless patient Spider
Lines: 249
Message-ID: <t5jogv$pnf$1@dont-email.me>
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad>
<t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<165236809836.5231.10460308342880170620@media.vsta.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 May 2022 19:51:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dbc53fa5058c2db5d642f16029d50020";
logging-data="26351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+s+YnPNWIWVXiF/BzSYcbz"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:xl9Ua1tefpjavowUq7tqppICx3s=
In-Reply-To: <165236809836.5231.10460308342880170620@media.vsta.org>
Content-Language: en-US
 by: BGB - Thu, 12 May 2022 19:50 UTC

On 5/12/2022 10:08 AM, Andy Valencia wrote:
> BGB <cr88192@gmail.com> writes:
>> When hand wiring stuff, it seems like a lot of MHz level stuff, some
>> amount of variability is acceptable.
>
> I remember my eyes widening with astonishment, the first time I opened up a
> SuperPET 9000 and saw how they wired the 6809 companion processor into the
> unit.
>
> https://vintagecomputer.ca/wp-content/uploads/2015/10/SuperPET-internals-close-up-1024x576.jpg
>
> (Yes, those are CPU signals running up that wiring harness.)
>

Yeah. Free wires work OK so long as they are roughly length matched.
Like, near the end of IDE/PATA's lifespan, there was a thing for a
little while of IDE cables where, instead of a flat ribbon cable, they
would have a bundle of loose wires inside of a woven sleeving or similar
(with PATA cable ends).

Typically they were typically running 66 MHz over these cables IIRC.

Less sure about length limits though, say:
If one were to make a 48 inch IDE cable, if it still would have worked.

At this length, a 66 MHz clock-pulse should be able to make it from one
end to the cable to the other and back.

If one doubles the length to 96 inches, then a 66 MHz clock pulse could
no longer round-trip over the length of the cable.

....

Seems like one could implement a delay-line memory also by having a
fairly long loop of wire.

At 50MHz, a 1 bit would travel 236 inches per clock pulse (say, we call
it 20ft for simplicity). Say, one buys a 1500ft spool of 30 AWG magnet
wire, could fit ~ 75 bits in the spool (or a little more, considering
that "the speed of light in a copper wire" is actually a little slower
than this).

Could also fit more bits by running it at 75 or 100 MHz.

Would likely need to re-wind the spool though to add foil separators or
similar though (to function as shielding), otherwise it seems like
interference within the spool would garble the bits before they get from
one end to the other.

....

But, as noted, at MHz speeds (say, under 100 MHz), the pulses travel
fast enough that, for free-hand wiring, one can mostly ignore the
propagation delays in most cases.

Now as to why I seemingly can't get 25 MHz over an 8 inch SDcard
extender, this will remain as a mystery.

Granted, my logic does drive all of the pins in sync, it is possible
that delaying the pins relative to each other, say:
Update MOSI at 0ns
Update CLK at 20ns
Capture MISO at 40ns

Could potentially be more reliable (and maybe able to reach the
theoretical 25MHz limit for an SDcard in SPI mode?...).

Dunno, this could maybe get the SDcard up to around 3 MB/s (in theory).

At this point, I am almost better off though looking into trying to come
up with a redesigned RAM controller based around using the SERDES
interface, since RAM IO speed is one of the major (remaining)
bottlenecks at this point (programs still tending to spend a majority of
their clock-cycles waiting for memory, *1).

Though, only around 30% of this is actual DRAM stalls. Around 10% is due
to L1 misses, and around 20% due to interlock scheduling issues (*2).

Looks like, if I use SERDES, then running the DDR controller logic at
50MHz should be able to drive the RAM at 200MHz.

This would result in a big blob of FPGA specific Verilog though
(instancing the ISERDES2 and OSERDES2 modules, apparently for nearly
every pin).

And, opposed to the front-end of the RAM controller using 16-bit data
signals, it would use 128-bit signals.

....

Though, at this point, it starts to seem like less effort to maybe just
give in and try to use AXI and MIG instead?...

*1: Say, if one runs Doom in a Verilog simulation with 100% L2 hit rate,
it basically runs pegged at the 32 fps framerate limiter (vs the
typically somewhat lower numbers I get when it needs to wait for
external DRAM accesses and similar).

Actually, Doom and similar could maybe also be made faster now if I were
to exploit that I am using a RAM backed VRAM buffer (and drawing
directly to the backing buffer rather than going through the MMIO
interface).

It is also probable maybe I should move the screen-blit logic into
TestKern rather than having the programs do the "blit to VRAM" part.
But, this partly turns it into an API design issue (would need to come
up with a sensible API and abstractions).

Something like doing a mockup of GDI or X11 abstractions would "kinda
suck" here.

But, a bare function for "Hey, copy this RGB555 buffer into VRAM" seems
a bit too low-level.

APIs like SDL provided API's to get a pointer to a buffer to draw into,
with a Lock/Unlock/Swap interface. Not necessarily sure I want to go
this route either.

In GDI abstractions, one would creates a window, and a DIB bitmap, then
draws the DIB bitmap into the window (say, with the framebuffer pointing
to a location following the BITMAPINFOHEADER structure in memory).

It is possible I could do something vaguely similar, likely having the
BITMAPINFOHEADER and image-data pointer as separate pointers, ...

Or, say:
BITMAPINFOHEADER *bmFbuf; //defines pixel format and resolution
WORD *pwFbuf;
HDC hScreen;
...
TkBlitDIBToScreen(hScreen, 0, 0, bmFbuf, pwFbuf);

Though, for drawing to bare VRAM, probably hScreen would be NULL or
something (with the 0, 0 here specifying the origin to draw to).

And (for a fast blit) the format defined in bmFbuf would need to match
the pixel format and resolution of the screen, eg:
biWidth=320, biHeight=200, biBitCount=15, biCompression=BI_RGB, ...

TBD if how I deal with orientation:
Assume (like most programs) that 0,0 is the upper left corner;
Assume (like GDI) that 0,0 is the lower-left corner;
Or (also like GDI), that the sign of biHeight encodes the orientation:
biHeight>0: Origin is lower-left
biHeight<0: Origin is upper-left

While GDI style abstractions kinda suck, they are at least "mildly less
terrible" (IMHO) than the X11 API abstractions (and would not preclude
an X11 API style wrapper or similar).

For the 640x400 screen mode, could consider using UTX1 or UTX2 as the
pixel format. In this mode, the fast case would require the blit to be
aligned to a multiple of 8 pixels. Both RGB555 drawing, and misaligned
blits, would require effectively unpacking to RGB555, rebuilding the
blocks, and feeding them through a color-cell encoder (not exactly optimal).

For something like a GUI, it would likely make more sense to keep the
off-screen framebuffer as 640x400 RGB555, with a bitmap of "dirty"
blocks, and then periodically re-encode any dirty blocks to color-cell
for the screen update. This would lead to a slow case regarding a
program regularly redrawing a large window though, but for a GUI this
would likely be unavoidable.

Note that even if I did expand the HW framebuffer to 640x400 RGB555
(relying on it being RAM backed), I still don't have enough RAM
bandwidth to pull this off effectively (with a 60Hz refresh, the usable
bandwidth is still only really sufficient for 128K of VRAM).

The UTX2 encoding isn't an exact match for the format used in VRAM, but
is closer-enough that it can be munged (4 blocks at a time):
Read Blocks A/B (Row 1)
Read Blocks C/D (Row 2)
Repack Color Bits for A and B (into Q0)
MOVLL Ra, Rb, Q0
Q0=(Q0&0x00007FFF00007FFF)|((Q0>>1)&0x3FFF80003FFF8000)|MODE;
Repack Color Bits for C and D (into Q1)
Same as above.
Pack high bits from A/B into a QWORD(Q2) (MOVHH op)
Pack high bits from C/D into a QWORD(Q3) (MOVHH op)
Store Q0, Q1, Q2, and Q3 to VRAM block.

It is possible I could define a biCompression mode for raw 256-bit VRAM
blocks as well (with the blit requiring an 8-pixel alignment in this
case for 640x400, or 4-pixel for 320x200).

Where it can be noted that in the 320x200 hi-color mode, it is still
using 256-bit VRAM blocks, just each is logically interpreted as 4x4
RGB555 pixels rather than 8x8, and are organized as an 80x50 buffer (an
80x50 text mode also technically exists; where the "text mode" is still
using 256-bit color-cells, and could technically also do graphics,
because it is "all the same stuff" as far as the HW is concerned in this
case; though text-mode only uses the low 128 bits of each VRAM cell).

The blit process for copying a hi-color framebuffer to VRAM effectively
repacking the pixels into the format that the display hardware uses.

Would still need to think some on this...

*2: This one is theoretically more of a software/compiler issue, namely
trying to use a value directly after loading it.

One can theoretically sorta work around this in C:
t0=foo->x;
t1=bar[1];
...
t2=t0+t1;

But, this isn't really the way a lot of code is written, and ideally the
compiler would do a better job about this sort of thing.

This could maybe be hacked around at the 3AC level rather than
necessarily leaving it solely to the codegen and WEXifier to try to deal
with. Say, by having logic that tries to shuffle 3AC ops around such
that an array or struct slot load isn't immediately followed by an
operation which operates on the loaded value (if possible).


Click here to read the complete article
Re: Petahertz, femtosecond logic gates

<688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25226&group=comp.arch#25226

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:2b09:b0:45b:59b:5df6 with SMTP id jx9-20020a0562142b0900b0045b059b5df6mr2766951qvb.22.1652408701420;
Thu, 12 May 2022 19:25:01 -0700 (PDT)
X-Received: by 2002:a9d:34b:0:b0:605:f0f1:e28e with SMTP id
69-20020a9d034b000000b00605f0f1e28emr1083670otv.304.1652408701191; Thu, 12
May 2022 19:25:01 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 12 May 2022 19:25:00 -0700 (PDT)
In-Reply-To: <fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:c868:a203:69ec:2ee8;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:c868:a203:69ec:2ee8
References: <K1VeK.7$XhAf.6@fx39.iad> <fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>
Subject: Re: Petahertz, femtosecond logic gates
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Fri, 13 May 2022 02:25:01 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 1723
 by: Quadibloc - Fri, 13 May 2022 02:25 UTC

On Wednesday, May 11, 2022 at 3:54:00 PM UTC-6, MitchAlsup wrote:

> But to temper expectations: If you took the current fast chips and snapped
> your finger to make logic delays take zero time, the chips would not reach
> 2× current frequencies. Wire is the problem, not logic.

You've noted this fact before. But if faster logic were available, surely
more effort and expenditure would be devoted to reducing wire delays
than at present.

John Savard

Re: Petahertz, femtosecond logic gates

<ae02f8bd-a36c-4cad-bc0a-b081a70404c6n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25229&group=comp.arch#25229

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2683:b0:69c:8c9c:5f80 with SMTP id c3-20020a05620a268300b0069c8c9c5f80mr2213629qkp.367.1652409913666;
Thu, 12 May 2022 19:45:13 -0700 (PDT)
X-Received: by 2002:aca:b782:0:b0:325:7a29:352d with SMTP id
h124-20020acab782000000b003257a29352dmr6426433oif.217.1652409913431; Thu, 12
May 2022 19:45:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 12 May 2022 19:45:13 -0700 (PDT)
In-Reply-To: <688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:8164:3f24:ecd9:a4a;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:8164:3f24:ecd9:a4a
References: <K1VeK.7$XhAf.6@fx39.iad> <fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>
<688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ae02f8bd-a36c-4cad-bc0a-b081a70404c6n@googlegroups.com>
Subject: Re: Petahertz, femtosecond logic gates
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 13 May 2022 02:45:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2599
 by: MitchAlsup - Fri, 13 May 2022 02:45 UTC

On Thursday, May 12, 2022 at 9:25:02 PM UTC-5, Quadibloc wrote:
> On Wednesday, May 11, 2022 at 3:54:00 PM UTC-6, MitchAlsup wrote:
>
> > But to temper expectations: If you took the current fast chips and snapped
> > your finger to make logic delays take zero time, the chips would not reach
> > 2× current frequencies. Wire is the problem, not logic.
> You've noted this fact before. But if faster logic were available, surely
> more effort and expenditure would be devoted to reducing wire delays
> than at present.
<
What mechanism to you want the designers to apply to make wires faster ?
a) you can use 2 wires side by side (1.5× capacitance ½ resistance) for a small
gain. {Top/Bottom does not work because alternating metal layers run N-S and
L-R.}
b) widen the wires--breaks up the optical properties of masks wrt halation
and diffraction properties.
c) more buffering--there is an optimal distance between buffers. All critical
signals are already nearly optimally buffered (we taught the logic tools to
do this automagically}
d) Lower resistance wire--name something lower than copper that is affordable ?
e) A dielectric with lower capacitance -- Hafnium ?
f) ??? your suggestion
>
> John Savard

Re: Petahertz, femtosecond logic gates

<t5kh0k$jbl$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25230&group=comp.arch#25230

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Thu, 12 May 2022 21:48:40 -0500
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <t5kh0k$jbl$1@dont-email.me>
References: <K1VeK.7$XhAf.6@fx39.iad>
<fa2a8392-23bf-4a1c-a6ca-d0dd073de766n@googlegroups.com>
<688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 13 May 2022 02:49:56 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0a5947a1b25db313c259bebcbaec0000";
logging-data="19829"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/IqyfXAoZAS5A4nOHM/YuN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:HAi3BZT/aUCMtrNGcSa+NzKijlo=
In-Reply-To: <688ec6d6-090a-4ce9-97de-cca3b169f8ffn@googlegroups.com>
Content-Language: en-US
 by: BGB - Fri, 13 May 2022 02:48 UTC

On 5/12/2022 9:25 PM, Quadibloc wrote:
> On Wednesday, May 11, 2022 at 3:54:00 PM UTC-6, MitchAlsup wrote:
>
>> But to temper expectations: If you took the current fast chips and snapped
>> your finger to make logic delays take zero time, the chips would not reach
>> 2× current frequencies. Wire is the problem, not logic.
>
> You've noted this fact before. But if faster logic were available, surely
> more effort and expenditure would be devoted to reducing wire delays
> than at present.
>

Likely the only real way to do this would be for the processor core to
be a fully 3D structure, so that routing distances can be shorter.

But, if this could be done, the issue of "where to send the waste heat"
would likely be even more of an issue.

100W would be a lot easier to dissipate from a 1cm^2 square than from a
0.5mm^3 cube.

You can throw a heat sink on the 1 cm^2; the latter would more likely
require using something a bit more extreme (such as using liquid helium
or similar as a coolant).

> John Savard

Re: Petahertz, femtosecond logic gates

<t5l94h$n96$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25233&group=comp.arch#25233

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Fri, 13 May 2022 11:41:39 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5l94h$n96$1@gioia.aioe.org>
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad>
<t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<165236809836.5231.10460308342880170620@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="23846"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Fri, 13 May 2022 09:41 UTC

Andy Valencia wrote:
> BGB <cr88192@gmail.com> writes:
>> When hand wiring stuff, it seems like a lot of MHz level stuff, some
>> amount of variability is acceptable.
>
> I remember my eyes widening with astonishment, the first time I opened up a
> SuperPET 9000 and saw how they wired the 6809 companion processor into the
> unit.
>
> https://vintagecomputer.ca/wp-content/uploads/2015/10/SuperPET-internals-close-up-1024x576.jpg
>
> (Yes, those are CPU signals running up that wiring harness.)
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html
>
1-5 MHz seems almost like DC these days, when individual clock pulses
can reach more than 100m, a computer enclosure seems tiny. :-)

It is the same scaling which means that almost any conceivable sound
processing can be handled in sw these days.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Petahertz, femtosecond logic gates

<t5m4t1$q9q$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25240&group=comp.arch#25240

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Fri, 13 May 2022 12:34:12 -0500
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <t5m4t1$q9q$1@dont-email.me>
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad>
<t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<165236809836.5231.10460308342880170620@media.vsta.org>
<t5l94h$n96$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 May 2022 17:35:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0a5947a1b25db313c259bebcbaec0000";
logging-data="26938"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/NNunTtQpZPAJBNJcMFbVM"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:8lGrXSNUZuXIWNOiLXqzLNwNb6o=
In-Reply-To: <t5l94h$n96$1@gioia.aioe.org>
Content-Language: en-US
 by: BGB - Fri, 13 May 2022 17:34 UTC

On 5/13/2022 4:41 AM, Terje Mathisen wrote:
> Andy Valencia wrote:
>> BGB <cr88192@gmail.com> writes:
>>> When hand wiring stuff, it seems like a lot of MHz level stuff, some
>>> amount of variability is acceptable.
>>
>> I remember my eyes widening with astonishment, the first time I opened
>> up a
>> SuperPET 9000 and saw how they wired the 6809 companion processor into
>> the
>> unit.
>>
>> https://vintagecomputer.ca/wp-content/uploads/2015/10/SuperPET-internals-close-up-1024x576.jpg
>>
>>
>> (Yes, those are CPU signals running up that wiring harness.)
>>
>> Andy Valencia
>> Home page: https://www.vsta.org/andy/
>> To contact me: https://www.vsta.org/contact/andy.html
>>
> 1-5 MHz seems almost like DC these days, when individual clock pulses
> can reach more than 100m, a computer enclosure seems tiny. :-)
>

Pretty much the whole point of my "assume it moves more or less
instantly" thing.

The wavelength is a lot longer than the lengths of wire one is dealing
with, so generally "everything works OK".

Well, as noted, except things like SDcards, which appear to be fairly
particular about when the clock edges arrive. Though, I suspect this
might be because these were actually designed to run at 100MHz in SDIO
mode, and SPI mode is more just sort of an edge case.

But, SPI mode was useful as its protocol is simpler (if albeit slower),
and SDIO also had issues with being patent encumbered.

I guess I could still try intentionally skewing the clock edges (by +/-
20ns) to compensate for signaling issues.

SDcard probably shouldn't care if MOSI updates slightly ahead of CLK.

Though, it is likely that 20ns would be too big of an adjustment if
trying to run at 25MHz (since this would clash with adjacent clock
transitions, so would only likely be usable at 12.5MHz, which seems to
work OK without it).

Would likely be needed to run the driver logic at 100MHz so that one can
use 10ns adjustments (1/4 of cycle phase).

> It is the same scaling which means that almost any conceivable sound
> processing can be handled in sw these days.
>

Pretty much. For stuff running on a modern PC, for good effect I can add
things like doppler shift, propagation delay, and dynamic environmental
reverb.

These help a lot for "effect" IMO, but seemingly pretty much no one does
this. The closest we got was Creative trying to use static reverb
presets as a way to try to sell physical sound-cards.

Pretty much everyone is seemingly happy enough with left/right pan and
attenuate based on distance.

Though, can note that one can get some good effect also by adjusting the
pan calculations based on the relative direction, and for doing the
doppler adjustments separately for left/right.

Say:
Doppler is always calculated based on "virtual ear" location;
Pan is adjusted based on forwards/backwards and up/down;
Things from behind being quieter than things from in-front;
Things from above/below/behind also having less pan separation;
...

A lot of the math for this isn't all that computationally intensive by
modern standards. The only thing that really comes close is reverb due
to needing big FIR filters (but, one can sorta cheat some by effectively
using micro-float numbers as filter indices; reducing the size/cost of
the FIR filter).

But, alas.

....

Re: Petahertz, femtosecond logic gates

<VbidnbJLOcieL-P_nZ2dnUU7-WWdnZ2d@earthlink.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25245&group=comp.arch#25245

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 13 May 2022 14:31:15 -0500
Date: Fri, 13 May 2022 14:31:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Petahertz, femtosecond logic gates
Content-Language: en-US
Newsgroups: comp.arch
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad>
<t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<165236809836.5231.10460308342880170620@media.vsta.org>
<t5jogv$pnf$1@dont-email.me>
From: david.sc...@earthlink.net (David Schultz)
In-Reply-To: <t5jogv$pnf$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <VbidnbJLOcieL-P_nZ2dnUU7-WWdnZ2d@earthlink.com>
Lines: 29
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 108.194.109.17
X-Trace: sv3-oiGPuo57PlPwDrGOVtXnqwiAO+ptDvax+iiYO/z1b/QasWuYX5vYh80etMsNVuwUfeH4JyspMX8NoJ7!OZI+dIzUygVGmDr3E8VWVChvuVq8eAtDNnrpIKLpIS3NMdjqLabyrLs4cJ8rOV0BOWn5Aofa1v6/!qLSogEXQjqM/lwGu4ZfZ3g8rEY6fWa+M
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2339
 by: David Schultz - Fri, 13 May 2022 19:31 UTC

On 5/12/22 2:50 PM, BGB wrote:
> Now as to why I seemingly can't get 25 MHz over an 8 inch SDcard
> extender, this will remain as a mystery.
>
> Granted, my logic does drive all of the pins in sync, it is possible
> that delaying the pins relative to each other, say:
>   Update MOSI at 0ns
>   Update CLK at 20ns
>   Capture MISO at 40ns

SPI outputs data on one edge and clocks it in on the other. The details
for SD cards have been kept out of the free version of the specification
since version 1.0. I found it in a MMC document long ago but of course
details are a bit different now. (Setup and hold times, etc.)

Update MOSI and CLK. (falling edge)
Wait 20ns
Capture MISO and generate rising edge on CLK (SD card clocks data in on
this edge)
Wait 20ns.
repeat

Then of course there is that old requirement from MMC days to limit the
clock to less than 400KHz during initialization.

--
http://davesrocketworks.com
David Schultz

Re: Petahertz, femtosecond logic gates

<t5mghg$g7q$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25248&group=comp.arch#25248

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Petahertz, femtosecond logic gates
Date: Fri, 13 May 2022 15:52:51 -0500
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <t5mghg$g7q$1@dont-email.me>
References: <t5hijc$4mr$1@dont-email.me> <K1VeK.7$XhAf.6@fx39.iad>
<t5hbkl$qos$1@dont-email.me>
<d1aa7399-97d0-4d6e-a68e-9aece9e58518n@googlegroups.com>
<165236809836.5231.10460308342880170620@media.vsta.org>
<t5jogv$pnf$1@dont-email.me> <VbidnbJLOcieL-P_nZ2dnUU7-WWdnZ2d@earthlink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 13 May 2022 20:54:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0a5947a1b25db313c259bebcbaec0000";
logging-data="16634"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MfOOE/YLksZk2TuxMnZGQ"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:W50z6JTkNzZvEzBGAz/zgm2C2II=
In-Reply-To: <VbidnbJLOcieL-P_nZ2dnUU7-WWdnZ2d@earthlink.com>
Content-Language: en-US
 by: BGB - Fri, 13 May 2022 20:52 UTC

On 5/13/2022 2:31 PM, David Schultz wrote:
> On 5/12/22 2:50 PM, BGB wrote:
>> Now as to why I seemingly can't get 25 MHz over an 8 inch SDcard
>> extender, this will remain as a mystery.
>>
>> Granted, my logic does drive all of the pins in sync, it is possible
>> that delaying the pins relative to each other, say:
>>    Update MOSI at 0ns
>>    Update CLK at 20ns
>>    Capture MISO at 40ns
>
> SPI outputs data on one edge and clocks it in on the other. The details
> for SD cards have been kept out of the free version of the specification
> since version 1.0. I found it in a MMC document long ago but of course
> details are a bit different now. (Setup and hold times, etc.)
>
> Update MOSI and CLK. (falling edge)
> Wait 20ns
> Capture MISO and generate rising edge on CLK (SD card clocks data in on
> this edge)
> Wait 20ns.
> repeat
>

I may need to look at it some more.

Looking at the code, it both updates MOSI and samples MISO on the
falling edge, then did nothing on the rising edge.

This is sorta working, but prone to break if I try to go much over 12.5 MHz.

Where, options would be:
12.5MHz, 80ns cycle, 4 cycles on 50MHz master clock (current);
16.7MHz, 60ms cycle, 3 cycles on 50MHz master clock;
25.0MHz, 40ms cycle, 2 cycles on 50MHz master clock.

But, if I could get it working better, 3 MB/s would be better than 1.5
MB/s, and stuff I read implies that 25MHz is what the standard says the
cards should be able to do in this case.

Switching to sampling on rising edge was a fairly trivial change to the
Verilog, but I guess will require testing it on actual hardware to see
if everything still works (I sometimes get lazy and mostly just run
simulations for the most part, only occasionally running FPGA tests due
to the relative inconvenience of setting things up).

> Then of course there is that old requirement from MMC days to limit the
> clock to less than 400KHz during initialization.
>

I was also doing this, eg:
Set SPI speed to slow (eg: 100 kHz), then pump FF bytes for a while;
Send a few commands, check responses.
If not one of the expected responses:
Repeat and keep pumping FF bytes.
Flag the type of SDcard detected.

In some cases I had found, the SDcard can take a much longer time than
normal to initialize (usually after I had accessed it from Windows and
updated files or similar), in which case it seems necessary to keep
pumping FF bytes for a longer period.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor