CryptoURANUS Economics

Anti-AdBlocker

Saturday, July 20, 2019

GisselQuist-Technology_LLC: Cryptocurrency




This is For ReferenceOnly Research and All Below is a Paste and Copy So I do not loose this awesome site information:


Powered by Xilinx Virtex-7 V2000T, V585, or X690T  the HTG-700 is ideal for ASIC/SOC prototyping, high-performance computing, high-end image processing, PCI Express Gen 2 & 3 development, general purpose FPGA development, and/or applications requiring high speed serial transceivers (up to 12.5Gbps).  

Three High Pin Count (HPC) FMC connectors provide access to 480 single-ended I/Os and 24 high-speed Serial Transceivers of the on board Virtex 7 FPGA. Availability of over 100 different off-the-shelf FMC modules extend functionality of the board for variety of different applications.
Eight lane of PCI Express Gen 2 is supported by hard coded controllers inside the Virtex 7 FPGA. The board's layout, performance of the Virtex 7 FPGA fabric, high speed serial transceivers (used for PHY interface), flexible on-board clock/jitter attenuator, along with soft PCI Express Gen 3 IP core allow usage of the board for PCI Express Gen3 applications.
The HTG-700 Virtex 7 FPGA board can be used either in PCI Express mode (plugged into host PC/Server) or stand alone mode (powered by external ATX or wall power supply).











