I'm investigating the edk2 (UEFI). So, I have some concerns about path of device defined in the DSDT table. In this table, we use /_SB for the root of system bus, but it's /_SB_ on Linux. For instance, I checked via command
$ cat /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0A08\:00/device\:00/path
And sometime, I also see some ACPI table use /_SB_ for referring a device path.
Do you know how it is different? How use it?
Thank you so much!
The ACPI specification (I here and further refer to v6.4) chapter 19.3.1 defines characters allowed to be used in the names. Though it doesn't tell clearly what happened to the names shorter than 4 characters. This is clarified in chapter 5.3
By convention, when an ASL compiler pads a name shorter than 4 characters, it is done so with trailing underscores (‘_’). See the language definition for AML NameSeg in the ACPI Source Language (ASL) Reference chapter.
This is also confirmed by chapter 20.4 which shows byte stream in AML. In example the name
\S2
is translated to
RootChar 'S2__'
That said, the \_SB and \_SB_ are the equivalent notations of the same name.
Related
The h.264 specifications from ITU 2017 contain this copyright notice:
(C) ITU 2017
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
I am writing a decoder, and I have some structs corresponding to some of the syntax structures defined in these specs. I have been commenting the fields of these structs (which are again reflecting fields of the syntax structures), and I am finding that it's really hard for it not to appear as if I'm just copying from the respective sections in the specs. Some of the phrases are quite short, and there is really no other way to word them.
I've tried looking at the details regarding copyright, and what constitutes an infringement, but I'm still not quite sure if what I'm doing is okay.
If I'm not allowed to do this, what do you guys recommend ?
Cheers
"I am writing a decoder... I am finding that it's really hard for it not to appear as if I'm just copying from the respective sections in the specs"
I think you're worried about nothing. When writing a decoder it's logical to quote the format's official specifications for readability purposes (eg: when code is passed on to another coder at some future date).
Are you quoting the examples pseudo-code from the section 7: Syntax and semantics?
"The syntax tables specify a superset of the syntax of all allowed bitstreams. Additional constraints on the syntax may be
specified, either directly or indirectly, in other clauses."
NOTE – An actual decoder should implement means for identifying entry points into the bitstream and means to identify and handle non-conforming bitstreams. The methods for identifying and handling errors and other such situations are not specified here.
"The following table lists examples of pseudo code used to describe the syntax. When syntax_element appears, it specifies that a syntax element is parsed from the bitstream and the bitstream pointer is advanced to the next position beyond the syntax element in the bitstream parsing process."
I'm using sharpsnmplib open source library to compile MIB files and use them in my custom snmp browser. The issue is that sharpsnmplib cannot compile RMON2-MIB file. And subsequent libraries that use it cannot be compiled as well. As it turns out, the (first) issue is with the text (RMON2-MIB.txt):
LastCreateTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object that stores the last time its
entry was created.
This can be used for polling applications to determine that an
entry has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data."
SYNTAX TimeStamp
Sharpsnmplib’s textual convention interpreter contains this text:
/*
* RFC2579 definition:
* Syntax ::= -- Must be one of the following:
* -- a base type (or its refinement), or
* -- a BITS pseudo-type
* type
* | "BITS" "{" NamedBits "}"
*
* From section 3.5:
* The data structure must be one of the alternatives defined
* in the ObjectSyntax CHOICE or the BITS construct. Note
* that this means that the SYNTAX clause of a Textual
* Convention can not refer to a previously defined Textual
* Convention.
…
Sharpsnmplib interpreter’s source
RMON2-MIB
RFC 2579
Interesting thing is that TimeStamp IS the textual convention defined in the SNMPv2-TC. And RMON2-MIB defines its own textual convention that uses TimeStamp. There are several other textual conventions in the RMON2-MIB that refer textual conventions from other MIB files.
Thus, if I’ve got it right, RMON2-MIB violates RFC2579. But this doesn’t make sense if RMON2-MIB is actively used MIB file.
What am I missing? How should the RMON2-MIB be properly interpreted?
First, #SNMP's open source MIB parser SharpSnmpLib.Mib is buggy and obsolete, as #SNMP Pro has a new SharpSnmpPro.Mib.
The code you found was even older (my handmade version), so I never expected it able to parse difficult MIB documents.
Second, RMON2-MIB is a very complex one, as it does rely on both SMIv2 core MIBs, as well as several SMIv1 ones. That requires you to have all dependencies properly located (using the correct copies, instead of downloading corrupt ones from the Internet).
Third, there is no conflict between RFC 2579 and RFC 4502 (RMON2-MIB). RMON2-MIB defines its own textual convention that uses TimStamp and that's nothing special or wrong.
I'm having some trouble designing a single port rom onto a spartan 6 board. I use the provided core generator to create block memory and choose single port rom with 32 bit width and 256 depth with a coe file that just counts from 0 to 255. I drop the rom into my vhdl as a component and add the XilinxCoreLib as a library. When I try to generate the programming file I get the translate error:
logical block 'rom1' with type 'rom' could not be
resolved. A pin name misspelling can cause this, a missing edif or ngc file,
case mismatch between the block name and the edif or ngc file name, or the
misspelling of a type name. Symbol 'rom' is not supported in target
'spartan6'.
I'm currently using Xilinx ISE 13.1 if that helps. I feel like this should be really easy to do but I haven't been able to find how to do it.
Edit: Thanks everyone, was a combination of things. Wrong speed grade, and didn't add a copy of the ngc file to my working directory. I'll use arrays in the future.
Easiest way is to forget the vendor tools altogether and simply declare a constant array!
If this is in a package separate from the rest of the design, a few lines of printf's or a simple script can generate the VHDL boilerplate around the contents, which come from your assembler or whatever tool creates the actual data
Since you're adding a Xilinx generated core to your design in ISE, you need to add both the VHD file and the NGC file via "Add Source" via the Project menu.
Even easier, depending on how large your ROM needs to be and what data goes into it, would be to not even bother with a Xilinx core, but to use pure VHDL to declare a constant array and initialization values right in your VHDL file. Here is an example:
type array_ROM is array (0 to NUMBER_OF_ROWS-1) of std_logic_vector (ROM_BITWIDTH-1 downto 0);
signal my_ROM : array_ROM
:=
(
x"12345678",
x"ABCDEF01",
...
x"01010101"
);
Now, you don't put the elipsis (...) in that initialization list, just put rows of constants with bit widths matching ROM_BITWIDTH. The NUMBER_OF_ROWS is the number of address locations you need in the ROM. In this example, ROM_BITWIDTH would have to be set to 32 as I've used 32-bit hexadecimal constants in the initialization list. Being a signal, it's actually modifiable, so if you need it to be constant, just use "constant" instead of signal.
I guess the problem is, as the message says, a misspelling. to get the correct component declaration/instantiation, select your rom.xco in the design-window of ISE. then select "view vhdl instantiation template" from process window. use the component declaration and instantiation described therein.
There are a number of things that can cause this problem, one is that you are using a blocck that was generated for another FPGA family and using it inside the Spartan6. the other is that you may have generated the ROM using an older version of the tool and the wrapper for the ROM has changed since then.
You can either generate a anrray like Brian suggested and forgetting about the tool specific ROM type, or re-generate the IP under your curernt project settings and see how it goes.
I have prepared an IP core named Cache(Block Memory Generator) in Xilinx. When i instantiated it in my module and synthesized it, i got an error saying Illegal Re-declaration of module<Cache>. The name of the same cannot be changed since it is an intellectual property of xilinx.
This is an error in your C-code.
You use a module-name called "Cache" that has been used before.
Maybe the module-name is used by xilinx in a standardmodule or by you.
Maybe you are including the "Cache.h" file more then one time.
Check your code for lines looking like the following:
include "Cache.h"
If you find more then one line, try to comment one of the lines out and try to recompile your project.
I'm new to programming with the Win32 API, and I'm still getting used to the prefix / suffix data type naming conventions. While Google and a little common sense will normally explain what the prefix is referring to, it would be nice if there was one (relatively) concise guide to explain them. Does anyone know of a resource like this?
And on a related note, what does the '_' (underscore) prefix mean with a variable? Does that underscore have a name, other than "underscore"?
The naming convention is called Hungarian Notation, as mentioned by others. Since you're not familiar with it, and are probably going to start using it, it is worth mentioning there are two main flavors of Hungarian:
prefix the variable with its type code
prefix the variable with its usage code
The difference is visible when, for instance, an int is used to describe the number of bytes in a certain strings. On the former, nLen will be used, meaning the variable is an int. On the later, cbLen will be used, meaning the variable counts bytes (as opposed to cchLen, which counts characters). Give this article a look, should give you a better explanation.
As for the underscores in front of a variable or function - this is a naming convention reserved for the compiler and its standard library. Some people use it for other purposes, but they really shouldn't. The purpose of the convention is to provide the compiler a naming standard that will prevent collisions with names given by the user.
Win32 API follows Hungarian Notation
It's called a hungarian notation, Wikipedia has some information about it, and there's something on MSDN.