xc6lx45

Members
  • Content Count

    740
  • Joined

  • Last visited

Reputation Activity

  1. Like
    xc6lx45 got a reaction from Septyawan in QSPI Program Load is Slow   
    Hi,
    I suspect you're using slow default options for bitstream generation. Increase the clock rate and enable bitstream compression. It should be much faster.
  2. Like
    xc6lx45 got a reaction from That_Guy in State machine vs Microblaze MCU   
    Hi,

    I suspect the complexity is far below the break-even point where the more complex architecture pays off.
    Making it work may even take a comparable amount of time, but you'll have to manage a design in more dimensions (user RTL, MCU, embedded code) compared to a simple "flat" RTL design.

    The MCU may create several problems (e.g. need for FIFOs, clock domain crossings) that can be avoided completely with a FSM.

    If you haven't done this repeatedly, it may take a little time to get fluent with coding FSMs in RTL. Until then, you may find you're biased towards "traditional" procedural programming, even though a plain Verilog FSM is often more concise and intuitive (opinion).

    For learning, why not try both. Bringing up a quick-and-dirty functional prototype shouldn't be that much work.

    And check what happens to the project build time when adding the MCU. Software changes are quick, though.



  3. Like
    xc6lx45 got a reaction from That_Guy in Vivado Hardware Manager disconnects CMOD-A7 target in Win7   
    >> having about 60uF of ceramic decoupling goodness
    Maybe it's even more a question of ESR than capacitance. Ceramic if money doesn't matter (e.g. Mouser: 22 µF: €4..6).
    The typical solution are staggered capacitors, with a quick look at the datasheet for the self resonance frequency in the impedance curve. I do this for RF (try to get a quality short at n GHz...) but if I had to make a blind guess, I'd use two orders of magnitude, e.g. 10 µ, 100n, 1n and with a nervous glance at my Voodoo doll, 10p.
    The CMOD A7 is reported quite frequently (possibly because it's one of the most attractive boards) but I can tell that I've run into the same issues with FTDI's reference module for the 2232H. The chip just shuts down if it doesn't like what it sees on VCC.
    It took a long Friday night in the lab to prove without doubt that our system is sensitive to USB cables. We changed the design and shipped with non-detachable cable. Zero issues so far.
  4. Like
    xc6lx45 got a reaction from jpeyron in Vivado Hardware Manager disconnects CMOD-A7 target in Win7   
    >> having about 60uF of ceramic decoupling goodness
    Maybe it's even more a question of ESR than capacitance. Ceramic if money doesn't matter (e.g. Mouser: 22 µF: €4..6).
    The typical solution are staggered capacitors, with a quick look at the datasheet for the self resonance frequency in the impedance curve. I do this for RF (try to get a quality short at n GHz...) but if I had to make a blind guess, I'd use two orders of magnitude, e.g. 10 µ, 100n, 1n and with a nervous glance at my Voodoo doll, 10p.
    The CMOD A7 is reported quite frequently (possibly because it's one of the most attractive boards) but I can tell that I've run into the same issues with FTDI's reference module for the 2232H. The chip just shuts down if it doesn't like what it sees on VCC.
    It took a long Friday night in the lab to prove without doubt that our system is sensitive to USB cables. We changed the design and shipped with non-detachable cable. Zero issues so far.
  5. Like
    xc6lx45 got a reaction from [email protected] in GPS Pmod   
    I must say I share [email protected]'s opinion here.
    What I would do is
    start with a plain serial port. Create a dumb (non-clocked) FPGA design that routes the FTDI chip's UART pins to some GPIOs, and hook up the GPS module. Alternatively, use a standalone FTDI-to-UART module or equivalent. Fire up teraterm (e.g.) on the PC, open the COM port, set the correct baud rate. Check that the GPS module responds as expected. Check that the message format is exactly as you expect it. I suspect this assumption
    >> it seems, that the given functions from digilents pmodgps.h heather are doing already the right stuff
    won't hold.
    What you're trying reminds me of the old joke about a gynecologist retraining as a car mechanic🙂
  6. Like
    xc6lx45 got a reaction from Ahmed Alfadhel in Pmod   
    Hi,
    >> "formal port ja_pin3_io of mode inout cannot be associated with actual port ja_pin3_io of mode out "
    is this maybe just a typo?
  7. Like
    xc6lx45 got a reaction from RuthKimberly in I Want to make a UI on C#.NET or LabVIEW   
    Have a look at Windows Forms. It has some small issues with its dinosaur DNA (e.g. need for pinvoke in a multi-threaded program) but it's mature and industrially proven. Search engines usually give the answer I'm looking for right away.
    You may also be able to run the code on Linux (mono) with a compatible library, even the same .exe running under Windows and Linux (sounds weird but the runtime takes care of it. The .exe can be really machine independent aka MSIL).
  8. Like
    xc6lx45 got a reaction from [email protected] in FFT / iFFT / RS - Basys3   
    OK that starts to make more sense. So one channel is reference signal e.g. transmitted signal, one channel the received reflection.
    Capture both, FFT, multiply (don't forget the conjugate), iFFT. On the bright side, in this specific case you can solve the circularity issues mentioned above with sufficient zero padding on the transmit signal (rule of thumb: Add enough zeros until all reflections have died down to negligible level). This may be easier said than done with a hardware FFT, though...
    Resolution is limited to the sample rate. If you want to do better, you can interpolate by stealing lines 315..345 here . Needless to say, this calculation needs to be done on a microcontroller or the like. In double precision it's usually accurate to 1 % of a sample.
    For a reference algorithm, have a look here (this is more complex and somewhat heuristic but has proven itself over the years). With noise-free data this can be accurate to about one nanosample.
  9. Like
    xc6lx45 got a reaction from yottabyte in [Zybo Z7] Which Zynq to choose in Vivado   
    Hi,
    most likely it's the slowest speed grade ("C"ommercial). The faster ones are AFAIK only available in "E"xtended (2, 3) or "I"ndustrial (2) temperature range.
    https://www.xilinx.com/support/documentation/selection-guides/zynq-7000-product-selection-guide.pdf page 5.
    As a rule of thumb, the price penalty is fairly substantial, the performance difference is not. Higher speed grades tend to be rare in mass market boards.
    E.g. see page 27 here: https://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf "Minimum clock period" -1=2.5 ns; -2=2.26 ns, -3=2.1 ns but there is more to the topic than just this one number.
    Of course, a design that is built for -2 or -3 speedgrade would be unreliable on -1 (if the bitstream is even compatible - but I can't recall ever seeing any efuse etc bits that would prevent it in hardware)
     
  10. Like
    xc6lx45 got a reaction from sungsik in what does this symbol means (in zybo Schemetic)   
    Hi,
    it shows that the traces are routed with special care as differential lines.
  11. Like
    xc6lx45 got a reaction from zygot in busbridge3: High-speed FTDI/FPGA interface   
    Thanks. Please check gitHub again, I added a fourth folder "sharpDevelop_build" (5.1 from sourceforge).
    This should run out of the box, if a CMOD A7 35 is found, and no other Digilent USB interface is present.
    If more debugging is needed, my exception handler might get into the way. I'd comment out the try/catch. Alternatively, enable "pause on exception", as shown in the screenshot here: http://community.sharpdevelop.net/blogs/siegfried_pammer/archive/2014/08/27/customizing-quot-pause-on-handled-exceptions-quot-in-sharpdevelop-5.aspx
    When porting to sharpDevelop I ran into an issue with type casting and bit shifting: Running the older code on sharpDevelop will cause an overflow error. Don't know why, probably different interpretations (or versions?) of the standard. Whatever, it is fixed now by stating the problematic cast explicitly.
    To get rid of the relative link to top.bit (it's ugly), change this line in Program.cs
    bitstreamFile = @"..\..\..\busBridge3_RTL\busBridge3_RTL.runs\impl_1\top.bit"; Console.WriteLine("DEBUG: Trying to open bitstream from "+bitstreamFile);
    e.g. to
    bitstreamFile = "top.bit";
    and copy top.bit into the folder where the .exe file is generated.
  12. Like
    xc6lx45 reacted to zygot in busbridge3: High-speed FTDI/FPGA interface   
    @xc6lx45
    Hi,
    I had no issues creating a bitstream in Vivado 2018.2 using your (imported) project file.
    While trying to recreate your project I ran into a snag with the C# code. I have VS2010 tools so of course your project files and solutions are unusable. I did manage to use the sharpDevelop tool you suggested. The executable configured the board and then threw an unhandled exception... (Arithmetic operation resulted in an overflow)  but still terminated gracefully. I'm afraid that my C# skills have become rusty.
    I had to modify the path for the top.bit since I was running out of a different directory than you did ( I had to create a new solution project); simple enough to resolve.
    Let me make a few suggestions for such projects:
    Identify exactly what tools (versions) you use to create components Since Microsoft tools are notorious for not playing nice with other versions of itself you might want to anticipate that most users will have to do a work-around; not a complaint, just a thought. Assume that you audience might have a different development trajectory, especially for PC software, than you did when developing the project. I got too close to quit but so far haven't accomplished a verification that your project can be recreated. I know that you are interested an any feedback, as I am for any projects that I've posted.
    regards
  13. Like
    xc6lx45 reacted to zygot in busbridge3: High-speed FTDI/FPGA interface   
    @xc6lx45,
    After second, more through look, my reaction has gone to really really nice! Excellent work! For anyone wanting a one step PC application to FPGA application this is a fantastic tutorial.
    [edited] And by the way best wishes in your new endeavour. When you need a change of pace stop by and drop off more of worthwhile your insight. We will all be poorer off without them.
  14. Like
    xc6lx45 got a reaction from jpeyron in busbridge3: High-speed FTDI/FPGA interface   
    Hi,
    as I may not have time for FPGA work for a while - just started in a fascinating new role related to high-speed digital diaper changing - I decided to post this now.
    Here's the Github repo (MIT-licensed)
    The project provides a very fast (compared to UART) interface via the ubiquitous FTDI chip to a Xilinx FPGA via JTAG. Most importantly, it achieves 125 us response time (roundtrip latency), which is e.g. 20..1000x faster than a USB sound card. It also reaches significantly higher throughput than a UART, since it is based on the MPSSE mode of the FTDI chip. Finally, it comes with a built-in bitstream uploader, which may be useful on its own. I implemented only the JTAG state transitions that I need but in principle this can be easily copy-/pasted for custom JTAG interfacing. So what do you get:
    On the software side an API (C#) that bundles transactions, e.g. scattered reads and writes, executes them in bulk and returns readback data On the RTL side a very basic 32 bit bus-style interface that outputs the write data and accepts readback data, which must be provided in time. See the caveats. In general, a significant increase in complexity over a UART. The performance comes at a price. In other words, if a UART will do the job for you, DO NOT use this project. For more info, please see the repo's readme file.
    For CMOD A7-35, it should build right out-of-the-box. For smaller FPGAs, comment out the block ram and memory test routines, or reduce the memory size in top.v and Program.cs.
    I hope this is useful.
    When I talked to the FTDI guys at Electronica last week I did not get the impression that USB 3.0 will make FT2232H obsolete any time soon  for FPGA: They have newer chips and modules but it didn't seem nearly as convenient, e.g. the modules are large and require high density connectors. In FPGA-land, I think USB 2.0 is going to stay...
    Cheers
    Markus
  15. Like
    xc6lx45 got a reaction from [email protected] in Voice-activited   
    >> Is that solution Will run?
    I suspect you mean crosscorrelation, and no, it will most likely not work.
    Maybe you'll save yourself much pain if you prototype the algorithm first in software. It doesn't need to be real time.
    E.g. get freeware Octave and use the audioread() function. Be sure to use two independent recordings for reference and simulated microphone input.
     
  16. Like
    xc6lx45 got a reaction from Junior_jessy in Voice-activited   
    >> Is that solution Will run?
    I suspect you mean crosscorrelation, and no, it will most likely not work.
    Maybe you'll save yourself much pain if you prototype the algorithm first in software. It doesn't need to be real time.
    E.g. get freeware Octave and use the audioread() function. Be sure to use two independent recordings for reference and simulated microphone input.
     
  17. Like
    xc6lx45 got a reaction from That_Guy in Diving in   
    Don't forget coupling capacitors - single-ended RF signals are +/- around GND
    Frequency accuracy is only as good as the reference, which will be badly (by RF standards) temperature dependent. Good enough for FM radio but any coherent demodulation will give you a hard time. A common reference clock between transmitter and receiver makes it easier
    Channel grid is another possible problem. Cascading PLLs on the FPGA can improve resolution to hit a single frequency.
    If you have $20 left in the budget, one of those into a clock-capable input of the FPGA gives a much better timebase, both in terms of phase noise / jitter and frequency resolution (note the voltage option letter).
    https://eu.mouser.com/ds/2/368/si570-243514.pdf
    This part is just off the top of my head (from the "official" Xilinx FMC card).
     
  18. Like
    xc6lx45 got a reaction from Ahmed Alfadhel in set_property SEVERITY {Warning} [get_drc_checks UCIO-1]   
    Hi,
    >> "To allow bitstream creation with unspecified pin locations (not recommended)"
    I would not do that when working with hardware. It's useful in situations where you don't care at what pin the signal is connected (e.g. a quick feasibility check).
    It is possible that some pins serve a board-specific special purpose e.g. are grounded. It's unlikely this would cause damage, but you may run into problems that require serious detective work to debug.
    Most likely it will actually work.
    Just guessing: If you need the outputs because interesting signals get optimized away otherwise, the attribute "DONTTOUCH" or "KEEP" should prevent this.
     
  19. Like
    xc6lx45 got a reaction from That_Guy in Diving in   
    >> it seems like it's very desirable to have a pure sin wave,

    Welcome to the world of radio engineering :)
    Very quick answer: Many modern receivers (e.g. take your cellphone) use a digital divider for LO generation that outputs a square LO signal.
    It actually gives higher mixer gain (which is good for noise) since the "switches" in the mixer conduct 100 % of the time and improves balance issues.
    The downside is, you get strong spurious responses at n times the LO frequency, which should be suppressed by filtering at the antenna side, before the mixer.

    But this is one problem from a very long list that you can probably ignore for a while.

    Generating a square LO is straightforward - simply use the clocking wizard to instantiate an MMCM/PLL. The chip does include LC oscillators (of which Colpitts is a textbook example) and they are digitally programmable. They can also provide 90 degree phase shifted outputs from a built-in divider.

    BTW, if you downconvert the ADC signal in software: You need a _decimating_ lowpass filter. Either that, or the number of MAC operations skyrockets (calculating samples that are mostly discarded).

  20. Like
    xc6lx45 got a reaction from That_Guy in Diving in   
    ... a slightly longer answer, if anybody is interested (analog mixing with square wave LO):
    One way is to look at the Fourier series of the square wave  as a sum of sines at frequencies f, 3f, 5f, 7f, ... and to a lesser extent 2f, 4f, 6f from implementation imperfections. Then think of the mixer as linear multiplier, and use superposition (the distributive property of multiplication) for a*(b3+b5+b7+...) = a*b3+a*b5+a*b7+...
    Hint, if anybody wants to formally go through the math, it gets much less messy with cos(x) = (exp(ix)+exp(-ix))/2 aka DeMoivre.
    So you really get multiple frequency translations instead of one. What remains to be done is to manage the input signal energy at those frequencies I don't want, with a filter or narrow-band antenna.
    In the digital world, you'd always use a sine wave.
  21. Like
    xc6lx45 got a reaction from [email protected] in Diving in   
    ... a slightly longer answer, if anybody is interested (analog mixing with square wave LO):
    One way is to look at the Fourier series of the square wave  as a sum of sines at frequencies f, 3f, 5f, 7f, ... and to a lesser extent 2f, 4f, 6f from implementation imperfections. Then think of the mixer as linear multiplier, and use superposition (the distributive property of multiplication) for a*(b3+b5+b7+...) = a*b3+a*b5+a*b7+...
    Hint, if anybody wants to formally go through the math, it gets much less messy with cos(x) = (exp(ix)+exp(-ix))/2 aka DeMoivre.
    So you really get multiple frequency translations instead of one. What remains to be done is to manage the input signal energy at those frequencies I don't want, with a filter or narrow-band antenna.
    In the digital world, you'd always use a sine wave.
  22. Like
    xc6lx45 got a reaction from That_Guy in Protocol Development   
    @Notarobot:
    Please check the datasheet (3 MBaud, not 1). If your UART doesn't achieve it, I'd start looking there.
    The achievable USB throughput is easily confirmed in a loopback test (code below, derived from FTDI's C# example)
    I measure 1352 ms for 3 MBit, which is close enough for this simple, single-threaded implementation.
    CMOD A7 loopback code:
    module mytop( input uart_txd_in, output uart_rxd_out ); assign uart_rxd_out = uart_txd_in; endmodule PC end:
    using System; using System.Collections.Generic; using System.Text; using System.Threading; using FTD2XX_NET; namespace LoopBack { class Program { static void Main(string[] args) { UInt32 ftdiDeviceCount = 0; FTDI.FT_STATUS ftStatus = FTDI.FT_STATUS.FT_OK; // Create new instance of the FTDI device class FTDI myFtdiDevice = new FTDI(); // Determine the number of FTDI devices connected to the machine ftStatus = myFtdiDevice.GetNumberOfDevices(ref ftdiDeviceCount); // Check status if(ftStatus == FTDI.FT_STATUS.FT_OK) { Console.WriteLine("Number of FTDI devices: " + ftdiDeviceCount.ToString()); Console.WriteLine(""); } else { // Wait for a key press Console.WriteLine("Failed to get number of devices (error " + ftStatus.ToString() + ")"); Console.ReadKey(); return; } // If no devices available, return if(ftdiDeviceCount == 0) { // Wait for a key press Console.WriteLine("Failed to get number of devices (error " + ftStatus.ToString() + ")"); Console.ReadKey(); return; } // Allocate storage for device info list FTDI.FT_DEVICE_INFO_NODE[] ftdiDeviceList = new FTDI.FT_DEVICE_INFO_NODE[ftdiDeviceCount]; // Populate our device list ftStatus = myFtdiDevice.GetDeviceList(ftdiDeviceList); if(ftStatus == FTDI.FT_STATUS.FT_OK) { for(UInt32 i = 0; i < ftdiDeviceCount; i++) { Console.WriteLine("Device Index: " + i.ToString()); Console.WriteLine("Flags: " + String.Format("{0:x}", ftdiDeviceList[i].Flags)); Console.WriteLine("Type: " + ftdiDeviceList[i].Type.ToString()); Console.WriteLine("ID: " + String.Format("{0:x}", ftdiDeviceList[i].ID)); Console.WriteLine("Location ID: " + String.Format("{0:x}", ftdiDeviceList[i].LocId)); Console.WriteLine("Serial Number: " + ftdiDeviceList[i].SerialNumber.ToString()); Console.WriteLine("Description: " + ftdiDeviceList[i].Description.ToString()); Console.WriteLine(""); } } // Open first device in our list by serial number ftStatus = myFtdiDevice.OpenBySerialNumber(ftdiDeviceList[1].SerialNumber); if(ftStatus != FTDI.FT_STATUS.FT_OK) { // Wait for a key press Console.WriteLine("Failed to open device (error " + ftStatus.ToString() + ")"); Console.ReadKey(); return; } ftStatus = myFtdiDevice.SetBaudRate(3000000); if(ftStatus != FTDI.FT_STATUS.FT_OK) { // Wait for a key press Console.WriteLine("Failed to set Baud rate (error " + ftStatus.ToString() + ")"); Console.ReadKey(); return; } ftStatus = myFtdiDevice.SetLatency(0); // Set data characteristics - Data bits, Stop bits, Parity ftStatus = myFtdiDevice.SetDataCharacteristics(FTDI.FT_DATA_BITS.FT_BITS_8, FTDI.FT_STOP_BITS.FT_STOP_BITS_1, FTDI.FT_PARITY.FT_PARITY_NONE); if(ftStatus != FTDI.FT_STATUS.FT_OK) throw new Exception(); ftStatus = myFtdiDevice.SetTimeouts(5000, 0); if(ftStatus != FTDI.FT_STATUS.FT_OK) if(ftStatus != FTDI.FT_STATUS.FT_OK) throw new Exception(); System.Text.StringBuilder sb = new System.Text.StringBuilder(); sb.Append("Hello World"); sb.Clear(); for(int ix = 0; ix < 3*125; ++ix) // 3 kBit sb.Append("x"); string dataToWrite = sb.ToString(); Console.WriteLine("Start"); System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch(); sw.Start(); for(int u = 0; u < 1000; ++u) { // 1000 repetitions UInt32 numBytesWritten = 0; ftStatus = myFtdiDevice.Write(dataToWrite, dataToWrite.Length, ref numBytesWritten); if((int)numBytesWritten != dataToWrite.Length) throw new Exception(); if(ftStatus != FTDI.FT_STATUS.FT_OK) throw new Exception(); string readData; UInt32 numBytesRead = 0; ftStatus = myFtdiDevice.Read(out readData, (uint)dataToWrite.Length, ref numBytesRead); if(ftStatus != FTDI.FT_STATUS.FT_OK) throw new Exception(); if((int)numBytesRead != dataToWrite.Length) throw new Exception(); } Console.WriteLine(sw.ElapsedMilliseconds + " ms for 3 MBit"); ftStatus = myFtdiDevice.Close(); Console.ReadKey(); } } }  
  23. Like
    xc6lx45 got a reaction from tip.can19 in What would be difference between clock latency and propagation delay?   
    I think the term propagation delay is typically used for a single logic block.
    Clock latency as in your drawing shows specifically the end-to-end length of the clock tree.
    For Xilinx, https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf
    does not contain the word "latency".
    The reality might be actually more complex: See "Clock Network Deskew" on page 72: Nowadays, clock rates are so high that we may not be able to simply define the reference phase at the input of the clock distribution network, and have the clock "latency" eat away the timing budget:
    In many cases, designers do not want to incur the delay on a clock network in their I/O timing budget therefore they use a MMCM/PLL to compensate for the clock network delay.
    So we use a dummy delay to advance the PLL phase by the nominal "latency", therefore moving the reference point to the end of the clock distribution network.
  24. Like
    xc6lx45 got a reaction from jpeyron in Old Knowledge seeking advice   
    Hi,
    if you have the endurance to get into FPGA technology (no disrespect but the learning curve seems to throw most people off before they ever use one for something useful), the cheapest board can keep you busy for months, possibly more. You may actually realize at some point that the hardware isn't even that important except for motivation - it just tells you "sorry, this doesn't work" and then it comes down to simulation to figure out why... Some 7-segment displays, switches etc are nice, but in the end one single LED is enough (this worked at least for me, plus later UART to connect to PC, very few boards don't provide the required hardware).
    You can download Vivado Web edition completely for free, and start all the fun, minus the hardware. Cost: $0.00
    A Raspberry pi might be another thing to consider. Belongs into every household, as far as I am concerned 🙂 this thing is amazing.
  25. Like
    xc6lx45 got a reaction from jpeyron in understand and configuration of xadc   
    Maybe one additional comment: The XADC appears as a register space on the bus. In Vivado you set the initial values that are valid until overwritten through the bus.
    If your software configures the XADC anyway, the initial values don't matter.