• Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

5 Neutral

About treadstone

  • Rank

Profile Information

  • Gender Not Telling
  1. Looks like you might have the voltage threshold set at a different point between the two? Or maybe no ground connected? Sent from my iPhone using Tapatalk
  2. I don't have a Nexsys 3 board but from the schematic the clock coming in on Pin V10 is a 100MHz clock. You can't define it differently in the ucf, even if you do it will still be 100MHz. You need to run it into a DCM and generate the appropriate clock, which looks like it needs to be 20MHz. Use the IP manager in ISE or Vivado to do that, then instantiate it where it tells you to in the top level file (below line 52 in the original, it says -- use a DCM to generate 20Mhz clock required by VGA process)
  3. I finally got to a computer and was able to download your original file and can see some of your problems. 1) You declare the VGA signals correctly in the top level entity on lines 15-17 as std_logic_vector but on lines 26-28 you need to keep VideoR, VideoG and VideoB as std_logic, not std_logic_vectors. This will fix the errors that come up on lines 88, 90 and 93 during synthesis. Change lines 26-28 to this: signal VideoR : std_logic; signal VideoG : std_logic; signal VideoB : std_logic; 2) On line 46 do connect the signal VideoR to each bit of the O_VIDEO_R like this: O_VIDEO_R <= VideoR & VideoR & VideoR; Do the same for the other two colors: O_VIDEO_G <= VideoG & VideoG & VideoG; O_VIDEO_B <= VideoB & VideoB; -- only 2 bits. That should get you through synthesis. Now for the Place & Route, you need to make sure you have the correct signal names in the ucf file. You need to uncomment (remove the leading #) and match the names to the names on your top level entity. For example on the nexys3_master.ucf you need the change line 156 to: NET O_VIDEO_R<0> LOC = "U7" | IOSTANDARD = "LVCMOS33"; do this for all the signals on your top level entity. I think that will get you through all the problems I can see.
  4. I went to google code and looked at the original source your are trying to modify. I don't know what other mods you made but from what I can see the errors you are getting above are caused by the fact that you didn't change the O_VIDEO_x signals into vectors. You are also trying to connect the outputs to the internal signal in some cases, it only works the other way around. Since the top level signals you are trying to make into 2 or 3 bit vectors are defined as std_logic right now if you want to make them 3 bit std_logic_vectors you need to do this: change O_VIDEO_R : out std_logic; to O_VIDEO_R : out std_logic_vector(2 downto 0); in the entity definition (line 15 in the original code). Do the same for the O_VIDEO_G and O_VIDEO_B, if you want them to be 2 bit instead of 3 then define them as std_logic_vector(1 downto 0); then where the O_VIDEO_R is connected to the internal signal in the architecture (line 46 in the original code) connect it like this: O_VIDEO_R <= VideoR & VideoR & VideoR; Do the same thing for G and B. The other thing you have to do is make changes in the constraints file to account for these extra bits. The ucf files have the bits defined already you just need to comment out the original O_VIDEO_R (and G and B ) lines by inserting a pound sign in front of them (#) then remove the pound sign from the front of the lines that you want to connect, like O_VIDEO_R(2), O_VIDEO_R(1), O_VIDEO_R(0) and make sure all the signals are connected to the right pins on the FPGA.
  5. Look up concatenation in an hdl design book, that is what you are trying to do. If you have a std_logic signal x and a 3 bit std_logic_vector y then you do this: y <= x & x & x; to copy the single bit x to each bit of the vector y.
  6. I agree with Jaxartes that when going from one bit to multibit vectors connection of the single bit to all bits of the vector is a better solution, go from zero to full scale. Thanks for correcting that. If you want to go the other way from multibit to one bit you would use just the msbit of the vector as its transition from 0 to 1 represents the mid point. This is only on unsigned of course.
  7. I don't have the code you referenced but I am assuming it is displaying a seven segment on vga. Maybe you are trying to connect the virtual seven segment lines to the vga lines. I believe the errors you are getting are because you are attempting to connect a std_logic_vector to a std_logic signal. If you are trying to connect a one bit vga signal to a three bit you should probably connect the single bit to the msb of the multibit and set the non-msbs to zero.
  8. Speeder I know this doesn't address your last question but one way I have used to look at fast pulses that happen infrequently (like I believe your sync pulse is) is to create a test signal that toggles one time for each pulse. That will need a slower sample rate than is required for a fast pulse on your logic analyzer and may work the way your setup right now. This test signal lets you know that at least something is being generated at the appropriate interval. If you have an oscope you can check a single pulses integrity in a separate test, or maybe use your logic analyzer in a lower channel mode (1 or 3 channels or whatever your lowest setting is) so you can increase your sample rate. Like Jack said, you need a sample rate of at least two times your fastest pulse to see the signal otherwise you will alias.
  9. I don't know the performance deltas for the current state of the art for fpgas versus asics but as the fab process gets smaller and faster for fpgas I have to believe it is closing. Like I mentioned earlier, I think asics make sense when you have a very large production run. I could add I think if you need a very small chip asics make sense. You should consider the latest system on chip as a third leg for consideration. Like Jack mentioned one way things are accelerated in a processor/fpga design is by offloading tasks that are faster in an fpga from the processor. If you don't need to go off chip by keeping your transfers internal on a SoC then you will save time there. Look at the zynq solutions from Xilinx as potential candidates. By the way, there are some books on where the industry has been, I saw a couple on Amazon by searching fpga trading, maybe those will help clarify your needs.
  10. The last time I heard a price to produce an asic it was a few million dollars, they only make sense if you are making a very large number of copies of a design. Say you need 1 million logic devices for a production run and a suitable fpga is $100, that might make sense for an asic which would be $3 million up front then $20 a copy in large quantity. Total investment is $23 million for asic versus $100 million for fpga. A middle ground is the hardcopy asic from altera, they take a device (I think stratix family) and once you have a working design with the stratix fpga altera will convert that to a custom built asic for you. I don't know the cost but remember hearing it was much cheaper/ easier than building an asic from scratch.
  11. I have a couple things to say about this. In general I don't think it makes sense to not initialize your counter. You can either use a reset signal or when you declare the signal assign it to zeros using := (others => '0'). You should do this because it will likely fail the =207 condition and then go to the increment but from what? It is undefined. I think you would get all 'X' in simulation which you should be doing if you have behavioral questions about your design. The initialization will not likely change what you are seeing it is just a better practice. As far as your issue, what are you using for your logic analyzer? What is the sample rate? It sounds like it may be an aliasing problem, make sure you are sampling >2 times your fastest pulse. Do a sim (after initializing sample_counter) and convince yourself it works then figure out what went wrong in hardware.