Thank you very much. I was hoping that you can take my comments not as a challenge, but as a simple exchange of ideas. Your experience seems to be complementary to mine, as I know more, and did more, of the inside-the-IC design as opposed to the general circuit/product level.

You need to stop thinking of "boards" and "large flat surfaces" as a necessary or desired property. We aren't designing a computer or anything like it. This is an problem in the class "embarrassingly parallelizable". Think of a series of very small boards electrically connected with two ribbons: one thick for power, one much thinner for signaling. The mechanical strength of the design will be provided by screwing the packaged chips to the large rail of aluminum heathsink. Or wrapping the chips around steel cylinder of one-stage water cooling loop.

My idea of minimum pinout:

0) common ground on the heathsink
1) Vcore/analog
2) Vglue/digital
3) ClkCore
4) ClkGlue
5) RxD
6) TxD
7) Reset

When push comes to shove the last three could be rolled into one using some 1-wire communication protocol. Obviously Vcore/analog would carry the most current and the most power so it will become a limit when using non-custom packaging. So it will be more like 50*10W with non-custom fast-turnaround packages or 10*50W or even 2*250W with customized high-current slow-turnaround packaging (similar to e.g. https://en.wikipedia.org/wiki/Silicon-controlled_rectifier ).



I found better pictures under https://en.wikipedia.org/wiki/Thyristor

Perfect for whom?

I'm going to kinda restate what I wrote 2012 to friedcat, unfortunately he deleted his replies same day he made them.

https://bitcointalk.org/index.php?topic=91173.msg1062969#msg1062969

1) the case needs to be one of the many power analog IC packages, like the one for the popular L298N motor buffer chip. I'm not up to speed on this market anymore, so I don't know the current market trends. In the past the popular power package was an 8-pin variant of the TO-3. There are 7-lead variants of popular TO-220 available cheaply:

http://www.psitechnologies.com/products/todo220.php

using any package with multiple tens or even over hundred pads is completely pointless and greatly reduces the chip's reliability. The fact that the connections are repetitive (e.g. 10 * Vcc) doesn't matter as the silicon has negative temperature coefficient and those repetitive parallel connections are inherently unstable and susceptible to the thermal runaway.

2) the chip has to be from the start designed using the mixed-signal workflow. The hashing cores have such a high tolerance for errors that they have to be from the start designed as analog circuitry with individual choice of noise margins for each gate/transistor.

3) the only digital portions of the chip will be the overall glue logic and clock generation & distribution. UART is probably the best one could do because of the paucity&expense of the synchronous chips handling SDLC/HDLC/other reliable protocols.

4) It needs two-stage clock generation system, probably a simple internal multi-phase PLL and more advanced external PLL supporting fine tuning the operating frequency. The hashing chip is by necessity very repetitive and one can be assured of the existence of rather high-Q internal parasitic resonances. Some clock generators support spread spectrum clocking where the clock is continuously varied to avoid exciting resonances (both internal and external to the chip). Those spread-spectrum clock generators are cheap because people frequently use them to sidestep the FCC restrictions on spurious radio emissions.

5) If we are really into dream leagues then we can think of the Intel's planar integrated magnetics to move the voltage regulators to the surface of the chip.

Well, guess what?

It is just 2 days later and the Litecoin's testnet is split again in the exactly same fashion: the new v3 ceased to propagate and network got stuck at block 645801 that was miner 14 hours ago.

Which basically confirms that no active developers are working on the Litecoin's code and whatever work was done to incorporate Bitcoin changes from 0.10.2 caused the network split by lack of propagation of the new blocks.

The old (v2) network one again overtook the supposedly updated network and seems to be at least at block 645939 and the new ones are coming in with the regular, expected cadence.

It turns as I was expecting, in other words the problem is back after less than a week:

1) the 0.10.2.2 chain got stuck at block 645801 (which was approximately 14 hours ago) and all further mined blocks don't propagate anymore

2) meanwhile the old chain running 0.8.7.5 an earlier is now at around 645939 and slowly getting further ahead.

3) which confirms my suspicion that there were no real developers looking at the problem and that probably Litecoin developers don't understand the new code their imported from Bitcoin.

At least here we are on the same page, it is too early, IC prices are too high.

