Return to Video

Adding Burst Transactions cs348 unit6

  • 0:01 - 0:06
    Let's have another look at our SOC model we saw in the beginning of this unit.
  • 0:06 - 0:10
    The different components exchange data via the Bus Interface. All right. So,
  • 0:10 - 0:14
    data flows, it's being read and written and things like that. Now, we're
  • 0:14 - 0:19
    building a new modern version of this SOC and we're adding additional features
  • 0:19 - 0:24
    to the Bus Architecture. In this case, it's going to be BURST Transactions. What
  • 0:24 - 0:29
    does this mean? In particular, it influences of how many transactions are being
  • 0:29 - 0:34
    exchanged between components at a time. So the number of transactions in a row
  • 0:34 - 0:38
    will be controlled by the BURST mode. There is a lot of other factors like
  • 0:38 - 0:43
    addressing and things like this which we will now discuss. Now, let's go ahead
  • 0:43 - 0:50
    and implement an add on a BURST type via AOP. In this file, we will add new
  • 0:50 - 0:55
    features to our existing verification environment. In particular, we're adding
  • 0:55 - 1:00
    support for BURSTS. The first step to do this is to use the existing enumerated
  • 1:00 - 1:05
    type called command_t, which specifies what kind of commands are being executed
  • 1:05 - 1:10
    on this Bus, and add a new value called BURST. The second step is then, to use
  • 1:10 - 1:16
    that new BURST type, extending our transactions, and do events subtyping. Inside
  • 1:16 - 1:21
    of this event subtype for BURST, we're adding a new field called burst_size, and
  • 1:21 - 1:27
    that field will be constrained to be able 8, 16, 32, or 64. So, the BURST, when
  • 1:27 - 1:32
    we send data, we will have to stay exactly within one of these values, right?
  • 1:32 - 1:39
    You cannot just do random number of, beats. The existing transaction has an,
  • 1:39 - 1:45
    already a field called number of beats. And we now will associate the burst_size
  • 1:45 - 1:50
    values with the number of beats. So, number of beats defines again, how many
  • 1:50 - 1:54
    read or write transactions you will perform in a row. We use a new form of
  • 1:54 - 2:00
    constraint syntax, so it makes our life easier. Instead of putting up some
  • 2:00 - 2:06
    complex [unknown] expression that says burst_size is 8 or 16 or 32 or 64, we can
  • 2:06 - 2:12
    just list the values here and say that burst_size is going to be inside of 8,
  • 2:12 - 2:18
    16, 32 or 64. To extend the enumerated type, we can just say, extend ENUM_TYPE
  • 2:18 - 2:23
    and just incrementally add our new fields here, our new values. In this case,
  • 2:23 - 2:27
    just BURST. Repeat events subtyping looks like this. You just say when, give the
  • 2:27 - 2:32
    new TYPE_NAME, and then, the original TYPE_NAME. And then, you implement your
  • 2:32 - 2:37
    functionality. So, put your code here. First, extend your command. Then, extend
  • 2:37 - 2:41
    your transaction. Add when subtyping, add the new field and the constraints.
Title:
Adding Burst Transactions cs348 unit6
Video Language:
English
Team:
Udacity
Project:
CS348 - Functional Hardware Verification
Duration:
02:41
Cogi-Admin added a translation

English subtitles

Revisions