-
Posts
8 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by bmouring
-
-
The example that I keep tucked in the ol' noodle is the exceedingly bizarre situation of a FXP number with a WL of 1 and an IWL of -1024, meaning you have 1 bit to represent the value (so only two numbers in the range) and that they are the exceedingly small numbers around 0, so ±2^-1024
-
I would recommend getting a VNC server setup on the machine that you will be remoting onto (it allows you to show what you are doing and basically act like a multi-player computer). Then, when you run into an issue/want to review something with a coworker they can see what you can see.
I've used UltraVNC on my old Windows machine with a fair amount of success (was out of the office for a few months, was able to do VI code reviews this way)
-
Whats the conversion from cookies to Internet points? To Internet dollars? To Zimbabwe dollars? Back to cookies?
- 1
-
I should really check these boards more often: yes, NI releases support for our internal Digital Electronics FPGA board (which can dock to an ELVIS II or be used separately) as well as the Spartan 3E XUP (500K version) board, however support for that board, as James noted, is limited to academic use only.
-
Hi, I'm working on project involves implementing on Xilinx Spartan 3E FPGA. I've completed the design, compiled it, then tested it and everything is OK. When I started writing the final results to my boss I encountered unusual problem. The percentage of LUT consumed by the design is 123% (5734 out of 4656). How is that possible? Again everything is working fine but how come the FPGA compiler reports that 123% of the LUT is used ?! Where did (5734-4656 = 1078) LUT come from?. Compilation report is attached. Thanks in advance.
If you look further down in the results (search for "Starting program map") you will see that you are well within the capabilities of the part, LabVIEW FPGA simply isn't reporting it correctly at the top (I'll look into this one for sure). I do notice however that it looks like you're using a large memory that doesn't seem to properly be mapped to a Block RAM, when I have a bit of time I'll look into why it's not being inferred properly. Out of curiousity, do you still have this project?
-
bluesky96
The latest release of the Spartan 3E Starter board support has been released for LabVIEW 2010. It can be downloaded here
- 1
-
Hi bluesky96,
Mellroth is indeed correct: the interface code behind the scenes is using LV semaphores to try to make things safe.
It was determined that this code was problematic (as you're seeing now) and was redesigned in the upcoming release of the package to be much more robust.
As such, unfortunately there is precious little you can do to solve this particular problem other than trying to reconfigure your design a bit to try to avoid the issue you're running into or wait for the impending release
Q: What causes unresponsive FPGA elements after restart?
in Embedded
Posted
From what it sounds like, I bet that James' notion was spot-on: the last closing of the session was resetting the FPGA, which is fine but will not result in the FPGA restarting (and, as he noted, opening a session to a non-running FPGA VI is perfectly valid, it's just not running).
Ensure (at least) one of the following: