Tag Info

New answers tagged

3

I would suggest a LFSR (Linear feedback shift register). This is a pseudo random number generator. See wikipedia for details about what a LFSR is. The only thing you have to store is the initialization vector that has to be different for each game. For instance: You have two LFSR of 32 bits. (The LSB of each LFSR register are the output of the LFSR ...


2

Since the sequence of lights/tones is going to be different each time you play the game, you should be thinking in terms of storing that sequence in a memory (block RAM inside the FPGA), so that you can read it out repeatedly, both for prompting the user and for checking their response. You will also need a state machine, but this machine will be more about ...


0

The advice to use the SPI clock to handle the SPI shift register is correct and saves you the bother of trying to oversample properly. One gotcha is in how you transfer that parallel register into another domain. DO NOT use a simple two stage FF synchronizer for each bit as you would for a solitary signal. If you use the FF synchronizers there is a real risk ...


0

I think you have to synchronize the loading of the data slot with the SYNC signal from the AC97. Also you need to wait until the codec is ready before sending it data. The codec sends a ready signal in bit 15 of slot0.


2

You do not need to have access to the VHDL or Verilog files for this project, what you need to do is to do a simple search for the error you get and find the information in the documentation provided by Altera. This parameter is something you have to provide to the procedure call. #include "sys/alt_flash.h" And you replace EXT_FLASH_NAME with the ...


1

Some important links: Board datasheet: http://www.digilentinc.com/Data/Products/BASYS2/Basys2_rm.pdf Board schematic: http://www.digilentinc.com/Data/Products/BASYS2/Basys2_sch.pdf FPGA datasheet: http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf I assume that you are talking about the I/O pins on JA, JB, JC, or JD. If you are asking ...


1

A picture here would be really good to understand your setup. First: Crosstalk is inductively and/or capacitively coupled. If your wires are just individual widely spaced wires in the air, you most likely do not have much of either. At that length you will have reflections if you don't manage that correctly. Reflections can easily cause double-clocking. ...


2

Some things I'd try: Use the slowest drive you can get away with. At these clock rates, you should be able to use very slow drivers. You don't mention a specific FPGA type, but if it were Xilinx, I'd be using the "quiet" drivers, or "slow" if not available, and a 4mA drive current. See how it looks on the scope, increase the drive current if necessary. ...


0

That tutorial is for a different board. In particular, it appears from the Trenz docs that their board is emulating a Digilent JTAG cable, not a Xilinx one. I'm not sure that is automatically recognized by the "Auto Detect" option shown in Fig38 of the tutorial you are using - or even whether it is supported by Vivado at all... I would suggest you try ...


6

A divider is a series of subtractions and multiplexers that select the value for the next step. If it is done purely combinatorially, then the critical path through all of this logic is quite long (even with carry lookahead on the subtractors) and the clock cycle must be very slow. But the process is easy to pipeline, and the number of pipeline stages you ...


1

You're unlikely to be able to synthesise connecting your tristate I2C line via a process like that. I would do this (I'm assuming you already have SDA_IN and SDA_OUT signals which you are currently using to create your SDA)... LED_or_SDA <= gpio_reg when register = '0' else '0' when register = '1' and I2C_SDA_OUT = '0' else 'Z'; ...


2

Your second "FSM" code has many problems, primarily in the last process — process (current_s, input). Just a few examples to start with: This is an asynchronous process, so you must list all of the signals used inside of it in the sensitivity list. Failing to do this means that the simulation will not match the behavior of the actual hardware. Since ...


1

Take the following VHDL design description: library ieee; use ieee.std_logic_1164.all; entity bidir is port ( Z : inout std_logic; Y : out std_logic; OE : in std_logic; A : in std_logic ); end; architecture behave of bidir is begin Z <= A when OE = '1' else 'Z' when OE = '0' else ...


5

Software simulations run slower than the hardware does. It's just a fact of life. In exchange, you get incredible visibility into the details of the logic for debugging. For example, on the moderate-complexity designs that I've done recently, I find that the simulation runs about 1/1000 as fast as the hardware — in other words, it takes 1 second to ...