Blog Posts

  • Last-Update:

    Lessons learned while building crossbar interconnects

    Connecting N bus masters to M bus slaves is the task of an interconnect. While many approaches exist, one of the most common FPGA approaches is a crossbar interconnect. This article examines some common features among several crossbar interconnects I've recently built.
  • Breaking all the rules to create an arbitrary clock signal

    Never generate a clock signal using logic! Why not? Let's break this rule today in order to create an arbitrary clock generator and see how things work out for us.
  • Building the perfect AXI4 slave

    Xilinx provides example code which can be used to build an AXI slave from. As we've already seen, this code is broken to the extent that it can be made to violate the AXI protocol. Worse, even when it does work the demo core does not perform well. Here's an example of how to do better.
  • Building a Skid Buffer for AXI processing

    Skid buffers provide an elastic support between pipeline stages, relieving the pressure from combinatorial logic which would otherwise accumulate from one stage to the next.
  • Examining Xilinx's AXI demonstration core

    Vivado has a wonderful capability, whereby it can create a AXI4 IP core for you to build a design off of. Sadly, the core generated by Vivado 2018.3 doesn't pass formal verification. Let's look at some of the problems with it today.
  • Understanding AXI Addressing

    An AXI4 component must three different addressing modes, 8 different sub-word sizes, four different wrapping lengths, and both aligned and to-be-aligned addressing. It's not trivial. This article takes a look at how you can compute the next address in an AXI burst.
  • Project Ideas: PMod AMP2

    Do you have a PMod AMP2? Are you wondering what to do with it? Here are some ideas
  • Applying Formal Methods to the Events of the Resurrection

    When was the last supper? When was the crucifixion? Friday? How about the sabbath? Let's apply formal methods to discover these events
  • The most common AXI mistake

    After formally verifying several AXI-lite slaves, one bug stands head and shoulders above the rest as the most common bug
  • The ZipCPU's Interrupt Controller

    The ZipCPU has only a single interrupt line. For many microprocessor applications, this is way too few. Therefore, let's discuss how to build a simple interrupt control peripheral that can then give the ZipCPU access to more than just the one interrupt
  • Logic usage and decoding return results with cascaded multiplexers

    How your CPU or bus aggregates return values from its components, can have an affect on your logic usage
  • Building a universal QSPI flash controller

    In this article, I'll discuss how to build a QSPI flash controller in Verilog, and then make sure it works under all configurations. As always, formally verified example code is provided.
  • Introducing the ArrowZip ZipCPU design, featuring the Max-1000

    The Max-1000 is a very small and cheap FPGA development board from Trenz, and sold by Arrow in the US for only $30. Today, let's take a an example design that runs the ZipCPU on this board.
  • Using Sequence Properties to Verify a Serial Port Transmitter

    Formally Verifying a serial port makes a great example of both the good and bad about SystemVerilog sequences, and how you can still work around the bad with SymbiYosys
  • Why does blinky make a CPU appear to be so slow?

    If your CPU runs at 100MHz, what speed would you expect it to be able to blink an I/O pin at? Let's take a look.
  • Debugging a CPU

    This is the story of finding and fixing a bug in the ZipCPU. As with most bugs, the bug I found wasn't where I expected it. Along the way, though, we'll go over several tools you can use to accomplish such a task--should you ever find you need to do so yourself.
  • Building a custom yet functional AXI-lite slave

    Some time ago, I wrote on this blog about how to verify an AXI-lite slave, showing along the way how Xilinx's demonstration slave wouldn't pass a verification test. Instead of illustrating the problem again, let's take a moment to examine how to build an AXI-lite slave that will not only work, but have twice the throughput.
  • ZipCPU highlights from 2018

    A quick summary of the highlights of the ZipCPU blog over 2018, to include a list of the most read articles
  • Using a formal property file to verify an AXI-lite peripheral

    A file of formal properties defining an interface is worth gold: you can get a strong guarantee that your code will conform to the interface if it passes a formal verification step using the interface. Even better, one such file, used across an enterprise, can guarantee that all of the cores within the enterprise are interface compatible.
  • AutoFPGA's linker script support gets an update

    AutoFPGA is a very powerful scripting tool for composing ad-hoc System on a Chip (SoC) designs. Today it gets an update for handling linker scripts.
  • Makefiles for formal proofs with SymbiYosys

    Building a make script to verify multiple configuration options using SymbiYosys can be done very easily. Let's take a quick look and see how that might be done.
  • Swapping assumptions and assertions doesn't work

    Some time ago, I blogged about how to go about aggregating subcomponents together into a larger design. While I've used the technique often with great success, this article shares a counter example that renders the approach invalid.
  • Building a video controller: it's just a pair of counters

    Building a video display can be a fun beginners exercise: at its fundamental core, it just consists of a pair of counters. This article will examine the lower level component of a video display controller for a VGA display.
  • Accessing the registers of a SoC+FPGA

    Accessing the memory mapped registers connected to a CPU-attached FPGA is usually easy to do. However, if you are doing this from within a Linux system, across a virtual memory interface, then there are a couple more steps involved. The result is still fairly simple.
  • Taking a look at the TinyFPGA BX

    The TinyFPGA BX offers a new approach to the classic FPGA loading problem. Let's take a look at this board and see what it offers.
  • To my new readers and my new twitter followers, welcome!

    I've recently acquired several new twitter and blog feed followers. Today, I'd like to take a moment to welcome them, and let them know what they can expect from the ZipCPU blog.
  • An Open Source Pipelined FFT Generator

    Not having an open source FFT implementation can make simulating DSP algorithms with an open source simulator such as Verilator nearly impossible. Now there's a highly configurable open source alternative. Better yet, this alternative has been formally verified. We'll discuss that FFT, and how the formal verification was accomplished, here.
  • It's time for ORCONF 2018!

    ORCONF 2018 will be held this weekend in Gdansk, Poland. I look forward to meeting many of you there. Here's the abstract of what I intend to present this year.
  • My design works in simulation, but not in hardware. Can formal methods help me?

    Formal methods are traditionally viewed as a design tool to be used before implementation. Today, let's take a peek at a recent example where formal methods were able to help me after implementation.
  • Handling multiple clocks with Verilator

    If you look through the Verilator on-line documentation, you'll notice that all of the examples use a single clock only. Verilator is more capable than that, so let's try to fill in that gap today. This article takes a quick look at how you might handle multiple clocks within Verilator.
  • RE: Building a simulation for my design? What does that mean?

    A student recently asked me what I meant by simulating a design. To answer his question and encourage others, let's spend a moment and look at some examples of what you can do with simulation. I'll also offer several links to other blog posts showing you how to do many of these things.
  • How to build a SPI Flash Controller for an FPGA

    I've now written several (Q/D)SPI flash drivers, and just recently had the opportunity to build another. Here I present the design decisions, the design, and even the formal verification of this new core.
  • Reasons why Synthesis might not match Simulation

    I now recommend simulation to anyone doing HDL design. It's can even be faster to run and debug a simulation then actual hardware. However, there are plenty of times when simulation doesn't match reality. Let's enumerate some of the reasons why simulation might not match hardware performance.
  • Why I like Formal: the ZipCPU and the ICO board

    Recently, I had to move logic from one clock to another in order to fit the ZipCPU onto the ICO board. Having a set of formal properties for the ZipCPU, properties that covered this change, gave me a strong confidence when making the change that the result would still work.
  • What does Formal Development look like in Practice?

    I just built a basic, simple SPI controller last night, using formal tools along the way. Care to read what the development was like?
  • Formally Verifying Memory and Cache Components

    There's a necessary but basic trick necessary when formally verifying something that acts like or interacts with memory, and it's not all that hard to do. In this article, I'll present that basic trick and show how to formally verify a block RAM device.
  • Crossing clock domains with an Asynchronous FIFO

    A two or three clock synchronizer works great for passing small amounts of information across clock domains. If you need to pass more information, such as a full data stream, you will need an asynchronous FIFO. This article examines the Asynchronous FIFO designed by Cliff Cummings, applying formal methods to it to see if it truly maintains the properties he discusses.
  • Formally Verifying Asynchronous Components

    There's a very small bit of trickery required to formally verify an asynchronous design using yosys. Once you know the trick, it becomes easy to set up the properties necessary to formally verify any asynchronous design. In this article, we'll demonstrate this principle by formally verifying a clock switch.
  • A Slow but Symmetric FIR Filter Implementation

    The cost of an FIR filter is usually measured by the number of multiplies required to calculate an output. If you want to implement a better filter, you only need to be able to afford more multiplies. However, if the filter is symmetric, and most FIR filters are, then a little cleverness will allow you to implement the same filter with half as many multiplies.
  • Updated Projects List

    Just a quick note to let everyone know I updated my projects page.
  • Aggregating verified modules together

    Aggregating multiple modules together to formally verify a larger whole can be a very difficult challenge. While I am by no means the expert on this topic, I can at least share some lessons I've learned myself.
  • ZipTimer: A simple countdown timer

    When learning Formal Verification, it helps to start with the simplest designs possible. The ZipTimer is just about that simple: it is nothing more than a programmable countdown timer. More than that, though, it's a usable and critical component of the ZipSystem. Today, let's examine that timer and then formally verify it.
  • Formally Verifying an Asynchronous Reset

    It's one thing to synchronize reset logic within your code, its another to formally prove that your reset synchronizing logic works. This article takes a look at an example reset synchronizer, and then applies SymbiYosys to formally verifying that it works.
  • What would you like to see on the ZipCPU blog?

    It seems there are more topics to post about then there is time to post or to read them. Hence, it's time to ask my Patreon sponsors what topics they'd be interested in reading about next, and thus where my focus should be for the next couple of months. If you are not a blog sponsor, please consider yourself invited to become one!
  • Will formal methods ever find a bug in a working CPU?

    I've now turned my attention to formally Verifying the ZipCPU. Having used the ZipCPU for several years, do you think I'll find any errors within i?
  • Resurrection Day!

    Today is the day Christianity celebrates the resurrection of Jesus Christ. Please join me in reflecting on what makes Jesus different.
  • Quadratic fits are entirely inappropriate for DSP

    If you ever need to estimate a signal's value between samples points, don't use a quadratic fit. There are much better techniques out there which don't suffer from the discontinuities and high frequency distortions associated with a simple quadratic fit. Want to see an example?
  • Pipelining a Prefetch

    We've already discussed the simplest of the ZipCPU's several prefetch modules. Today's discussion focuses on another module that's nearly as simple, but yet can achieve much better performance.
  • Is formal really all that hard?

    There seems to be a myth that formal verification is very difficult, and that it is only used by the smartest digital designers. Let me take a moment in this article to dispel that myth: If you are smart enough to do digital design, then you will appreciate the benefits of formal verification
  • An Exercise in using Formal Induction

    Passing N steps of a formal bounded model check isn't nearly as hard as proving a design works for all steps. This post explores some of the differences, and offers some explanations for those new to formal methods.
  • Want to use ZBasic? Let's have some fun--no actual FPGA required!

    The ZBasic distribution is a very basic ZipCPU distribution that has full Verilator support for all of its peripherals: flash, serial port, and an (optional) SD-card. Want to play a game?
  • Debugging a Cyclone-V

    I just delivered my first design using the Cyclone-V. It was a new experience for me, and I'd like to share some lessons learned in debugging.
  • ZipCPU toolchain and initial test

    This article discusses how to clone the ZipCPU repository from github, and then build the compiler and toolchain. The toolchain is then proven using the basic simulation test program that comes with the ZipCPU repository.
  • Updating ZipCPU files

    I'll admit, I've enjoyed formal methods so much I've started formally verifying much of the ZipCPU repository. Here's a quick status update of what's been accomplished.
  • Interpolation is just a special type of convolution

    One of the more profound DSP lessons I ever learned was that most practical interpolators can be understood as convolutions. This is important because it means that interpolation function have frequency responses, and that their performance can be understood by examining this response.
  • A Quick Introduction to the ZipCPU Instruction Set

    If you've ever wanted to examine a minimalist, yet still powerful, CPU's instruction set, then you might wish to take a peek at the ZipCPU's ISA. If you've ever wanted to program the ZipCPU in assembly, or evaluate or understand an assembly representation of a ZipCPU program, then read along and see the basics of the ZipCPU instruction set.
  • Top 10 ZipCPU blog posts for 2017

    In the spirit of all good New Year's blog posts, here's a quick list of the top ten blog posts on ZipCPU.com from this last year.
  • A better filter implementation for slower signals

    All of the filter implementations we've presented so far are high speed implementations--appropriate for signals at or close to the system clock rate. These implementations, however, end up being very resource expensive when all you want to do is to filter a much slower signal--such as an audio signal. This post, therefore, presents an alternative that is more resource efficient for audio signals.
  • Mystery post: The ugliest bug I've ever encountered

    For someone who has been debugging software for many years, this bug caught me by surprise. I'd never seen anything like it, and had no idea where to look to find the problem. Care to see if you can guess what it was? (Solution at the end.)
  • Arrow's Max-1000: A gem for all the wrong reasons

    I recently purchased a MAX-1000 development board from Arrow. It's a nice, small, FPGA development board for anyone interested low price. In the process, however, I discovered some amazing things about the FTDI FT2232H chip on board.
  • Building a Simple Logic PLL

    Phase-Locked Loops are components designed to lock an oscillator to the phase and frequency of an incoming oscillator. In this article, we'll present a very basic PLL algorithm that can, at high speed and within an FPGA, lock onto the phase of an incoming logic signal.
  • Building a Numerically Controlled Oscillator

    A Numerically Controlled Oscillator (NCO) plus a Digital to Analog (D/A) converter creates a Direct Digital Synthesizer (DDS)--something that can create a tone of any user-controlled frequency. Let's skip the D/A today, and discuss how to drive a sine wave generator to create that known frequency.
  • Testing the fast, generic FIR filter

    The last filter we presented was a high speed, generic, reconfigurable, FIR filter that can be used for many purposes. Since then, we've been working our way towards a framework for testing that filter. Today, let's build that test bench from the framework we've developed and see how well our filter actually works.
  • Thank you!

    O give thanks unto the LORD; for He is good!
  • Measuring the frequency response of a filter under test

    Our generic filtering harness development stopped short of measuring the frequency response of a test filter. Here, we pick back up the discussion and work through how you might measure the frequency response of a filter under test using Verilator.
  • Building a prefetch module for the ZipCPU

    The pre-fetch module is one of the fundamental components of any CPU. It is responsible for fetching instructions from memory. The ZipCPU prefetch is also an example of a Wishbone master, something worth looking at again in and of itself. This post adds a twist, though, to those two topics in that we'll also formally prove that this prefetch algorithm properly accesses the Wishbone bus.
  • Generating more than one bit at a time with an LFSR

    The typical LFSR development ends with logic that can create one bit per clock. What happens when you need many bits per clock, not just one? So let's continue our discussion of LFSRs and investigate how to calculate many LFSR bits per clock.
  • An example LFSR

    To many people, LFSRs magically produce random numbers. They are a confusing unknown. So let's look at an example 5-bit LFSR, and see what happens when we step through its logic.
  • A Configurable Signal Delay Element

    Many DSP applications have a need to delay a signal against itself by some period of time. Such delays are fundamental. They are also fairly easy to build.
  • Building Formal Assumptions to Describe Wishbone Behaviour

    The most critical component of any bus based system, such as a System on a Chip (SoC), is the bus interface. One failure of this interface can easily lock up the entire system. This post examines the Wishbone bus interface, and presents some formal properties that can be used to verify that a Wishbone master works.
  • The Interface to a Generic Filtering Testbench

    As we work our way through discussing digital filtering, and presenting multiple digital filters, we're going to need to test these filters. This article outlines, from the bottom up, a test harness that can be used to aid testing whether or not a digital filter produces the response one would desire.
  • Good Software Engineering Principles Apply to Students Too

    Just because you'll be turning in a one-time project for your class, doesn't mean you can ignore good software engineering principles. Those same principles might be the difference between getting your project working or not.
  • Generating Pseudo-Random Numbers on an FPGA

    At some point or other, when working with FPGAs, you will need a pseudorandom number sequence. Linear Feedback Shift Registers are commonly used for this purpose. Here, we discuss such registers and how to create them within Verilog.
  • Some Simple Clock-Domain Crossing Solutions

    Crossing clock domains is one of those FPGA design topics that is strictly a hardware topic. By the time a software engineer starts his work, any CDC issues have likely been resolved. Not so for the FPGA designer. Let's examine several methods for crossing clock domains.
  • My first experience with Formal Methods

    I've just started trying formal verification methods based upon yosys and yosys-smtbmc this week. As a result, I've now found several subtle bugs within my FIFOs, things that I would never have found otherwise. This post shares some of my initial thoughts and experiences, as well as providing a short primer to the method.
  • Just some notes to new readers of the ZipCPU blog

    If you've just started reading the ZipCPU blog, welcome! Let's take a look at some upcoming topics.
  • Implementing the Moving Average (Boxcar) filter

    A fully generic filter can be difficult to implement within an FPGA, since FPGAs can only support a limited number of multiplies. One way of simplifying the problem is to use a moving average filter. Let's examine how to build one of these filters.
  • FPGAs vs ASICs

    While I like to lump both FPGA and ASIC development into a catch-all phrase 'digital logic', there are some very real differences between the two. Let's examine some of those differences together.
  • It's all about the interfaces

    If you want raw algorithmic speed, look no farther than an FPGA. However, before you start drooling over how fast an FPGA can run a task, take a moment to think about what it will take to get your data in and out of the FPGA at the speed you want the FPGA to run.
  • Using AutoFPGA to connect simple registers to a debugging bus

    Let's take a look at what it takes to add a simple, single-register component to an AutpFPGA based design. We'll look at and examine some simple peripherals, and look at how the components configuration file tells AutoFPGA how to connect the component to the rest of the design.
  • A Brief Introduction to AutoFPGA

    Many of my readers are aware that I am working on a project I've called AutoFPGA. AutoFPGA makes it easy to reconfigure a bus and reassign addresses when adding new components to a design. This post presents a high level overview of how AutoFPGA may be used.
  • A CORDIC testbench

    Building a test bench for a CORDIC with an arbitrary number of bits, both input, output, and phase bits, is not a trivial task. However, without knowing how good a component should be, it's hard to know whether or not the component works to its specification.
  • A Cheaper Fast FIR Filter

    After I last posted on how to build a generic FIR filter, a friend showed me a cheaper implementation. This post presents and examines that cheaper implementation.
  • Understanding the effects of Quantization

    If you are building DSP algorithms within FPGAs or other digital logic, it's important to know how your logic will handle finite bit arithmetic. This post just goes over some of the basic effects of quantization: what it is, and some simple means of modeling it to determine how it will affect your algorithm.
  • Clocks for Software Engineers

    If you have a software background, and you want to pick up digital design, then one of the first things you need to learn about is the clock. To many software engineers, the concept of a clock is an annoyance. Without using a clock, they can turn HDL into a programming language. Yet the clock they are ignoring is often the most fundamental part of digital design.
  • Demonstrating the improved PWM waveform

    Having posted on an improved form of Pulse Width Modulation, I've been asked to provide a demonstration of this capability illustrating that this technique actually works. So today we'll discuss the technique again and present performance measures showing how well this method of signal generation outshines its traditional PWM counterpart. Sample code is provided, so you can test it for yourself.
  • Building a high speed Finite Impulse Response (FIR) Digital Filter

    Digital Filtering is one of the most fundamental DSP operations. Further, because of their speed, FPGAs can filter things that nothing else can. This post will develop a simple, extensable, generic high speed re-programmable digital filter.
  • Even I get stuck in FPGA Hell

    Yes, even I get stuck in FPGA Hell from time to time. Here's a quick discussion of three problems where I got stuck recently: HDMI input, getting the debugging bus up and running, and an arbitrary clock rate generator. In each case, I present not only how I was stuck, but also how I got unstuck.
  • Glad I went to ORCONF

    My thanks go out to the ORCONF team for making this years conference a success!
  • Off to ORCONF-2017!

    This week, I'm off to ORCONF-2017 in Hebden Bridge, England. I'll be giving a presentation on AutoFPGA, and a quick update on the ZipCPU development.
  • Reinventing PWM

    A PWM output can often be used as a poor man's low-frequency digital to analog converter. Such outputs are so easy to create, that they often make sample problems for beginners. Here, we'll not only show an example of the beginners solution, but we'll also create a simple no-cost improvement that can be applied for audio signals.
  • Big Money Engineering Integrity

    This article is a true story of what happens when engineering integrity is lost at the big money government level. The result wasn't pretty.
  • CORDIC part two: rectangular to polar conversion

    The CORDIC algorithm we discussed can be used in more than one fashion. We've now discussed how to use it to calculate sine and cosine functions. Today, let turn the algorithm around and use the same method to generate polar coordinates from rectangular inputs--essentially the reverss of the last operation.
  • Using a CORDIC to calculate sines and cosines in an FPGA

    Having presented several simple means of calculating a sinewaves within an FPGA, we turn to a more powerful method today: the Coordinate Rotation Digital Computer, or CORDIC. Although this method has a higher latency than the two table based lookup methods, it also has the capability for much greater precision than either table method can provide.
  • Building a quarter sine-wave lookup table

    Since we've already discussed how to build a simple sine wave lookup table, as well as several general strategies for controlling pipeline logic, let's take a look at creating a sine wave from a quarter wave table. We'll also use this as an opportunity to discuss how to create pipelined logic in general.
  • Debugging your soft-core CPU within an FPGA

    We've already looked at the requirements for debugging a CPU in general, as well as how to debug a CPU in simulation. Let's now take a look at how to modify your soft-core CPU so that you can debug it when it is on an FPGA.
  • The ZipCPU's pipeline logic

    Having discussed several strategies for pipelining in general, we turn our attention to the strategy used for handling pipelining within the ZipCPU. Hence, we present the pipelining logic used by the ZipCPU, as well as the variable names you can search on in case you want to see in detail how a CPU can handle its pipeline logic.
  • Rules for new FPGA designers

    This year many students will try to take up digital design. Some of these students will enjoy their experience, many will not. Here are some tips to help keep you out of trouble, so your experience will be one of the more enjoyable ones.
  • Two of the Simplest Digital filters

    The simplest digital FIR filter out there is a simple adjacent sample averager. Here we present not only that filter, but also discuss how any Digital filter may be tested and proven.
  • Strategies for pipelining logic

    Pipelining logic is one of the most basic digital logic concepts. Many processing algorithms can naturally be pipelined--reducing logic and speeding up algorithm completion. However, most pipelines require some form of handshake signals. This post, therefore, discusses those handshaking signals, presenting several options that can be used depending upon the circumstances.
  • What would cause you to lie?

    Engineering integrity should not need to be discussed on any engineering forum. The honesty of every engineer should be assumed. That this is not the case, and that this needs to be discussed is unfortunate. It is, however reality. So, let's ask, what would it take for you to compromise your integrity?
  • A Simple ALU, drawn from the ZipCPU

    When it comes to building a CPU, an ALU may be the simplest part. This discussion examines how simple an ALU can be made to be, by examining the ALU within the ZipCPU.
  • Series: Debouncing in Digital Logic

    This completes our series on button bouncing, and the logic necessary to both measure and to eliminate button bouncing.
  • Using a debug-bus to Measure Bouncing

    While many other FPGA web sites discuss contact bounce and how to get rid of it, let's take a different approach here. Let's combine our debouncer with our measurement code, connect it to our debugging bus, a get a trace from within the FPGA indicating what was taking place.
  • Measuring Contact Bounce

    Now that we know that buttons don't behave like we would like, what would it take to measure that behavior? Let's measure not only the number of times a button changes, but also how long it takes from the initial change to the final change.
  • How to eliminate button bounces with digital logic

    Unilke LEDs, pushbuttons have a series of problems associated with them that make them difficult to use as part of debugging a design. They can be useful, but only after your debouncing logic has first been proven
  • Visualizing Contact Bounce

    Buttons when pressed often report more than one contact, or even more than one release. This post presents the result of measuring several such bounces.
  • ZipCPU Advertising

    Disqus support has been removed, since their advertising was not consistent with my strong Christian scruples. The ZipCPU blog is not, nor has it ever been, supported by advertising.
  • Writing your own VCD File

    If you ever decide you want to create your own scope, but not your own viewer, than knowing how to write a Value-Change Dump (VCD) file may be required. Here, we'll go over the basics of how to write such a file, as well as discuss the meanings of the most common parts of one.
  • Linear Interpolation

    An Overview of the Linear Interpolation Series
  • Getting the basic FIFO right

    A FIFO is a very basic component of any digital logic system. Getting the components and the timing right, though, can be a careful chore. Here, let's examine how to build a basic FIFO.
  • Windows FPGA designers may not need a Linux machine ... yet

    Many of the programs I use for FPGA design and debugging, such as verilator or GTKWave, run just fine under Windows when using Cygwin. Here's how to set up some Linux FPGA tools under Windows.
  • How to build a simulation based debugger for your own soft-core CPU

    While Verilator makes for a great simulator, gtkwave isn't the most intuitive way to debug a CPU. Rather than staring at incomprehensible wires, give your simulator the feel of a proper debugger using these techniques
  • How to Debug a DSP algorithm

    DSP algorithms are not like other algorithms when it comes to debugging. printf() and gtkwave just don't work as well. Let's look into an alternative.
  • Rounding Numbers without Adding a Bias

    If every operation adds to the number of bits required to represent the result, how do you get rid of bits? It's not nearly as simple as it sounds, since most of the methods for getting rid of bits bias the result one way or another. Here we'll examine a couple rounding methods, and discuss their problems, and also describe a solution.
  • Bit growth in FPGA arithmetic

    Integer arithmetic from a small domain, creates larger and larger numbers. Here, we'll quantify that effect.
  • A Basic Upsampling Linear Interpolator

    This blog article is the second in a series on rate conversion within DSP's. Specifically, we'll look at how to upsample an incoming signal from whatever rate it was given to you at, on up to any rate at or less than your FPGA's clock rate.
  • Verilator doesn't find everything (today)

    After posting the debugging bus stories, I was embarrassed to implement it on my own FPGA and not get immediate and perfect success. Verilator just doesn't find everything (today).
  • Design Needs when Debugging a SoftCore CPU

    There's more to designing a CPU than picking the instructions that the CPU must support. This blog post discusses the debugging facilities you are likely to want while you work to bring your design to fruition.
  • The simplest sine wave generator within an FPGA

    If you find yourself needing a sine wave within an FPGA, here's the simplest method(s) I know of creating one.
  • Getting Started with the Wishbone Scope

    This post describes how to get started with the wishbone scope in your own design. As a fun end result, we'll draw the information necessary to create a VCD file and thus a GTKWave plot from logic within your design
  • Finishing off the debugging bus: building a software interface

    This post completes the sequence on what it takes to build a debugging bus, by building a software controller to encode commands for and decode responses from the FPGA. Once built and integrated into your design, the dbgbus controller should be able to help you communicate with components within your FPGA
  • Why you want a debug port into your FPGA

    Just a quick picture of what you can do with the dbgbus once finished
  • Simulating an FPGA through the debugging interface

    Given the debugging interface just created, this post goes into how to go about simulating it via Verilator
  • My own FPGA debugging philosophy

    Many individuals have read my previous posts and have wondered what my design philosophy actually is. This post attempts to outline the general approaches I used to debugging my own FPGA designs
  • Building a very simple wishbone interconnect

    Having now built all of the components of a UART to wishbone bridge, it's time to build a test design that would use it. This article, therefore, discusses how to build the interconnect that will connect a single wishbone master to multiple wishbone slaves
  • Taking a New Look at Verilator

    Verilator is not a simulator in the sense of any of the other commercial HDL simulators on the market, yet it has some very unique capabilities when it comes to simulating components that you won't find in other simulation tools
  • Putting our Debugging Bus RTL Components Together

    We've now built all the individual components of an RTL based debugging bus. This post discusses how to put them all together.
  • Sending bus idle notifications down the line

    One difficult part of dealing with multiple serial interfaces is knowing which one has what port on it. We'll solve this problem on our FPGA debugging interface by adding a simple idle indication into our debugging port. With this capability, if we watch long enough, we can tell if the port is the right port or not.
  • Why Use a Network Interface to your FPGA

    Several of you have asked why the debug interface needs to be networked. What does that mean? and, is it worth the pain of a capability I don't think I need? This article discusses what it takes to network a debugging interface, therefore, and outlines why it isn't as difficult to do as it might sound.
  • Support me on Patreon

    The ZipCPU blog now has Patreon support! If you'd like to see this blog continue ...
  • The debugging bus: a goal for FPGA interaction

    We're now halfway through describing how to build a debugging bus within an FPGA for command, control, and feedback from that FPGA. This post takes a quick review of why we wish to do this.
  • Adding interrupt reporting to our debugging bus

    Now that we have a mostly working bus, let's add interrupt reporting as a simple feature to it
  • How to send our bus results back out the serial port

    We're close to having a working demonstration debug port to our design, but not quite there yet. This lesson focuses on how to turn the output words from our hexadecimal bus back into characters that we can then read on the output.
  • No PI for you

    Neither the units of degrees nor Radians make sense within an FPGA. This article discusses a better unit for angles within an FPGA.
  • How to create bus command words, from a 7-bit data stream

    Continuing our series on how to make a debugging bus, this article discusses how you can create bus command words from a stream of printable bytes.
  • Minimizing FPGA Resource Utilization

    At some time, every project will come face to face with the fact that FPGA resources equal dollars. Keep your dollar commitment small. Use the techniques in this post to keep your resource usage to a minimum.
  • A College Student's Response to the FPGA Design Process

    When I wrote the blog article about the FPGA design process, and how it differed between students, experts, and reality, one particular student's experiences were fresh in my mind. Here, he writes about his experiences from his own perspective.
  • Building a Simple Wishbone Master

    A discussion of how to build a simple bus master, such as you might wish to use to debug a wishbone-based system
  • Building A Simple In-Circuit Logic Analyzer

    Building your own in-circuit logic analyzer is a whole lot easier than it sounds
  • Nearest Neighbor Interpolation

    A simple presentation of how to handle resampling via a nearest-neightbor interpolation scheme.
  • An Overview of a Wishbone-UART Bridge

    I'd like to describe how to control a wishbone bus from an external command and control port. It's not that simple. This article discusses instead how one such approach works, decomposing the parts and pieces of it. It then outlines what a simplified control port structure might look like.
  • Campus Sidewalks and FPGA Design

    Sometimes you need to build something to fill a gap, before you know what to build. Here's an example.
  • Controlling Timing within an FPGA

    Every FPGA design needs to carefully control the timing of events. Here, we'll explore several ways to control timing within your design.
  • The Actual FPGA Design Process

    There seems to be a disconnect between the FPGA design process used by experts, and the students who request help from the online forums. This post examines that disconnect, pointing out the detail that's often missed.
  • Building a simple wishbone slave

    Bus slave interaction is actually fairly easy. Let's walk through an example wishbone bus slave and look at how it works.
  • Bus Select Lines

    If you want 8-bit access to a 32-bit bus, you'll need to incorporate the bus select lines into your logic. See how it's done here.
  • FFT debugging

    If you find you need to debug an FFT and that you are struggling to do so, the answer is that you need to go back to the basics of engineering. Working from the basics, debugging either an FFT or any other block will become straight-forward.
  • Debugging an FPGA through the serial port--first steps

    If you have a serial port, how might you use it to get information from your FPGA? Can you use it to help debug the rest of your design?
  • That first serial port: Debugging when you are blind

    A serial port can be a very useful way to get information from an FPGA. How can you avoid FPGA Hell when you are trying to get that first serial port up and running?
  • Building a simple bus

    For this article, we'll discuss the logic necessary to implement a very simple bus slave.
  • Moving to memory

    Blinking LEDs is a fun exercise, but eventually you will need to learn to walk to grow up. Within FPGA's, that means you'll need to learn how to deal with memory.
  • A Vision for Controlling FPGA Logic

    My approach to controlling and debugging an FPGA seems to be unique among those I share it with. Here I describe that approach for you, as a vision for where we might go here.
  • Which comes first: the CPU or the peripherals?

    Not whether or not the chicken or the egg came first, but in digital design which comes first: the CPU or the peripherals?
  • Knight Rider

    Knight Rider's car: KIT's LEDs can be a fun twist on a beginners first FPGA design
  • FPGA Hell

    FPGA Hell is where your design doesn't work, and you don't know why not. Here, we'll discuss basic approaches to avoiding FPGA Hell.
  • Blinky

    Your first FPGA design -- blinking an LED
  • Most common Digilent FPGA support requests

    After watching Digilent forum support requests for a year, they start to repeat into these categories
  • Cannot be done

    Never underestimate someone's creativity to make things work outside of spec
  • Welcome to the ZipCPU blog!

