BeScopeBundle System Files
thoth
Posts: 75
2014-08-28 06:02 If you just want to run your kit you don't need to wade through this thread reading about how badly Arrow screwed up - just install the files according to my instructions below. If you need to build the system you can install Q14 and restore the archive provided in the Arrow distribution and compile it. Alternatively you can program the BeMicro CV with the .jic file I provided and you can then run the BeScope with system-console in Q13 or Q14.
/2014-08-28 06:21
I am assuming, given that you're in this forum, that you already have a version of Quartus II installed and running and that you know where your Altera folder lives.
Download the Arrow provided distribution at www.arrownac.com/solutions/bescope/downloads/BeScope_Installation_package_8-7-14.zip
Unzip the files in the distro and place the BeScope directory in the Altera folder.
Put the attached BeServer.tcl file in the BeScope folder.
Follow the instructions in the downloaded BeScope user manual but remember that Q13 will work in place of Q14 to program the BeMicro CV. Q14 is only required to unpack and build the BeScope FPGA archive. Q13 does not compile correctly on my XP system. I didn't pursue why - it may be something simple.
2014-08-26 04:15 - I have attached a BeScopeImages.rar file that contains a working .sof and .jic file.
The .jic file in Arrow's distribution is broken.
Use the one provided here in the links. It programs and runs fine for me under XP/32 Q13.0 and W7/64 Q14.0. The archived project requires Q14.0 to build.
Here is the command line I use to make system-console run - change the path as needed for your setup:
\altera\13.0\quartus\sopc_builder\bin\system-console -cli --script d:\Altera\BeScope\BeServer.tcl
Often this fails the first time I run it and then succeeds on the second attempt. I don't have to dis/reconnect the BeMicro CV - just run the above command line a second time.
2014-08-26 04:31 AntoineDoinel points out that the VCCIO jumper has to be in the 3.3 volt position for the BeScope to work right. That's the same position that Chip shows in the .png file for the BeMicro CV Propeller project. The board does NOT come set that way. Check's Chip's picture in the BeMicro CV P1v source folder. Rotate the jumper 90 degrees clockwise.
Don't expect much from the scope - it's a toy and its primary value, to me anyway, is that it shows how to use Qsys and the system-console to allow relatively slow TCPIP communication between the FPGA and a python program using a socket interface. The FTDI comm chip on the BeMicro CV is only a full speed device so 100kBs is about the best that's possible. Samples are acquired and converted into ASCII strings via a slow TCL interpretor script before being forwarded to the python app. The bad news is that to use this communication link one has to do the FPGA design using the Qsys module package and all the complications that involves. It chews up 1K of the BeMicro CV LUTS to provide a clumsy, slow and rather inconvenient TCPIP interface that was primarily intended by Altera to be used as a debugger. Since the BeScope designer decided to ground all the unused I/O pins rather than stick up a few for a Prop Plug kind of interface, there isn't any other way to communicate with the BeScope without interposing a board or set of connectors that can break out a few pins. Not worth it really given the lackluster performance of the hardware. I would mostly recommend this to someone who wants to see a rather simple application using the Qsys/SOPC framework being used as a communication channel. It also contains a working example of SignalTap for capturing realtime signals from the scope.
Some good news is that the kit comes with a decent 150mhz scope probe that's $30 from Aliexpress. Looks to be a higher speed grade of what I received with my Rigol.
If you want to run the scope software on a laptop and don't want to install the full Quartus Web edition you can install just the programmer part and that will install the system-console utility and require much less space. I believe one can, contrary to what the documentation says, use the programmer download from Q13.x for XP machines rather than Q14 which won't run under XP. The pathname to the system-console utility is different from what's shown above when you only have the programmer installed.
The BeMicro CV will get pretty warm running this and I suppose that's because it's sampling at 250 million times a second. The P1v doesn't get even slightly warm.
Is it worth the trouble to even install this stuff? Good question without a clear answer. You'll end up with one of the prettiest, most idiotically laid out scope displays with a totally spastic set of control knobs and a data display that can't be saved or zoomed. The triggering is so basic that it's mostly useless. The settings data is all scrunched up in tiny text that's nearly unreadable. I've seen horrible USB scope implementations from Hantek and others of their ilk but this makes their stuff look like its from Tektronix or HP.
On the other hand the python code for the display is pretty well documented and probably could be a good starting point for a better layout.
The BeScope is a really mixed bag and I suggest some thought about motivations before wasting too much time on it. The input offset is awful. The amplifier gain factors are totally oddball. It goes on and on. And it's clear to me that whoever designed it hasn't used an oscilloscope much.
The BeScope is a textbook example of why a bunch of salesmen and marketers (Arrow) shouldn't be in the business of designing anything. What results is a fiasco like this with broken software that, even after it's fixed, isn't useful. They end up wasting their customer's time and looking foolish.
Here's my interpretation of what probably happened.
Analog Devices laid out a reference design for the BeMicro CV that uses their AD converter chip - the board is obviously laid out by professionals. But the board was never intended to be a real scope - just something to show off the capabilities of the AD chip.
Arrow then got the bright idea of selling it as a real Oscilloscope and hired nCk-research to create an application. nCk knows NOTHING about oscilloscopes - they're a couple of engineers that produce specialize TCPIP stuff for FPGAs. But things were a little slow so they took on the job and created an application that sort of kind of looks a little like an oscilloscope. Then they packed up the files and forgot to include BeServer.tcl (without which nothing works) and included a broken .jic file and gave it to Arrow.
Arrow, being the aforementioned set of salesmen and marketeers, didn't bother to actually have somebody actually sit down and see if the package was working but just stuck it on their website in an obscure location.
Hours of frustration later I've managed to correct their muffups. And, given that I knew why I wanted the scope board in the first place, I'm happy enough to have it.
/2014-08-28 06:21
I am assuming, given that you're in this forum, that you already have a version of Quartus II installed and running and that you know where your Altera folder lives.
Download the Arrow provided distribution at www.arrownac.com/solutions/bescope/downloads/BeScope_Installation_package_8-7-14.zip
Unzip the files in the distro and place the BeScope directory in the Altera folder.
Put the attached BeServer.tcl file in the BeScope folder.
Follow the instructions in the downloaded BeScope user manual but remember that Q13 will work in place of Q14 to program the BeMicro CV. Q14 is only required to unpack and build the BeScope FPGA archive. Q13 does not compile correctly on my XP system. I didn't pursue why - it may be something simple.
2014-08-26 04:15 - I have attached a BeScopeImages.rar file that contains a working .sof and .jic file.
The .jic file in Arrow's distribution is broken.
Use the one provided here in the links. It programs and runs fine for me under XP/32 Q13.0 and W7/64 Q14.0. The archived project requires Q14.0 to build.
Here is the command line I use to make system-console run - change the path as needed for your setup:
\altera\13.0\quartus\sopc_builder\bin\system-console -cli --script d:\Altera\BeScope\BeServer.tclOften this fails the first time I run it and then succeeds on the second attempt. I don't have to dis/reconnect the BeMicro CV - just run the above command line a second time.
2014-08-26 04:31 AntoineDoinel points out that the VCCIO jumper has to be in the 3.3 volt position for the BeScope to work right. That's the same position that Chip shows in the .png file for the BeMicro CV Propeller project. The board does NOT come set that way. Check's Chip's picture in the BeMicro CV P1v source folder. Rotate the jumper 90 degrees clockwise.
Don't expect much from the scope - it's a toy and its primary value, to me anyway, is that it shows how to use Qsys and the system-console to allow relatively slow TCPIP communication between the FPGA and a python program using a socket interface. The FTDI comm chip on the BeMicro CV is only a full speed device so 100kBs is about the best that's possible. Samples are acquired and converted into ASCII strings via a slow TCL interpretor script before being forwarded to the python app. The bad news is that to use this communication link one has to do the FPGA design using the Qsys module package and all the complications that involves. It chews up 1K of the BeMicro CV LUTS to provide a clumsy, slow and rather inconvenient TCPIP interface that was primarily intended by Altera to be used as a debugger. Since the BeScope designer decided to ground all the unused I/O pins rather than stick up a few for a Prop Plug kind of interface, there isn't any other way to communicate with the BeScope without interposing a board or set of connectors that can break out a few pins. Not worth it really given the lackluster performance of the hardware. I would mostly recommend this to someone who wants to see a rather simple application using the Qsys/SOPC framework being used as a communication channel. It also contains a working example of SignalTap for capturing realtime signals from the scope.
Some good news is that the kit comes with a decent 150mhz scope probe that's $30 from Aliexpress. Looks to be a higher speed grade of what I received with my Rigol.
If you want to run the scope software on a laptop and don't want to install the full Quartus Web edition you can install just the programmer part and that will install the system-console utility and require much less space. I believe one can, contrary to what the documentation says, use the programmer download from Q13.x for XP machines rather than Q14 which won't run under XP. The pathname to the system-console utility is different from what's shown above when you only have the programmer installed.
The BeMicro CV will get pretty warm running this and I suppose that's because it's sampling at 250 million times a second. The P1v doesn't get even slightly warm.
Is it worth the trouble to even install this stuff? Good question without a clear answer. You'll end up with one of the prettiest, most idiotically laid out scope displays with a totally spastic set of control knobs and a data display that can't be saved or zoomed. The triggering is so basic that it's mostly useless. The settings data is all scrunched up in tiny text that's nearly unreadable. I've seen horrible USB scope implementations from Hantek and others of their ilk but this makes their stuff look like its from Tektronix or HP.
On the other hand the python code for the display is pretty well documented and probably could be a good starting point for a better layout.
The BeScope is a really mixed bag and I suggest some thought about motivations before wasting too much time on it. The input offset is awful. The amplifier gain factors are totally oddball. It goes on and on. And it's clear to me that whoever designed it hasn't used an oscilloscope much.
The BeScope is a textbook example of why a bunch of salesmen and marketers (Arrow) shouldn't be in the business of designing anything. What results is a fiasco like this with broken software that, even after it's fixed, isn't useful. They end up wasting their customer's time and looking foolish.
Here's my interpretation of what probably happened.
Analog Devices laid out a reference design for the BeMicro CV that uses their AD converter chip - the board is obviously laid out by professionals. But the board was never intended to be a real scope - just something to show off the capabilities of the AD chip.
Arrow then got the bright idea of selling it as a real Oscilloscope and hired nCk-research to create an application. nCk knows NOTHING about oscilloscopes - they're a couple of engineers that produce specialize TCPIP stuff for FPGAs. But things were a little slow so they took on the job and created an application that sort of kind of looks a little like an oscilloscope. Then they packed up the files and forgot to include BeServer.tcl (without which nothing works) and included a broken .jic file and gave it to Arrow.
Arrow, being the aforementioned set of salesmen and marketeers, didn't bother to actually have somebody actually sit down and see if the package was working but just stuck it on their website in an obscure location.
Hours of frustration later I've managed to correct their muffups. And, given that I knew why I wanted the scope board in the first place, I'm happy enough to have it.
Comments
and then connect the python scope app I get the following:
Welcome to Altera's System Console
This Tcl console provides access to the hardware modules instantiated in your
FPGA. You can use System Console for all of the following purposes:
* To start, stop, or step a Nios II processor
* To read or write Avalon Memory-Mapped (Avalon-MM) slaves using special
masters
* To sample the SOPC system clock as well as system reset signal
* To run JTAG loopback tests to analyze board noise problems
* To shift arbitrary instruction register and data register values to
instantiated system level debug (SLD) nodes
In addition, the directory <QuartusII Dir>/sopc_builder/system_console_macros
contains Tcl files that provide miscellaneous utilities and examples of how to
access the functionality provided. You can include those macros in your
scripts by issuing Tcl source commands.
Aug 25, 2014 7:12:22 PM com.altera.systemconsole.internal.core.SystemConsole logInfo
INFO: Executing startup script
BeScope TCL-TCP Server v0.0.1
nCk Research, LLC. 2014(C)
Found: /devices/5CE(BA2|FA2)@1#USB-1/(link)/JTAG/(110:132 v1 #0)/phy_0/masterLaunching TCL-TCP Server on port 2540
Accept sock508 from 127.0.0.1 port 1514
Aug 25, 2014 7:13:03 PM com.altera.systemconsole.internal.core.SystemConsole logWarning
WARNING: This transaction has not completed in 10 seconds. System Console will keep trying for 50 more seconds.
Aug 25, 2014 7:13:53 PM com.altera.systemconsole.internal.core.SystemConsole logSevere
SEVERE: This transaction did not complete in 60 seconds. System Console is giving up.
java.lang.Exception: This transaction did not complete in 60 seconds. System Console is giving up.
at com.altera.systemconsole.internal.core.services.MasterChannelDecorator.waitForFutureResponse(MasterChannelDecorator.java:180)
at com.altera.systemconsole.internal.core.services.MasterChannelDecorator.pokeMemoryService(MasterChannelDecorator.java:299)
at com.altera.systemconsole.internal.core.services.MasterChannelDecorator.writeWords(MasterChannelDecorator.java:252)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.altera.systemconsole.internal.core.JavaCommand.invoke(JavaCommand.java:268)
at com.altera.systemconsole.scripting.TCLCommand.execute2(TCLCommand.java:107)
at com.altera.systemconsole.scripting.SystemConsoleThreadTCLInterpreter$2$1.run(SystemConsoleThreadTCLInterpreter.java:208)
at com.altera.systemconsole.internal.core.SystemExecutor$4.run(SystemExecutor.java:553)
at com.altera.systemconsole.internal.core.SystemExecutor$ComparableTask.run(SystemExecutor.java:151)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Aug 25, 2014 7:13:59 PM com.altera.systemconsole.scripting.TCLCommand execute2
SEVERE: master_write_32: This transaction did not complete in 60 seconds. System Console is giving up.
master_write_32: This transaction did not complete in 60 seconds. System Console is giving up.
while executing
"master_write_32 {/devices/5CE(BA2|FA2)@1#USB-1/(link)/JTAG/(110:132 v1 #0)/phy_0/master} {0x00000} {1073803483}"
while executing
"master_write_32 $nm 0x00000 $val
(procedure "IncomingPacket" line 41)
invoked from within
"IncomingPacket sock508"
Anybody else have better luck?
I wallowed through the TCL script and discovered that what seems to be happening is that the BeScope is attempting to send data to python at same time the python is trying to send settings to the board. As a result the socket callback from the board's GET (data) is lost and the system hangs.
2014-08-26 04:34 - this is not the case. Both GETs and SETs are issued by the beApp python application. What was really happening is that the .jic image file provided by Arrow was broken and master_write_32 calls from system-console would hang forever. A new image fixes this problem.
I don't know if this is peculiar to timing on my system or what. If anyone else cares to test this out I'd love some feedback.
I made a desktop <cmd> shortcut and a macro for C:\altera\13.0\quartus\sopc_builder\bin\system-console and stuffed the BeServer.tcl script into the script directory in the left panel. Right click on the scripts line opens its directory. Then I ran the script out of the console. If the console hangs it's necessary to quit and restart the console after dis/reconnecting the BeScope. When it hangs it really screws up Java's innards. But the console allows running scripts line by line which can be helpful in isolating problems.
I'm about ready to throw up my hands and say my educational experience is now complete - I've learned that I want nothing to do with qsys and its system-console which is a convoluted bastardized aggregation of Java, TCL and god knows what else. Too many layers.
A pretty good education for a buck plus sales tax.
If I get a working script back from Matt I'll post it.
I don't think it is that off topic, as many will have the Scope option, and it certainly makes the spend more justifiable, if the scope actually works
There was a screen shot posted here
http://forums.parallax.com/showthread.php/156989-BeScopeBundle-Tip-for-those-who-want-to-buy-an-FPGA-development-board?p=1288542&viewfull=1#post1288542
but it's not clear if that was of a working unit, on the posters own bench.
Thoth I meant to thank you already for your efforts, even though I won't get to benefit from them for a week or two. We are still trying to secure some BeScopeBundles for this country. Its a bit of a hike and so common to go in for 'group buys' on this kind on thing. Unfortunately when they only sell one at a time, that process backfires.
Anyway please be assured your efforts are valuable, and will certainly be appreciated by many following behind the bleeding edge. That goes for all you other trailblazers too.
cheers
Lachlan
What appears to be happening is that a GET is issued before the SET command completes and this causes the program to hang. I can demonstrate this with the following code:
global i
global echo
global nm
global d
# check for socket close call from BeScope Application software
#
gets $sock line
puts "Incoming Packet = $line "
gets $sock line
puts "Incoming Packet = $line "
Launching TCL-TCP Server on port 2540
Accept sock36 from 127.0.0.1 port 2204
Incoming Packet = SET0x4000f0db
Incoming Packet = GET
Enter GET SET
GET rx - GET
Incoming Packet = GET
%
and this is what I got back this morning:
Are you following all the instructions in this guide? http://www.arrownac.com/solutions/bescope/downloads/BeScope_User_Guide_and_Hardware_Ref_Guide_v0%20%282%29.pdf I think I left out the -cli switch when I emailed you last night. Matt
Like Cool Hand Luke says at the end of the movie - "What we have here is a failure to communicate."
I quit.
Or are they stalling for time? Sounds like they should have that all sorted out before shipping 200+ packages.
!: The scope software is a pretty face on a totally muffed out body. The controls are wildly misgrouped and misplaced and they are jittery and clumsy to operate.
2: The triggering is extremely basic.
3: To operate this - assuming it even works - requires running a quartus sopc system-console program. It may be possible to copy the sopc stuff over to another computer - like a netbook - and have it run independently but there's no reason to assume it will. And geez - why bother for such a piece of Smile?
4: When the java based system-console runs it hogs one full core of my CPU. (2014-08-26 09:53 - this is wrong - it's pretty minimal)
5: The 4096 byte sample buffer gets expanded into 20K of ascii text by an interpreted TCL script running in java before being passed on to the python script. It's a pig that needs to be turned into bacon.
6: The guy who wrote the code responds to a detailed problem description by asking me if I'm following all the instructions in the manual. He might as well have sent me a reading from an astrology column. Totally clueless clown.
7: Arrow is willing to put out kits that they have never even tested. This has been a total waste of time for me - the only lessons I've learned are that Arrow is not to be trusted and that they hire clowns to do their product development.
Now, do you want to know what I REALLY think?
It's not worth the extra dollar!
Well, that may be but they sure aren't running the software that Arrow provides on their website because THAT zip file doesn't include BeServer.tcl and there's no communication without it.
2014-08-26 04:36 - and it contains a broken .jic file
OK, I've screwed this up a little bit. The scope firmware is a slave - it accepts SET and GET commands issued by the host. So what appears to be happening is that the python script is issuing a SET command that isn't being responded to by the BeScope. The BeScope DOES respond to a GET command and returns a buffer full of data that is shown on the screen.
In BeServer.tcl if I comment out the master_write line below, the console doesn't hang anymore and I can see traces on the display though, of course, I can't change any settings because I'm not writing them out to the scope.
if {[string compare [string range $line 0 2] "SET"]==0} {
#puts "SET found"
set r [string range $line 5 13]
#puts $r
scan $r "%8x" val
#master_write_32 $nm 0x00000 $val <--- comment out this line and the console doesn't freeze.
So the problem appears to be that the scope isn't responding to master_write_32 commands for reasons unknown.
I've tried it on two XP machines with the same results.
And, yes, the display update rate is slow as molasses as expected when you have a tcl script executing in a java based virtual tcl interpretor expanding 4KB of data into 20KB of ascii for every sample period.
Arrrgh! There's a part of me that just won't say die on these time-wasters.
But..Many..Many thanks on pursuing this.
Jim
I'm a glutton for pain I guess. And very very stubborn. And don't like being passed off as a fool.
And I expect a certain level of competence in the commercial world - Arrow and nCk are acting like they're running a makershed out of Lincoln Nebraska.
I just loaded the .jic onto a second BeMicro CV to make sure there was no difference. It hangs in exactly the same way.
Your work is appreciated!
(Assuming my BE scope bundles ever arrive, I will benefit from it personally)
As a recent purchaser of a BeScope, thank you for your efforts, I won't be wasting time with the scope part.
The next FPGA board I'll buy will be from Terasic, not Arrow.
From the manual:
System Console provides visibility into your system. This visibility allows faster debugging and time to
market for your FPGA. System Console is both a platform and an application for interacting with the
debug-enabled portions of your design.
You can perform the following high-level tasks with System Console and tools built on top of System Console:
Perform board bring-up, with both finalized and partially complete designs.
Remote debug from anywhere with internet access.
Automate complex run-time verification solutions through scripting across multiple devices in your
system.
Test serial links with point-and-click configuration tuning in the Transceiver Toolkit.
Debug memory interfaces with the External Memory Interface Toolkit.
Integrate your own debug IP into the debugging platform.
Sure doesn't sound like a tool to be used as a communication link for a finished product, does it? In fairness (and I'm ALWAYS fair) the BeScope is not intended to be a production scope but an example of how to use various chips from Arrow's partners.
Knowing how to use the system-console is useful for debugging apps built using the qsys/sopc framework.
I love the DE0-NANO. It's one of the best designed and prettiest boards I've every encountered. And the beauty is more than skin deep. The compile time is less than 1/2 that of the BeMicro CV. The .jic load time is 1/10th that of the BeMicro CV. It feels good in the hand. It has standoffs. So what if it's a bit more expensive? That money is paying the salaries of people designing a great product with excellent documentation. And the board will be available tomorrow and two years from now if I need more. I like Terasic - they're a classy outfit that do their own designs. There's a good reason Altera has partnered with them for development boards.
One area where the DE0 falls short is that it doesn't provide differential input lines for super high speed devices like the AD converter on the BeScope board. If I can ever get that damn thing working it would be a great little device for high speed DAC for FFTs using a P1v for communications. What with all those multipliers in the Cyclone IV, creating a MAC for FIRs will be easy too.
I'm not interested in commercial applications - I'm interested in seeing how the stuff works at the lowest possible level.
Since my use is educational I really don't need a 115K part like the DE2. Who likes to sit around for twenty minutes waiting for a compilation? The trick is to keep modules small and individually testable. When they work they can be integrated into a framework like qsys and debug time should be minimal (HAH! famous last words). I find the six minutes for an eight cog P1v intolerable so I generally keep the cogs down to 2 until I've got working code. With 2 cogs I'm under 2 minutes and that's tolerable.
I notice that there is no mention of multipliers used in the Cyclone V Quartus utilization reports. I'm assuming the capability is still there. Anybody know about that? Obviously I can't use a DE0 with the BeScope so I'm stuck with a Cyclone V.
I appreciate the appreciation!
If any of this comes to anything and the board is useful maybe I can get couple strips of those double wide 2x20 long tailed sockets I think you mentioned earlier so I can use them as is (without an interposer board) to let me break out some signal lines currently grounded by the BeScope for hooking up a Prop Plug. To make the board really useful I think it should have a high speed serial connection, a la Prop Plug, so Python can grab data using something like pyserial. One thing that might be useful is to run length encode the incoming data to reduce storage requirements.
If the data stream gets compacted via a simple RLE engine then there's reason to think that with a bit of fifo buffering the realtime stream could be stored in the onboard SRAM, and that would dramatically increase the size of the data acquisition buffers. Maybe use a dual ported fifo in FPGA ram the AD can write to while the RLE engine reads, crunches and stores in SRAM.
I'm being "drugged" into this kicking and screaming (that's perfectly normal for me) but making the P1v compatible with qsys would make for some interesting possibilities since that framework does a lot of tedious housekeeping (in the manner of an overweight lazy housekeeper no doubt but hey!). And there's a big library of public domain IP for it I think. Not sure about that. I'm way out of my depth here but that never stops me from having an opinion. Making P1v's Port B available as a 32bit bus to qsys might be a simple way to start.
I think the BeScope has a lot of possibilities - it's mostly a matter of deciding how much effort the board is worth given that there's no assurance Arrow will ever restock them and with the understanding that the provided code is nothing more than a crude example of use that probably has a lot of bugs in it. Still very useful though. Coupled with the tutorial I attached earlier and the generally excellent Altera documentation conversion of the P1v into a qsys module should be doable - after a fashion. I'd appreciate Chip's opinion on that since he's the Man when it comes to FPGA and Altera. Proceeding in the darkest ignorance as I am, there may be something making this conversion impractical.
I find idea of having a P1v qsys module really interesting.
Note how often I completely contradict myself - didn't I say I hated QSYS and would NEVER use it just a few posts ago? Keynes said, "When the facts change I change my mind. And, what, sir, do you do?" well, I don't even need the facts to change!
There may be a clue here, I tend to assume no one deliberately sets out to ship flaky products, but sometimes they only need to see it working once. - so that may make it a system/init/sequence sort of issue.
Does the product ship with the scope engine pre-installed ? - I guess there has to be some FPGA code here ?
If so, perhaps a couple of posters here can run their scope portions up, straight out of the box, to get some more reference points.
I recompiled the code under Quartus 14 w/ Windows 7/64 and loaded it up and it runs. Next I'll try the provided image and see if that works too.
I had been running under Quartus 13.0 under XP when it didn't work right. The manual specifies that Quartus 14 is the version to use so that's probably the source of the difficulty. I've learned a lot about system-console in the process and I guess that's a plus.
Stay tuned. The good news is that the BeServer.tcl file is working correctly under Q14!!!
I tried running the copy I just built w/ W7/64 Q14 under XP/32 Q13.0 system-console and it runs fine! This is pretty conclusive evidence that the .jic file provided by Arrow is defective.
If anyone has trouble with .rar files let me know and I'll convert it to a zip file.
2014-08-26 04:20 - added .jic file to the archive.
Sounds like good progress.
Just to clarify, the file posted above is a Scope-Engine source (name?) built with Q14, W7/64.
That build file works ok in Q13 (XP/32) and works ok in Q14 (W7/64) but Q13 is unable to build a working image (even tho it can run a Q14 image) ?
I can confirm that it works! (recompiled after being hinted by your previous post, Q14).
Got the jic done and flashed too.
Thanks a million thoth, if it wasn't for you the ADC board would have ended sad and alone in a drawer, with a sticker reading "someday my prince will come".
You're very welcome.
I'd hate to see that dollar's worth of circuitry go to waste!!
Glad it's working for you.
Actually the BeMicro CV shipped with the bundle comes blank as far as I can tell. The BeScope user manual says to use the programmer and burn the provided (and defective) .jic file.
I'm totally lost but I'll start reading through these threads and try to figure out what the heck I'm supposed to do now. I had not intended on joining in on the FPGA fun but the (initial) posts about this BeScopeBundle made it sound like it would be worth the effort to learn.
I'm still not sure if I should be thanking you all or cursing you all.
Yes Duane,
My board got delivered today.
It's going to be a curse. I never indented in get involved in FPGA stuff, but now I got suck in.
Many man weeks going down the tube.
Place the BeScope tree in the Altera folder. Copy the BeServer.tcl I have provided in a link on the first page in the BeScope top level folder.
If you want to see the scope in action just use the .jic provided on the first page in place of the one in the Arrow distribution. The instructions in the BeScope manual worked for me. You can use Q13.0 or Q13.1 if you have an XP machine - the .jic will burn fine and the system-console command will work OK.
<Installation drive>\altera\<version>\quartus\sopc_builder\bin\system-console -cli --script <Installation drive>\Altera\BeScope\BeServer.tcl
That will set up a communication link that the beApp.exe can use. At that point you'll have a fairly useless oscilloscope but at least you can see that everything is working.
For me the real value of the BeScope project is to provide a working example of how to create a simple project using Qsys, the Altera module manager. There are lots of embellishments that would make the scope more useful but if you really need a scope I'd recommend you get a cheap Rigol rather than trying to make a silk purse out of this sow's ear.
Note that the BeMicro CV board gets pretty warm when configured to run BeScope and that's normal since it's acquiring 250 million samples a second.
Did you mean setting the jumper to 3.3V? I only see settings for 2.5 and 3.3.
BTW..Again.. many thanks for putting this together. It's much appreciated. I would not have know where to start.
Jim