In an ngspice netlist, one can add analysis, and other commands, in the control section.
For example:
.control
unset askquit
save vcc # branch
tran 1 n 500 n
plot vcc # branch
rusage all
.endc
Is there a way to add comments within the control section?Thanks
Related
So, as the title says, is it possible that Processor 0 has line A with a Shared (S) state, and Processor 1 has line B with an Invalid (I) state?
Imagine the following situation:
P0: Line A | Modified
P1: Line A | Invalid
P2: Line A | Invalid
If P2 makes a read request for Line A, what is P1 final state? Shared or keeps Invalid?
TL;DR
P1's line A will still be in Invalid state. An Invalid state cannot be changed by other processors' actions.
Both P0 and P2 will have line A in Shared state.
On the Wikipedia's page for the MSI protocol there's the state machine description of the algorithm.
Along with the English description, there are two pictures.
Given a set of processors and their relative cache lines, a processor can either be "active" by making one action among "load/read" and "store/write", or can be "passive" by snooping an event on the bus.
The input to the MSI (and similar) protocol is either an action or a bus event. For simplicity Wikipedia split the state machine in two: one when the input is an action and one when the input is a bus event.
This way you can use one picture to calculate the new states for the lines of the active processor (which is exactly one) and the other picture for the states of the lines of the passive processors.
Let's say processor X is the active one, thus making a load or a store.
The first picture describes how the cache lines state changes for processor X (the active processor):
Each label has the form x/y where x is the input action (either PrRd for a load/read or PrWr for a store/write) and y is the bus event that is emitted ("-" means no event is emitted on the bus).
The second picture is used similarly but for the passive processors (any processor but processor X):
Each label here is again a x/y pair but x is a bus event and y is a bus action.
The bus events are:
BusRd -> Another processor needs to read a line from memory (or upper cache).
BusRdX -> Another processor needs to read a line from memory (or upper cache) but then will immediately modify it (i.e. because it was doing a write).
BugUpgr -> Another processor just wrote to one of its cache line that was only read so far.
Of course, a Flush is the act of writing a line to memory. Wikipedia considers it a bus transaction (I consider it a bus action since it's not used as an input).
We are now ready to answer your question.
P2 is the active processor and needs to read line A, so it performs a PrRd. The first picture tells us that its line A will end up in S state and that a BusRd is issued on the bus (note that this is a mental model, real hardware won't probably send a special transaction, rather it will detect the read itself).
P2: LineA -> Shared
Both P0 and P1 are passive processors and both see the BusRd.
P0 has the line in state Modified, the second picture tells us that it will flush the line (making the last value available to P2) and set line A to state Shared.
P1 has the line in state Invalid, from the second picture we see that there is no way to escape an Invalid state for a passive processor. Specifically, the BusRd input will set the state of line A to Invalid again (it is actually ignored).
So after the read from P2 we have:
P0: LineA -> Shared
P1: LineA -> Invalid
P2: LineA -> Shared
I compiled BPF example from samples/bpf/pare_simple.c (from the Linux kernel tree) with very simple change:
SEC("simple")
int handle_ingress(struct __sk_buff *skb)
{
return TC_ACT_SHOT;
}
So I want ANY packets to be dropped. I install it as follows:
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
$ tc qdisc add dev eth0 clsact
$ tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple verbose
Prog section 'simple' loaded (5)!
- Type: 3
- Instructions: 2 (0 over limit)
- License: GPL
Verifier analysis:
0: (b7) r0 = 2
1: (95) exit
processed 2 insns, stack depth 0
So it seems it installs successfully, however this filter/ebpf does not drop packets, I generate ingress traffic on eth0 interface, e.g. ICMP, and it passes on. What am I doing wrong?
TL;DR: You should add direct-action flag to the tc filter command, as in
tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple direct-action verbose
^^^^^^^^^^^^^
The short help for tc bpf filter bpf help mentions this flag, but is has not made its way to the tc-bpf(8) manual page at this time, if I remember correctly.
So, what is this flag for?
eBPF programs can be attached two ways with tc: as actions, or as classifiers. Classifiers, attached with tc filter add, are supposed to be used for filtering packets, and do not apply an action by default. Which means that their return values have the following meaning (from man tc-bpf):
0 , denotes a mismatch
-1 , denotes the default classid configured from the command line
else , everything else will override the default classid to provide a facility for non-linear matching
Actions attached with tc action add, on the other hand, can drop or mirror or perform other operations with packets, but they are not supposed to actually filter them.
Because eBPF is kind of more flexible than the traditional actions and filters of tc, you can actually do both at once, filter a packet (i.e. identify this packet) and perform an action on it. To reflect this flexibility, the direct-action, or da flag was added (for kernel 4.4 or newer, with matching iproute2 package). It tells the kernel to use the return values of actions (TC_ACT_SHOT, TC_ACT_OK, etc.) for classifiers. And this is what you need here to return TC_ACT_SHOT in a way the kernel understands you want to drop the packet.
If I remember correctly, the reason why we use this flag instead of just dropping filters for actions is that you need a filter anyway with tc to attach you action to? (to be confirmed). So with the direct-action flag you do not have to attach both one filter and one action, the filter can do both operations. This should be the preferred way to go for eBPF programming with tc.
In QSYS I have an ADC, PLL and an Avalon-MM Read Master to access the internal ADC of the Altera Max10. The control and user interface of the Read Master are exported.
Now I struggle to setup the control interface to access the ADC channels. Mainly following signals:
control_fixed_location
control_read_base
control_read_length
The interface description is:
The block diagram for the Read Master is:
Questions:
- How do I need to set the control signals to access the ADC channel x?
- Where can I find the base address for the ADC implemented in QSYS?
Attached is the quartus archive. Maybe someone can give me an example to simulate this interface in ModelSim.
Thanks in advance!
I have an answer to your second question. I am struggling myself with the first question.
Where can I find the base address for the ADC implemented in QSYS?
I know two methods to find the base and end address of a component.
One is to open the System Contents view (standard) and scroll to the right side .
I am not permited to embed images yet.
There you see a row named Base and End. Here you can find the addresses.
The second method is to open the Address Map. Should be located in the same column as System Contents, or you can select View in the top left corner and select it there.
Have a look. You should be able to find it yourself with this information.
What i use when i am searching for examples or prebuild designs is the altera website. Here a link for you https://cloud.altera.com/devstore/platform/
Probably you like this one: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/max-10/ug_m10_adc.pdf
The configuration is complete in QSYS? Like selecting channels and Sequencer in your ADC Block. Selecting the right input clocks and the right frequencies?
You wrote:
In QSYS I have an ADC, PLL and an Avalon-MM Read Master to access the internal ADC of the Altera Max10. The control and user interface of the Read Master are exported.
Have you created a clock for your PLL? When i want to simulate a clock signal for a QSYS system i export the clock signals and define the wanted clock in an additional file.
When you go one step further and include a nios2 processor i recommend to have a look at the altera_modular_adc.c file.
*edit
If you haven't assigned any base addresses there is a function in QSYS which does the job for you.
In System (Same column as File) -> Assign Base Addresses
So I want to make a space for my code caves in minesweeper.exe (typical Windows XP minesweeper game, link: Minesweeper). So I modified the PE header of the file via CFF Explorer to increase size of the .text section.
I tried increasing raw size of .text segment by 1000h (new size was 3B58), but Windows was unable to locate the entry point and the game failed to launch. Then I tried increasing the size of the .rsrc section, adding a new section, increasing the image size, but none of those attempts were successful, Windows was saying that "This is not x32 executable".
So here is the question: how do I make space for my code cave? I don't want to search for empty space left by the compiler, I want to have nice and clean 1000h bytes for my code. A tutorial for that and a detailed explanation for how to do that without corrupting a game would be GREAT! (And yes, I am actually hacking a minesweeper)
You can't increase the size of a section without invalidating the following ones (typically because it invalidates offsets and addresses in those sections). This remains possible but it's extremely error prone and doesn't worth the hassle when you have a simpler solution.
Typically, you juste need to add a section at the end of the PE and jump there from the code section. There is usually a little bit of space at the end of the code section (code cave) so you can place your JMPs (or a little code stub) there to redirect to the new section. You can also add other new sections for data or new resources or whatever you want.
Note: I'm using two tools: CFF explorer as a PE browser; an hex editor.
This file is quite particular so it is a little bit harder than usual to add a new section.
Let's start!
Below is an hex view of the array of IMAGE_SECTION_HEADER:
Usually there is some room to add a new section but in this particular case, there's none... The last section header is immediately followed by something.
Judging by the content, this is probably a bound import directory, which is confirmed in CFF explorer (offset of the bound directory is 0x248):
Bound import directory are of no use today, especially with ASLR, so we can zero out the whole directory (its size is 0xA8 bytes as indicated in the previous screenshot):
You can also zero out the Bound Import directory RVA in the Data Directories although this is not strictly required:
Now, it's time to add the new section.
Add a new section
Minesweeper comes with 3 sections by default, so increment the Number of sections from 3 to 4:
Go to the sections headers and add a new section (you can do it directly in CFF explorer; I named mine, .foobar, be wary that section names are at most 8 characters and don't need to end with a NULL byte):
You need to choose two numbers:
The raw size of the new section (I picked 0x400) ; it must be a multiple of FileAlignment (which is 0x200 in this case).
The virtual size of the new section (I picked 0x1000); it must be a multiple of SectionAlignement (which is 0x1000 for this binary).
Now we" need to calculate the two other members, Virtual Address and Raw Address.
Virtual Address
Let's take an example with the first and second section.
The first section starts at virtual address 0x1000 and has a virtual Size of 0x3A56. The next section virtual address must be aligned on SectionAlignement (0x1000) so the calculation is (using python here):
>>> def round_up_multiple_of(number, multiple):
num = number + (multiple - 1)
return num - (num % multiple)
>>> hex(round_up_multiple_of(0x1000 + 0x3a56, 0x1000))
'0x5000'
Which gives 0x5000 which is right (.data section starts at virtual address 0x5000).
Now, where our last section should start?
.rsrc section starts at 0x6000 and has a size of 0x19160:
>>> hex(round_up_multiple_of(0x6000 + 0x19160, 0x1000))
'0x20000'
So it must start at virtual address 0x20000. Put that number in Virtual Address.
Raw address
(Typically this is not needed as all sections are already aligned the last section must start right at the end of the file, but we'll do it).
As a reminder, the raw address is an address in the file (not in memory).
Let's start with an example (first and second section):
The first section raw address is 0x400 and its raw size 0x3c00. FileAlignement is 0x200, thus:
>>> hex(round_up_multiple_of(0x400 + 0x3c00, 0x200))
'0x4000'
The second section should start on the file (its Raw address) at 0x4000 which is right.
Thus for our new section, the calculation is:
.rsrc section starts in the file at 0x4200
.rsrc section size on file is 0x19200
FileAligment is 0x200
The calculation is as follow:
>>> hex(round_up_multiple_of(0x4200 + 0x19200, 0x200))
'0x1d400'
Our last section starts at the raw address 0x1d400 in the file which is confirmed with an hex editor:
Final steps
One last step is required, the calculation of the SizeOfImage field in the Optional header. According to the PE specification the field is:
The size (in bytes) of the image, including all headers, as the image
is loaded in memory. It must be a multiple of SectionAlignment.
Hence the calculation can be simplified as: VirtualAddress + VirtualSize of the last section, aligned on SectionAlignment (0x1000):
>>> hex(round_up_multiple_of(0x20000 + 0x1000, 0x1000))
'0x21000'
Now, save all your modifications in CFF explorer and exit.
Adding room for the new section
The last step is to add the required bytes for the last section. As I choose a Raw size of 0x400, I insert 0x400 bytes at Raw Address (0x1d400) with an hex editor.
Save you file. If you followed all the steps it must work (tested on Win 10) as is and you can start the modified executable without any errors.
Try to experience with a different raw size for the new section if 0x400 is not enough.
Now you have a new empty section, the rest is up to you for modifying the code :)
I have a piece of hardware connected to an FMC, I know for a fact that there is a design fault and the hardware has a polarity inversion along the FMC pins. I want to simply try and quickly correct for this.
I tried doing it in the project, on the LVDS buffers, the inputs were connected to a "not" to try and flip them, this gave me this error for the pins:
NgdBuild:925 - input net 'usr/fmc2_map/la[0].fmc_la_buf/io_n_INV_1415_o'
is connected to the incorrect side of buffer(s):
Next I tried editing the UCF file:
NET "fmc2_la_n[0]" LOC = G20 ; # IO_L10N_MRCC_26
NET "fmc2_la_p[0]" LOC = F21 ; # IO_L10P_MRCC_26
NET "fmc2_la_n[1]" LOC = H20 ; # IO_L11N_SRCC_26
NET "fmc2_la_p[1]" LOC = H19 ; # IO_L11P_SRCC_26
I tried swapping over the n and p, I'm told that I'm inverting the polarity (which is what I want to do) and it tells me to add this:
XIL_PAR_ALLOW_LVDS_LOC_OVERRIDE
But where do I add this, or how do I disable these messages?
For the weary traveller....
Type this into the command line before launching ise:
export XIL_PAR_ALLOW_LVDS_LOC_OVERRIDE="1"