logic analyzer 4usamuel/pdm/report.pdf · to analyze the signals, determine interesting sequences...

Logic Analyzer 4U

Master Project

Winter 2010

Student: Samuel Burri

Supervisor: René Beuchat Laboratoire d’Architecture des Processeurs IN-F Ecublens CH-1015 Lausanne

http://lap.epfl.ch

of 31

1. Abstract Logic Analyzer 4U is a self-contained 48 channel logic analyzer with a sample rate of 240MHz. Logic

Analyzer 4U uses FPGA4U and integrates a logic analyzer together with a web server for a simple and

efficient user interface. An add-on printed circuit board ensures proper interfacing to digital circuits

using voltage levels between 1.2V and 3.3V. With these specifications Logic Analyzer 4U aims to

become the tool of choice for students debugging digital circuits, whether they are microcontroller

based or on an FPGA.

During the work on this project several independent hardware and software modules were

developed which can be used by students in their own FPGA4U designs. They are well documented

and can also be used as example designs to inspire students in courses related to embedded system

design and VHDL.

This document describes the design and development of Logic Analyzer 4U and touches the domains

of PCB design, hardware description using VHDL, system software development in C and web

development with HTML, CSS and JavaScript. These domains are brought together to illustrate the

workings of an embedded system and provide a very usable, high-performance logic analyzer.

of 31

2. Table of contents 1. Abstract ........................................................................................................................................... 2

3. Introduction .................................................................................................................................... 4

4. Related Work .................................................................................................................................. 5

5. Logic Analyzer 4U ............................................................................................................................ 7

System overview ................................................................................................................................. 7

Interfacing the circuit under test .................................................................................................... 7

Sampling and storing the signals .................................................................................................... 9

Hardware System Design .................................................................................................................. 11

Voltage translating interface ........................................................................................................ 11

FPGA logic design .......................................................................................................................... 12

Software System Design ................................................................................................................... 20

Firmware ....................................................................................................................................... 20

Client-side software ...................................................................................................................... 21

6. Conclusion and future work .......................................................................................................... 23

7. References .................................................................................................................................... 24

8. Appendix ....................................................................................................................................... 25

PCB schematic and layout ................................................................................................................. 25

VHDL source of the SDRAM controller ............................................................................................. 27

of 31

3. Introduction With the widespread introduction of Field Programmable Gate Arrays (FPGAs) in universities it

became possible for students to design and implement complex embedded systems, encompassing

hardware as well as software, in a relatively short amount of time. As the complexity increases

however, it is more and more likely that errors are introduced in the system and hence debugging is

needed. As embedded systems present a tight interaction between hardware and software it is

increasingly difficult to locate errors and therefore powerful tools are needed to assist the system

designer. In the world of software design the notion of a debugger is well understood and debugging

software is used throughout the design cycle. In the embedded domain however, where custom

software works in close connection with custom hardware, the notion of a software debugger needs

to be expanded to take into account the hardware.

A logic analyzer, a unit to record and display the evolution of digital signals, presents a powerful tool

to aid with debugging custom hardware. A logic analyzer is used where classical methods such as

software debugging or hardware simulation fail to locate the problem in the embedded system. The

logic analyzer captures physical signals either on-chip for a FPGA-based system or off-chip if the

critical signals are lines on a Printed Circuit Board (PCB).

The logic analyzer presented in this work is itself an embedded system running on the FPGA4U

platform developed at EPFL and is aimed towards helping students design digital systems based on

FPGA4U or other microprocessor platforms. It provides the interface to acquire 48 digital signals in

parallel at a rate of 240MHz and store the signals in memory for later reviewing or archiving. The

data is stored in on-chip buffers backed by a high-speed SDRAM interface. An embedded processor

and network interface provide a web based user-interface which can conveniently be accessed with

any web browser.

The rest of this work is organized as follows: Section 4 describes some similar projects available in

the public domain or commercially, points out their differences and shortcomings and compares

them to Logic Analyzer 4U. Section 5 presents the design of Logic Analyzer 4U detailing the tradeoffs

necessary to use the FPGA4U base with minimal additions. Furthermore the software design

approach is explained, decomposed in a section about the firmware running on FPGA4U and the

client-side software responsible for the data presentation in the web browser on the user’s machine.

Section 6 concludes the work and lays out some possibilities for future enhancements. Further

information concerning technical details and the full source code for the project can be found in the

files distributed with Logic Analyzer 4U at http://fpga4u.epfl.ch/wiki/LogicAnalyzer4U.

of 31

4. Related Work In this section we want to discuss projects and existing solutions with similar goals as Logic Analyzer

4U. The community of electronic enthusiasts on the World Wide Web has developed a broad range

of tools serving similar purposes, namely observing digital signals to help in debugging a circuit. The

simpler and cheaper approaches are based on microcontroller circuits. What all of them have in

common is the low sampling rate and small to non-existent sample memory. They may be well

suited for the electronic hobbyist programming his first microcontroller to debug the serial

connection to another chip running at a frequency of some kilo-hertz. To analyze anything with a

frequency of more than some MHz they are completely useless. An example of this category of logic

analyzers is the one offered commercially at poscope.com. For 100€ you get a box with USB

connection and 16 logic inputs for 5V signals with a maximum sampling rate of 8MHz.

The more sophisticated projects use a FPGA or its smaller brother a CPLD1 in order to achieve a

sampling rate beyond 100MHz. To store the sampled data some projects use on-chip memory only

and achieve a very high sampling rate, other projects use external memory, generally SRAM and are

limited in the sample rate by the SRAM frequency. To display their data most of the projects use a

simple computer program which is specific to their hardware. At sump.org you can find a logic

analyzer project using a FPGA development board from digilentinc.com that sells for 100USD and

has a 1MB SRAM chip. This logic analyzer can reach a sampling rate of 200MHz when using 16

channels and store 256 kilo-samples in the SRAM running at 100MHz. The analyzer is connected to

the PC through a serial connection and data is displayed using a Java application. All source files are

freely available.

There is only a small difference from the publicly available projects to the best priced commercially

available products. Examples of this kind of products are found at pctestinstruments.com or

salaea.com/logic where the latter is microcontroller based. They range in price from about 150$ to

500$, offer between 8 and 40 channels and a sampling rates around 200 million samples per second

(MSps) for FPGA based solutions. Cheaper products are based on microcontrollers and can generally

be identified by a sampling rate well below 100MSps and small memory. Some products eliminate

the sample memory entirely and stream their data directly to the computer. The main difference to

fully open and documented projects lies in the quality of their software which generally has a much

nicer appearance than that of hobby projects and offers a rich suite of protocol interpreters and

displaying options.

On the other end of the performance scale we find commercial products intended for industrial use

which will easily cost several ten thousands of dollars and in turn offer capabilities far exceeding

what is possible using FPGA4U. Well known manufacturers are Tektronix, Agilent and National

Instruments to name a few.

Logic Analyzer 4U should be compared with available solutions based on a FPGA. Logic Analyzer 4U

uses the FPGA4U as its base platform and adds a simple voltage translating interface to reliably

acquire signals from low voltage digital circuits. To use it to debug the design on another FPGA4U

the two boards can directly be stacked and the logic analyzer in the top FPGA will sample whatever

1 Complex Programmable Logic Device

of 31

the bottom FPGA presents on its connectors. A major shortcoming of FPGA4U for the design of the

logic analyzer is that there is only one SDRAM memory connected to the FPGA and the memory

bandwidth is therefore restricted.

Table 1 lists the main characteristics of some of the discussed logic analyzers and compares them to

Logic Analyzer 4U.

Logi

c A

nal

yzer

4U

FPG

A

48

24

0M

Hz

2k

sam

ple

s

CH

F 3

0 +

FP

GA

4U

3M

sam

ple

s fo

r lo

w t

ran

siti

on

rate

tek.

com

ASI

C

34

50

0M

Hz

32

M s

amp

les

USD

10

’00

0

Nu

mer

ou

s tr

ade-

off

op

tio

ns;

sam

plin

g fr

equ

ency

up

to

2G

Hz

sale

ae.c

om

Mic

roco

ntr

olle

r

8 24

MH

z

- USD

15

0

pct

est

inst

rum

ents

.co

m

FPG

A

34

50

0M

Hz

2k

sam

ple

s

USD

39

0

Sam

ple

co

mp

ress

ion

wh

en

f acq

< 2

00

MH

z;

exte

rnal

clo

ck a

t 2

00

MH

z

sum

p.o

rg

FPG

A

16

200

MH

z

256

k sa

mp

les

USD

100

po

sco

pe.

com

Mic

roco

ntr

olle

r

16

10M

Hz

- EUR

100

Nam

e

Typ

Nr.

of

chan

nel

s

Sam

ple

ra

te

Sam

ple

mem

ory

Pri

ce

Co

mm

ents

Table 1: Comparison of different logic analyzers.

of 31

5. Logic Analyzer 4U Logic Analyzer 4U is a project spanning multiple areas of computer and electronic engineering:

Software development for a real-time embedded operating system

Web user interface software development

Hardware development in the form of VHDL design targeted at an FPGA

PCB hardware design for an external interface circuit

The main goal of the project is to give students a tool to aid in the development of digital circuits in

courses related to digital system design. The system should be capable of capturing digital signals in

a circuit and present those measurements in an appropriate manner. At the same time Logic

Analyzer 4U should be usable as example of a complete system on chip project.

The following sections describe the whole system and design decisions relating to its functionality

and the interaction of the different parts before describing the different parts that make up the

system and the design decisions related to them.

System overview A logic analyzer can roughly be divided in three main components that make up the complete

system. These are the acquisition interface, responsible for sensing the signals to be analyzed and

translating them to a representation compatible with the logic part. The task of the logic part then is

to analyze the signals, determine interesting sequences and store them for later inspection by the

user. The frontend part of the logic analyzer finally interacts with the user to control the other parts

of the system and present the results of the analysis to the user. Figure 1 shows the data flow from

the circuit under test producing the signals to the user of the logic analyzer observing them on the

computer. The following subsections are going to discuss the major design decisions that led to Logic

Analyzer 4U.

Circuit under test

Signal discrimination and isolation (PCB)

Logic analysis and storage (FPGA)

Display and user interface (PC)

Figure 1: Simplified block diagram of a logic analyzer

Interfacing the circuit under test

In a logic analyzer we are mainly concerned with the logic levels of digital signals. That is, signals

coming into the logic analyzer are determined to have either a value of zero or a value of one. We

are not concerned with signal integrity issues that are better analyzed by specialized equipment to

measure and plot eye diagrams. The logic value of an electronic signal is generally linked to a voltage

of 31

potential although current signaling and differential signaling are also found especially in high-speed

applications.

As we are using the FPGA4U platform as a base for the logic analyzer we have to use the input

standard of the Cyclone II FPGA which is a single ended 3.3V standard. Because the FPGA4U should

be usable without changes we also have to take into account that there are LEDs connected to the

inputs coming from the external connectors. These LEDs, normally used as outputs when there is

nothing connected to the FPGA4U, add a resistive load to the inputs seen from the connector. For

fast switching applications expecting a small load on their signal lines this load may severely degrade

the signal integrity up to the point where the FPGA can no longer properly discriminate the logic

level from the circuit under test. Figure 2 illustrates the connection from the circuit under test to the

FPGA through a voltage level translator.

The maximum switching rate on 3.3V inputs for the Cyclone II FPGA in speed-grade C8 as used on

the FPGA4U is 360MHz which theoretically allows for a data rate of 720Mbps per pin. However such

signaling rates can only be achieved for a few channels at a time as the FPGA logic fabric and the

internal memory blocks are too slow.

Based on this analysis the decision was made to build a minimal voltage translating interface to

connect the logic analyzer to circuits functioning with voltages ranging from 3.3V down to 1.2V and

to isolate the circuit from the FPGA4U and the LEDs connected to its inputs.

Another possibility would have been to use voltage comparators to discriminate the signals and to

allow very precise control of the discrimination voltage with an adjustable voltage reference.

However there are no reasonably priced voltage comparators on the market that fit well in our

requirements of being fast, functioning with single supply at 3.3V, being able to drive FPGA pins with

LEDs connected and having 48 channels. Altogether an array of voltage comparators offers no

significant advantage over dedicated level translator ICs.

CUT FPGA

Isolation and voltage translation

Figure 2: The connection from the circuit under test to the input pins of the FPGA

A third and even more interesting, but also much more complicated way to acquire the signals is to

directly sample them with a high-speed analog to digital converter and afterwards find the logic

levels of the signals with digital discrimination. While this method provides the best accuracy and

of 31

permits to identify signal integrity problems it is also the most expensive solution and certainly not

practical for 48 channels. Basically this would then be a digital oscilloscope.

Sampling and storing the signals

Considering the logic part inside the FPGA there are two main goals:

