I don't think you are making yourself clear. Please post the link to the FTDI application notes that describe the change you are requesting.

http://www.ftdichip.com/Support/Documents/AppNotes/AN_121_FTDI_Device_EEPROM_User_Area_Usage.pdf

Are you talking about this?

I would recommend against that, unless some driver fairy can obtain a WHQL signature for the modified VID/PID. Trying to run with unsigned drivers under 64-bit Windows is an unnecessary hassle.

The market gained would be some open-source extremists. The market lost would be those who can't or wouldn't modify their Windows installations. Let the US-ians fight the monster from Redmond.

As a dev board user I can tell you the following: market is full of single FPGA dev boards. The uniqueness and greatness of your designs (Icarus & Lancelot) lies in them being paired FPGAs with non-trivial interconnectivity. The only problem with them is that they have a bent straw instead of a pipe for the external communication.

I'm even thinking of getting a Lancelot and paying someone to rework the FT232R connections using additional 10 wires soldered to the unpopulated GPIO vias. But this is something above my manual skill and resources, and because of that it will have to wait.

If you ever find a need to do Lancelot v2 (like Icarus v2) then just please remember to route all the available signals from the comm chip to the FPGA.

And for your future designs please consider using the high-speed USB chips instead of full-speed USB and having one comm pipe per FPGA. So the Lancelot v5 would have FT2232H (dual high-speed USB). The market for the multi-FPGA boards its there already:

https://bitcointalk.org/index.php?topic=78239.msg973019#msg973019

I just realised that I have given such a pitch already years ago. I was an early advocate of dual Pentium (Classic) and dual Celeron (with SMP mod) motherboards. Those who listened were very well prepared for the arrival of multicore CPUs. Something similar will happen with FPGAs.

"Oh boy!" for not connecting all available pins from the FT232R to the FPGA.

Any non-mining application would need more communication bandwidth. The easies way would be to route all 8 DBUS signals for parallel byte communication. Then the CBUS signals can be configured in EEPROM to expose the RD# & WR# strobe signals. It all works together to allow easy implementation of bit-bang I/O. And it is easy both on the host side software in the computer and easy on SLICE resources on the FPGA.

It is just 6 traces more, but the value of the board as a development kit increases immensely. The default 115200bps maximum speed in UART is a serious limitation for non-mining uses.

I'll wait for the schematic and constraint files to ask further questions.

I have some other development board with FTDI chip and I will write a quick loopback test software for Windows and a trivial loopback Xilinx project.

I have non-mining questions:

1) You replaced Prolific PL2303HXD with FTDI FT232R, is that right?
2) Are all 8 DBUS pins from FT232R connected to the FPGA U1?
3) How about 5 CBUS pins? I see TXD1 and RXD1 LEDs so 2 are already used. Where are the remaining 3 connected? I'm hoping for RD# and WR# bit-bang strobes.
4) What is the number of connections between U1 and U2?
5) What is U3?
6) What is U9 and the HOT LED?
7) I see two Winbond chips U4 & U5. Are those SPI configuration memory?
Assume that FPGA is configured for loopback only and not for any work. Did you test that the FT232R works reliably at the full 3Mbps serial communication speed?

Thanks in advance.

Thanks for the clarification. Fortunately for me I never had the problems with on-board signals but only with off-the-board comms.

One thread of scrypt(1024,1,1) requires exactly 131583 bytes of memory, which is 128.5 kB. Thus 128MB would allow for pipelining of over 1000 parallel scrypt() threads.

I don't have the CM1 hardware, but I watch this thread and I have to ask:

Why not using PLL_ADV in front of the DCM to filter out the jitter? Just from looking at the floorplan of Spartan-6 the PLL_ADV block is about twice the size of the DCM block. With BANDWIDTH=LOW it should serve as a decent jitter filter.

Client-attorney privilege covers that. P.M. holds the funds "in trust". There's a long history of this type of arrangements to hold up to all kinds of judicial challenges.

And this where the forum provides real value: indirect education and intellectual stimulation. This isn't rote memorization and sightseeing in the Bitcoin Disneyland. Even Vladimir, who built the Bitcoin Disneyland (bitcoin.org.uk) is back here. Nowhere else one can get schooled both in financial responsibility and crass irresponsibility within the same thread.

Please, if you can't stand the heat, get out of the kitchen.

None. I don't know nor cooperate with anyone active on this forum nor any primarily-Bitcoin entity. I prefer to remain a "disinterested party" with respect to Bitcoin.

Not directly. But when push comes to shove people do this by building some sort of multivibrator circuit involving the I/O pads and external analog components. Then the temperature can be measured indirectly by counting up the time it takes for some capacitor to charge/discharge through some internal resistance. Calibration can be difficult for such circuits.

Multilayer silicon is simply not required. The Bitcoin hasher chip is extraordinarily simple as far as digital design goes. The only unusual part is the power dissipation per area-unit. Somebody experienced with power analog design should be able to solve it quickly and without much expense.

It is basically a lottery-ticket buying machine. Even if cetrain fraction of the tickets is mangled the whole machine is still worth it. There will be no yield issues: it will be either zero (completely doesn't work) or nearly 100%.

Too many pins would be required to shuffle the data between the hot and cold parts. Essentially the whole hashing chip is hot.

What makes sense is to use a single chip with split clocks and split power supply. One clock and power for the "core" and one clock and power for the "I/O".

The split you suggesting also makes sense for the "full custom" versus "cell library" choices. Use "full custom" for the core hashing round and "cell library" for all the glue logic. But I don't think that the fab the Block Erupter uses would allow them to do this. It seems like they are committed to the cell library only design.

Edit: Here's the link to how Xilinx uses two-process' (65nm and 28nm) split for their $10k per chip Virtex-7 line.

http://www.xilinx.com/support/documentation/white_papers/wp380_Stacked_Silicon_Interconnect_Technology.pdf

Don't forget to ask the analog side of your fab for the suggestions on the casing. If you use serial I/O then 8 pins should be plenty. And if you need only 8 pins you could use one of the many IC cases designed for power analog application with a screw-hole for the heatsink mounting. The PCB will be an afterthought distribution strip. The power heatsink bars are ultra cheap and sold by the linear feet.

Good luck.

I'm fine with the "experienced forex broker" answer.


Somebody with years of experience in a regulated industry would be a very good advisor on how to operate in the grey zone, e.g. operate out of Singapore but accept only US dollars not Singaporean dollars.

Also the UI choices show signs of a deliberation. The UI is so easy to use that only easy marks would want to use it.

The answer is actually both. He's both the original creator of Bitcoinica and a frontman for the "advisor".

https://bitcointalk.org/index.php?topic=48850.msg587530#msg587530
https://bitcointalk.org/index.php?topic=55970.msg673426#msg673426

It appears to trigger slow convergence in the place and route phases. The unrolled implementation has the similar problem, but less bad.

It seems like the heuristics in the global optimization phases can't find an usable gradient which could be used to guide the optimizer. So it kind of wanders in a fog over the terrain consisting of small hills and shallow valleys.

Please add the Litecoin's testnet block explorer to the list of services. This is crucial to allow normal software development. By "normal" I mean that the developers aren't at the same time the owners of whatever they are developing. Currently it seems like the whole Litecoin development community consists of one-person shops.

Also, please run the testnet litecoind at all times. It doesn't have to mine, it is sufficient that it just sits there logged in to the IRC channel and is ready to serve the testnet blockchain. The difficulty on testnet is low enough that anyone who really needs to do some testing can CPU mine the required block on a spare computer.