xc6lx45

Members
  • Content Count

    740
  • Joined

  • Last visited

Reputation Activity

  1. Like
    xc6lx45 reacted to Tickstart in VHDL BASYS3 internal clock problems.   
    I'm afraid they are correct  But no one really knows how the Vivado simulator works, sometimes it does, sometimes it doesn't. As far as I know, there isn't any simulator-simulator to test the simulator and figuring out why it won't simulate properly.
    I just debug my VHDL code like I debug C, just stare at it long enough. But I know that doesn't cut it.
  2. Like
    xc6lx45 got a reaction from [email protected] in fft spectrum analyzer on SOC   
    and I was curious what brings you to that question. It's so difficult to come up with a meaningful homework problem (this one would be good), I don't want to carelessly ruin it 🙂
  3. Like
    xc6lx45 got a reaction from farhanazneen in XADC and the FFT   
    BTW it should be "20*log10(fftshift(abs(fft(...)))) not 10.
    If you're dealing with voltage, current, wave quantities, anything that gets converted to physical power by squaring, use 20 log10 =2*10*log10(x) = 10*log10(|x|.^2)
  4. Like
    xc6lx45 got a reaction from Mayur in Arty A7-35T IPs for communication with a Linux PC   
    Hi,
    using AXI without a processor is unnecessarily complex. In comparison, the UART functionality is almost trivial.
    You should be able to reach maybe 2 MBits / second. For comparison, JTAG goes up to 30 MBits / second but it's not as easy.
    Below some very old code from a very dusty corner of my hard drive. You have to set "nBitCycles" to the length of one bit in clock cycles, e.g. for 9600 baud and 100 MHz clock it's 100e6 / 9600.
    The easiest way to test is to link serialRx/out_byte to serialTx/inByte, serialRx/in_strobe to serialTx/inStrobe. Then it'll echo back all data.
    // note: if rx is an external (asynchronous) input, it must be registered first module sk61_serialRx(clk, in_rx, out_byte, out_strobe); input clk; input in_rx; parameter nBitCycles = 0; reg [31:0] count; reg [3:0] state = 0; reg [7:0] data; output reg out_strobe; output [7:0] out_byte; assign out_byte = out_strobe ? data : 'bx; always @(posedge clk) begin out_strobe <= 1'b0; // non-final if (state == 0) begin if (!in_rx) begin state <= 1; count <= $floor(nBitCycles/2+0.5); end end else if (state == 10) begin // stop bit // wait for nominal sampling instant if (count != 0) count <= count - 1; else if (in_rx) begin // after nominal sampling instant, wait for line to go high // => ready to signal next byte with falling edge // => restart state <= 0; count <= 'bx; data <= 'bx; end end else begin if (count != 0) begin // start bit count <= count - 1; end else begin // data bits data <= {in_rx, data[7:1]}; state <= state + 1; count <= nBitCycles; if (state == 9) begin // final data bit out_strobe <= 1'b1; end end end end endmodule module sk61_serialTx(clk, out_tx, in_byte, in_strobe, out_busy); parameter nBitCycles = 0; input clk; output out_tx; input [7:0] in_byte; input in_strobe; output out_busy; reg [31:0] count; reg [3:0] state = 0; reg [7:0] data; assign out_tx = (state == 0) ? 1'b1: // ready (state == 1) ? 1'b0: // start bit (state == 10) ? 1'b1: // stop bit data[0]; // data bits assign out_busy = (state != 0); always @(posedge clk) begin // correctly timed, in_strobe appears only during idle state (0) // however, if echoing data from a UART, small timing error may cause // a new byte to start already during the stop bit // This implementation does not prevent retriggering at any time, // but this will cause garbled data. if (in_strobe) begin count <= nBitCycles; state <= 1; data <= in_byte; end else if (state != 0) begin if (count == 0) begin count <= nBitCycles; // (non-final) state <= state + 1; // (non-final) case (state) 1: begin // startbit end default: begin // data bits data <= {1'bx, data[7:1]}; end 10: begin // stop bit state <= 0; count <= 'bx; data <= 'bx; end endcase end else begin count <= count - 1; end end end endmodule  
  5. Like
    xc6lx45 got a reaction from BogdanVanca in PmodHB5   
    I'm sure it's possible to "drive" it at any rate. What I don't know is the amount and color of the magic smoke coming out :-)

    This is a fairly basic power electronics question: Each switching event dissipates energy because there is voltage across the transistor while current is nonzero. The question is, how much energy dissipation can you tolerate.

    With a 2A transistor you can probably feel with your finger whether or not it runs hot.

    In similar applications, PWM frequencies of 15 kHz or more are possible (search for "brushless ESC") but I doubt the motor will run any smoother.
  6. Like
    xc6lx45 got a reaction from radug in Cora Z7-10 and Vivado 2018.2 (2)   
    Hi,
    >> Which has nothing to do with the way , the signals are defined in the constraints file (led0_b, etc.)
    Yes: if I compare the constraints file with your "IO Bus port properties" screenshot, the names don't match. Also, the locations are different (because Vivado has auto-assigned them, thus the warning).
    I'd try to use 
    ... get_ports{rgb_leds_tri_o[0]}
    in the constraints file instead of e.g. led0_b.
    This may be not the "proper" way to use the example so best make a backup first.
  7. Like
    xc6lx45 got a reaction from JColvin in ethernet communication   
    I believe "putty" is one.
    Here are more.
  8. Like
    xc6lx45 got a reaction from tnet in Systematic approach for Verilog implementation   
    Hi,
    I'm sure there will be some long follow-up answers. I specialize in short answers, so here we go 🙂
    Engineers are frighteningly unsystematic. What engineers are good at is cutting corners.
    Either you're completely in over your head, or you are facing an easy problem. For easy problems, engineers do a quick sketch on a paper napkin (skip if no napkin is available) and start coding.
    So what you need is the Verilog skills to write down a FSM. Essentially, it might look like this
    reg [7:0] state = 8'd0 always @(posedge clk) begin switch (state) case 8'd0: if (something) then begin ... state <= 8'd1; end case 8'd1: if (something) then begin ... state <= 8'd2; end endcase // this must be at the bottom of the enclosing begin...end block if (synchronousReset) begin state <= 8'd0; ... set everything else to init values end end It might look completely different (matter of style) but avoid e.g. asynchronous reset as commonly found in pre-FPGA tutorials.
    Then write down what you think it should do. Simulate. Figure out why it does something else. Rinse and repeat and also update your understanding of what you think it should do...
    Oops. It wasn't that short.
  9. Like
    xc6lx45 reacted to [email protected] in Systematic approach for Verilog implementation   
    @tnet,
    Let me try to add to what @xc6lx45 just said.  I've seen several design processes.  The typical student design process is

    This ends up quite confusing for the student.  What @xc6lx45 is recommending would look more like,

    I've argued in the past that this approach only makes sense if you have a means of properly viewing what's going on within the FPGA.  If you have no way of viewing the logic within an FPGA, then I'll argue that should be your first task.  You can read about the problem that results when you don't have that ability here.
    This process, however, will not work for ASIC flows.  (FPGA flows typically teach students the design methods that they'll get paid more for when working for ASIC companies ... )  In an ASIC flow, the design *must* work right the first time (if you want to keep your job).  There's a *HEAVY* dependence on simulation and so forth.  Broken designs aren't allowed by the boss to go to the next step.
    My own design process has morphed a bit since I first wrote the article on this topic.  I've now picked up formal methods as a means of building designs, using the free and open source tool yosys with SymbiYosys as the driver.  With every new bug I find using them, I get hooked all the more.  As a result, my new development approach for something like this would be:
    Scribble out some code Add a property package, like the one for the wishbone bus.  (I also have packages for Avalon and AXI available for sale, at least until I blog about them and then they will be public) Add some other ad-hoc assertions (or assumptions about inputs) based upon my own estimation of my code Apply the formal tools View the VCD waveform in gtkwave.  Compare it to the trace I'm trying to match.  Create a cover property once the tools stop producing failing traces. Lather rinse repeat until the code matches Create a simulation component for the hardware I am attempting to interact with Create a design including this component, and test via simulation At this point ... the yellow figure above now applies again. You can read my ramblings on how this works here if you'd like.
    Hopefully that helps, if not then I've just rambled on for longer than @xc6lx45!
    Dan
  10. Like
    xc6lx45 got a reaction from artvvb in Systematic approach for Verilog implementation   
    Hi,
    I'm sure there will be some long follow-up answers. I specialize in short answers, so here we go 🙂
    Engineers are frighteningly unsystematic. What engineers are good at is cutting corners.
    Either you're completely in over your head, or you are facing an easy problem. For easy problems, engineers do a quick sketch on a paper napkin (skip if no napkin is available) and start coding.
    So what you need is the Verilog skills to write down a FSM. Essentially, it might look like this
    reg [7:0] state = 8'd0 always @(posedge clk) begin switch (state) case 8'd0: if (something) then begin ... state <= 8'd1; end case 8'd1: if (something) then begin ... state <= 8'd2; end endcase // this must be at the bottom of the enclosing begin...end block if (synchronousReset) begin state <= 8'd0; ... set everything else to init values end end It might look completely different (matter of style) but avoid e.g. asynchronous reset as commonly found in pre-FPGA tutorials.
    Then write down what you think it should do. Simulate. Figure out why it does something else. Rinse and repeat and also update your understanding of what you think it should do...
    Oops. It wasn't that short.
  11. Like
    xc6lx45 got a reaction from tnet in Verilog Question   
    >> Therefore it's 2^3 and can address up to 8 bits
    not bits but the value goes 0..7. The original design needs a value of 6 so 3 bits is the minimum. Makes sense.
    There is an implicit division-by-two in the negation of the output flipflop
    clk_track <= ~clk_track;
    so you need to set half the division ratio.
    That said, DO NOT use this approach for creating an actual FPGA clock. Modern FPGAs are more complex and distinguish between dedicated "clock" signals and "information signals", with distinct routing resources. The clock divider would create a bridge from an information routing resource to a clock routing resource, and that gives you a warning in Verilog and a sub-optimal design.
  12. Like
    xc6lx45 got a reaction from Adriann in What is the maximum current the Spartan-3E Starter Board can drive on I/O pins ?   
    They are very robust. Xilinx is a bit shy in telling numbers, but their posts indicate that they are short circuit proof.
    https://forums.xilinx.com/t5/Virtex-Family-FPGAs/Effect-of-short-circuit-on-V6-outputs/m-p/227493#M13565
    https://www.xilinx.com/support/answers/23277.html
    I got the impression that reports of failed voltage regulators are more common than busted FPGAs (expect that blowing one pin kills the whole IO bank).
     
  13. Like
    xc6lx45 got a reaction from juergenR in Vivado - How to reflash HDL code quickly   
    good 🙂
    One more hint: A simulator and the warnings window / timing reports from Vivado are the key tools.
    If you start with Verilog (as opposed to VHDL), iverilog plus GTKWave can be extremely useful to debug the logic (cursor-up / return / alt-tab / ctrl-R takes me about 1 second. This is the immediate feedback you were looking for). There's nothing special about it, it's just mean and lean and works.
    Implementing the design in Vivado up to bitstream is important to keep in touch with reality - HDLs were originally implemented for simulation, not synthesis, and a great deal of online information is just misleading for FPGA, telling things that aren't implementable. You won't get rid of many warnings, but understand every single one. Vivado is trying to tell you something you need to at least understand as a concept. Consider it an automated private lesson. The compiler is your friend. All it takes is a lot (and I mean a lot) of time.
    Hardware debugging is actually fairly limited - essentially it tells me "simulate some more and re-read the warnings..."
  14. Like
    xc6lx45 reacted to Piasa in Designated Numbers Moore FSM with 4 bit counter   
    How should the FSM should handle 8 7 0 1 1 8 8 8 7 0 1 7 8 7 0 0 0 1 7?
    87011 is not 87017.
    8887017 contains 87017.  But if 8701 was seen before, the 87017 seen occurs after 8887.
    8700017 conatins 870 and 17, but has two extra 0's.
    I don't think any FSM model allows async inputs that modify state.
    I've always found that Mealy is the FSM that devs want to write -- even when they write Moore/Mendevev FSMs.  Mealy provides next-state/next-value logic -- often avoiding code duplication.  But it uses more lines of code so it is rarely used.
    For this context, VHDL and Verilog are basically the same.  This problem doesn't make use of any Verilog/VHDL specific features and both languages handle the general logic design in very similar ways.
    In terms of using the CE on DFFs vs the CE on BUFGCE, just make sure you constrain the CE signal to the BUFGCE.  The CE signal does have a setup/hold similar to a FF and shouldn't be changing close to a clock edge that affects logic.  Because designs can have thousands of different CE signals for DFF control sets, but normally only 32 BUFGCE's, the CE feature of the BUFGCE is less used.
  15. Like
    xc6lx45 reacted to Notarobot in Protocol Development   
    xc6Ix45
    You are absolutely correct, I should have noticed that you are proposing direct connection.
    Sorry for bringing unrelated issue.
  16. Like
    xc6lx45 got a reaction from [email protected] in Preparation for an FPGA (VHDL) developer job interview   
    Not sure if I should comment on this. Well, I've done job interviews for one (1) FPGA opening, and it was a non-standard case (but quite a few in general). So my experience surely doesn't reflect the state of the FPGA industry specifically.
    Maybe "work hard then be honest" is a good guideline. If you have worked hard, you can afford to be honest. Doing tutorials alone does not qualify as "working hard". It's spoon-fed baby food. Well we all needed it at some point but rarely talk about it (insert special thanks here to Numato for their excellent Zynq bare-metal two-pager...)
    JColvin's "engineering through problems" is spot-on but requires the "working hard" before. A large part of the world's population has their FPGA knowledge from marketing material, not from learning things the hard way. In a job interview, be careful not to be mistaken for one of those.
    For someone coming from school, having some published project on github etc might be worth a lot (but: quality, not quantity. This can work against you if the code shows you haven't understood the basics). Refer to that in the CV.
    Having own projects also shows you have a genuine interest in this line of work, which is usually a good thing.
    And keep in mind, you're playing a ball game with the recruiter. Not against him / her. Give them something to talk about and be prepared to do the talking. It's surprisingly hard to come up with good questions that lead somewhere.
  17. Like
    xc6lx45 got a reaction from jamey.hicks in Vivado slowness reality check   
    For comparison: My labToy project on CMOD A7 35 builds in 3:40 min (excluding clock IP, measured on my wristwatch by resetting synthesis, then "generate bitstream").
    It's not a large project - about 20 % of DSP used and slices touched - but not trivial either.
    A hello-world project compiles in maybe 1 min, give or take some. But my desktop was built for the job (water-cooled i7 4930 @ 4.5G, 32G quad-channel RAM, M2 SSD).
    Most of this doesn't help with a one-LED design, but there are a number of things that will slow down the run considerably:
    - Use correct timing constraints:
    For example, a LED driven from logic clocked at 200 MHz can be very difficult to route (but at the 12 MHz crystal frequency it shouldn't matter much).
    A simple
    set_false_path -to [get_ports LED] makes it "don't-care".
    - Throw in extra registers where appropriate, especially between blocks (which tend to be physically separate). Most of the time, it does not matter whether the signal arrives one or two clock cycles late, and some spare registers will simplify implementation. This is especially useful for register rebalancing.
    - For the extra registers, it may make sense to use a "don't touch" attribute. E.g. in Verilog:
    (* DONT_TOUCH = "TRUE" *)reg [5:0] wa [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg [17:0] wd [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg we [1:NWRDELAY]; When I have multiple, parallel instances of a timing-critical block, the input registers are logically equivalent, get optimized away, and then P&R takes ages because timing is so difficult. The "don't touch" attribute" keeps them separate, possibly using a couple of FFs more than strictly necessary.
    - Removal of redundant logic can take a long time. For example, when I simulate pipelined DSP like the "labToy" generators I simply carry all data all the way through the pipeline, even though most of it isn't needed. Optimization will eventually remove it, but the cost is runtime. The LabToy example includes 8 instances each with a 6-lane 14-cycle 18-bit wide pipeline, and it adds minutes to the synthesis time if I don't remove the unused ends of delay chains in the source code.
    - Read and understand every warning, and read the timing report. "The compiler is my friend"
    For example, with PLL blocks it is easy to create duplicate clocks with the same frequency (one from the constraints file, one from the IP block). Timing analysis tries to (and will eventually) sort out all possible interactions, but it takes a lot of time and can create meaningless but difficult routing constraints.
    - Fix "critical warnings" related to timing. Even if common sense tells the design will work e.g. classroom demo with buttons,  Vivado will waste a lot of time trying the impossible.
     
     
     
     
  18. Like
    xc6lx45 reacted to hamster in Vivado is bugged up the *** per usual (no, my bad)   
    I can't see what the issue is... can you describe exactly how are you expecting this to reverse the order of the bits? 
    If your assignment into 'reverse_order_bits' does change the order, then when you assign that into 'out_sig' then that will also reverse the order.
    So if the output is always the input, then 'rev' (and that means 'SW[4]') also has no effect, and can be optimized out.
    And if the out_sig always equals in_sig, then your design does indeed contains no logic, just three connections from input pins to output pins.
    All seems consistent to me.
    Try it with explicitly reversing the order of the bits.
  19. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T MICROBLAZE INTERFACING WITH FABRIC LOGIC   
    Hi,
    one hint: "regular" AXI is fairly complex and achieves its performance by writing bursts. AXI-Lite is in comparison very simple but limited to writing only a single value at a time (which is usually what I want).
    With a 667 MHz Zynq and the simple example I posted earlier, a single write takes about 0.5 microseconds (a for-next loop counting down from 2M writing a constant to the bus takes one second, give or take some). I wonder how a microblaze (at 100 MHz) will perform.
    "Polling" is one approach - repeatedly check, whether new data is available. In more complex systems, interrupts would be used, opening up a pretty standard but still XL-size can of worms...
  20. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T MICROBLAZE INTERFACING WITH FABRIC LOGIC   
    ... of course, a ready-made AXI GPIO might be just as good.
  21. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T MICROBLAZE INTERFACING WITH FABRIC LOGIC   
    Check out the AXI GPIO. For simple designs, it may be all you need.
    On the other hand, putting my own logic on the bus allows some elegant solutions like read-sensitive registers that may simplify the software greatly. Digitop design has its own little team in larger projects (at least on ASIC), don't expect this to just fall into place.
    Maybe someone else can comment on "standard way", those are just paths I figured out for myself.
  22. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T Missing CFGBVS and CONFIG_VOLTAGE Design Properties   
    Hi,
    I'm 99 % certain that the problem is caused because you specify a clock twice: Once in the constraints file, once in the frequency setting of the clocking wizard.
    Solution: remove the constraints for clock frequency on the input pin.
    If you look closely, you'll see that the "Inter"-clock error ("from one clock to the other") relates to two clocks on the same signal, that is clk_out_2_clk_wiz_0 with a suffix that identifies the clock. In my understanding, this makes more sense when clocks are switched / gated (which you don't do).
    The constraint is meaningless and creates an impossible situation for Vivado, which it tries to resolve at best effort. Screwing up the rest of the design => failure to close timing.
     
    BTW, the setting in the clocking wizard that controls the auto-generated buffer is under the "Clocking options" tab (which is for some reason the 2nd one in your screenshot).
    Section "Input clock information" Input clock: Primary. Change "Source" from "single ended clock capable" to "No buffer". This is taken from clocking wizard 5.4 on an Artix.
     
     
     
  23. Like
    xc6lx45 got a reaction from jpeyron in FTDI Drivers Issue   
    Hi,
    have you tried a different PC?
    There are some USB host chipsets which simply don't work reliably.
     
  24. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T Missing CFGBVS and CONFIG_VOLTAGE Design Properties   
    Do you maybe use a different Vivado version than I do (2017.4 here)? I don't have the "Board" tab at all, maybe because I didn't include any CMOD A7-specific files for this project.
    I'd comment it out in constraints
    >> Tthen I've to remove this constraint row from my XDC?
    (yes, this line).
    If that doesn't help, create a new project from scratch based on the FPGA type (not any board setup file).
    There is also an odd error message on the right behind your last screenshot... board_part file invalid?
  25. Like
    xc6lx45 got a reaction from BYTEMAN in Cmod A7-35T Missing CFGBVS and CONFIG_VOLTAGE Design Properties   
    I suspect things will make sense if you connect the clock input pin only to the MMCM's input, without other connections to the net.
    Most likely, the IO can only drive a single clock-net buffer at the pin site, but you're trying to drive two. For that, the signal needs to go to the fabric => DRC 23-20 (theory!).
    Note, if you're using default MMC settings, "clk_div_inst" will include its own clock buffer. This can be disabled on the first page of the clkWiz IP configuration page (bottom right corner).
    If I had to measure jitter on the input clock per my own suggestion, the easiest way might be to simply build a 2nd bitstream