A high sample rate in order to acquire high-speed signals with the best possible accuracy

A large sample memory for storing a long sequence of signals

The sample rate is bound by the speed of the acquisition interface and the inputs of the FPGA which

deliver signals to the chip and the speed of the internal logic and memory elements of the FPGA. The

sample memory is determined by the available memory resources in the form of on-chip memory

elements and off-chip storage. The off-chip SDRAM used on FPGA4U presents the main bottleneck

constraining the acquisition rate. Its bandwidth is limited because there is only one SDRAM chip

connected with a 32bit-wide data bus capable of operation at theoretically 166MHz. Also the

operating frequency of internal memory blocks of speed-grade C8 Cyclone II chips is limited to about

160MHz in the most favorable setting. Table 2 lists some hardware designs and the clock frequencies

they achieve under optimal conditions.

FPGA

Sampling Run length compression

Buffer FIFOTrigger

Control

Configuration

SDRAM controller

NIOS II soft core processor

EPCS controller LAN controller

Figure 3: Overview of the FPGA logic. Arrows indicate main data flow.

In the course of development it turned out to be difficult to get a reasonably sized design such as the

logic analyzer to run with a clock speed faster than 120MHz and internal RAM which is used for

of 31

buffering cannot run faster than 160MHz anyway. To offer nevertheless a sampling rate higher than

120MSps the input signals are sampled on the rising as well as the falling edge of the driving clock.

The internal buffer is split in two parts to allow efficient sample compression while being capable to

absorb the full data rate.

As a result the design achieves an acquisition rate of 240MSps. It is possible to source the clock for

the acquisition from an external pin, so there is no need to oversample the signal and a data rate of

240Mbps per pin is possible. To provide a deep sample memory, the internal memory of the FPGA

needs to be backed up by the external SDRAM which is limited in bandwidth to about 55MSps2. To

mitigate this limitation, the acquired samples are run length encoded and only if changes in the

acquired signals are detected are the samples stored in internal memory.

Application Performance (MHz)

16-to-1 multiplexer 286.04

32-to-1 multiplexer 191.02

16-bit counter 310.65

64-bit counter 126.27

Simple dual-port RAM 128x36 with single clock 163.13

Simple dual-port RAM 128x36 with separate read and write clocks

163.02

Table 2: Performance for hardware designs on a speed-grade C8 Cyclone 2 FPGA. (Excerpt of the datasheet)

Using an additional memory chip on the extension PCB is an alternative solution to the one we have

chosen. There is fast Synchronous Static RAM (SSRAM) on the market achieving data rates of

400Mbps and more. This SSRAM could be used to sample the data directly and later deliver it to the

user through the FPGA. However SSRAM chips are more expensive and smaller in size than SDRAM.

Also with SSRAM the trigger logic still needs to be implemented somewhere (in the FPGA) and run at

full speed. As can be seen in table 2 the FPGA is quite limited in frequency and already 240MHz

sampling rate is difficult to implement. Also when the samples go directly into the SSRAM no sample

compression can be done. Off course we could forgo the FPGA4U as base and develop a new

independent tool. This however was not the goal of the project and probably is beyond what can be

done for a master project.

Focusing on the user interface to the logic analyzer the goal is to have a self contained system on the

FPGA4U requiring the least amount of external hardware. The connections available from the

FPGA4U to the external world are USB 2.0 and Ethernet. Lets first examine the Ethernet option.

As today’s web browsers are quite powerful and allow rich user interfaces and graphical output is

seems convenient to include a web server in the FPGA4U to interface with the user via a web

browser. This also opens up the possibility of remotely debugging a circuit over the internet. The

main limitation is that, as there is only one SDRAM available as external memory, the web server and

the logic analyzer would have to share that memory. To that cause a custom arbiter including clock

crossing logic to the SDRAM was implemented giving the logic analyzer priority when accessing the

SDRAM. As the internal memory will often be sufficient given sample compression, there is the

option of disabling the SDRAM for the logic analyzer ensuring that the web server can execute

2

of 31

unimpeded. For longer acquisitions with data rates close or higher than that of the SDRAM the web

server will inevitably become unresponsive as it can no longer access its memory.

An advantage of a USB connection to the computer is that it can be implemented on the FPGA in a

way not influencing the logic analyzer and being responsive when an acquisition is running at full

speed. Drawbacks are that some non-trivial software with USB drivers and graphical user interface

has to be installed on the computer in order to be able to use the logic analyzer.

Comparing the two connections either has its advantages and drawbacks. Because the idea of a web

browser as user interface is very attractive, the Ethernet connection was adopted for the project.

Hardware System Design The following sections describe the hardware aspects of Logic Analyzer 4U. First the voltage

translating interface connecting the logic analyzer to the circuit under test is presented, and then we

turn to the system on chip and its components.

Voltage translating interface

Low dropout voltage

regulator

Digital potentiometer

Voltage level translators

FPGA connector

Input connector

signal signal

power

power

control

power

power

adjust

Figure 4: Simplified PCB schematic

The purpose of the voltage translating interface is to provide the connection to the circuit under test

and isolating it from the logic analyzer. As different (parts of) circuits run with different voltages

ranging from 1.2V to as high as 5V and the FPGA4U being fixed at 3.3V, the voltage levels need to be

adapted for the FPGA4U before the signals reach the FPGA. To offer some flexibility a PCB has been

designed which holds the connectors for the circuit signals and some integrated circuits for voltage

level translation. The voltage translating ICs use a dual power supply for their buffers and

differentiate signals according to the rules of integrated circuit logic. A signal below some threshold

is considered logic zero and a signal above a certain threshold is considered logic one with a window

in-between where the output is undefined. Table 3 lists the thresholds taken from the datasheet of

the voltage translators used for the interface circuit.

of 31

1

undefined

0

VCC

VIH

VIL

GND

Input side supply voltage VIH VIL

1.2V to 1.95V 0.65 VCC 0.35 VCC

1.95V to 2.7V 1.6V 0.7V

2.7V to 3.6V 2V 0.8V

Table 3: Datasheet excerpt concerning the input discrimination of the voltage level translators

As already mentioned the logic analyzer is not concerned with signal integrity, the measure of which

would require more expensive and faster circuits as this problem requires the measure of analog

voltage signals over time. For the signals coming into the logic analyzer it is therefore assumed that

they have a well-defined voltage.

To supply the acquisition side of the voltage translators an adjustable low dropout voltage3 regulator

is used. The voltage adjustment is done with the help of a digital potentiometer connected to the

