zygot

Members
  • Content count

    165
  • Joined

  • Last visited

  • Days Won

    4

zygot last won the day on June 9

zygot had the most liked content!

About zygot

  • Rank
    Community Super-Star

Recent Profile Visitors

1,483 profile views
  1. @D@n, I didn't notice the first line of your post until a second look. "You beat me to the punch" matched my comment to " Sending 16-bit Values over RS-232" project that @Hamster submitted a few days ago. His came while I was busy preparing to release my UART_DEBUGGER. Your UART effort is unique and definitely deserves a hearty recommendation to be read by everyone regardless of expertise.
  2. Funny how people around the world can be working on the same thing at the same time. One advantage of Verilog over VHDL is its simulation features. I know people who write code for synthesis in VHDL and simulate in Verilog. This project offers a freely available Uart to test my code. It's not perfect but usable. Look out for wolves dressed as Gma!
  3. Here's a utility for debugging and testing your code in hardware and uses any IO pin to send an ASCII representation of any signal through a hardware UART interface. If you don't have a UART on you FPGA board there are TTL USB UART breakout boards and cables that allow any spare IO pin to become a UART interface. This code is functionally the same as one recently released by Hamster but developed independently for the Fast Data Interface project. I recommend comparing the different coding styles. I decided to release this as a separate project as there are likely more people interested in this one that the other. This project contains test bench code. UartDebuggerR1.zip
  4. Zygot goes back to the future to transfer data between two FPGA boards at 600 MB/s. Along the way he has a debugging adventure, learns ( AGAIN!!! ) why free stuff rarely is free and remembers when Digilent made FPGA boards that were great for development projects. This is a nice project for beginners or old hands to read through even if you don't have the hardware. CAUTION!!! You must read through the README text file before trying to replicate this project in hardware. Release 2 fixes some bad commentary in the source files and improves the behaviour of the UART transmitter FastDataInferface_R2.zip
  5. @frank2020, I may not be understanding your question but since you reference the unpopulated ASEM1-100.000MHZ-LC-T I'm assuming that you don't need your 100 MHz clock to be synchronous with an external component. Is there a reason why you don't want to use an MMCM to create a derived clock from the USB 12 MHz clock input? That's what I did in my CmodA735T demo. You can find it in the project vault. If you want to feed a clock into your design through one of the IO pins PIO36 on the Cmod A7-35T goes to a clock capable pin. Any MRCC, SRCC type _P IO pin will do. The schematics aren't complete but it looks like you don't want to try soldering a ASEM1-100.000MHZ-LC-T component onto your board as its output is tied to the USB 12 MHz clock output through a 50 ohm resistor.
  6. @hamster, If anyone gains some experience doing FPGA development they will find that having a few debugging tools in the toolbox is a great time saver. While simulation is a requirement and ISE and Vivado ILA tools are helpful, spitting out values to a USB serial port, when what you want to observe is intermittent or at a low data rate, or you need to capture data involving multiple clocks that are orders of magnitude apart in frequency, is a really nice thing to have. An extra bonus is that you can have most serial terminal programs log the out put to a text file or better yet use Python to capture data and write it to a text file. If you have a high data rate to capture a USB parallel data port is better though requiring a bit more work on the software side. I've been working on a project using the old Genesys and Atlys boards to demonstrate a fast inter-board communication path and wanted to debug the incoming scan codes from the Genesys PS2 keyboard inputs. I wrote a similar debug tool. Since I don't like to reinvent the wheel my code has parametrized data length in 4-bit characters and UART baud rate. Also it has a write enable included on the input port to simplify writing n-bit words to log. Sometime you want to leave design choices to a higher level but with debugging tools I've found that making them self-sufficient is better... you'll want to instantiate them quickly with as little fuss as possible. Lastly, documenting how to use them in your code is essential. Such tools are gifts ( whether or not you write it yourself or get it from someone else ) that keep on giving if done correctly. PS, I was going to post a short tutorial about my keyboard/LCD debugging adventure and post my UART ASCII writer but you got the drop on me as far as the debug code goes. Kudos. Also, I like to see that you are warming up to the idea of including a wee bit more documentation in your code.... this is helpful to anyone using it... including yourself when using code written a few years back and you don't remember exactly what it is that you did.
  7. To anyone who thinks that my answers to this question were way too brief and not verbose enough I offer one more thought. No one has asked what the difference is between LVCMOS33 and LVTTL33. But in the interest of my moving on mentally I'll take a stab at the answer. It's not as simple as one might suppose. This web page is a nice visual of the basics to take into consideration for connecting to various logic technologies and families: http://www.interfacebus.com/voltage_threshold.html Now then, I'm one of those old dinosaurs who had to work with a lot of logic families back in the day when logic came in 14 or 16 pin DIP packages. Though the chart referenced above might be confusing it does show the 4 basic specifications to worry about. Clarissa doesn't provide a schematic or mention what devices are connected to her FMC interface but let's assume, for the sake of this discussion, that it has actual TTL or CMOS devices. For the purposes of whether or not your logic can decide if an input signal is a logic high or low there are minimum and maximum voltages that have to be met for both high and low. If the input signal is not within these ranges the logic can't reliably tell what level the input signal is. All logic families also have minimum, typical and maximum output specifications for logic high and logic low that are guaranteed. So, for the most basic analysis, whatever is driving your logic had better meet the input specifications for your logic inputs. What I've mentioned so far has to do the the DC specifications. in the old days when a lot of logic was in discrete LSI and MSI devices the analysis for whether or not you circuit worked was complicated by things such as temperature variations, supply voltage variations, capacitive loading, etc. When the Schottky logic came out with really fast transition times we had to also consider the signal integrity of the wiring between output and input pins. Now we're talking about AC specifications. Now this isn't close to being a complete lecture on using discrete logic as there is more to consider but perhaps those who are interested will do some investigation on their own. Texas Instruments has some information as they still manufacture the old stuff. If Clarissa's interface uses some other components then the data sheet for those devices usually states if the logic inputs and outputs are TTL or CMOS compatible.
  8. @Clarissa, You wrote in the original post:"Dose it mean that if I set the SET_VADJ(1:0) on 11, the VADJ voltage = 3.3V, so the FMC signalss' I/O standards can be set as LVTTL? " I assume that you're working with an FMC mezzanine card that replaces the old FX2 interface. It's important to follow my previous advice by checking all of the FMC voltage connections that are connected to the logic through this FMC card. In particular make sure that: - only the Nexys Video board is sourcing the 12V0, 3V3, and VADJ pins. Also that everything connected to these pins is compatible with those voltages. - any logic connected to the GA0 or GA1 pins is 3.3V compatible - any logic connected to any of the FMC logic pins is really is LVCMOS33 compatible. LVCMOS33 and LVTTL33 are not exactly the same. Once you have satisfied yourself that everything is OK then, you would want to do what you have stated above, I use a big counter that stops counting before it rolls over to 0 to time the operations stated in the manual. I assume that you didn't check out the code in the DIfferential PMOD Challenge. I've posted the toplevel module here. You'll want to set set_vadj <= "11". Look over the process that controls vcnt. Your implementation will depending on the clock frequency that you are using of course, but I'd suggest that you use my timing as a minimum. You'll want to allow for the power supplies to settle. As far as I know Digilent has never offered guidance on how to follow the instructions in their manual. There's one aspect of my code that you should note. If areset is asserted VADJ is disabled and the whole procedure is repeated. You may or may not want to do this. I suggest that you prove to yourself that the VADJ voltage is really working as expected by using an oscilloscope to capture VADJ before connecting your FMC mezzanine card. As written you can check this by asserting areset. Note that the switches and all but the CPU reset button use the VADJ supply ( likely there are more things using Vadj) .... Also note that the CPU reset button is doesn't have any hardware conditioning to correct contact bounce so you may want to debounce CPU reset in you code if that's what's used to assert areset. If you don't understand anything that I've already stated in this thread you'll have to address specifically. NexysVideo_SDR_Test.vhd
  9. @hamster Your code is an interesting introduction to using the DRP to dynamically change an MMCM2 block. The DRP port is a marvellous way to access internal configuration registers for a lot of Series7 modules. I'd like to add a few observations: - I urge anyone interested in using your code to read through the XAPP888 document and example code carefully. The example follows a more rigorous method for updating MMCM DRP registers as there are bits that need to have previous values retained. - Some readers might not realize the importance of the lock output signal or that the output lock will not be valid until the MMCM achieves a lock condition. Using a button to change the MMCM is not necessarily the same as using a high speed internal signal to do the same. - It should be noted that an LED indicator has limitations. If you clock a 32-bit counter and connect one of the high bits to an LED you have an indicator with limitations. If the counter process is correct and the LED is not blinking then your indicator pretty reliably indicates a missing clock. If you choose the correct counter bit to drive the LED then you have some idea, more or less, about the clock frequency... with emphasis on the more or less part. If an LED indicator blinks as expected this does not mean that the design is correct or functioning properly. In general LED indicators should be used with caution as they don't indicate transient conditions very well. I just wouldn't assume that all readers understand this. - Trying to control multiple things through the DRP might be problematic As a general template for using the DRP to control the MMCM your code is nice as long as you understand the details. As always I enjoy reading about your ideas and experiments.
  10. I've got two questions. Why is this post in the project vault? Why is using the Vivado or ISE simulator so burdensome that simple syntax problems require posting such a question? Really... I don't understand this.
  11. To anyone interested I figured out how to show the latest project code versions in the first page.... I could post a more recent version but so far haven't had sufficient interest.
  12. @JCOLVIN It appears that I can edit the first page of a project post and upload there. Don't ask why I didn't think of that before... thanks for your input.
  13. @JCOLVIN Thanks for the quick reply. I'm not sure exactly how the comment pinning would work. Would I be adding a comment such as " look for xxx_R3.zip" in the thread pages? And would I have to request an update for rev4? regards, zygot
  14. Well that works IF you have a primary repository.... I haven't seen the need for one for any of the projects that I've submitted to the Digilent Project Vault. But you might be onto something that Digilent could provide. I realize that there is no prescribed format for distributing code here. Some upload individual files, some archived project files... My intent is to throw out some ideas and get a discussion going. It probably comes down to what Digilent can easily implement; and I haven't a clue about that.
  15. Currently, a project in the vault allows code to be submitted in posts. The problem is that for a project like the Differential PMOD Challenge where there are quite a few posts it's hard to know how many versions of code have been posted or even on what page they are to be found. One solution would be to start a new post for every version... but this would also get quite confusing. I wonder if there could be a way to show the latest code archive for a particular project at the initial page? Any ideas would be welcome.