Besides what Klaus states you'll also have to use a protocol that transmits the address prior to the data transfer either sending data (write) or receiving data (read).
I defined some signals as registers to stores some values in. I would like to know how is it possible to readback the content of those signals (registers) from FPGA back to PC??
Given the lack of information in this statement and the lack of clarification from the OP, I suspect maybe they want the hardware equivalent of a printf in C.
Which if so the best solution is vGoodtimes, polled send on state change UART suggestion. If they lack design skills to implement this then using Chipscope (Xilinx SignalTap equivalent) to monitor the registers would work. Note, adding a signal that pulses high on state change would be advisable so that you can use that as the capture qualification in Chipscope.
I explained what I want to do in my previous comment for you !
I am sending a command via UART from PC to a specific address in FPGA and now I want to read back the content of that address from FPGA to PC. That's all... is it possible through activation of another UART (I have 2 uart ports on my board) or JTAG interface?
This statement and your original don't say the exact same things (understandable as it's unlikely English is your primary language). This now explicitly states the PC->FPGA connection is used to send commands to the registers (updating them?) and you want to read those registers later FPGA->PC.
Probably less headache to use both UART ports. One is the command/status port, send commands, read/write register, etc. You can have 256 separate commands, or beak it into fields and have less commands with some commands having an address field. e.g. 5-bit command+3-bit address. Then use the other UART to transfer the data bytes write/read
Uh, I'm not designing this for you. You're supposed to be designing it. Come up with a protocol to handshake the transfer, either using a single UART or both, but you have to either find a standard solution (which I've never seen) or just make one up.If I want to read back a content of an address from FPGA --> PC, how should I configure it?
I was suggesting using both UARTs one specifically with command information e.g.:
write command (00000) at address (000): 0x00
read command (00001) at address (010): 0x0a
etc...
and a separate data UART.
Uh, I'm not designing this for you. You're supposed to be designing it. Come up with a protocol to handshake the transfer, either using a single UART or both, but you have to either find a standard solution (which I've never seen) or just make one up.
One option is to just have a data FIFO in the FPGA connected to one UART and send the bytes to that UART from the PC for writes. The other UART1 is used to determine where the bytes that are now stored in the UART2's FIFO go using the decoded command and address fields.
Reads do something similar, send the read commands and they get stuffed into the UART2 transmit FIFO and are sent to the PC.
Of course I just made this protocol up in the last 5 min, so it might be rubbish. ;-)
- - - Updated - - -
ARRGH, dpaul wish I'd notice this duplicate thread S**T earlier.
USE THE SEM CORE FROM XILINX. The example design generated already has a protocol for this command interface. The SEM core reads frames in error, you might be able to latch onto the ICAP to separately capture the frames as they get read out, but most of that core is made up of encrypted files. Once you've captured a frame (in a FIFO?) you can send it out a UART.
You do know that using the SEM and accessing the FPGA configuration frame data is..an EXTREMELY ADVANCED FPGA topic.
Here is my PC uart_rx pin ------> UART_RECEIVE -------> RECEIVE_FIFO ------ Here is FPGA
---------------------> TRANSMIT FIFO --------------------> UART_TRANSMIT -------------> uart_tx pin
Here is FPGA [/COLOR][/B] uart2_tx ---------> TRANSMIT_FIFO ---------> UART_TRANSMIT ----- Here is my PC
UART_RECEIVE ----------> RECEIVE_FIFO ------------> uart2_rx
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?