output voltage and the adjustment pin. The voltage at the adjustment pin is regulated to a value of

0.6V and so the ratio of the resistances from the output to the adjustment voltage to the ground

defines the target output voltage. The potentiometer presents a total resistance of 10k Ohm and the

wiper can be moved with a precision of 10bit. The voltage regulator is a low dropout regulator that

regulates an input voltage between 2.7V and 5.5V to an output voltage of 0.6V to 5V. The voltage

regulator can source up to 1.5A of current and consumes at most 4.5mA. The maximum dropout

voltage is 375mV.

FPGA logic design

The FPGA contains all the logic necessary to store and retrieve signal samples. This includes the

acquisition, trigger logic, buffer memory, a NIOS II soft-core processor, a SDRAM controller and some

additional processor peripherals and glue logic. Figure 3 on page 9 shows an overview the FPGA

logic. The description of the components will follow the data flow of the signals entering the logic

analyzer, being stored in SDRAM and finally displayed to the user through a web browser interface.

The logic analyzer

Let us begin with the data acquisition as the signals enter the FPGA coming from the voltage level

translation. Upon entering the FPGA the signals are sampled on the rising and falling edge of the

sampling clock which drives the logic analyzer part of the circuit. This clock is distributed in the FPGA

using a global net sourced by a clock control block which implements a clock multiplexer. The clock is

3 Dropout voltage designates the voltage drop from the input to the output of a voltage regulator.

of 31

chosen between an internally generated 120MHz clock and an externally fed clock from the FPGA

connector. The external clock input can be used for fast signals to ensure proper synchronous

sampling, whereas slower signals (for example from a microcontroller circuit) up to about 24MHz

can be accurately sampled using the internal clock. Figure 5 shows the clock multiplexing circuitry.

The multiplexer selection input is controlled by the soft-core CPU.

Figure 5: Clock selection circuit for the sampling clock

The logic signals are sampled using a vendor provided double data rate (DDR) input block. As the

Cyclone 2 does not have dedicated DDR input registers, the component constrains the design to use

the normal input registers and the registers closest to the pins in the FPGA logic fabric to acquire the

signals. This ensures that the path from the pins to the registers is at the minimum length and best

matching possible with the Cyclone 2 FPGA. The signals are then resynchronized to the rising edge of

the clock and both samples are transported to the comparison logic for run length compression. In

figure 6 you see a one bit sampling and synchronization circuit.

Cy clone II

inclk0 f requency : 24.000 MHz

Operation Mode: Normal

Clk Ratio Ph (dg) DC (%)

c0 5/1 0.00 50.00

inclk0 c0

PLL

inst

clk

Global Clock

clkselect

inclk1x

inclk0xoutclk

CLKCTRL

inst1

CLRN

DPRN

Q

DFF

inst2

VCCClock_connector INPUT

Sampling clock

Clock and data from CPU

VCCFPGA4U_24MHzINPUT

of 31

Figure 6: Double data rate acquisition and synchronization circuit

An internal clock divider determines whether the one or both of the acquired samples need to be

analyzed and eventually stored. This clock divider allows maximizing the efficiency of the run length

compression when (very) slow signals are sampled using the internally generated 120MHz clock. The

number of samples between changes in the input is stored with a resolution of 16bit allowing a peak

compression of 1:216. The output of the clock divider is a stream of 2bit signals indicating whether

the first and/or second sample presented during the clock period need to be analyzed. The stream

consists of all ones for full speed acquisition, of alternating values for half speed and more and more

zeros are inserted as the frequency is further lowered. The clock can be divided by a factor of up to

4096. Table 4 shows resulting acquisition streams for selected clock divisors.

Clock divisor Resulting acquisition stream Comment

0 11 11 11 11 11 11 11 11 11 Acquire every sample

1 01 01 01 01 01 01 01 01 01 Acquire every second sample

2 10 01 00 10 01 00 10 01 00 Skip two samples between acquisitions

5 10 00 00 10 00 00 10 00 00 Skip five samples between two acquisitions Table 4: Acquisition enable stream for different clock divisor values. For odd divisors the sample is chosen by the user.

The clock division unit can conveniently be used to indicate on which edge of the external clock

source the acquisition should take place.

The logic for run length compression turned out to be the critical part in the acquisition pipeline as it

has to be done at full speed which means we need to analyze two samples every clock cycle. When a

sample is to be analyzed according to the output from the clock division unit, we compare it to the

last stored sample. If the sample changed we push it down into the trigger pipeline, together with

the count of unchanged samples before. Upon overflow of the compression counter a sample is also

stored even if there were no changes. To achieve the timing requirements of the design this

comparison and analyzing logic had to be carefully optimized. All comparisons that can be done

without knowing the actual sample were moved to the preceding cycle and the results stored in

single bit flip-flops. This was applied to counter overflow checks for example. The critical path then

runs from the registers holding the acquired samples through the 48bit comparator comparing the

first sample to the last stored value and the control logic to the input registers of the trigger pipeline.

CLRN

DPRN

Q

DFF

inst

CLRN

DPRN

Q

DFF

inst1

CLRN

DPRN

Q

DFF

inst3

CLRN

DPRN

Q

DFF

inst4

CLRN

DPRN

Q

DFF

inst5

CLRN

DPRN

Q

DFF

inst6

NO

T

inst2

Data input

Clock

Sample 1

Sample 0

of 31

A sample is only stored when the compression counter overflows or when there was a change to the

last stored sample. As there are two samples to examine they have to be compared to each other

also. In figure 7 you find a slightly simplified schematic of the circuit used for sample compression of

one bit samples. Timeout indicates that the counter for compression is about to overflow. The

acquire registers hold the values from the clock divider. The circuit shown is correct only when there

is at most one sample to be acquired. When every sample needs to be acquired, i.e. the analyzer is

running at full speed, there are different timeout indicators for the two samples.

When the sample is finally stored the compression counter value is stored with it and the counter(s)

reset. A stored sample consists of the number of unchanged samples encoded in 16 bits and the new

value of the signals in 48 bits. A sample is from here on a 64 bit entity consisting of the compression

count and the signals. If only 16 channels are sufficient for the user, 32 of the data signals can later

be ignored.

Figure 7: Simplified sample compression logic

After a sample is deemed worthy of being stored it enters the trigger pipeline which is simply a three

sample deep register chain that holds the values which need to be analyzed for trigger logic. Three

samples need to be analyzed as there are two new samples which may enter the pipeline at every