But I've been observing the Bitcoin mining market for many years. A lot of purchasing decisions are being made for the reason of acquiring a status symbol, novelty, desire to gamble, etc. Just look at Spondoolies and their neato designer rack mountable cases.

Or just look upthread:

One one hand we could just quote the Wikipedia page:
and ask "what's the point of Type-C without USB3?"

But on the other hand you have a market segment with money burning in their pockets and literally demanding "go ahead and take my money and rip me off!"

I think sidehack mentioned earlier that he isn't interested in "making another toy for hipsters," which I understand and agree.

But on the other hand, who's left in this market, beside hipsters with money burning their pockets?

While I mostly agreed with your previous post, with this post I mostly disagree. You are essentially doing a historical revisionism.

The historical serial bandwidths peaked at 115200 bps for RS-232 or 230400 bps for RS-422 (Apple Localtalk). The devices supporting or requiring higher USART speeds are extremely, extremely rare.

The main driving force for USB 1.1 to USB 2.0 upgrade was that 1.1 devices slowed down the USB hubs forcing people to the inconvenient setups involving separate hubs for USB 1.1 and USB 2.0. At the same time USB 1.1 and USB 2.0 still used nearly exactly same PHY interface, in particular using the same copper pair for the signaling.

The situation with USB 3.0 is different. The USB 3.0 signals go over a separate pair of copper pairs (4 additional wires altogether) with the completely duplicated PHY interface to maintain the galvanic contact and compatibility with old USB 1.1/2.0 signaling copper pair. This not only duplicates the copper wires but duplicates the silicon area. Only the 3.0 portions of the circuitry receive the benefits of the new technology. Here's the short quote from the Texas Instruments' TUSB1310A: "Fully Adaptive Equalizer to Optimize Receiver Sensitivity". But it is only engaged when device works in the USB 3.0 regimen, not when in backward compatibility USB 2.0 mode.

In my opinion this is nearly the same technological shift that happened when the parallel interfaces got replaced by the serial interfaces. It slowly became obvious that de-skew-ing the parallel buses is more complex than ser-des-ing the serial buses. Once the adaptive noise equalizers become ubiquitous intellectual property macros everyone will switch to the newer standards just to take advantage of the increased reliability and noise immunity.

The necessary devices already exist. I mentioned Cypress FX3:

but I want to reiterate that I'm not advocating implementing them now. It may be worth considering for the future.

http://www.cypress.com/fx3
http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller

In a nearby thread sidehack mentioned that his ideal USB stick miner will have "8-bit AVR microcontroller with firmware coded in assembly, probably less than 200 lines". Well, here it is an USB 3.0 peripheral controller with 32-bit ARM and 0.5MB RAM for free, but probably needs C programming, not just assembler.

Again, I'm not advocating developing it now and I'm not shilling for Cypress or Texas Instruments. But it is the way of the future. The USB 1.1/2.0 after many years completely subsumed old DB-9/DB-25/Centronics cables. The modern, advanced high speed serial buses USB 3.x/Thunderbolt/Lightning will subsume the classic, rather primitive USB generations.

I only partially agree with what you wrote. Your point of view is very short term.

Currently there are no USB 3.0 to serial/SPI/I2C chip. But there will be. Sort of like the initial serial chips were USB 1.1, but everybody mostly converted to USB 2.0, despite backward compatibility.

Same thing will happen with USB 3.0 transition. It is "backward compatible", but the signals are carried over different pins, and only the native USB 3.0 get the benefit of the better noise immunity and the hardware equalization that is applied only to the USB 3.0 signals.

I expect that in the future there will be native USB 3.0 serial/SPI/I2C/JTAG & other rather low bandwidth protocol integrated circuits. Currently I've only seen USB 3.0 to SATA bridges, but that exactly parallels the USB 2.0 evolution when one of the first chips were USB 2.0 to ATA bridges.

The other significant improvement over USB 2.0 will be when the XHCI drivers will mature. XHCI interface is generally significantly better designed than the older UHCI/OHCI/EHCI interfaces. The XHCI is in my opinion destined to win purely on its being from the start designed to properly support virtual machines.

https://en.wikipedia.org/wiki/Extensible_Host_Controller_Interface

