xc6lx45

Members
  • Content Count

    740
  • Joined

  • Last visited

Reputation Activity

  1. Like
    xc6lx45 got a reaction from Riesenrad in SPI TFT Display   
    You can try this one, attached. It's about as basic as it gets. There is default content in the screen buffer => just wire it up and you should see some weird picture.
     
    The character mem and display buffer use the same memory. This was really designed for minimum size on a Spartan 6 (1 block RAM and a bunch of LUTs). I can pack, I think, about fourty of them on one chip...
    it needs a 21.75 MHz pixel clock (clk)  for [email protected] Hz for the graphics card end (only, the memory bus side allows its own, independent clock).
    This is the interface:
    module sk61_VGA(clk, clkConfig, in_we, in_addr, in_data, out_data, out_vsync, out_hsync, out_blank, out_rgb);
    clkConfig, in_we, in_addr, in_data, out_data: That's the bus where you write into the screenbuffer or modify the character RAM (can even do small graphics...)
    out_vsync, out_hsync, out_blank, out_rgb This goes to the monitor, ignore "blank". For total late-70ies look-and-feel use monochrome green and leave R&B open :-)
    sk61_VGA.v
  2. Like
    xc6lx45 got a reaction from John_Anacall in Announce: LabToy 0v1 (CMOD A7 35T board)   
    An FPGA can be a useful "swiss army knife", but all the nice features aren't easily accessible.
    Enter "LabToy": A batteries-included collection of utilities, just double-click and go.
    As the name implies, this isn't meant to compete against "real" test equipment. The main selling point is like a pocket knife - this fits into a shirt pocket and the power tools don't. And speaking of "selling points", it's free to use.
    So what do we have here:
    - Digital data: Shows the input state of all pins
    - Analog data: Readings from the two ADCs, up to about 700 ksps sustained (XADC "simultaneous sampling" mode, phase-accurate between channels)
    - Streaming data logger: Both analog and digital data can be written to a .vcd file, to be shown in gtkwave. There is no limit to the capture length.
    - Analog signal generator: 8 fully independent channels, sine, square wave, the usual suspects. Well, the DACs won't win any audiophile awards, but they are usable.
    - "Programmable" digital LED mode: Configurable pulse width to suppress short glitches, or edge detect with a built-in pulse generator to highlight them.
    - Analog LED mode: Shows the input value of the ADC in real time
    Some screenshots:
    1k sine / cosine from DAC jumpered to ADC (in gtkwave)
    The digital signal is the generator's sync output that can be recorded as a digital input.

    Realtime display of the inputs.
    With pocket knives in mind ("this button will unlock the large blade, allowing it to be manually returned to its folded position") I decided to keep the screen uncluttered and put descriptions into tooltips.
    The large displays are the average voltage readings from the ADC. The smaller ones show the digital inputs in groups of four.

    Generator controls (frequency, minimum voltage, maximum voltage, phase).
    The voltage scaling is a bit unusual (typically there is "AC magnitude" and "DC offset") but I chose this approach because it shows clearly the limitations of the 0..3.3V output range.
    Most people will probably leave all this at the default values for a full-scale signal.

    Data capture

    Example: The output in gtkwave after I touched a jumper cable to the digital inputs on the DIL connector.
    +++ DO NOT USE THE +5V OUTPUT P24 FOR THIS KIND OF TEST +++ (3.3 V is available on the PMOD connector, bottom row)
    The red "undefined" marks flag the first input in an 8-bit group. In this example, they aren't too meaningful, but they can alert me to the fact that no data events have been observed yet.

    LED control
    The two numbers give the number of consecutive 1 or 0 samples (at 125 MHz) before a signal change is propagated to the LED.
    E.g. put 125 million there and it'll take one second after changing the input state for the LED to light / go dark.
    Those can be used interactively  to study an unknown signal.
    "Level": no further processing ("level" mode and 1 / 1 sample counts is equivalent to directly connecting the LED to the physical input) "Edge" mode generates a brief pulse on signal changes, the LED is dark otherwise. "Invert" flips the input right next to the pin (0 becomes 1, black becomes white and man gets himself killed on the next zebra crossing -DA).
    How to get it:
    The file is attached:
    labToy0v1_beta.exe
    The installer unpacks a single .exe.
    Happy hacking!
    Requirements:
    Windows 64 bit (!) .NET 4.5 FTDI libraries CMOD A7 35 T (not 15 T). Warnings:
    Direct access to digital IO pins is an inherently dangerous activity.
    "PROVIDED WITHOUT WARRANTY OF ANY KIND" means Just That.
    And beware of the +5V pin.
    PS:
    If you try it, kindly let me know whether it works, or what goes wrong.
  3. Like
    xc6lx45 got a reaction from jpeyron in Announce: LabToy 0v1 (CMOD A7 35T board)   
    An FPGA can be a useful "swiss army knife", but all the nice features aren't easily accessible.
    Enter "LabToy": A batteries-included collection of utilities, just double-click and go.
    As the name implies, this isn't meant to compete against "real" test equipment. The main selling point is like a pocket knife - this fits into a shirt pocket and the power tools don't. And speaking of "selling points", it's free to use.
    So what do we have here:
    - Digital data: Shows the input state of all pins
    - Analog data: Readings from the two ADCs, up to about 700 ksps sustained (XADC "simultaneous sampling" mode, phase-accurate between channels)
    - Streaming data logger: Both analog and digital data can be written to a .vcd file, to be shown in gtkwave. There is no limit to the capture length.
    - Analog signal generator: 8 fully independent channels, sine, square wave, the usual suspects. Well, the DACs won't win any audiophile awards, but they are usable.
    - "Programmable" digital LED mode: Configurable pulse width to suppress short glitches, or edge detect with a built-in pulse generator to highlight them.
    - Analog LED mode: Shows the input value of the ADC in real time
    Some screenshots:
    1k sine / cosine from DAC jumpered to ADC (in gtkwave)
    The digital signal is the generator's sync output that can be recorded as a digital input.

    Realtime display of the inputs.
    With pocket knives in mind ("this button will unlock the large blade, allowing it to be manually returned to its folded position") I decided to keep the screen uncluttered and put descriptions into tooltips.
    The large displays are the average voltage readings from the ADC. The smaller ones show the digital inputs in groups of four.

    Generator controls (frequency, minimum voltage, maximum voltage, phase).
    The voltage scaling is a bit unusual (typically there is "AC magnitude" and "DC offset") but I chose this approach because it shows clearly the limitations of the 0..3.3V output range.
    Most people will probably leave all this at the default values for a full-scale signal.

    Data capture

    Example: The output in gtkwave after I touched a jumper cable to the digital inputs on the DIL connector.
    +++ DO NOT USE THE +5V OUTPUT P24 FOR THIS KIND OF TEST +++ (3.3 V is available on the PMOD connector, bottom row)
    The red "undefined" marks flag the first input in an 8-bit group. In this example, they aren't too meaningful, but they can alert me to the fact that no data events have been observed yet.

    LED control
    The two numbers give the number of consecutive 1 or 0 samples (at 125 MHz) before a signal change is propagated to the LED.
    E.g. put 125 million there and it'll take one second after changing the input state for the LED to light / go dark.
    Those can be used interactively  to study an unknown signal.
    "Level": no further processing ("level" mode and 1 / 1 sample counts is equivalent to directly connecting the LED to the physical input) "Edge" mode generates a brief pulse on signal changes, the LED is dark otherwise. "Invert" flips the input right next to the pin (0 becomes 1, black becomes white and man gets himself killed on the next zebra crossing -DA).
    How to get it:
    The file is attached:
    labToy0v1_beta.exe
    The installer unpacks a single .exe.
    Happy hacking!
    Requirements:
    Windows 64 bit (!) .NET 4.5 FTDI libraries CMOD A7 35 T (not 15 T). Warnings:
    Direct access to digital IO pins is an inherently dangerous activity.
    "PROVIDED WITHOUT WARRANTY OF ANY KIND" means Just That.
    And beware of the +5V pin.
    PS:
    If you try it, kindly let me know whether it works, or what goes wrong.
  4. Like
    xc6lx45 got a reaction from [email protected] in Troubleshooting Switch Issues on FPGA   
    Hi,
    if I were faced with the issue (this is maybe somewhat overkill) , I'd set up a five-line design that routes two switches (one known-good) to two LEDs.
    Then build and run twice, with pullups or pulldowns enabled in the constraints file for the switch input
    set_property PULLDOWN true [get_ports {mySwitchPorts[*]}]
    same alterrnatively with PULLUP
    If the LED follows the pull direction on the broken switch, the pin is floating. This would indicate a bad solder connection or a torn PCB trace / via.
    Sometimes, pushing gently with a finger on PCB and FPGA can reveal such a failure.
    Disclaimer: 99.9 % of all isses are NOT hardware-related (but that makes the remaining 0.1 % all the harder to spot)
  5. Like
    xc6lx45 got a reaction from ef.neuro in Driving DAC cs4344   
    if you find nothing better - it's a fairly popular component - I've made it work the hard way, once upon a time.
    See attachment. This was on a Spartan 6.
    CS4344_DAC_demo.zip
    sk61_CS4344_DAC.v
  6. Like
    xc6lx45 got a reaction from ef.neuro in Driving DAC cs4344   
    Hi,
    here is the file on google drive:
    https://drive.google.com/file/d/1w5bB3QoOe6YPBvX45e82ZW1CK0tdeHh4/view?usp=sharing
  7. Like
    xc6lx45 got a reaction from ef.neuro in Driving DAC cs4344   
    BTW, thinking back to when I wrote those comments in the code:
    I generate the SPI clock signal from a regular information bit.
    Timing analysis guarantees that the signal is stable at the edges of the clock it is associated with. It does NOT guarantee that the signal is glitch-free in-between.
    Glitches on a clock signal means the slave may see more than one clock edge and bits slip.
    Thus the comment. If it comes straight from a register, the signal will be clean. If there were combinational logic behind it, there could be glitches => avoid.
    It didn't give me any trouble so I guess it's OK for home audio.
    Please don't use in pacemakers, autonomous driving or thermonuclear missiles.
  8. Like
    xc6lx45 reacted to zygot in Feedback on a register file design?   
    @xc6lx45,
    You must like experimenting with the reaction of Africanized bee colonies to jack-hammers. I'm in a feisty mood today so what the heck...
    There is absolutely a place for hard CPU core based FPGA devices like the Zynq. I don't even feel the needs to support that statement. For almost all low power applications the FPGA can't compete with a commercial uC or DSP. I tend to be more sympathetic with you on soft CPU cores using FPGA resources. The exception is when you are pursuing a project that is a labour of love. Implementing a full-stack Ethernet interface in HDL makes no sense to me. There are times when post configuration programmability might push me toward a soft processor. But then I'd use an Atmel clone that someone else's software toolchain. If someone ( I can think of someone ) makes a great soft processor that is compatible with the gcc toolchain I might be interested. By and large HDLs get almost everything done that needs to be done.
    BTW there's thread in another section in the Digilent forum dedicated to just this topic... which would be a better place to post your argument.
  9. Like
    xc6lx45 reacted to [email protected] in Feedback on a register file design?   
    @xc6lx45,
    I had never heard of anyone actually using this practice before.
    Some time ago, I was given this article which appears to describe the practice you are recommending above.  The individual who had given it to me suggested that ARM got themselves in a lot of trouble (i.e. stuff not working that should have) by using this practice.
    While I'm not familiar with all the details, I did find the article fascinating--and now more so in light of your suggestion.
    Dan
  10. Like
    xc6lx45 got a reaction from CurtP in Feedback on a register file design?   
    >> a general purpose CPU
    CurtP,
    you could have a look at J1:
    http://www.excamera.com/files/j1demo/verilog/j1.v
    It's a beautiful design. Not that I'd propose Forth for any real-world work but it's perfect for a simple hardware implementation. It might even make make "business sense" in Picoblaze territory.
    There is a VHDL port, too, but possibly not as concise.
     
     
     
  11. Like
    xc6lx45 got a reaction from jpeyron in CMOD A7: standard FTDI JTAG access not working   
    Thanks Jon.
  12. Like
    xc6lx45 reacted to jpeyron in CMOD A7: standard FTDI JTAG access not working   
    HI @xc6lx45,
    You should tri-state the other pins (configure as inputs). The buffer isn’t necessary. We missed removing it from the design.  It has been removed from some upcoming designs.
    thank you,
    Jon
  13. Like
    xc6lx45 reacted to jpeyron in CMOD A7: standard FTDI JTAG access not working   
    Hi @xc6lx45,
    Try driving ADBUS7 high to enable the tri-state buffers.
    cheers,
    Jon