clock cycle and we need to be able to detect edges between every two samples. The trigger

configuration is stored in three registers indicating for each signal whether to look for a certain logic

level, an edge or whether to ignore it. A schematic of the trigger logic for a one bit sample is shown

in figure 8. This logic is replicated for the following sample to analyze two samples in every clock

period. When the trigger matches on all channels it fires.

When the signal acquisition starts samples flow past the trigger and are stored in memory until the

trigger fires. At the moment the trigger fires a countdown is started which determines how many

samples to additionally acquire before stopping the acquisition process. This permits to observe

signals before or after the trigger as the user requests and the sample memory can provide. A

CLRN

DPRN

Q

DFF

inst2

XNOR

inst3

XOR

inst

Sample 0

Sample 1

Last Sample

Equal samples

Sample changed

CLRN

DPRN

Q

DFF

inst4

Timeout

CLRN

DPRN

Q

DFF

inst5

CLRN

DPRN

Q

DFF

inst6

Acquire 0

Acquire 1

OR3

inst7

NOT

inst8

AND2

inst9

AND2

inst10

OR2

inst11

Store 1

Store 0

of 31

countdown value of zero is used if the interesting data is before the trigger. Higher values are used if

the interesting data is after the trigger.

Figure 8: Trigger logic: Edge indicates that there must be a change and state indicates the new level.

When the samples leave the trigger pipeline they get stored in an on-chip buffer before eventually

being written to SDRAM. As there may be two samples to be stored in a single clock cycle there are

two FIFO memories which are written in an alternating fashion. The memories can hold up to 2048

samples before overflowing. If the memory master is not able to keep up with the bandwidth of

incoming data the FIFOs may eventually overflow. If the FIFOs overflow the oldest samples are

discarded. This means that at the end of an acquisition the last correctly acquired signals remain in

the FIFOs and can be moved to memory. In case of an overflow the memory address from where the

data is guaranteed to be valid - that means without missing samples - is stored. This address is used

to define the memory region where the acquired data is stored. If there are only 16 signals to

observe the number of samples in on-chip memory is doubled as two samples are stored in one FIFO

element for that case. Figure 9 shows a simplified version of the multiplexed FIFOs without the

optimization for 16 bit samples.

Sam

ple

0Sa

mp

le 1

FIFO 01024 x 64 bit

FIFO 11024 x 64 bit

Mem

ory

M

aste

r

Figure 9: Multiplexing of two memory elements to increase the available bandwidth.

CLRN

DPRN

Q

DFF

inst

CLRN

DPRN

Q

DFF

inst1

CLRN

DPRN

Q

DFF

inst2

State

Mask

Edge

Sample n+1

Sample n

XOR

inst5

XOR

inst6

OR2

inst7

NOT

inst8

AND2

inst10BOR2

inst11

AND2

inst12

Trigger

of 31

Due to the internal memories at least 2048 samples are reliably acquired independent of the

acquisition clock. When the rate of transitions at the input never exceeds the data rate of the

SDRAM (55MSps) averaged over a window of 2048 samples the number of samples acquired is

limited by the size of the SDRAM. If we use 24MB of the 32MB available we can store over three

million full samples.

The samples leave the two FIFOs one at a time in the same order as they were written to be

transferred to the SDRAM. Two configuration registers define the memory region where acquired

samples are to be stored. This memory region is written sequentially and when the last address is

reached we wrap back to the first. The word containing the compression counter is written first and

the second part of the sample is written to the immediately following memory address. The write

interface is compatible with the Avalon bus and 32bit wide as the SDRAM on FPGA4U is also 32bit

wide. The transfer to memory can be disabled by the user in which case only the internal buffers are

used for storing the acquired signals and the data is streamed to memory once the acquisition is

finished. As the memory is shared with the soft-core processor running the web server this ensures

the processor will respond to user requests and cannot be blocked by the logic analyzer.

Sample n

64 bit

Sample n+2

64 bit

Compression

count 16 bit

Channels

47 to 32

Channels

31 to 16

Channels

15 to 0

Increasing memory addresses

Figure 10: Layout of samples in memory. Samples are always aligned.

The SDRAM arbiter and controller

The Avalon master writing the samples from the FIFOs is directly connected to a custom SDRAM

arbiter module which stores the requests in a dual clocked FIFO to cross the clock domain from the

sampling clock to the clock of the SDRAM controller running at a fixed frequency of 120MHz. The

SDRAM arbiter also connects the CPU to the SDRAM using two clock crossing FIFOs as the CPU is

running at a lower frequency than the SDRAM. In figure 11 you see the SDRAM arbiter with the clock

crossing FIFOs. The arbiter gives priority to the logic analyzer input offering it the full write

bandwidth available from the SDRAM controller. In case the logic analyzer writes more data than the

SDRAM can consume (therefore its internal buffers overflow) the CPU is effectively blocked from

accessing the SDRAM where its code and data are stored.

Logic Analyzer Memory master

FIFO

NIOS II soft core

CPU

FIFO from CPU

FIFO to CPU

Arbiter

SDR

AM

co

ntr

olle

r

Figure 11: SDRAM Arbiter with clock crossing FIFOs

As the SDRAM controller offered from Altera cannot run at frequencies above 100MHz, a new

optimized version was written specifically targeting the FPGA4U. It is based on the same principle as

of 31

the Altera controller but uses more efficient encoding for its state machines and internal data

buffers. The controller contains two state machines, one responsible for executing the startup

command sequence and one for the user commands to the SDRAM. The only optimization

implemented is the following. After a transfer has been initiated to the SDRAM the corresponding

row is kept open and compatible requests are the accepted on each clock cycle and streamed to the

SDRAM. Once a refresh is needed or an incompatible request (different data direction or bank/row)

should be executed the controller closes the active row and returns to an idle state to determine the

appropriate action to take. For sequential read and writes more than 95% of the clock cycles are

used to transfer data to or from the SDRAM.

Other optimizations, such as opening multiple banks at the same time and keeping track of which

row is open on which bank or close interleaving of read and write transfers complicate the logic,

causing the maximum frequency to drop below 100MHz. Given that for sequential accesses we can

use 95 percent of the available bandwidth no other optimizations were applied.

idle

refresh

waitrefresh

activatewait

activate

read write

spinread

spinwrite

wait precharge

precharge

Figure 12: State transition diagram for the SDRAM controller's main state machine.

Figure 12 shows the main state machine of the SDRAM controller. Upon startup the state machine is

in idle state. When the state machine is in idle state all banks of the SDRAM are in idle state and

