I have an FPGA which accepts an 8-bit address and data bus (one bus is used for both) from two microcontrollers.
Using a 2:1 multiplexer, my FPGA only selects one device's inputs at a time (address and data) and the selection is based on an external signal to the FPGA.
I also have a separate decoder and register module which the microcontroller reads and writes to. How do I link the bidirectional output signal from my multiplexer to the decoder/register bidirectional input module at the higher level using the port map assignment?
Using a std_logic_vector(7..0), it will not work as I get an error "this signal is connected to multiple drivers". I think I need to tri-state the two, but I'm not sure. Looking at the image below, the green circle is what I'm trying to glue together.
My FPGA project
You are right in thinking you need to tri-state, but this is needed at the edge of the FPGA, i.e., on the I/O pins.
You cannot have bidirectional ports inside an FPGA. So for each bidirectional pin you have three signals, incoming outgoing and a direction. If all pins always have the same direction you can use the same signal for all.
For you this means you don't need to multiplex the incoming signals as they can be split (one signal to multiple instances), but you need one for the outgoing signals (multiple instances to one signal).
Related
I need to realize point-to-point multigigabit connection between two FPGAs. For that I can use 4x6.25Gbps serial lines, and transport the data over optical link. The problem is, that the connection - realized over those 4 optical lanes - must look as single point-to-point channel (so single channel with >20Gbps).
The lanes assembly is exactly what for example JESD204B/C does when connecting fast ADC or DAC to the FPGA through HSSI.
I was wondering, whether an instantiated JESD204B ip core on two distant FPGAs is able to assemble a channel composed of 4 lines and function as a transport channel for the data.
I somehow feel, that the problem might occur during synchronization phase, because the two IP cores always act as masters and they expect a component (ADC or DAC) to be attached for the synchronization.
The link shall be established between Intel and Xilinx FPGAs.
My project goal is to design a 'heart rate module' using zed board and ppg sensor.
I'm going to use Pmod as ADC for converting the analog signal from the ppg sensor to the digital signal so that the zedboard would be able to process it.
there is a problem at this point.
my module gets a '12-bit signal' as input,
but I found out that the Pmod provides the digital output in serial peripheral protocol.
the input of the module has 12-bit range, but the output of pmod(which will be connected the module as a module input) is only 1-bit range.
I think their bit range differs, which shouldn't
how can I solve this problem?
Assuming that I have understood your problem correctly, you need to design a Deserialiser module. The most common way of doing this is by creating a Shift Register.
The Shift Register operates by shifting serial data in, 1 bit at a time. When enough bits have been shifted in (determined by your application) you can shift the contents of the register out in a parallel shift. You now have parallel data.
But wait, it may not be that easy for you. You mentioned that the device you are using communicates via a SPI bus. Unless you have a SPI module that is helpfully outputting serial data (and telling your register when to shift) then you need also design some SPI compliant logic. Don't forget to pay attention to the timing requirements of the SPI port.
I want to send signals (doesn't matter what type of signal, just random binary) over MGT lanes of a Xilinx FPGA. This is for testing the MGT traces on the PCB. What is the simplest way I can achieve this? For a regular IO I would simply use an output buffer (OBUF) and send out the signal to the output pins. What would be the equivalent of this (or the simplest equivalent of this) for MGT bank pins?
EDIT:
I want to stay away from ipcores as much as possible. I'm looking for a really simple solution to somehow buffer signals to MGT pins.
If you have both TX and RX lanes then I would suggest to perform loopback test. FPGA would produce data on TX link, receive it on RX and compare results.
To do so you can connect TX lanes to RX lanes on PCB connector and use FPGA Ibert core that will automatically create transmit, receive and compare circuits and produce nice results for each lane.
For 7 series here is the link to Ibert core
http://www.xilinx.com/products/intellectual-property/ibert_7series_gtx.html
For other families Ibert is also available.
In atmega128, what is the difference between assigning internal pull-ups and not assigning pull-up when port is used as input ? I don't see the point of assigning pull-up when using port as input..
Sometimes your input won't have an output connected to it. By enabling the internal pull up, you guarantee the input will be read as high in that condition. Without the pull up, the input would just be "floating".
In atmega128, what is the difference between assigning internal pull-ups and not assigning pull-up when port is used as input ? I don't see the point of assigning pull-up when using port as input.
If there is a component connected to the input that is always actively driving the line to either low or high, you won't require a pull-up/down. You use pull-up/down resistors to ensure a well-defined logical level under all conditions.
The simplest example is an unconnected input pin of a micro controller. It would be "floating" without a pull-up/down weakly driving it to a specific level.
Consider this circuit:
Lets assume that C is the input to your micro controller and Vin is controlled by a mechanical switch. If Vin is 0V/open, the transistor is switched off. If you wouldn't use the pull-up resistor Rc (which could be the internal pull-up of your controller), the input C would be floating. Rc also serves a a current limiter when the transistor is switched on.
You need to connect either PullUp or PullDown. So if you are ok with a PullUp, they're already there and you can spare external resistors for that matter.
If you need PullDown, you have to connect resistors externally.
I have designed an Asynchrounous asymmetric fifo using VHDL constructs.It is generic fifo with depth and prog_full as parameters. It has 32-bit in 16-bit output data width.
You can find the fifo design link here.
The top level asymmetric fifo (fifo_wrapper.vhd),is built upon an 32-bit asynchronous fifo(async_fifo.vhd). This internal fifo (async_fifo) is build using the logic from generic FIFO on open cores (http://opencores.org/project,generic_fifos). I have added a simple testbench to try out this fifo design.
BUT there is some issue with this design that I am not able to figure out. The fifo design works perfectly fine when I simulate it, but when I synthesize it and run It along with my other design on hardware I get some erroneous data sometimes. May be there is some corner case that I am not able to simulate or Is it some thing else?
That's why I would like anyone who needs this design to try it and let me know if he/she encounters any Issues during simulation or after synthesis.
thanks
PS: kindly let me know if there is some other forum where I can put my design for public use. thanks
There are a number of issues to point out in relation to this asynchronous FIFO
design, based on the assumption that the write and read clocks are fully
asynchronous.
A (and probably THE) major problem is that the write side pointer (wp in
async_fifo), which is a normal binary counter, is transfered and synchronized
to the read side clock without any Gray encoding. So the different bits in
the vector may arrive at different time in the read clock domain, thus the
write pointer value can (and most likely will from time to time) be different
from the write side value. The comparison with the read pointer (rp) will
therefore make no sense. Binary values that are transfered over clock
domains should be Gray encoded before transfer and decoded at arrival. Also
use synchronization with two flip-flop levels.
The two clocks (rd_clk and wr_clk) are assumed to be asynchronous, but there
is only a single reset (rst), so timing may be violated when reset is
deasserted, unless there are some additional requirements for clocking at the
time of reset deassert.
An similar with clear, where there is only one signal for use in two
different clock domains.
Suggestion would be to use a port naming convention where the clock domain
relationship for the port is cleared indicated in the name, like naming all
the ports in the write clock domain wr_* (e.g. wr_clk_i, wr_clk_we_i, etc.,
and all the ports in the read clock domain as rd_*.
Reset is asserted low, so a naming of rst_n would be nice.
n'I can't access your code (firewall) so I'll just mention the general points in designing them, which might be of help to you and others.
to be completely clock safe, the write side should exchange its pointer to the read side using a fully safe asynchronous handshaking method using 2 meta-stability signalling chains.
This contruct for this is a double buffered register.
The write side registers its write pointer into a buffer, and asserts a valid signal high.
A meta-stability chain reclocks the buffer valid signal to the read clock domain
On the read clock side, once a transition to high of valid is seen at the output of the meta chain, the data in the write side buffer is reregistered onto another register on the read domain. This is ok, because it is known that the data in the buffer is stable. (because of the meta chain).
The read domain asserts an ack signal high.
Another meta-stability chain reclocks the ack signal to the write clock domain.
The write side awaits a transition of the ack signal at the output of the meta chain, once seen it deasserts its valid signal.
The read side awaits a transition of the valid signal at the output of the meta chain to low, once seen it deasserts its ack signal.
The write side awaits a transition of the ack signal at the output of the meta chain to low. The cycle is now complete.
The current write pointer, which may have moved on quite a bit now, may now be transferred again.
A similar approach is taken for transferring the read pointer to the write domain.
It can be seen that although this approach leads to a latency between the write pointer on the write/ read side, and the read pointer on the read / write side, that this latency can never lead to overflow. Instead it leads to a premature full on the write side, adn a premature empty on the read side, which will eventually resolve once the pointers are next exchanged.
This approach is the only completely clock safe design for a fifo that doesn't depend on a-priori knowledge of the clock speeds. Gray coding is not required at all.
The other thing to note is that the logic for addressing / empty / full etc. needs to be duplicated on each clock domain.