I don't know if the current problems with USB 2.0 mining devices plugged to USB 3.0 ports are caused by hardware (e.g. lower noise margins on the USB 2.0 pins) or by the driver problems caused by the cgminer attempting to threat USB 3.0 controller port & hub as an USB 2.0 controller port & hub and seeing only the fraction of the true picture.

The IC devices to natively support USB 3.0 will be on the market in several years. Maybe even -ck and kano will deign to read the XHCI documentation and update the cgminer to properly use their capabilities and not run them in their backward compatibility mode? Stranger things had happened in the Bitcoin milieu.

This error reoccurred, this time not involving older Macintoshes, but up-to-date patched, clean, unmodified Windows with Internet Explorer 11:


All those protocols were already enabled, and this time I'm positive that my ISPs (plural ISPs) were all working correctly and there wasn't man-in-the-middle or any other shenanigans going on.

The time stamp are in the range:

2015-07-23T00:00 UTC

to

2015-07-23T00:31 UTC

and this time I ran several tests on various ISPs and various OS installations.

It is all because lack of the real USB3.x bridge chips that interface serial/SPI/I2C.

All SiLabs bridge chips are USB 2.0 at most.

All useable FTDI bridge chips are also USB 2.0.

FTDI publicly has only two USB 3.0 chips (FT60{0,1}) that serves only parallel FIFOs (16&32-bit wide).

Do you know of any useable native USB 3.0 chips serving serial/SPI/I2C ? Not an entire ARM-based controller like Cypress FX3/FX3S that will require extensive programming?

The closest historical approximation to the present Bitcoin mining community that I can think of are the prayer mills that are used all over Tibet and Nepal:


Sometimes individual, sometimes whole farms of them:

Some even use renewable energy to keep them spinning:

https://en.wikipedia.org/wiki/Tibetan_prayer_wheel
https://en.wikipedia.org/wiki/Prayer_wheel

Fun, and a perception of play, is a very individual thing. The only 'fun' that I can recall that involved soldering irons was when the professors left the room, we over-applied the rosin-based flux and played really loud "Smoke on the water" by Deep Purple on the tape recorder and tried to come up with alternative lyrics to that song. I'll be perfectly happy to never need to touch the soldering iron again in my life and do all my work by supplying design plans to the workshops.

I'm glad to hear that you are considering next version.

But you are going to commit a grave mistake if its going to have a programmable microcontroller with firmware. USB 2.0 has enough bandwidth to support all the required circuitry in the completely dumb-terminal mode.

Unfortunately I don't know the specifics of the ASIC you are using, but the general design points are as follows:

1) absolutely no firmware or microcontrollers can be run on the same power supply as the mining chip !!!one!eleven!
2) simple, high bandwidth USB to serial converter chip with high noise immunity using SPI, I2C, plain serial with hardware flow control, etc.
3) pre-calibrated SPI/I2C thermometer IC touching the same heathsink
4) external clock generator with programmable frequency and duty cycle.
5) SPI/I2C interfaced programmable voltage converter
6) if the chip doesn't have a an on-die temp-sensing diode maybe there is a way to rig up a temperature sensor by doing e.g. IO-pad leakage to time converter with external RC components and measure chip temperature indirectly by measuring time in the host software.
7) obviously, if there is an on-die diode then just hook it up the external thermometer IC.

I'm trying to. But I sense that you are probably not aware what can a single person do with e.g. a copy of National Instruments LabView Student Edition when that person doesn't need to practice screwdriver artistry and work around firmware limitations/bugs/faults but can simply do a proper laboratory workflow by setting up operational points (voltage,clock parameters) and measure the outputs (temperature,hashing speed & error rates).

One additional comment about the lame design choice that Spondoolies made: they used on-chip temperature-to-digital converter macro instead of a cheaper and simpler diode with external thermometer IC. The internal SSN (simultaneous switching noise) on their chip made their temperature readouts rather unreliable. And they knew very well that the SHA256 mining chip is very close to the theoretical maximum toggle rate of any practical digital circuit.

http://www.ztex.de/ is opening for me just fine. Ask them or search around on the forum for the used ones. They won't be cheap, because they are actually very well designed.

The cheap ones are e.g. Enterpoint's Cairnsmore with their horrible ringing on the clock signals that almost killed the whole business.

Substitute "crutches" for "solutions".

