Allan Flippin

Members
  • Content Count

    14
  • Joined

  • Last visited

About Allan Flippin

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. xc6lx45, Yes, I'm expecting my UART design will be a bit unusual to adapt to the clocks I have available. I don't have my books with me at the office, but I found an article that discusses my point about synchronizers. https://www.edn.com/electronics-news/4356211/Keep-metastability-from-killing-your-digital-desig Check towards the end of the article starting with this: "Before trying to handle an asynchronous signal properly, make sure that it actually is asynchronous. The metastability equations assume that the input data transition is equally likely to occur at any time during the clock period." Allan
  2. The tool is allowing 2:1 mode. I was surprised by that too. The problem I have with a "second clock" is that I just have the single 100Mhz oscillator on this board. No matter what I come up with frequency wise, the DDR clocks and the UART clock are coming from the same source. Synchronizer theory works only for clock domains that have totally independent sources. With upper and lower bounds of 303Mhz and 310.7Mhz, I don't have any useful frequency multiples to work with. Allan
  3. I went through the process of running MIG7 (Vivado 18.3) to generate a DDR3 controller for the Arty A7-100. I copied the digilent board files into the Vivado 18.3 board_files directory and chose arty-a7-100 when opening my project. When MIG7 starts, the first thing it wants is clock period. That's where I'm having the problem. MIG7 allows numbers between 2500 and 3300ps. But with my board, MIG7 won't allow any period less than 3225ps. That's a very narrow range of frequencies! I need to consider my FPGA general system clock speed in connection with making a high-speed UART for PC communication. Between 3225ps (310.7Mhz) and 3300ps (303Mhz), there are no useful frequencies I can find in common with baud rates that are multiples of 1,000,000. If the tool allowed 3333ps, I'd end up with an FPGA clock of 150Mhz (with 2:1 ratio). I could make that work easily. After looking at the "stub" Verilog file and reading in UG586, I see that sys_clk_i is a user input. Could I not feed 300Mhz in there? I don't care that memory would be a tiny amount slower. Would the DDR controller not work? Is there any reason the tool could not directly allow a slower clock specification? Thanks for all your help. Let me know if any file I have would be helpful to you on this. Allan
  4. kwilber Thanks! That's what I need to know for now. I'm solidifying my choice of board and trying to locate anything which can't work with the board that I choose. I've been leaning towards Arty A7, and this was the last potential gotcha I have to check. I'll move forward now and assume Arty A7 is it. I'm still trying to get my company to install Vivado on my PC, or I would have been able to look myself directly. Allan
  5. Thanks for your replies. Sure, if I can use the single USB cable for debug plus device configuration, I'll be glad to do it! I just didn't understand how Vivado would know about the USB-to-FTDI chip link for the Arty A7. Isn't this why we require Adept for configuration instead of doing it directly by Vivado? Also, I'm I'm using a UART bridge for communicating with the Arty A7, wouldn't debug wreck that connection? I'll look at the videos, but I doubt this sort of thing is covered, PC communication with the Arty boards is not something that most people do. Allan
  6. I'm looking through Xilinx file pg115-mdm.pdf about the Microblaze debug module. If I use a Microblaze core, I'm sure I'll need some debug capability. But I'm not sure how the MDM can be used on an Arty board. MDM seems to be a JTAG-based debugger. I think it uses the FPGA's JTAG pins. I know the Adept2 utility uses the USB connection to access JTAG through the FTDI chip. But "JTAG debugging" isn't on the list of what Adept2 does. In the Adept SDK, I see information about an API to access JTAG. That would probably work, but I'd rather not be debugging debug system software while I'm trying to debug my Microblaze software. Another issue is if I use the existing USB cable for JTAG debugging, will I have trouble running the UART bridge interface? If I get a Digilent JTAG-HS2 and use that for JTAG, will that solve the problems? The Vivado software would know how to use the JTAG on this adapter for its debugger right? And the UART bridge would still work as usual. Do I have it right? Or am I missing something stupid. I just want to make sure there's no problem with Microblaze debugging that makes it too hard to use in my application. Thanks. Allan
  7. Jon, Thanks. I'm looking at the information from ftdichip.com. The only thing I'm unclear about is how the baud rate is set? I'm trying to find out if my HDL UART block will need auto-baud detect. Allan
  8. Jon, I think the USB UART bridge would work for me. I shouldn't need more than 1Mbaud. I'd use it to transfer the contents of block RAM to/from PC. A few seconds to transfer the data seems fine. As xc6lx45 suggests, it would be a good idea to transfer in Hexscii so I can add a simple command set to control the process. Looking at the Arty Z7, I see a different problem. That board doesn't have an FTDI controller. I see that instead the board has a TI USB Phy and uses the USB controller embedded in the Zynq 70x0. In that case, is there any way at all to transfer application data over USB with the PL? This isn't a show stopper for me. I don't think I'd benefit much from having ARM CPUs for this application. Thanks for all your help! Allan
  9. Jon, Yes. You've hit upon my issue. The memory read/write functions in the Adept 2 utility were very useful with the Nexys 3. Does it seem I can still access data through the utility, but I need support in my FPGA code to make the connection to block RAM or whatever I'm using? Sorry, if I had the board here, I'd just experiment. But this is going into my decision whether to buy this or a different board for the job. Allan
  10. Jon, Thanks for the speedy reply. Now I'm trying to figure out why I thought Adept 2 wouldn't work on Arty boards. If indeed it does, my problems are solved. I'll check the documentation. If not, I can use a UART as xc6lx45 suggests. Thanks to you both. Allan
  11. I've used the Nexys 3 board for some time and I've found the adept 2 utility to be very useful! I used the utility to write data to my Nexys 3 board and also read back results to my PC after running some tests. As long as my FPGA code could access the memories properly, I knew I could transfer results to and from my PC. I'm now looking into moving to one of the Artix-based boards. But Adept doesn't work with them. I've read the documentation and I don't see any replacement for this capability. On one of the Arty boards, how does one transfer data with a PC? I suppose Ethernet could be used but wouldn't that require lots of software? Perhaps I'm missing some basic concept. Thanks for any help! Allan
  12. Jon, Thanks for your speedy reply. The Zynq Book in particular looks very useful. I don't need Linux, but I do need to write software on the ARM. I'll be using the Atry Z7 to help me test an SMBus peripheral chip that I just finished designing. That chip has a good bit of analog. I'll put the chip and associated circuitry on a board that connects to the Z7 through the Arduino shield interface. I don't have any video, ADC or high-speed serial. I just need the ARM to feed commands to my chip and monitor its results. The chip uses alerts, so I'll need to write an interrupt handler for it. That's why i don't want the Linux overhead, because it would mess up my interrupt handler timing. Allan
  13. Looking through the Arty Z7 documentation, I see that mostly it's about people running Linux on the embedded ARM. My application is more bare-bones. I'll need to write C code for the ARM including interrupt handlers. This needs to be real-time, so I can't afford the overhead of Linux running. In the reference manual, I see that "bare metal" programming on the ARM is possible. But I've not been able to locate any documentation for this. Have you got something I can read? I just want to make sure the job is not way too complicated before embarking on it. Thanks!
  14. Thanks JColvin and Bianca. Yes, I had searched online for that part. I noticed a few sources, but all in the UK and none in the US. That doesn't bother me, except I thought perhaps the connector was being phased out. Allan