ready for an activate or refresh command. When a refresh command is needed the state machine

transitions to the refresh state during which the command is issued and then to the wait refresh

state where it waits until all banks are idle again. On a request from the Avalon slave interface the

row containing the accessed data is activated. After waiting for the activate command to complete

the state machine transitions to the next state where a read or write command is issued. As long as

there is no refresh needed and commands of the same type to the same row are requested the state

machine will keep the row open and issue commands to the SDRAM on every clock cycle. Commands

are issued when the state machine is in either the read or write state and the row is open and ready

for additional commands when the state machine is in spin read or spin write state. When a refresh

of 31

command needs to be issued or an incompatible address is requested the state machine transitions

to the precharge state where a precharge command to all banks is issued and after the precharge

time elapsed the state machine will return to idle state.

The remaining logic modules

Now that it has been explained how the signal samples travel from the input pins to the SDRAM we

will explain how they are taken out again and presented to the user of the logic analyzer. The

remaining hardware part is quite short, but the topic continues into the software part where most of

the complexity resides.

The custom modules were written with Avalon compatible interfaces so that they can easily be

integrated with compatible cores from Altera and others. Figure 13 shows the custom made

modules connected with a NIOS II CPU and the LAN91C111 network controller for the FPGA4U

Ethernet chip. The SDRAM arbiter contains the SDRAM controller.

Figure 13: Relevant components and their interconnect in SOPC -Builder

Along with the logic analyzer and SDRAM controller the FPGA also contains a NIOS II soft-core CPU

together with the peripherals needed to run a web server. There is an EPCS flash controller to boot

from the configuration flash memory, a UART, a timer and the network controller. The processor

also connects to the SDRAM through the SDRAM arbiter and its code and data resides in the SDRAM.

The processor is of the fastest variant Altera offers and has small on-chip code and data caches to

improve performance.

The complete logic design including the logic analyzer, the SDRAM controller, the soft-core

processor and other components consumes about 50% of the 18’752 logic cells available in our

FPGA. The logic analyzer can run with a clock of up to 120MHz, the SDRAM controller runs at a fixed

120MHz and the NIOS II processor runs at 80MHz. Of the 52 M4K memory blocks in the FPGA there

are only four not used and available for extensions or as addition to the CPU caches.

of 31

Software System Design The software part of the logic analyzer which is mainly responsible for user interaction can be

decomposed into two parts, where one part is the software running on the NIOS II soft-core

processor in the FPGA controlling the hardware and the other part is the software running on the

user’s computer communicating with the FPGA and displaying the results.

To communicate with a PC the FPGA4U offers USB2.0 and Ethernet ports. The FX2 USB interface chip

on the FPGA4U board can be used for communication using an USB connection. This requires the

writing of system software on the PC capable of accessing the USB bus and in all but the simplest

cases (where all the intelligence is on the computer side) a soft-core on the FPGA to handle the

requests from the computer application. To access the USB on a PC you have to either write a driver

for the FPGA4U or use a generic driver such as libusb4. On the other hand when using Ethernet

network to communicate the code to be executed on the PC can be sent in the form of JavaScript to

a web browser and there is no need to maintain a separate computer program.

The solution using the web browser is very convenient because there is no need to have special

software. This fits well with the goal to have a system usable by every student for some quick

measurements. Hence this solution was adopted for the project. As mentioned in previous sections

the soft-core processor might be blocked from accessing the SDRAM and will in that case not be able

to respond to requests from the user. There is no problem for short measurements and there is a

reset button to interrupt the logic analyzer and cancel the acquisition in case it turns out to take too

long.

Firmware

The firmware is the software that runs on the soft-core processor in the FPGA4U and implements

the web server communicating with the browser on the user’s machine. The web server software is

based on the examples given by Altera to run on their evaluation platforms and it has subsequently

been adapted for the use on FPGA4U and especially in conjunction with Logic Analyzer 4U.

The web server uses the MicroC/OS-II real-time embedded operating system5 and the NicheStack

TCP/IP Stack6 for networking. Those two components, adapted to NIOS II by Altera, together with

the Hardware Abstraction Layer (HAL) build the base for the implementation of a simple web server.

Figure 14 shows the different abstraction layers offered by the software development environment

from Altera. To delve into the details of software development for NIOS II processor systems is

beyond the scope of this project. There is ample literature available from Altera on the workings of

the processor, the system interconnect and the software modules.

4 http://www.libusb.org/

5 http://micrium.com/page/products/rtos

6 http://www.iniche.com/products.php

of 31

Figure 14: The layered software model as illustrated by Altera in the NicheStack TCP/IP Stack tutorial

The web server source code from Altera is adapted to their evaluation boards and therefore certain

changes had to be made. All the functions dealing with hardware that is not present in our system

were deleted and the routines for finding the MAC and IP addresses were adapted to FPGA4U.

Furthermore the original code uses a flash based file system which is not available on FPGA4U and

therefore a custom, very simple, RAM based file system was created. The Altera web server handles

only the most basic request types from browsers. Additional functionality for parsing request

parameters and serving dynamic files had to be added to the web server.

In addition to serving web pages and data files containing acquired sample data, the NIOS II

processor is also in control of the hardware module for the logic analyzer part. An additional lower

priority task was added to initiate data acquisition sequences. The software on the client side then

has to poll the web server periodically to know whether the acquisition has triggered and to then get

the data.

Client-side software

Client-side software running in the web browser of the user of Logic Analyzer 4U is responsible for

displaying a user interface and the results of an acquisition sequence. The user interface is a

standard web page using asynchronous JavaScript and XML (Ajax) to create an interactive

application in the browser. To ensure compatibility across a broad range of different web browsers

the jQuery7 JavaScript library is used for any functionality that might not be uniformly implemented

by all major web browsers. Together with the user interface library also offered by the jQuery

developers an application with a complex user interface can be built and used in any web browser.

No other software than a recent, JavaScript enabled, web browser is needed on a user’s computer to

use the functionality of Logic Analyzer 4U.

7 http://jquery.com

of 31

Request index.html

Send static page

Display user interface

Set trigger conditions, start

acquisition

Acquisition running

Request sample data

Send raw sample data

Interpret sample data and present it

to user

Tim

e

Client Server

Figure 15: Illustration of the communication between the web browser and the server.

Figure 15 shows the interaction between the web browser on the computer and the web server on

the FPGA. After the start of the acquisition the client has to poll the logic analyzer to know whether

the acquisition finished and to get data.