1

Most FPGAs do not have internal tri-state buffers except at the IOB (I use Xilinx terms). Therefore it is recommended to put all inout signals at the top-level (with the associated 'Z' driving logic), and use plain old in and out ports throughout your design. In fact, given an inout port "DataBus", I create signals "DataBus_in" and "DataBus_out". ...


2

Speaking from experience... Many years back my company was experimenting with a low-volume FPGA application. At the time there were no production boards that met our needs and because of time pressures it wasn't feasible to design our own. We ended up going with a demo board produced by a well known Xilinx distributor. The biggest negative we encountered ...


1

There is no fundamental reason why an inout pin cannot be used as a simple output...just ignore the input signal. I suspect your problem is in the actual VHDL code (rather than the version you posted) or in the details of how you are implementing the design on an FPGA.


2

You'll probably have to use HDL coder to create a sub-block with all your detailed processing in, and use the Altera tools to create you a PLL to multiply up your clock. Then build a top-level VHDL or Verilog file with the pins on it. Inside that you can instantiate your PLL and processing logic and wire them together. It's very rare you can use a tool ...


3

You use one of the on-chip PLLs (there are four of them in your device) to multiply the 50 MHz input clock to something higher, such as 200 MHz. That becomes the sample rate you use for the VGA output.


0

See page 141 of "Section 3" available here for jitter requirements for 1000BASE-SX and 1000BASE-LX Ethernet.


2

You will need to push packets out of your FPGA using a block of HDL code which implements at least some of the Ethernet protocol. If you limit yourself to a point-to-point link, then you should be able to write something fairly simple which will just generate broadcast packets with your data in. You can then work up from there to a more conventional ...


1

You don't have CLKFB connected - I'm surprised you get anything! From the Spartan 3 userguide, UG331 CLKFB Clock feedback input to DCM. The feedback input is required unless the Digital Frequency Synthesis outputs, CLKFX or CLKFX180, are used stand-alone. The source of the CLKFB input must be the CLK0 or CLK2X output from the DCM and the ...


4

If you're serious about this, you need to read UG380, "Spartan-6 FPGA Configuration User Guide". (If it turns out that this isn't the correct FPGA familly, there's a similar document for every family Xilinx produces; just search for it.) The Overview (starting on p. 15) shows that there are several ways to configure a Spartan-6, and JTAG isn't necessarily ...


0

If you take a look at your routed design, you will see that the DCMs inside the SPartan 3A device are placed on the 4 side of the IC. There are 'dedicated' IOs or IOs with easy routing to the GCLKMux available close to those DCMs. In this image you see the 2 DCM and the optimized IOs for those DCM on a SPARTAN 3A device: I don't have access to the ...


2

Basically what it is saying is that there is a fast path (a direct connection) from certain pins into the DCM but for some reason this fast path can't be used. This could be for a number of reasons. If I'm reading the datasheet right, P53 isn't a clock capable pin so there won't be a fast path. You can also get problems if you've LOC'd the DCM to the ...


6

the rising_edge() parameter is only really for clock signals. One option would be the following: clk_proc: process( clk, switch1, switch0 ) begin if switch1 = '1' then counter <= ( others => '0' ); elseif rising_edge( clk ) then if switch0 = '1' then counter <= counter + 1; end if; end if; end ...


1

Since you didn't identify any specific difficulties, here's a quick run-through. If there are points you still don't understand, ask followup questions in the comments below. flipflops is used to create an edge detector; counter_set pulses high every time there's an input transition. (Note that this is poor design — since button is an asynchronous ...


3

Found it! See page 38 of this document.


0

It all depends on what power supply rails you have. If you have a -12V power rail then you could amplify the 3.3Vp-p signal to 12Vp-p and apply a dc offset to centre the output to -4V. This can be done with an op-amp quite easily but, choosing the op-amp depends on how fast the 3.3Vp-p signal is. If it is at 1MHz or above, a little more care has to be taken ...



Top 50 recent answers are included