Quite a few digital design engineers limit their activities to architecture design and RTL coding. Missing first hand experience with later design phases is then easily detected by how much their code and architecture complicates physical implementation. Areas where this surfaces most often are clock/reset schemes, clock domain crossings (CDC) and scan/DFT aspects.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY | |
;by doppelganger ([email protected]) | |
;This file is provided for your own use as-is. It will require the character rom data | |
;and an iNES file header to get it to work. | |
;There are so many people I have to thank for this, that taking all the credit for | |
;myself would be an unforgivable act of arrogance. Without their help this would | |
;probably not be possible. So I thank all the peeps in the nesdev scene whose insight into | |
;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// A round-robin priority arbiter for valid/ready signaling using carry chain logic. | |
module arbiter#(parameter N = 2) | |
( | |
input wire clk, | |
input wire [N-1:0] s_valid, | |
output wire [N-1:0] s_ready, | |
output wire m_valid, | |
input wire m_ready | |
); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{-# LANGUAGE GADTs #-} | |
{-# LANGUAGE ImplicitParams #-} | |
{-# LANGUAGE TypeFamilies #-} | |
module Assert | |
( assertProperty | |
, initialAssume | |
, getReset | |
) where | |
import Clash.Prelude |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/env python3 | |
import re | |
import sys | |
import time | |
import subprocess | |
import multiprocessing | |
import termplotlib as tpl | |
import numpy as np |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# This is an nmigen delay line for ECP5 FPGAs using the open source toolchain. It strings together a series of | |
# manually placed carry chains into a "thermometer." It returns a signal that's (length) long that represents | |
# the chain "snapshotted" at the primary clock domain (using the flip flops colocated in the slice). | |
# | |
# This can be used in a Time to Digital Converter (i.e. to measure the time between to events) or in | |
# an ADC by comparing (with LVDS) a signal to a reference signal. | |
# | |
# Note that the bit precision (read: delay per carry element) varies as a function of temperature. On | |
# a LFE5U-25F-8MG285C, I've measure delay times of approximately 43ps on average. Due to assorted reasons, | |
# the delay time will vary between bits and due to variations in routing (even when manually places), you might |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// video generation | |
// ~12,288,000 hz pixel clock | |
// | |
// we want our video mode of 320x240 @ 60hz, this results in 204800 clocks per frame | |
// we need to add hblank and vblank times to this, so there will be a nondisplay area. | |
// it can be thought of as a border around the visible area. | |
// to make numbers simple, we can have 400 total clocks per line, and 320 visible. | |
// dividing 204800 by 400 results in 512 total lines per frame, and 240 visible. | |
// this pixel clock is fairly high for the relatively low resolution, but that's fine. | |
// PLL output has a minimum output frequency anyway. |