The user interface of Logic Analyzer 4U is similar to that of other logic analyzers and allows the user

to control all the functionality Logic Analyzer 4U offers.

of 31

6. Conclusion and future work Logic Analyzer 4U is a very diverse project covering topics from electronic engineering to web

development and therefore offers interesting aspects for engineering as well as for computer

science students. The electronics engineer is mainly concerned with the interface of the circuit under

test to the logic analyzer and the computer architecture student is concerned with the design of the

system on chip. To run the system also needs software and so the system programmer is very

interested in how the operating system and the different peripherals in the system interact and how

they need to be programmed. The final step of connecting with the user is the responsibility of the

web developer designing the user interface that runs in a web browser. Parts of Logic Analyzer 4U

can be used to illustrate every aspect of embedded system design.

Logic Analyzer 4U is based upon FPGA4U with only a minimal extension and can even be used

directly when interfacing another FPGA4U board. FPGA4U has been analyzed to find its potential

and necessary trade-offs when used as a logic analyzer. Within the goals of having a complete

system based on FPGA4U to do logic analysis, this project tried to strike the best compromise when

approximating the ideal logic analyzer with unlimited memory and infinite sampling rate. The result

is a logic analyzer capable of sampling digital signals at a frequency of 240MHz and a guaranteed

sample memory of 2048 samples. The user interfaces with Logic Analyzer 4U using a simple web

browser taking advantage of the Ethernet port FPGA4U offers. No special software tools are

necessary to use the logic analyzer once the FPGA4U is programmed.

Several enhancements for Logic Analyzer 4U are possible and some we want to outline here:

The design of the logic analyzer and the SDRAM need to be fully parameterized. For the

logic analyzer especially the number of channels and the size of the internal buffers can be

parameterized to control the resource usage of the module. Once this is done it can then be

instantiated along other logic and be used to debug circuits on the same FPGA instead of

using vendor provided tools. In the SDRAM controller the different parameters of the

SDRAM chip should be made configurable. These are the number of banks, rows, columns

and the timing parameters of the chip.

The trigger logic which is rather simple can be extended to include other conditions or

counters to be able to more precisely trigger on certain events. As the trigger logic is not on

the critical path this presents no major problem.

A USB module can be added to the system to transfer sample data via USB. If the module is

made simple enough to not require any RAM it will always respond to client requests, even

if an acquisition is running. For that the module we would have to implement is a USB-to-

Avalon bridge. All the intelligence including knowledge about the system memory map is

moved to the client software on the PC.

Different protocol analyzers can be added to the client software to simplify debugging of

serial and parallel protocols from signals recorded by the logic analyzer.

The external interface PCB can be used to implement a pattern generator to inject test

signals in other circuits. To do this the data direction on the voltage translators which is

controlled by the CPU needs to be inverted and data streamed from the FPGA to the

connector.

of 31

7. References Documentation on the FPGA, soft cores, programming model and software modules from

Altera: http://www.altera.com/literature

Documentation on FPGA4U: http://fpga4u.epfl.ch

of 31

8. Appendix

PCB schematic and layout

Figure 16: First part of the PCB schematic showing the voltage regulation and the connector to the FPGA4U.

of 31

Figure 17: Second part of the PCB schematic showing the voltage level translators and input connectors.

Figure 18: PCB layout for the top layer containing the voltage translators and connectors.

of 31

Figure 19: PCB layout for the bottom layer containing the FPGA connector and the voltage regulation.

VHDL source of the SDRAM controller Below you find the source of the SDRAM controller used for Logic Analyzer 4U. The controller is

targeted specifically at FPGA4U and the 32MB ISSI SDRAM it uses.

library ieee;

use ieee.std_logic_1164.all;

use ieee.numeric_std.all;

entity fpga4u_sdram_controller is

port(

--Avalon slave interface (pipelined, variable latency)

signal clk, reset : in std_logic;

signal as_address : in std_logic_vector(22 downto 0);

signal as_read, as_write : in std_logic;

signal as_byteenable : in std_logic_vector(3 downto 0);

signal as_readdata : out std_logic_vector(31 downto 0);

signal as_writedata : in std_logic_vector(31 downto 0);

signal as_waitrequest : out std_logic;

signal as_readdatavalid : out std_logic;

--SDRAM interface to FPGA4U SDRAM

signal ram_addr : out std_logic_vector(11 downto 0);

signal ram_ba : out std_logic_vector(1 downto 0);

signal ram_cas_n : out std_logic;

signal ram_cke : out std_logic;

signal ram_cs_n : out std_logic;

signal ram_dq : inout std_logic_vector(31 downto 0);

signal ram_dqm : out std_logic_vector(3 downto 0);

signal ram_ras_n : out std_logic;

signal ram_we_n : out std_logic

);

end entity;

architecture arch of fpga4u_sdram_controller is

--Initialisation signals

type init_state_t is (init_reset, init_pre, init_wait_pre, init_ref, init_wait_ref,

init_mode, init_wait_mode, init_done);

signal init_state : init_state_t := init_reset;

signal init_wait_counter : unsigned(15 downto 0);

signal init_ref_counter : unsigned(3 downto 0);

--Main state machine

type state_t is (idle, ref, wait_ref, act, wait_act, read, spin_read, write, spin_write,

precharge_all, wait_precharge);

signal state : state_t := idle;

signal ref_counter : unsigned(10 downto 0);

signal ref_req : std_logic;

signal wait_counter : unsigned(2 downto 0);

of 31

--Active transaction signals

signal int_address : std_logic_vector(22 downto 0);

signal int_readdata : std_logic_vector(31 downto 0);

signal int_writedata : std_logic_vector(31 downto 0);

signal int_byteenable : std_logic_vector(3 downto 0);

signal int_writeop : std_logic;

--open bank and row

signal open_bank : std_logic_vector(1 downto 0);

signal open_row : std_logic_vector(11 downto 0);

--readdata ready pipeline

signal readdata_ready : std_logic_vector(4 downto 0);

signal ram_cmd : std_logic_vector(3 downto 0);

begin

--State machine to handle SDRAM initialization

INITSTATE : process(clk, reset)

begin

if reset = '1' then

init_state <= init_reset;

--power up delay

