All Activity

This stream auto-updates   

  1. Today
  2. Yesterday
  3. Glad to hear you got this working. Jack
  4. This has been resolved. I had placed channel A in opto isolation to use a JTAG connector and channel A appears to be mapped to the RX/TX lines rather than channel B. Seems backwards from the hardware pin-out, but it works.
  5. Hello, I have a very simple project programmed into the FPGA and I am monitoring all of the I/O directly through ChipScope. Currently, I am experiencing some issues with implementing a UART. At this point, all I am really doing is monitoring the RX line (pin 101) for any edge triggers. Through the FT Prog tool, I have verified port B is setup as a virtual com port and as an RS232 UART. The com port shows up in device manager as expected. I've disabled chan A, so I am confident that I am picking the correct com port. When I open putty or tera term and try to send some random data over this line, I do not see any activity on chipscope. Chipscope is clocking because I can trigger on other signals. Tomorrow, I will look at the FPGA and USB-to-UART chip (U3) under a microscope and see if I can see any loose pins or solder joints. I will also check the continuity between the sets of pins to rule out trace problems. If I can get my hands on one, I will probe U3 with a scope and verify I have chipscope setup to reflect reality. I may not have access to one this week though... which is the reason for my question: is there anything else that I may be overlooking in initial setup? Jumpers, etc? Appreciate any additional insight. Thanks!
  6. Last week
  7. No, I never used Microblaze at all. I find the architecture (most notably the function preambles/postambles for C ABI) a bit awkward. And it's commercial Alvie
  8. Just wondering: Do you know the Microblaze debugger that comes with Web-edition Vivado? I've used the basic features (breakpoints, step, edit variables etc) on an Artix. It was surprisingly simple and usable without having read any manual.
  9. Well, I just tried to see if it works on the Papilio Pro and I didn't get a response using the OLS client. I only have about 15 minutes to put into it this morning unfortunately. Here is the latest version, you can unzip it into the libraries folder of your DesignLab installation and then find the Winsbone_Sump_LA/OLS_CLient example under Examples in DesignLab. You will then need to load the circuit to your board, load the sketch, and open the OLS client and try to connect to it. The status that we left off was that it was 80% working and just needed some bugs in the OLS_CLient sketch to be worked out... Development fell off because we discovered that the performance is not that great. The best that we were seeing was about 30Ms/s... Jack.
  10. hello, Actually i am working in SPARC V8 .Can u guide me i have the grlib-gpl-1.5.0-b4164 folder .With what u hv worked I want to synthesize the design in XILINX but i am not getting the procedure can u plz guide me
  11. BTW if anybody is interested: I could dig up my 640x480 monochrome text adapter (40x20 char) that fits into a single 2kByte block ram. It's ugly as hell but excellent for debugging as one write port of DP ram can be used by the application at any clock without restrictions.
  12. Regarding video timings, the pixel rate is generally higher than the calculation of refresh*horizontal*vertical, due to periods that no pixels are being transferred. For the most common 640x480x60Hz resolution, it's 40ns per pixel instead of 54ns. has more detail. One way to stretch that time is to buffer part of the screen in the FPGA's own on-chip memory. If you read and buffer one scan line at a time, you can get it to 50ns per byte, using only 640 bytes of buffer memory. (Calcuation: 640 pixels in a scan line, one byte per pixel, a buffer to hold one scan line is 640 bytes; in the standard 640x480 screen, a scan line takes 32us; 32us/640=50ns.) If you can reduce the amount of memory your screen image takes up, you might be able to fit it entirely onto the FPGA without any off-FPGA RAM. That gives you a number of benefits: It's easy to work with, it's fast, and (at least on the ones I've used) it's dual-ported. The downside is that capacity is limited (it depends on the particular FPGA). But you may be able to reduce how much you need, using techniques from back when computers' memory was much smaller: Fewer bits per pixel; text mode / tile mapped graphics. (For example, 1024x768x8bpp would be 768kB, but gets 1024x768 resolution with only 12kB RAM for video.)
  13. Jack and Alvie, I would really like to try experiment with your Logic Analyzer implementation that uses DMA on a 2MB Duo. In an earlier message you said you didn't have DMA working but could simulate it, and in a later message you seemed to suggest that DMA is working. If I want to use your latest version, where should I get it, and what works and what doesn't? In your video, it is not using the OLS client, but instead is using an Zpuino program and the terminal. Is this still the way it works? Thanks, Blake
  14. I believe we also have the generic VGA working on DUO for those resolutions. Alvaro
  15. Hi, did you check the voltage rating of the RAM? I think it's 5 V, won't work in a 3.3 V environment. The Papilio Duo might be able to do the job with its on-board SRAM, or Saanlima's Pepino.
  16. It should be fixed by now, I think.
  17. We have such an implementation using the SDRAM. If I recall well, it works OK at 640x480x8bit. Ideally you should get a memory which is almost 3 times as fast as the fastest datastream you need (read or write). You will also need to arbiter between the read and write requests, and probably will need a read FIFO to account for the jitter of the arbiter (we do exactly that). You may want to take a look here: Alvaro
  18. For a personal hobby project I'm looking to make a small vga display using an fpga. I was thinking of making the display 640x480 pixels with one byte colour per pixel at 60hz (I believe those timings should work on any monitor?) By my calculation that means I need to read 640*480*60 bytes from the ram every second which is 18432000 bytes per second giving a time per byte of a little over 54ns per pixel. I'm looking at a device something like this for my memory. The datasheet indicates that it has an access time of 45ns so by my understanding it should be fast enough for my fpga to read the data from it. But I'd have to update it during the period when no data is being displayed as it's not fast enough to complete a read and write in that time. Are my calculations correct, and would such a device be suitable for using in this way? Or did I miss something?
  19. Earlier
  20. Stumbling over my old post, if someone is sent here by Google on a mission to reduce latency... The secret to achieving low latency with a UART is... don't use a UART. The 2232H chip, programmed through the DLL interface, can achieve physical roundtrip (!) times, e.g. send a byte via JTAG bypass through the FPGA and back in MPSSE mode, of slightly over 1/8 ms. If I extrapolate the 3.75 ms UART roundtrip time I achieved earlier... my boss wouldn't be happy :-)
  21. Sounds great. Jack.
  22. Thanks Jack, I went through more of the forum and found the rotation approach you mentioned above. I'm up to speed now on the way the A, B, and C connectors are arranged. I've purchased the Pro and LogicStart megawing because I want more than 2MB. My initial plan is to drive the 7 segment LED's and, if I have to, I'll run jumpers from the bottom of the MegaWing to free pins on the Pro. Thanks again, Mr Minix
  23. Hello Mr. Minix, I have heard of people reversing the LogicStart MegaWing like in this post: The other option is to go with the Papilio DUO and the LogicStart Shield. The VGA portion of the LogicStart Shield snaps off and gives you access to 16 pins... We are currently out of stock of the DUO right now but will have some 2MBs ready soon, or you can order from Seeed Studio. Jack.
  24. Hi all, I'm about to buy a Pro to replace an existing Spartan 6 design. I'd like to have a 4 digit 7 segment LED display and 8 toggle switches. The LogicStart MegaWing looks just right but I have one problem. I need 6 free pins (not including ground) for 3 instantiated uarts but the MegaWing uses every pin on the Pro so I am out of luck. Does anyone have a recommendation for how I can get my LED display, toggle switches and free pins? I can always connect the display and switched off board but will purchase existing products if possible. Thanks, Mr Minix
  25. Hi Jack, That's a good result then. Unfortunately my workstation has more history than a fresh vagrant image. There is constant frustration trying to run development environments in a reproducible environment. I have been trying to use nix-shell manage the problem recently - works nicely with Stack/Haskell. I was concerned about having problems with the USB drivers if I ran DesignLab in a virtual environment, seemed pretty heavyweight to include ISE as well. Configuring interacting docker instances seems to be difficult and ever-changing. I am considering trying out Ubuntu's Snaps as a solution. There is quite a nice Smalltalk implementation that I'd like to look at, but it is extremely hard for anyone but the sole developer to get the environment running. Anyway - my lack of java config skill was to blame. DesignLab seems easy to configure - amazingly interesting. Well done! Cheers, --Peter G
  26. It's weird though, I brought up a fresh OS install using vagrant to pull down an untouched VM image for Ubuntu 16.04 and 16.10 and all I had to do was an "sudo apt-get install default-jre" and run the file and it worked perfectly. No need to set JAVA_HOME at all. Did you maybe install the JDK instead of the JRE? Maybe that would explain the difference... Jack.
  27. I wonder if maybe it is related to your video card drivers? Here is a discussion about something vaguely related: One of the things they bring up is video card drivers which is not a bad idea to check since it has never happened on any of the systems I've used during development... Jack.
  28. Hello Sleat, That looks annoying, in all the time I have spent developing and working with the IDE I don't recall seeing that happen... Does it go away if you minimize and maximize the app or do an alt-tab to switch between apps quickly? DesignLab was forked from Arduino IDE 1.5.8 so if that was an existing problem with Arduino then it would be brought forward with us. If we can find a commit to the Arduino IDE that solves this problem then we can apply it to DesignLab too. Jack.
  29. Hi, Overall, I'm having a great time with the Duo and Pro and some assorted shields! Whilst working through some of the tutorials, though, I've noticed that after a short time the IDE menus begin to glitch. Specifically what happens is that the menu will jump around in strange ways, with the currently selected menu item not matching the item which was just below the mouse pointer before it was moved. This manifests itself soon after running the app, and very quickly as soon as large menus like "examples" are selected. One definite symptom is that the top of the menu gets graphically copied to the place just below the mouse, so the actual menu content below the mouse cannot properly be seen until the mouse is over it. Not a show-stopper, but annoying. Screenshots included. The main screen also fails to redraw occasionally when obscured by menus or other windows. This problem does not occur at all in large menus in the Arduino IDE 1.8.1 but DOES happen in the examples menu of Arduino IDE 1.0.3 and 1.5.2 when mousing up and down the File=>Examples sub-menu. OS is Windows 7 Pro 64 with 12GB of system RAM. No other programs seem to be doing this. Is anyone else seeing this, and is there a fix? Cheers! Joe
  30. Load more activity