How to calculate number of bits in logical address and physical address when
logical address space of 8 pages of 1024 word each, mapped to physical memory of 32 frames?
15 is the correct answer
i think this is correct way
size of logical address space is No. of pages * Page size = 8 * 1024 = 2^3 * 2 ^10 = 2^13 No. of bits for logical address is 13
Size of Physical address space is 2^5 * 2^10 = 2^15 No. of bits for physical address is 15
Consider the following room/floor analogy: Each floor in a hotel contains 10 rooms. The door in each room is labeled 01, 02, 03, ..., 10. Then you get off the elevator, there is a plaque with the floor number. There are 3 floors in this hotel: floors 1, 2, and 3. Therefore, you can say that, to eliminate the ambiguity in room numbers, you concatenate the floor number to the room in the following format: floor:room. So, 1:01 is different than 2:01, or 3:01.
Viewing this graphically:
1 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
2 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
3 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
The floor number can be expressed with one digit. The room number can be expressed with two digits. To express the unique location of the room (floor:room concatenation), you need three digits. Replace floor with frame, and room with page.
There are 8 pages in logical address space so, 2^3 = 8 then page size of 3-bits
We have 1024 words(1 word = 2-bytes) then, 1024 * 2 = 2048 bytes
which we can say that 2^11 = 2048 then so there are 11 + 3 = 14-bits are the total number of bits in a logical address.
Now coming towards the Physical address:
we have 32 frames so 2^5 = 32 we have 5-bits for frame + 11 bits = 16-bits
then we have 16-bits for our physical address.
Offset for both pages and frames is the same to comply with design. In the problem, offset is 1024, so offset for page = offset for frame = 2^10.
Total bits needed to give logical address to each word of each page = 3+10.
Since there are 5 bits needed to uniquely define each frame,the Physical address will require 5+10 = 15 bits.
size of logical address space is No. of pages * Page size
= 8 * 1024
= 2^3 * 2 ^10 = 2^13
No. of bits for logical address is 13
Size of Physical address space is 2^5 * 2^10
= 2^15
No. of bits for physical address is 15
here i think the main memory information is not needed at all.
Given Total no of pages = 8 and page offset is 1024.
we know that logical address spaces is = total no of bits required to represent total no of pages + bits required to map page offset.
Hence total bits required = 3 (because total no of pages is 8 and to represent you need three bits) + 10 (page offset is 1024 so you need 10 bits) = 13 bits all total.
Thanks.
After searching the internet, i could find the solution for the question.
Each page/frame holds 1K; we will need 10 bits to uniquely
address each of those 1024 addresses. Physical memory has 32 frames and
we need 32 (2^5)
bits to address each frames, requiring in total 5+10=15 bits.
A logical address space of 8 pages requires 3 bits to address each page
uniquely, requiring 13 bits in total.
this tutorial will provide more details regarding this question
Related
Can anyone tell me or point me to a section of the specification(s) that clearly demonstrates how from an elementary stream with a series of NALUs how these should be written into a ISO BMFF mdat?
I can see looking at samples and other code that I should have something like: AUD, SPS, PPS, SEI, VideoSlice, AUD etc etc
Things that are not entirely clear to me:
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
What is the requirement for AUDs?
If I am generating sample sizes for the trun is the calcuation for this? In the example I am working to recreate the first sample in the trun has a size of 22817 however if I look at the first sample in the mdat the NALU size prefix is 22678. The value in the trun appears to be the size of all the NALUs + sizes up to and including the first sample (see my example below)
>
1 0016E405 (1500165) - box.Size
2 6D646174 (mdat) - box.Type
3 00000002 (2) NAL Size
4 0910 - (2) AUD # 5187
5 00000025 (37)
6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
7 00000004 (4)
8 28DEBCB0 (4) PPS
9 0000000B (11)
10 06000781 36288029 67C080 (? SEI ?)
11 0000000C (12)
12 06010700 00F00000 03020480 (? SEI is type 6)
13 0000002D (45) # 5269
14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
15 00005896 (22678)
16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
No
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
Yes, if you choose to include them, but there is no reason to
What is the requirement for AUDs?
They are optional
If I am generating sample sizes for the trun is the calcuation for this?
The number of bytes in the access unit (AU, aka frame). Which may contain more than one NALU. SPS/PPS/SEI/AUD all counted toward the AU size. The 4 byte size prefixed to each NALUs is also counted in the AU size recored in the trun.
bytes
4 | 3 00000002 (2) NAL Size
2 | 4 0910 - (2) AUD # 5187
4 | 5 00000025 (37)
37 | 6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
4 | 7 00000004 (4)
4 | 8 28DEBCB0 (4) PPS
4 | 9 0000000B (11)
11 | 10 06000781 36288029 67C080 (? SEI ?)
4 | 11 0000000C (12)
12 | 12 06010700 00F00000 03020480 (? SEI is type 6)
4 | 13 0000002D (45) # 5269
45 | 14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
4 | 15 00005896 (22678)
22678 | 16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
------|
22817 | <- bytes total
I have some question related the RISC V manual
It has different types of instruction encoding such as R-type,I-type.
Just like the MIPS encoding.
* R-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| funct7 | rs2 | rs1 |funct3| rd | opcode |
+------------+---------+---------+------+---------+-------------+
* I-type
31 20 19 15 14 12 11 7 6 0
+----------------------+---------+------+---------+-------------+
| imm | rs1 |funct3| rd | opcode |
+----------------------+---------+------+---------+-------------+
* S-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| imm | rs2 | rs1 |funct3| imm | opcode |
+------------+---------+---------+------+---------+-------------+
* U-type
31 11 7 6 0
+---------------------------------------+---------+-------------+
| imm | rd | opcode |
+---------------------------------------+---------+-------------+
But it also have something called immediate format:
such as I-immediate, S-immediate and so on
* I-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 24:21 |20|
+-----------------------------------------+-----------+-------+--+
* S-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 11:8 |7 |
+-----------------------------------------+-----------+-------+--+
* B-immediate
31 12 11 10 5 4 1 0
+--------------------------------------+--+-----------+-------+--+
| <-- 31 |7 | 30:25 | 11:8 |z |
+--------------------------------------+--+-----------+-------+--+
* U-immediate
31 30 20 19 12 11 0
+--+-------------------+---------------+-------------------------+
|31| 30:20 | 19:12 | <-- z |
+--+-------------------+---------------+-------------------------+
* J-immediate
31 20 19 12 11 10 5 4 1 0
+----------------------+---------------+--+-----------+-------+--+
| <-- 31 | 19:12 |20| 30:25 | 24:21 |z |
+----------------------+---------------+--+-----------+-------+--+
According to the manual, it say those immediate is produced by RISC-V instruction but how are the things related?
What is the point to have immediate format?
The 2nd set of diagrams is showing you how the immediate bits are concatenated and sign-extended into a 32-bit integer (so they can work as a source operand for normal 32-bit ALU instructions like addi which need both their inputs to be the same size).
For I-type instructions it's trivial, just arithmetic right-shift the instruction word by 20 bits, because there's only one immediate field, and it's contiguous at the top of the instruction word.
For S-type immediate instructions, there are two separate fields in the instruction word: [31:25] and [11:7], and this shows you that they're in that order, not [11:7, 31:25] and not with any implicit zeros between them.
B-type immediate instructions apparently put bit 7 in front of [30:25], and the low bit is an implicit zero. (So the resulting number is always even). I assume B-type is for branches.
U-type is also interesting, padding the 20-bit immediate with trailing zeros. It's used for lui to create the upper bits of 32-bit constants (with addi supplying the rest). It's not a coincidence that U-type and I-type together have 32 total immediate bits.
To access static data, lui can create the high part of an address while lw can supply the low part directly, instead of using an addi to create the full address in a register. This is typical for RISC ISAs like MIPS and PowerPC as well (see an example on the Godbolt compiler explorer). But unlike most other RISC ISAs, RISC-V has auipc which adds the U-type immediate to the program counter, for efficient PIC without having to load addresses from a GOT (global offset table). (A recent MIPS revision also added an add-to-PC instruction, but for a long time MIPS was quite bad at PIC).
lui can encode any 4k-aligned address, i.e. a page-start address with 4k pages.
I have been working on viterbi decoder in matlab2009 on simple 1/2 rate convolutional encoder.
Here is my code
trel = poly2trellis(3,[7 5]);
msg = [ 0 1 0 1 1 1 0 0 1 0 1 0 0 0 1 ];
code = convenc(msg,trel);
% Traceback Length
tblen = 5;
ucode = real(awgn(1-2*code,tblen,'measured'));
dcd = vitdec(ucode,trel,tblen,'cont','unquant');
According to this input code
i am getting the code = 00 11 10 00 01 10 01 11 11 10 00 10 11 00 11
which is correct
but talking about the dcd which is output after viterbi decoder is coming incorrect
i.e 000000101110010. which is far different from my msg input.
guide me where i am going incorrect
The decoded output depends on the type of opmode Input you selected.
In case of cont, there is a delay in the output equal to tblen number of symbols whereas there are 'term' and trunc modes as well.
You can compare the initial msg(1,end-tblen) symbols with dcd(1,tblen+1:end). They are same!
You may check vitdec at Matlab help.
I have been breaking my head about trying to optimise a matlab script that needs to process quite long arrays.
Basically, there are 2 arrays: AbsoluteTimeTag and Channel.
AbsoluteTimeTag will hold int values signifying time that are recorded using a 16 bit counter. Since the counter is limited to 2^16 values it will often roll over during the course of the measurement. Channel registers this and when it does, bitand(Channel,2048) will evaluate true.
How these arrays are generated is out of my control and the overflow markers occur "in sync" with the data coming in.
It is now easy to reconstruct the absolute time by doing:
AbsoluteTimeTag(i) = NoOfOverflows * 65536 + TimeTag(i);
In a loop:
for i=1:NumberOfRecords
%Running through all records, if we meet anything other than an
%overflow record, we van just calculate its absolute time based on
%current overflow count and its timetag.
AbsoluteTimeTag(i) = NoOfOverflows * 65536 + TimeTag(i);
% We are running through all records so if we encounter an overflow
% (signified by bitand(..., 2048), we add 1 to the overflow count.
if bitand(Channel(i),2048)
NoOfOverflows = NoOfOverflows + 1;
end;
end;
I have been really breaking my head on how to potentially vectorise this (since Matlab is pretty bad at loops). So far however, I do not see the light for some reason.
Problem is that the number of overflows up to a certain record index along AbsoluteTimeTag can change as you walk the vector from start to end.
I do not know how I could express "count all occurrences of overflow up to this point" in a vectored operation.
Can somebody comment on whether or not this might be feasible at all?
EDIT
Example data would look like this:
TimeTag (each element is an event for which time is counted un a 2^3 register for simplicity):
[ 01 03 04 07 xx 02 03 04 05 xx 01 03 04 07 xx ... ]
overflow:
[ 00 00 00 00 01 00 00 00 00 01 00 00 00 00 01 ... ]
Which would need to yield
[ 01 03 04 07 xx 10 11 12 13 xx 17 19 20 23 xx ... ]
The reason xx is there is because originally, all records, both the events and the overflows are in one large uint32 array where each record holds different types of info on the different bits. The xx locations can undergo any operation but they are further meaningless when considering the TimeTag records. I have a logical array keeping track of what locations hold actual meaningful data.
"count all occurrences of ... to this point" in a vectored operation would be best expressed as cumsum.
Assuming NoOfOverflows is initialized as zero before the start of the loop and AbsoluteTimeTag, Timetag have NumberOfRecords as their number of elements , see if this works for you -
%// Get the overflow for all Channel entries in one go
bitand_all = bitand(Channel,2048)~=0;
%// AbsoluteTimeTag appears to be a cumsum of overflows plus Timetag
AbsoluteTimeTag = [0 ; cumsum(bitand_all(1:end-1).*65536)]+ TimeTag;
%// Get the count of overflows as NoOfOverflows
NoOfOverflows = sum(bitand_all);
Consider a magnetic tape drive with density=1666 bpi and IBG=0.5 inch. How many inches of tape are required to store 50,000 records, each record is 120 bytes. Blocking factor is 45.
I don't understand how to convert the units to an answer...
You don't specify how many bits per byte, but if you assume 8 bits is 1 byte, then each 120 byte record will be 120 * 8 = 960 bits.
The total number of bits in 50,000 records will be 50,000 * 960 = 48000000 bits. At a density of 1666 bpi, this is 48000000 / 1666 = 28811.5 inches.
Then, as your blocking factor (I'm assuming this means the number of records per data block), is 45, and you have 50,000 records, you will need 50,000 / 45 = 1112 blocks (rounded up), so there will be 1111 inter-block gaps (IBG). Therefore, you will have 1111 * 0.5 inches of IBG = 555.5 inches.
In total, you will have 28811.5 + 555.5 = 29367 inches of tape.
You'll need to double-check my assumption of the terminology and also the underlying size of a single byte in bits.