The mining hardware market is a showcase of how not to design hardware. You can find pretty much every possible dumb fault in various hardware miners. By "dumb" I mean "something that would be nearly trivial financially to fix and productize correctly".

ngzhang was the closest to an ideal with his dual FPGA board. But he routed only TxD and RxD from the FTDI serial chip to the Xilinx Spartan, despite FTDI supporting 8 or 12 signals. How much time they then spend trying to fix and work around this problem at the protocol level!

In the ASIC group the Spondoolies would be the closest to the nice platform for experimentation. But they completely fubared the airflow design, heating some chips in the loop with the exhaust air of the others. How dumb is that?

The way I'm serving the market of experimenters is by warning them away, unless they want to learn about the pathologies of electronic design. Buy and disassemble an old radio or TV, or even an old computer.

There's almost nothing in the Bitcoin hardware milieu that I could with the clear conscience suggest as a learning and educational toy for the interested student. ztex.de is the only exception, but they never really catered to the demands of the Bitcoin market.

The painfulness of driver code is mostly Con Kolivas, Kano's & Luke-Jr fault. They intentionally made their miners frighteningly convoluted "bags of drivers". The early BitFury miner was a thing of beauty and elegance despite having to straighten out the jumbled data due to the metal misrouting in his original chips.

In my opinion lack of voltage control and temperature measurement (not just overtemp warning) is what nearly completely removes the learning and experimenting potential of those devices.

It is one thing to "make them work" and the other thing "to make them work and make them worth studying and learning".

The 2nd market is there, but isn't getting served. Such a shame...

Then what are you waiting for? Get an FPGA kit, it will completely cure your jones for DIY. All the toolchains I've seen support schematic capture as one of the design input method, so you aren't saddled with coding in Verilog or VHDL, and go back to the familiar concept wiring the gates.

For the sake of old times buy yourself a can of rosin in the store that serves musicians (it is used to maintain bows for violin, cellos, etc.) and slowly melt it to get the whole sensual experience of the old style electronic DIY.

I read your review of some upcoming USB stick miner and it shows that the Bitcoin community completely missed the ball on creative experimenting.

It wouldn't increase the cost much to include the proper software-controllable voltage regulator instead of a lousy trimpot. Same with adding a pre-calibrated heath-sink temperature sensor IC. Does the included ASIC chip even have an on-chip diode that can be used to measure the die temperature?

The marked evolved to serve "compulsive miner" people, not the "learning and experimenting" people.

Dude, if you are longing for the breadboard days you just need to get yourself an FPGA development board. The cheapest ones are under $100 and for sure they can mine coins. What do you think is my avatar?

But you will have to move with the times. Search this forum archives for the mentions of FPGA and you will find plenty of interesting resources.

Unless you are one of those who are really longing for the soldering iron burns, the FPGA kit is all you need to make you happy. With FPGAs you won't even need the expensive logic analyzers, the development toolchains have a Chipscope, which is basically a software logic analyzer connected over JTAG/serial/USB interface.

 

The days of DIP chips with 5V or 3.3V power supply and current draw in miliamperes are gone. It is still possible to have them made, but they are surprisingly expensive to make.

You'll need to clearly mark edits to have a meaningful discussion on the forum. Otherwise I'm going to assume that you are simply drunk or otherwise under the influence.
Looking through the post in the Litecoin launch thread I see that I've run both litecoin's mainnet & testnet less than 3 days after the official launch. The 1st testnet probably run even earlier than the official launched mainnet, although I can't access that machine now.

You seem to be confusing the dates of the resets of the testnet with the dates of the launches.

What I'm afraid of is that Litecoin's core development team had abandoned it's creation. This would be a shame and disappointment. In the past there were lulls in the interest and development around the Litecoin core client. I recall testnet partitionings, but I do not recall such a long fork.

Anyway, is there anybody awake and sober reding this thread who could either restart the Litecoin's testnet client on his machine ot sjust start it from scratch and report back?

Developers, if they existed, would care about long forks.

You are certainly right about plentitude of short forks, they are expected and inconsequential. "getchaintips" show 717 branches in one of my test nodes.

But the long fork and a complete stall in the updates of the blockexplorer for couple of days means only one thing: the code is buggy, nobody's watching it, and nobody's developing any software to be used with Litecoin.

Testnet is always an early warning system for the software problems.