Writing Bitstream into file: VHDL/Verilog

Hi,

Is it possible to write bitstream (data width of lets say 4 bits i.e. std_logic_vector(3 downto 0))coming from some ports/pins of FPGA (lets say from some GPIO pins/Switch etc) into a file after some processing in FPGA using VHDL/Verilog?

I need it for test purpose.

Any help please.

If you have a bit file it would be a lot easier to just use a computer and read the file off the HDD and process it with your favorite language and write the processed data back to the HDD. Why involve an FPGA and VHDL/Verilog into the mix. Connecting a FPGA to a HDD to write some inputs into a file isn't going to be a trivial project.

ads-ee said:

Why involve an FPGA and VHDL/Verilog into the mix. Connecting a FPGA to a HDD to write some inputs into a file isn't going to be a trivial project.

Click to expand...

Thanks for the suggestion.

I am using RGMII TSE MAC (Ethernet). I have 4 bit data stream coming from PC to FPGA at both rising and falling edge of rx_clk.
I would like to analyze the received data.

Alternatively I put signal Tap II logic analyzer(Quartus) at RX_port of TSE MAC but I can see data only at one edge of clock(and not at both rising and falling edge of clock). May be it is limitation of this tool (signal Tap II logic analyzer).

Therefore I wanted to write coming data into file and analyze the data.

Is there any other alternative way for this purpose?

Any suggestion please?

Alternatively I put signal Tap II logic analyzer(Quartus) at RX_port of TSE MAC but I can see data only at one edge of clock(and not at both rising and falling edge of clock). May be it is limitation of this tool (signal Tap II logic analyzer).

Therefore I wanted to write coming data into file and analyze the data.

Click to expand...

I don't get the reasoning behind "therefore".

The limitation is in the operation of FPGA registers and block RAM that is clocked on a single edge. Any logic writing data to a "file" will have similar restrictions.

In cases where you want to analyze data with higher resolution, you'll operate SignalTap or whatever you're using to acquire the data at a higher clock rate which can be easily generated by an on-chip PLL. Of course the maximum core clock is a limitation.

You can also add registers to latch data at both edges and acquire it in two streams.

beginner_EDA said:

I am using RGMII TSE MAC (Ethernet). I have 4 bit data stream coming from PC to FPGA at both rising and falling edge of rx_clk.
I would like to analyze the received data.

Alternatively I put signal Tap II logic analyzer(Quartus) at RX_port of TSE MAC but I can see data only at one edge of clock(and not at both rising and falling edge of clock). May be it is limitation of this tool (signal Tap II logic analyzer).

Click to expand...

The why don't you find where the data width is widened to 8-bits on a single clock edge. I'm certain that the double data rate 4-bit input doesn't stay that way for long inside the FPGA. I suspect that the very first registers past the I/O are the rising/falling registers and that immediately gets converted to a single clock edge register of 8-bits. You can then signalTAP that data and export the data to a file.

FvM said:

In cases where you want to analyze data with higher resolution, you'll operate SignalTap at a higher clock rate which can be easily generated by an on-chip PLL. Of course the maximum core clock is a limitation.

You can also add registers to latch data at both edges and acquire it in two streams.

Click to expand...

If I understood correctly, does it mean following:
I have 4 bit data stream acquisition at both rising and falling edge of rx_clock at 125 MHz. Then considering your suggestion, generate 250 MHz (double of previous) on chip PLL clock and perform data acquisition at only rising edge of this 250 MHz generated clock and use the signal tap to test the data. it sounds feasible but I guess there may be synchronization problem of generated clock and data acquisition.
or did I misunderstood?

Double clocking is one option. The clock can be aligned respectively to meet the timing requirements. I agree however with ads_ee's comment that the parallel data may be available after 8-bit conversion in a different design location. So everything depends on what you want to achieve.