init_wait_counter <= to_unsigned(24000,init_wait_counter'length);

--number refresh cycles before mode register write

init_ref_counter <= to_unsigned(2,init_ref_counter'length);

elsif rising_edge(clk) then

--count down when not 0

if init_wait_counter /= 0 then

init_wait_counter <= init_wait_counter - 1;

end if;

case init_state is

when init_reset =>

if init_wait_counter = 0 then

init_state <= init_pre;

end if;

--do a precharge

when init_pre =>


init_state <= init_wait_pre;

when init_wait_pre =>


init_state <= init_ref;

end if;

--do a refresh

when init_ref =>


init_ref_counter <= init_ref_counter - 1;

init_state <= init_wait_ref;

when init_wait_ref =>


if init_ref_counter = 0 then

init_state <= init_mode;

else

init_state <= init_ref;

end if;

end if;

--set the mode register

when init_mode =>


init_state <= init_wait_mode;

when init_wait_mode =>


init_state <= init_done;

end if;

when others =>

null;

end case;

end if;

end process;

--Asynchronous waitrequest to allow one transfer per cycle (critical path)

as_waitrequest <= '0' when (state = idle and ref_req = '0' and (as_read = '1' or as_write = '1'))

or ((state = read or state = spin_read) and ref_req = '0' and as_read = '1' and

as_address(22 downto 11) = open_row and as_address(10 downto 9) = open_bank)

or ((state = write or state = spin_write) and ref_req = '0' and as_write = '1' and

as_address(22 downto 11) = open_row and as_address(10 downto 9) = open_bank)

of 31

else '1';

--Main state machine

make_state : process(clk, reset)

begin

if reset = '1' then

state <= idle;

ref_counter <= (others=>'0');

ref_req <= '1'; --begin with a refresh

wait_counter <= (others=>'0');

readdata_ready <= (others=>'0');


--counters for delays and refresh generation

if wait_counter /= 0 then

wait_counter <= wait_counter - 1;

end if;

if ref_counter /= 0 then

ref_counter <= ref_counter - 1;

else

ref_req <= '1';

ref_counter <= to_unsigned(1800,ref_counter'length);

end if;

--main state machine runs when the initialization is done

if init_state = init_done then

case state is

when idle =>

if ref_req = '1' then --go do a refresh

ref_req <= '0';

state <= ref;

elsif as_write = '1' or as_read = '1' then --accept the request and go open the row

int_address <= as_address;

int_writedata <= as_writedata;

int_byteenable <= as_byteenable;

int_writeop <= as_write;

state <= act;

end if;

when ref =>

wait_counter <= to_unsigned(5,wait_counter'length);

state <= wait_ref;

when wait_ref =>

if wait_counter = 0 then

state <= idle;

end if;

when act => --save the open bank and row

open_bank <= int_address(10 downto 9);

open_row <= int_address(22 downto 11);


state <= wait_act;

when wait_act =>

if wait_counter = 0 then

if int_writeop = '0' then

state <= read;

else

state <= write;

end if;

end if;

when read => --issue a read command, feed a one in the readdata_ready pipeline,

--when it exits data is ready for the master

as_readdata <= int_readdata;

as_readdatavalid <= readdata_ready(4);

readdata_ready <= readdata_ready(3 downto 0)&'1';

if ref_req = '0' and as_read = '1' and as_address(22 downto 11) = open_row and

as_address(10 downto 9) = open_bank then


state <= read;

else

state <= spin_read;

end if;

when spin_read => --wait for reads to complete and eventually issue more compatible reads

as_readdata <= int_readdata;

as_readdatavalid <= readdata_ready(4);

readdata_ready <= readdata_ready(3 downto 0)&'0';

if readdata_ready = "00000" and (ref_req = '1' or as_write = '1') then

state <= precharge_all;

elsif ref_req = '0' and as_read = '1' and as_address(22 downto 11) = open_row and



of 31

state <= read;

elsif readdata_ready = "00000" and as_read = '1' then


end if;

when write => --the same as read, except there is no pipeline as data is presented to

--the SDRAM on the same cycle as the command


if ref_req = '0' and as_write = '1' and as_address(22 downto 11) = open_row and





state <= write;

else

state <= spin_write;

end if;

when spin_write => --same as for read

if wait_counter = 0 and (ref_req = '1' or as_read = '1') then


elsif ref_req = '0' and as_write = '1' and as_address(22 downto 11) = open_row and





state <= write;

elsif wait_counter = 0 and as_write = '1' then


end if;

when precharge_all =>

state <= wait_precharge;

when wait_precharge =>

state <= idle;

when others=>

null;

end case;

end if;

end if;

end process;

--data from the ram needs to be sampled on the falling edge of the controller clock for proper operation

process(clk)

begin

if falling_edge(clk) then

int_readdata <= ram_dq;

end if;

end process;

--process generating the command sequence for the SDRAM

ram_cke <= '1';

ram_cs_n <= ram_cmd(3);

ram_ras_n <= ram_cmd(2);

ram_cas_n <= ram_cmd(1);

ram_we_n <= ram_cmd(0);

OUTPUTS : process(clk, reset)

begin

if reset = '1' then

ram_addr <= (others=>'0');

ram_cmd <= "1111";

ram_ba <= (others=>'0');

ram_dq <= (others=>'Z');

ram_dqm <= (others=>'1');


if init_state = init_pre then

ram_cmd <= "0010"; --precharge

ram_addr <= (10=>'1', others=>'0');

elsif init_state = init_ref then

ram_cmd <= "0001"; --refresh

elsif init_state = init_mode then

ram_cmd <= "0000"; --mode set

ram_addr <= "000000110000"; --no burst, three cycles latency

elsif init_state = init_done then

if state = ref then

ram_cmd <= "0001"; --refresh

elsif state = act then

ram_cmd <= "0011"; --activate

ram_addr <= int_address(22 downto 11);

ram_ba <= int_address(10 downto 9);

of 31

elsif state = read then

ram_cmd <= "0101"; --read

ram_addr <= "000"&int_address(8 downto 0);

ram_dqm <= "0000";

elsif state = write then

ram_cmd <= "0100"; --write


ram_dq <= int_writedata;

ram_dqm <= not int_byteenable;

elsif state = precharge_all then

ram_cmd <= "0010"; --precharge


ram_dqm <= "1111";

else

ram_cmd <= "1111"; --nop

ram_dq <= (others=>'Z');

end if;

else

ram_cmd <= "1111"; --nop

end if;

end if;

end process;

end arch;

The complete sources for software and hardware as well as the most recent version of Logic

Analyzer 4U can be found at http://fpga4u.epfl.ch/wiki/LogicAnalyzer4U.

logic analyzer 4usamuel/pdm/report.pdf · to analyze the signals, determine interesting sequences...

Documents