Tickstart

Members
  • Content Count

    83
  • Joined

  • Last visited

  • Days Won

    3

Tickstart last won the day on September 30 2018

Tickstart had the most liked content!

About Tickstart

  • Rank
    Frequent Visitor

Recent Profile Visitors

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

  1. Heh, don't get me wrong, I'm fully aware of this fact =D
  2. 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.
  3. Continuing this subject, on a different note: So, considering what we've learnt, how do you efficiently pipeline a design on an FPGA, i.e in Vivado etc? An initial thought is of course to maticulously plan your circuit, that's all well and fine. But can an acceptable approach be to write your specification, have a look at the synthesized circuit layout and then go back and place flip flops in between critical paths that you observe in the schematic? Perhaps Vivado even has functionality to facilitate this process.
  4. Make sure you have the correct basys 3 master .xdc-file as your constraints file. Some settings that you configure under the Implementation-menu (device configurations), end up as text commands in the .xdc file. In my experience, I think it was some modifier named something something -"persist = yes" that completely broke everything, so even if I had the correct xdc-file and so on, still complained that I used some illegal pin. Check at the bottom of the .xdc file.
  5. :'D reminds me of: https://youtu.be/vH2-sXTmzWI?t=20m13s
  6. I've never thought about pipelining when designing a circuit, does the synthesis tool or compiler or whatever of VHDL pipeline anything automatically? I guess paralellizing things is easier for a compiler to do than pipelining. Is pipelinging common in HDL designs? Thank you for an excellent explanation ham.
  7. But yes, it does make sense, I guess.. In respect to each flipflop, in the first example they have to wait for the rest of the chain before they can deliver their next unit. Think of it as one of those.. "Trafficking chains" (thanks google translate) or whatever when something is on fire and people stand in a row and hand each other buckets of water, passing them along the chain of people. Each bucket may actually take longer to get there compared to if one person were to run with it to the fire, but by paralellizing it like this, many buckets can be on their way at once. Does that make sense?
  8. I am prolific on this forum for asking the most dumb questions, but hey at least i excel at something. I was reading in an excellent book about computers (Digital Design and Computer Architecture), about an example involving baking cookies, which I can relate to. In it, Ben is putting dough on his only tray, and puts it in the oven and waits for it to bake. Once finished, he takes it out and puts more dough on the tray. In the improved version he has two trays, and when one is baking in the oven he prepares the other in the meantime. This is all jolly. However, when they actually start talking about circuits again, I'm confused.. To me, it's not obvious how adding flipflops to everything is better.. Surely no more work is being done. I can understand that, in the first example (fig 3.58 or "nopipe") the total delay is 9.5 ns and thus the clock cannot tick faster than this signal propagates, and by sticking a flipflop in between (thus "halving" the delay) the frequency can be increased. But it seems like you're fooling yourself thinking this will produce results faster, the flipflop doesn't magically boost the speed of electricity, the signals still have to pass through all the combinational logic?? Can someone explain to me what is going on. I know it's gonna be one of those "oh yes of course, how stupid am I.."-moments but just give it to me, I can take it.
  9. Yes yes, I understand. So there is no way to flip the order this way, i.e you need to keep the to or downto chain consistent between modules? I'm sorry I slandered you Vivado :'(
  10. It could be the textbook that's lying also. That you can reverse bits like that (with a downto vs to trick).
  11. Every time... Here I am, just wanting to test the most benign of things, and Vivado has to give me ****. It says "design rev_top has unconnected port sw[4]" (I assume because "design revving has unconnected port rev" - which it is connected to), which I know for a fact is a lie. It also says "design has unconnected top module" and I'm suspecting Vivado has become senile at this point. My goal is to reverse bits, depending on a signal (sw(4) - to reverse or not). Just to test the syntax and functionality of VHDL. VERY SIMPLE, IF I JUST HAD A CHANCE TO TEST IT. library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity rev_top is Port (clk : in STD_LOGIC; sw : in STD_LOGIC_VECTOR (4 downto 0); led : out STD_LOGIC_VECTOR (3 downto 0)); end rev_top; architecture Behavioral of rev_top is component revving is Port (clk, rev : in STD_LOGIC; in_sig : in STD_LOGIC_VECTOR (3 downto 0); out_sig : out STD_LOGIC_VECTOR (3 downto 0)); end component; begin REVERSER: revving port map(clk => clk, rev => sw(4), in_sig => sw(3 downto 0), out_sig => led); end Behavioral; library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity revving is Port (clk, rev : in STD_LOGIC; in_sig : in STD_LOGIC_VECTOR (3 downto 0); out_sig : out STD_LOGIC_VECTOR (3 downto 0)); end revving; architecture Behavioral of revving is signal reverse_order_bits : STD_LOGIC_VECTOR (0 to 3); begin reverse_order_bits <= in_sig; out_sig <= reverse_order_bits when rev = '1' else in_sig; end Behavioral;
  12. Thanks Dan, now I know for sure I'm in way over my head :'D
  13. I have this really important job interview coming up, I feel very fortunate to have gotten this chance and I need to make the most of it. I don't know what to expect and, to be frank, I am a newbie when it comes to FPGA's and digital design. But I still have some experience, enough to know that I find this subject interesting and would like to pursue a career in it or its related fields. I've ordered a recent book that should arrive within a week or so, "Digital System Design with FPGA: Implementation Using Verilog and VHDL" which I hope will give me more insight into good practices and so on. For all of you who have a lot of experience, what would you ask if you were hiring, and what would you like to hear? I'm not looking for a cheat sheet, but rather I'd like to know what's really important and what I should focus my attention to. (For instance, @D@n taught me to always keep my processes synchronized to the same clock) (@hamster also being very knowledgeable and helpful)
  14. Make sure you understand the problem first, as it can be daunting to begin with. It's really simple though, when everything is said and done. The datasheet will inform you on which segments light up to form a character, like a 3 or A for example. Now, all segments will display the same information, 3 or A or whatever, so it's up to you to turn on only the relevand digit position for that character, so you "sweep" over the display in very rapid succession. For my project on the Basys 3 I split up every character to 4 bits (I wanted hexadecimal notation), made a decoder (simple case-statement list) to produce the specific bit combination depending on which number to display. Then a way to switch position to light up and what information to send to the decoder as a result.
  15. Okay, I did make some progress just now. Seems Vivado had bugged out and added an enable-pin which I didn't agree to. I removed it and now it works again. Get your act together Xilinx! Ah, seems the Block Memory Generator cannot produce a "low power"-implementation without the enb-reset pin enabled, or something. That explains it. It added it automatically and when I swapped back it did not remove the enb pin again.