I have a 64bit register and want to define an event when it changes,something like:
event clk is change('~/top.reg')#sim;
Is there a limitation on the number of bits in top.reg? and if yes, how can I do the same for 64bit reg?
You can sample only the bits that interest you in the register instead of all the register, which will be costly in performance.
if you want to sample all the register you can divide the sample into 2 X 32 bits.
You can also define list of event ports and connect each list item to the specific register's bit.
Related
I am working on a project that requires me to use 5 TLC7524 DACs. They will all be receiving data from an 8 bit bus. For data transfer, the process is CS pin, WR pin, send Data. I was wondering if I could get away with grounding the CS pin on all of them and control them with just the WR pin.
Link to datasheet for TLC7524 -
http://www.ti.com/lit/ds/slas061d/slas061d.pdf
Usual way is select the DAC by /CS and the /WR signal is common for all of them.
In this way, you can connect it on FMC and create the /CS for each chip from the address (FMC is available on Nucleo144 boards, but not on Nucleo64 ones).
Also selected chips may have much higher current consumption (as they are active). For example SRAM chips are using much more current when enabled by /CS.
I am currently using the STM32F103RD processor, which has 14 available filters on the CAN1 bus.
I am connecting to a J1939 bus, and I need to monitor around 20 PGN's. How do I handle setting up the 20 PGN's with only 14 filters available?
These 20 PGN's are not sequential, so I can't setup a specific range to allow. These 20 may be all over the place.
You have 14 filter banks, but each of those banks can match two distinct PGNs using identifier list mode (FBMx=0). So you can actually match up to 28 PGNs with this part! See section 24.7.4 of the STM32F10x reference manual (page 655) for details.
If you need to match more than 28 PGNs, you have two options:
Pick sets of three or more PGNs and match each of those sets with a single mask-mode filter bank. To reduce the number of unwanted messages that are matched, you will need to pick the sets of matched PGNs carefully (i.e, keep the number of "don't care" bits in the resulting mask to a minimum). Since J1939 is relatively slow, though, filtering some unwanted messages out in software shouldn't be a huge burden.
Use a connectivity-line STM32 part, such as the STM32F107VC. These parts have double the number of CAN filter banks.
I got it working using the list mode. The tricky part is that PGNs need to be shifted around into a 32-bit header so that it can match the "CAN_RI0R" register to trigger an interrupt. For example, I want to receive Engine RPM which is PGN 61444 (0xF004). This needs to be converted into the following header:
0xC7802004
How to compute this:
Start with PGN 61444 (0xF004)
Shift it left by 8 bits so that it is in the correct J1939 Frame Format location.
OR it with 0x0018000000
Shift it left by 3 bits so that it matches the STM32 register locations for STID/EXID.
OR it with 0x4 to set the "Extended" bit indicating that it is an extended header.
The only caveat with this method, versus the mask mode is that as far as I know, you can only receive messages from one single ECU, since the source address is included in the header, and it must match exactly. Meaning, you can only receive messages from the Engine ECU (0x00). For example, 0x18F004XX, where XX is the source address. When using the mask mode, you can ignore the Source Address bits, and receive the PGN from any ECU.
I have a product that is basically a USB flash drive based on an NXP LPC18xx microcontroller. I'm using a library provided from the manufacturer (LPCOpen) that handles the USB MSC and the SD card media (which is where I store data).
Here is the problem: Internally the LPC18xx has a 64kB (limited by hardware) buffer used to cache reads/writes which means it can only cache up to 128 blocks(512B) of memory. The SCSI Write-10 command has a total-blocks field that can be up to 256 blocks (128kB). When originally testing the product on Windows 7 it never writes more than 128 blocks at a time but when tested on Linux it sometimes writes more than 128 blocks, which causes the microcontroller to crash.
Is there a way to tell the host OS not to request more than 128 blocks? I see references[1] to a Read-Block-Limit command(05h) but it doesn't seem to be widely supported. Also, what sense key would I return on the Write-10 command to tell Linux the write is too large? I also see references to a block limit VPD page in some device spec sheets but cannot find a lot of documentation about how it is implemented.
[1]https://en.wikipedia.org/wiki/SCSI_command
Let me offer a disclaimer up front that this is what you SHOULD do, but none of this may work. A cursory search of the Linux SCSI driver didn't show me what I wanted to see. So, I'm not at all sure that "doing the right thing" will get you the results you want.
Going by the book, you've got to do two things: implement the Block Limits VPD and handle too-large transfer sizes in WRITE AND READ.
First, implement the Block Limits VPD page, which you can find in late revisions of SBC-3 floating around on the Internet (like this one: http://www.13thmonkey.org/documentation/SCSI/sbc3r25.pdf). It's probably worth going to the t10.org site, registering, and then downloading the last revision (http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r36.pdf).
The Block Limits VPD page has a maximum transfer length field that specifies the maximum number of blocks that can be transferred by all the READ and WRITE commands, and basically anything else that reads or writes data. Of course the downside of implementing this page is that you have to make sure that all the other fields you return are correct!
Second, when handling READ and WRITE, if the command's transfer length exceeds your maximum, respond with an ILLEGAL REQUEST key, and set the additional sense code to INVALID FIELD IN CDB. This behavior is indicated by a table in the section that describes the Block Limits VPD, but only in late revisions of SBC-3 (I'm looking at 35h).
You might just start with returning INVALID FIELD IN CDB, since it's the easiest course of action. See if that's enough?
I'm working on a project where I need to send a value between two pieces of hardware using CoDeSys. The comms system in use is CAN and is only capable of transmitting in Bytes, making the maximum value 255.
I need to send a value higher than 255, I'm capable of splitting this over more than one byte and reconstructing it on the receiving machine to get the original value.
I'm thinking I can divide the REAL value by 255 and if the result is over 1 then deconstruct the value in to one byte holding the remainders and one byte holding the amount of 255's in the whole number.
For example 355 would amount to one byte of 100 and another of 1.
Whilst I can describe this, I'm having a really hard time figuring out how to actually write this in logic.
Can anyone help here?
This is all handled for you in CoDeSys if I understand you correctly.
1. CAN - Yes it's in byte but you must not be using CANopen you are using the low level FB that ask you to send a CAN frame of an 8 byte array?
If it is your own two custom controllers ( you are programming both of them in CoDeSys) just use netvariables. Netvariables allows you to transfer any type of variable and you can take the variable list from one controller and import it to another controller and all the data will show up. You don't have to do any variable manipulation it's handle under the hood for you. But I don't know the specifics of your system and what you are trying to do.
If you are trying to deconstruct construct variables from one size to another that is easy and I can share that code with you.
In the movie The Social Network, when Mark Zuckberg was in class, the teacher asked this question:
Suppose we're given a computer, with a 16-bit virtual address, and a page size of 256-bytes,the system uses one-level page tables that start at address hex 400, may be you want DMA (Direct Memory Access) on your 16-bit system. Who knows? The first pages are reserved for hardware flags, etc. Assume page-table entries have eight status bits. The eight status bits would then be ...
Mark Zuckberg answered:
One valid bit, one modified bit, one reference bit and five permission bits.
How did he get this?
http://chomaloma.blogspot.com.au/2011/02/social-network-inaccuracies-regarding.html
That does explain it a little
Intel nomenclature in parentheses. The 'valid' (present), 'modified' (dirty) and 'reference' (accessed) bits are the minimum set of bits you need for a demand paging manager and MMU.
The 'valid' (present) bit is used by the MMU to know whether the page is mapped to a valid physical address.
The 'modified' (dirty) bit is used by the demand paging manager to determine if the page being evicted needs to be written to backing media. As accessing backing media can be considered an expensive operation, you really want to keep this to a minimum--especially when writing to it as that is generally slower than reading from it.
The 'reference' (accessed) bit is useful to the demand paging manager to figure out how to age the pages it controls. You don't want to evict the most frequently used pages as that would require saving and/or loading them repeatedly from backing store (which has already been stated as SLOW).
The remaining five bits are gravy. They are free to use as permission and/or option bits. For example, can the page be accessed by supervisor and/or user threads? Is the page available for write, or is it read-only? What is the caching strategy to be used on the page?
Hope this helps.
Sparky
How did he get the answer?---That is just movie BS.
If you take the number of bits in the address and subtract the number of bits used to represent a page, you get the number of bits available for the processor to use as system status bits.
With that information, he could identify the number of system status bits
The usage of those bits is another story. The allocation of system status bits is system dependent. Maybe they exist, but I don't know of any 16-bit virtual addressing system. So he's not referring to any specific type of system.
A reference bit is not used by all systems (e.g. VMS). That's not even mandatory.
Hollywood magic.