1
00:00:01,420 --> 00:00:07,480
What are the pros and cons of this key design approach, this lecture will answer this question and

2
00:00:07,480 --> 00:00:13,150
give the underlying idea of using the design techniques explained in the rest of this section.

3
00:00:15,600 --> 00:00:22,290
As mentioned previously in discourse, this key design approach provides efficient implementations for

4
00:00:22,290 --> 00:00:29,910
sequential circuits such that they can accept inputs in every class cycle and provide the maximum throughput

5
00:00:30,270 --> 00:00:32,070
available to an application.

6
00:00:35,090 --> 00:00:41,930
The first benefit of the ISKA design approach is performance, if you can design our circuit, considering

7
00:00:41,930 --> 00:00:48,230
the highest frequencies available in the underlying FPGA platform, we can provide high performance

8
00:00:48,230 --> 00:00:53,810
hardware as the second potentially can consume and generate data on each clock cycle.

9
00:00:54,200 --> 00:00:57,700
In other words, the circuit doesn't waste any clock cycle.

10
00:01:00,090 --> 00:01:04,680
The second benefit is the simplicity of the communication between two Hakamada.

11
00:01:05,730 --> 00:01:13,080
Let's consider a data generator hardware module denoted by M1 and a data consumer hardware module denoted

12
00:01:13,080 --> 00:01:13,740
by M2.

13
00:01:14,250 --> 00:01:21,460
If M1 generates its data in each cycle, then M2 will consume that data in the following cycle.

14
00:01:22,230 --> 00:01:26,730
Therefore, there is no need to have any synchronization mechanism between them.

15
00:01:27,660 --> 00:01:34,200
The only constraint is that the data generator should keep the data stable during each clock cycle to

16
00:01:34,200 --> 00:01:36,220
be consumed by the data consuming.

17
00:01:41,110 --> 00:01:47,230
The first drawback is the high clock period, and it is when we cannot design a circuit with a fast

18
00:01:47,230 --> 00:01:47,900
clock signal.

19
00:01:48,400 --> 00:01:49,960
We should increase the clock period.

20
00:01:50,200 --> 00:01:52,720
Consequently, reducing the performance.

21
00:01:54,350 --> 00:02:00,800
The second drawback is unsynchronized data transaction in some circuits following the risky design approach

22
00:02:00,800 --> 00:02:01,630
is not possible.

23
00:02:02,680 --> 00:02:08,470
If it is, science cannot generate their output data or consume their input data on each clock cycle,

24
00:02:09,100 --> 00:02:16,360
then the communication between two modules can be complicated as they do not know when the data is ready

25
00:02:16,360 --> 00:02:17,140
for consumption.

26
00:02:18,690 --> 00:02:25,830
The consumer model may miss some input data or receive invalidate to handle this issue, and explicit

27
00:02:25,830 --> 00:02:31,830
synchronization or hand checking mechanism is required for communication between two modules.

28
00:02:35,680 --> 00:02:43,240
Using the ESC approach to design all circuits is impossible, so some circuits require hand checking

29
00:02:43,450 --> 00:02:49,220
to inform others if they generated data are valid to provide safe data transactions.

30
00:02:49,780 --> 00:02:54,960
What are the handshaking mechanisms available in Etchells and how can we use them?

31
00:02:55,630 --> 00:03:00,540
The next lecture will define the general concepts of handshaking in Etchells.

32
00:03:02,860 --> 00:03:08,740
These are our takeaway messages, this good design approach facilitates a data transaction between two

33
00:03:08,740 --> 00:03:09,310
modules.

34
00:03:10,460 --> 00:03:14,930
There should be a handshaking mechanism between two multiclass cycle modules.

35
00:03:18,000 --> 00:03:23,820
Now, the quiz question, when do we need the handshaking mechanism between two logic circuits?