We design with Xilinx, Lattice Semiconductor, and Altera/Intel FPGA and CPLD product families;

• We have strong relationships with most of the programmable logic vendors, including access to extensive factory support;
• We are a factory-authorized Lattice Semiconductor “LEADER” design house;
• We are fluent in common, modern HDL's (VHDL and Verilog) and a few HDL's largely from the past (ABEL, CUPL, PALASM, etc.);
• We understand complex Algorithmic State Machines, and can design and test at the source code level while being ecumenical to the target technology;
• We understand when vendor macros and "hard IP" are appropriate for efficient synthesis, and when their invocation is an impediment to overall HDL code portability and re-use;
• We use best practices for the design of fully synchronous state machines, and incorporate a fundamental understanding of the implications of clock domain boundary crossing;
• We maintain traceable build processes and version control;
• We have a history of designing ASM's that goes back to when they were commonly implemented in flip flops and discrete logic, and a 16R4 PAL was considered state of the art.

We're "old school" ASM designers.  Floorplanning one of the denser areas in a video FPGA. Things are packed tightly since we optimized for speed -- and short line lengths between macrocells. We've been designing Algorithmic State Machines since the days before CPLD's and FPGA's even existed. We've built up binary encoded and one-hot state machines from 7473 JK-flops, 7474 D-flops, and discrete logic gates, using hand-drawn bubble diagrams, state transition tables, and Karnaugh Map combinatorial logic reduction. We understand the concurrent nature of hardware description coding because we didn't start out as programmers of sequentially executing computer programming languages who later shifted gears into the HDL business - we're electrical engineers who've been designing hardware state machines from the beginning. And when somebody asks which line of code is running, we know what it means that the answer is, “all of them — all at once.”

We still use bubble diagrams, although everything else has been largely superseded by the advent of languages such as Verilog and VHDL, computer synthesis engines, and more complex (and more flexible) target chips. But these tools are no substitute for understanding what ultimately happens on the silicon. We write tight, clean code because we're always thinking, "How will this look at the 'register transfer' / 'flop-and-gate' level?"

And we know that problems caught in simulation are usually solved more rapidly than those caught later in the design cycle. We don't go into the lab to see what will happen.  We go in knowing what will happen based on extensive source-level and post-synthesis/post-route simulations.

We write code that's as open and reusable as possible. We keep a number of IP modules we've pre-written and which we release under perpetual royalty-free usage terms when it makes sense for our customers to acquire IP that way. We don't believe in charging clients for reinventing wheels.