Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
No FPGA 'contains' soft IP.. it's up to you to design anything and program it into the FPGA. You can run a soft IP processor in any FPGA (as long as the design fits).
Yes! Subject to size constraints - it might not be possible on the absolute smallest FPGA device.
That'll be completely up to...
Pros: You can develop the architecture exactly how you want
Cons: You waste loads of time, when an existing core could have done everything for you
What do you think the distinction between a microprocessor and a microcontroller is? Traditionally, a processor was a chip that had few peripherals...
Actually, given the requirements you've listed, pretty much any FPGA will be able to handle this.
If you need to be able to input and output all 128 bits of data in parallel, then you'll want one that has at least 128 I/O pins. If you have a high data rate requirement, you might need to...
The difference between the two methods is very important for good FPGA design. When you use the clk'event method, the synthesis tool wants to use the signal to drive the clock input of a flip-flop. The warning occurs because the pin your signal is coming from is not a GCLK (global clock) input...
You are using signal'event in place of a proper edge detection circuit. The CLOCK_DEDICATED_ROUTE workaround will fix synthesis, but it will leave you with clock domain crossing issues. Plus this is very bad design practice. Here's a guide on doing edge detection in VHDL: **broken link removed**...
I don't think this is the best way to go about it - you have three clock domains (cam_vsync: falling edge, cam_href: rising edge, and cam_pclk: rising edge). I would be surprised if you didn't get loads of warnings when trying to synthesise this code.
Just use one clock domain (cam_pclk) with...
No, I still don't think that will work. As I said before, you should use the sync signals to reset your counters.
As it is, your design assumes that the FPGA and sensor are perfectly in sync when they turn on and remain so forever. This isn't a good assumption to make in practice - if the...
Treating all incoming inputs as clocks is the wrong way to think about FPGA design. You should bring VSYNC and HREF into the same clock domain as PCLK by registering them. You should then detect rising edges by using two flip flops as a shift register and checking that the first flip flop is...
It's not really clear to me how you're capturing the same picture each time.. even if you don't move the camera or subject, the picture won't be exactly the same every time due to changing light conditions or random noise. If you're able to see an output on an LCD, can you deduce anything from...
I haven't used the Virtex-6 MIG so I can't tell you for sure. The MIG is different for every FPGA family, but I think that if you are already familiar with Xilinx cores in general and HDL you shouldn't have much trouble moving from one MIG to another, at least if you are building a design from...
I doubt it'll be a big deal. If you're concerned, you could use an oscilloscope to see if there's much cross talk. For the types of applications the BASYS2 is intended for (i.e., you are not going to be using it for communications in the gigabit per second range, because it doesn't have any I/O...
It depends on the nature of the signal you're routing near the oscillator.
A low level (analog) RF signal? Forget it. A digital output to an LED? It'll probably be fine.
You haven't given us a lot to go on. How do you know that the signals are 'working fine'? Obviously something is not right if the display isn't working.
Here are the things I would check:
- Is your design's timing properly constrained? For both the system clock and the module's setup and hold...
What's the design you're using? Something you've written yourself, or have you converted the Atlys/Nexys 3 demo project?
Are you sure the UCF is correct? Does your simulation show that you're sending the correct signals to the display?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.