05a Section4 Notes CPD SDDS1 Topdown1

MIDAS CPD Digital Design 12 Week Course

===================
Sept Dec
===================
..
..
===================
Top Down Design 1 (TDD1)
===================

Richard Gahan
richard.gahan@tudublin.ie
November 10, 2022

CPD SDDS1 - TopDown1 Rev A01
Contents
1 Top Down Design 2
1.1 FIFO Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 FIFO4 Top Level DFD . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 bytesInFIFOCounter Design . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 countControl Design . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.4 counterDecode Design . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.5 UpDownCounter Design . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.6 4byteStore Functional Partition . . . . . . . . . . . . . . . . . . . . 9
1.2 TestQuestion1 FIFO Design and Code . . . . . . . . . . . . . . . . . . . 10
TUDublin © rgahan Page 1 of 10

Section 1
Top Down Design

1.1 FIFO Design
Consider the FIFO context diagram shown in gure 1.1.
Figure 1.1: FIFO4 Context Diagram
The FIFO4 description of specication is as follows:
1. The FIFO can store up to 4 bytes of data.
2. It accepts data from a byte interface and stores that data into the next available
FIFO location if one is available otherwise it drops (ignores) the incoming data.
3. When there is data in the FIFO the oldest data is presented on foData[7:0] and
waits there until byteTaken(H) asserts.
4. When byteTaken(H) asserts, the next stored byte is presented after the next rising
CLK edge.
5. foFull(H) asserts when the 4 byte fo is Full
6. dataAvail(H) asserts when there is one or more locations of the FIFO holding data.

A timing diagram showing an example of required behaviour is below.
Figure 1.2: FIFO4 Timing Specication Diagram

1.1.1 FIFO4 Top Level DFD
The rst step in the solution is to break the problem down into sensible and logic subsec-
tions. There are many possibilities but the key to successful partition is to make it easier
to understand and explain how the design will work.
Figure 1.3: FIFO4 Data Flow Diagram
Then each new signal is described. In this case we have
1. writeEn(H)
This signal asserts when a byte of data is to be written into the 4ByteStore Block.
2. wrAdr[1:0]
This is the 2 bit address in memory where the rxByte[7:0] will be written into on
the next rising edge of the clock.
3. rdAdr[1:0]
This is the 2 bit address in memory where the foData[7:0] is being read from. This
is an asynchronous read i.e. once the address asserts the data becomes valid after
combinational delays of intervening logic.
The block called 4ByteStore holds the bytes in the FIFO but it is under the control of the
bytesInFIFOCounter.
The writeEn signal asserts when a byte is to be written to the memory, to the address as
given on wrAdr[1:0]. In this dataow diagram the datapath is distinct from the control
path.
The next task is to either design the blocks as shown in the DFD or to break them down
further. In this example it is instructive to break bytesInFIFOCounter down further
and to design the 4ByteStore.
TUDublin ©
rgahan Page 4 of 10
1.1.2 bytesInFIFOCounter Design
Figure 1.4: bytesInFIFOCounter Data Flow Diagram
1. increment(H)
This signal asserts when a byte is being written into the FIFO to tell the upDown-
Counter to count up so we know how many valid bytes are in the FIFO.
2. decrement(H)
This signal asserts when a byte is being read from the FIFO to tell the upDown-
Counter to count down so we know how many valid bytes are in the FIFO
3. foByteCount[2:0]
This is a count of the valid number of bytes in the FIFO. There can be 0,1,2,3 or 4
bytes in the FIFO. When there are 4 bytes in the FIFO it is full.
This design works as follows the upDownCounter keeps track of how many valid bytes
are stored in the memory. The value may be incremented or decremented. When a value
is being written into memory the value is incremented and when a value is read from (or
taken out of ) memory the count is decremented.
The countControl block determines whether the counter should be incremented, decre-
mented or neither as can happen when there is a write and a read from memory at the
same time the amount of data stored stays the same!.
The counterDecode block decodes the foFull and dataAvail signals from the value of
foByteCount[2:0].

1.1.3 countControl Design
This owchart goes through all the possibilities of writing and reading the memory. This is
fairly self-evident. However take notice of the path with rxByteAvail=1 and byteTaken=1
notice that neither increment or decrement asserts as they cancel each other out. And
this can happen even if the FIFO is full.
Are there any bugs in this design?
Figure 1.5: countControl FSM Diagram

1.1.4 counterDecode Design
A very simple block - it too must be checked!
Figure 1.6: counterDecode Logic

1.1.5 UpDownCounter Design
This block is so simple it is ready for code. However we can represent it in an FSM
diagram yet.
Figure 1.7: foByteCount FSM Diagram

1.1.6 4byteStore Functional Partition
Figure 1.8: 4byteStore Functional Partition

1.2 TestQuestion1 FIFO Design and Code

Consider FIFO4B as shown in gure 1.9 which is a small variation on what we have just
completed in FIFO4 above.
Figure 1.9: FIFO4B Context Diagram
Modify the FIFO4 design to take account of the changed functionality on the input side.
rxAckH asserts to take the byte presented on rxByte[7:0] as indicated by rxByteAvailH,
otherwise the byte remains presented on the interface until rxAckH asserts.
Write verilog code for this design and a simple testbench to test the functionality.

05a Section4 Notes CPD SDDS1 Topdown1

Uploaded by

Copyright:

Available Formats

05a Section4 Notes CPD SDDS1 Topdown1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05a Section4 Notes CPD SDDS1 Topdown1

Uploaded by

Copyright:

Available Formats

MIDAS  CPD Digital Design  12 Week Course

November 10, 2022

TUDublin © rgahan Page 1 of 10

Top Down Design

Figure 1.1: FIFO4 Context Diagram

The FIFO4 description of specication is as follows:

1. The FIFO can store up to 4 bytes of data.

5. foFull(H) asserts when the 4 byte fo is Full

TUDublin © rgahan Page 2 of 10

A timing diagram showing an example of required behaviour is below.

Figure 1.2: FIFO4 Timing Specication Diagram

TUDublin © rgahan Page 3 of 10

1.1.1 FIFO4 Top Level DFD

Figure 1.3: FIFO4 Data Flow Diagram

Then each new signal is described. In this case we have

1.1.2 bytesInFIFOCounter Design

Figure 1.4: bytesInFIFOCounter Data Flow Diagram

TUDublin © rgahan Page 5 of 10

1.1.3 countControl Design

Are there any bugs in this design?

Figure 1.5: countControl FSM Diagram

TUDublin © rgahan Page 6 of 10

1.1.4 counterDecode Design

A very simple block - it too must be checked!

Figure 1.6: counterDecode Logic

TUDublin © rgahan Page 7 of 10

1.1.5 UpDownCounter Design

Figure 1.7: foByteCount FSM Diagram

TUDublin © rgahan Page 8 of 10

1.1.6 4byteStore Functional Partition

Figure 1.8: 4byteStore Functional Partition

TUDublin © rgahan Page 9 of 10

1.2 TestQuestion1 FIFO Design and Code

Figure 1.9: FIFO4B Context Diagram

TUDublin © rgahan Page 10 of 10

You might also like

MIDAS CPD Digital Design 12 Week Course

The FIFO4 description of specication is as follows:

5. foFull(H) asserts when the 4 byte fo is Full

Figure 1.2: FIFO4 Timing Specication Diagram

Figure 1.7: foByteCount FSM Diagram

1.2 TestQuestion1 FIFO Design and Code