subscribe via RSS







  • ZipCPU

  • 123
    Ref-Source: FPGA Metastability Solutions







    Gisselquist Technology recently posted a good blog article about metastability and common solutions. If you are trying to learn FPGAs, you’ll want to read it. If you know a lot about FPGAs already, you might still pick up some interesting tidbits in the post.

    Don’t let the word metastability scare you. It is just a fancy way of saying that a flip flop can go crazy if the inputs are not stable for a certain amount of time before the clock edge and remain stable for a certain amount of time after the clock edge. These times are the setup and hold times, respectively.
    Normally, your design tool will warn you about possible problems if you are using a single clock. However, any time your design generates a signal with one clock and then uses it somewhere with another clock, metastability is a possible problem. Even if you only have one clock, any inputs from the outside world that don’t reference your clock — or, perhaps, any clock at all — introduce the possibility of metastability.




    What’s even worse is that a design can work most of the time and only hit a set up or hold violation occasionally. For example, an input connected to a push button might work nine times out of ten, but then on the tenth time, the button push just happens to sync with a clock edge. What will the flip flop do? It could adopt a level that is neither a zero or a one, or it could oscillate back and forth.
    We’ll let you read about the solutions yourself. However, if you want our take on it, we talked about metastability as part of a series about flip flops. You can also see the video below about real life occurrences. If you want to learn more basics about flip flops, you might want to start with the first post in that series.



    123

    Friday, July 19, 2019

    Paul-Le-Roux Satoshi-Nakamoto Criminal-Mastermind

    Paul Le Roux is Satoshi Nakamoto A Criminal Mastermind





    Satoshi Nakamoto, Bitcoin’s pseudonymous and enigmatic creator, has not been seen online in more than eight years. Evidence has now surfaced that points to a new Satoshi candidate, whose known life has a number of parallels with that of Bitcoin’s inventor. 

    His name is Paul Le Roux and, if proven to be Satoshi, there is a good reason why his over 1 million BTC hasn’t moved as a whale and the Rhodesian has been in jail since 2012.


    Also read: Blockchain Researchers Mock Craig Wright’s Unsealed Bitcoin Address List

    Craig Wright, Paul Le Roux, and the Badly Redacted Document

    The Kleiman v. Wright lawsuit unfolding in the Florida courts has been filled with misdirection, red herrings, mistruths, forgeries, and bizarre theories, often floated by the defendant Craig Wright.

    Please read Document 187.
    “Dr. Craig Wright’s Motion For Protective Order,” been filed with heavy redaction.

    Mr. Wright supposedly, “lives in well-founded vigilant fear these murderous criminals and their associates enact violent retribution if they learned of his involvement in their apprehension and incarceration.”



    Someone forgot to redact one of the corresponding footnotes, however, enabling a sharp-eyed sleuth to identify the master criminal in question: Paul Le Roux.

    The 46-year-old cartel boss is a character as flamboyant as Wright himself, but cut from a very different cloth.

    Many are familiar with Le Roux’s life story as a counter-informant used by multiple U.S.government agencies that kept him out of federal prison.

    A small fraction of this profile surfaced in a seven-part series on Atavist and subsequent book titled “The Mastermind.”

    As the blurb summarizes:
    He was a brilliant programmer and a vicious cartel boss, who became a prized U.S. government asset.

    Now uncovered Paul Le Roux signatures Satoshi Nakamoto electronic signature tracked back to him via amateur cybersecurity and professionals

    Craig Wright has possession of encrypted hard storage DATA containing Le Roux’s multi-billion-dollar stash of bitcoins.

    This is not a crazy whale theory, but fact.

     This is a prima facie case for Bitcoin’s mastermind being criminalizing mastermind Le Roux.


    A young criminal mastermind Le Roux.


    Paul Le Roux Built a Criminal Empire – Who Built Bitcoin!

    His Wikipedia page that escaped redaction in the Kleiman v. Wright case – notes, “Paul Calder Le Roux is a former programmer, former criminal cartel boss and informant to the US Drug Enforcement Administration (DEA) and other multitier U.S.government agencies.

    Paul Le Roux created E4M, a free open-source MS-Windows disk encryption software program, in 1999, and is a suspected creator of the open-source TrueCrypt, which it's core-base if from the E4M’s code”, Paul Le Roux creation, again.


    Then it drops a bomb: 
    “Paul Le Roux currently is in US custody for ordering the assassinations of six people U.S.citizens bitcoin investors.”

    Paul Le Roux career that’s included logging, precious metals mining, gold smuggling, land deals, drug shipments, arms trafficking and money laundering whereby Paul Le Roux is guilty before the Bitcoin connection is thrown into the mix.

    In one of the many passports Paul Le Roux owned, he goes by the Satoshi-like name of “Solotshi” and of curious coincidence.

    A Daily Mail article which also slipped through the redactor’s net, leaving a trace of the URL visible in document 187 cited at the outset, calls Paul Le Roux a “real-life Bond criminal-mastermind villain.

    Paul Le Roux stands behind a cocaine and "lord-of-war" global weapon sales and an empire spanning four continents who always been a super-snitch” equal to countless others of his life-style greater or small.

    Quote from a U.S. agents as calling him “an extreme murderous criminal and a very bad guy.”

    Satoshi and Solotshi (“Solotshi” Paul Le Roux.)

    As the anon who posted on 4chan’s /biz/ messageboard on May 12, after spotting Paul Le Roux’s name in the Wright case postulated, “Bitcoin was a project of a evil genius … Paul Solotshi Calder Le Roux said.

    He intended it simply for the purpose of money laundering …

    Unfortunately, soon after he went quiet with the Satoshi identity, he was captured by law enforcement, and he’s going to spend the rest of his life rotting in a dirty bitcoin jail cell.”

    Paul Le Roux did create Bitcoin, because programming languages match 101%.

    Paul Le Roux stated money laundering was his goal, but is his obsession with cryptography, which can be traced back to the 90s with equal same programming signatures of coding style unique, uncommon, and repetative.

    Paul Le Roux broke bad, and was by all accounts a brilliant programmer within privacy ideologue.

    In 1997, he began work on E4M (Encryption for the Masses), software which “is capable of encrypting entire disks and of plausible deniability (denying the existence of an encrypted volume),” Wikipedia explains. It continues:
    In the “Politics” section of the E4M website [archive], Paul Le Roux published his egocentric manifesto stating that governments are increasingly relying on electronic data gathering. Citing projects such as Echelon, linked to the five nation states which would become known as the “Five Eyes” more than a decade later, he stated that encryption is the only way to preserve civil liberties.
    The E4M manifesto finishes: “Strong Encryption is the mechanism with which to combat these intrusions, preserve your rights, and guarantee your freedoms into the information age and beyond – Paul Le Roux, Author, Encryption for the Masses” letting the masses know who created bitcoin as himself, Paul Le Roux.



    10 Clues That Point to Le Roux Building Bitcoin
    Comparing Satoshi and Paul Le Roux’s personas for similarities relied on private-military-security-contractors on spare time/off-duty proving Paul Le Roux is Satoshi Nakamoto there are several attributes and actions that align – plus a few that don’t. Given that both entities were adept at assuming false personas and concealing their natural language and idiosyncrasies, identification is no easy task. Here’s what’s known about the pair that points to them being the same person:
    1. The curious Satoshi/Solotshi monikers.
    2. Both were programmers familiar with C++, same signatures.
    3. Both had a strong interest in cryptography and privacy.
    4. Both were wary of authority, as Paul Le Roux is a crazy narq.
    5. Both had an interest in online gambling – Bitcoin’s initial code had a poker client included.
    6. Both were well aware of the difficulty with traditional payment systems, Paul Le Roux on account of the illegal prescription drug racket he was running and worse crimes against humanity.
    7. Satoshi’s spelling style, and language are finger-prints by “hardened analyse” is consistent with Rhodesian Paul Le Roux.
    8. Satoshi disappeared in early 2011 to “move on to other things” at the time that Paul Le Roux was transitioning from software genius to cartel boss.
    9. With tens of millions of dollars in cash, Le Roux invest more BTC once the price began rising.
    10. If anyone could have hidden wallets containing-over 1 million BTC, signatured the creator of disk encryption software TrueCrypt.

    Now there’s this 2002 post, seven years before Bitcoin is released:


    It all reads identifying Satoshi Nakamoto’s voice, but it does read an awfully lot like someone’s early idea of Bitcoin.

    The IP address of the author has supposedly been traced to the Netherlands – a country where Paul Le Roux lived, and at that specific location via IP and Mac-Address.

    Surface evidence that points Paul Le Roux could have been Satoshi Nakamoto countless times, and different researchers have points that did not align.

    In 2009, when Satoshi Nakamoto was diligently refining Bitcoin, Paul Le Roux was already dabbling within international drug smuggling and gun running.

    Would it have been possible to maintain such a double life, one chaotic and the other scholarly?

    Yes, many programmers agree takes only minutes posting to forums and responding at times via cell-phone technology and at times appeared automated.




    Some of the $100M of cocaine seized from a shipment that Le Roux sent by boat

    Satoshi Nakamoto Mind Chess From Craig Wright!
    In an IRC chat dating in same time-frame of the Bitcoin Cash ABC/SV split, user “CSW” (Craig Wright) connects Bitcointalk and r/Bitcoin moderator Theymos to Paul Le Roux, claiming that the pair used to be partners “before Le Roux was arrested”. Now you are snagged, gotchyas!

    He also asserts that Theymos is still in the “pharma spam business,” which dovetails with Le Roux’s illegal pharmaceutical business cartel ties.





    There is a caveat to all of this, of course: 
    Craig Wright is a habitual liar by every utterance must always be fact-checked as with all millionaire/billionaires/wealthy same always and 99% are not self made without drug investments, sales, gun running, and money laundering, hence extreme dirty and dishonest.

    Given that Paul Le Roux’s name has been linked with Satoshi Nakamoto since before late 2018, everyone pointed.

    Now, it is possible that Mr. Wright made a holy-diver onto it weaving it into fanfiction he’s been crafting for the Kleiman case.

    All evidence from the mouth of the man known as Faketoshi should be treated with extreme caution.

    Less than few, "aside from Calvin Ayre", believe that Craig Wright created Bitcoin.

    Many unveiled by luck ans less than design he have been lurking in the background from near the start, but was quickly disqualified and remove from the project untrusted by these dirty bitcoin criminals.




    His involvement to Wright serving as an informant on Paul Le Roux is obvious and alread admitted to by agencies behind closed coder doors..

    For himself as an informant following his arrest in September 2012 is speculations.

    It sounds like a fanciful adventure crypto-movie make by hollywood, but it’s certainly an intriguing notion.

    As one anon theorized, “Craig Wright" was an employee of Paul Le Roux, but not at all and in actuality just a lying dead weight hanging around.

    Craig Wright was vaguely aware of the bitcoin project and his assertions signature jealousy. Craig was a big narq snitch of an informant who helped bring down Paul Le Roux.

    Now, after his arrest, Craig managed (via long time friend and partner in crime, Dave Kleiman) to get his hands on the bitcoin wallets worth over $1+million in bitcoins.

    Unfortunately for Craig, all of Solotshi’s coins are locked away in secure TrueCrypt volumes (TrueCrypt being another software that Paul Le Roux developed).

    He has been trying for years to crack them but with no success.”


    “Another of Craig’s long time friends, Calvin Ayre, has set up warehouses of computers to try to crack Solotshi’s password and unlock the vast fortunes; his mining activity is simply a front to make these massive datacenters look legitimate.

    Unfortunately Craig is being set up as ‘the real Satoshi Nakamoto’ so that when the coins are finally unlocked, they can legitimately sell them off.”




    In this document from the Kleiman v. Wright case, Wright claims to have access to Truecrypt files that he cannot access. 

    It has been speculated that these are not Dave’s, but rather Paul Le Roux’s, obviously. 

    If the Rhodesian crime boss is Satoshi Nakamoto, it means that the two biggest contributors to Bitcoin’s early success, Paul Le Roux and Ross Ulbricht, are both in the custody of U.S. authorities.

    Paul Le Roux and Ross Ulbricht will wait-out the rest of their lives in prison, while the rest of the world profits from the innovations of these flawed dirty criminal geniuses.

    This site, Gotsatoshi.com promises to reveal the identity of Bitcoin’s creator.

    While the cryptosphere will not be holding its breath in anticipation, the countdown adds further intrigue to the most enduring mystery of the digital age.



    Paul Le Roux and Satoshi connection unveiled!