-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data Stream in/out SoC <-> FPGA #391
Comments
Hi,
Yes right, that's not the way to go.
Yes, serializing things is a better tradeoff i think, then eventualy buffering things into a Mem (ram) for later reuse. |
Thank you @Dolu1990 , Apb3Axis is connected in the main SoC scala code, the Apb3Axis class looks like above
main C sample code is below
then the verilog top function syntetized
|
I was able to make it works, but I've performance problem. So, first. How i make this work using readStreamNonBlocking and createAndDriveFlow, using a 31 bit payload. Apb3Axis looks now like below:
software side (almost like below) - notice I'm using a Gpio output to check the timing on the the analyzer
Verilog side
Code above works with StreamFifo and .queue. I've find no difference using that or the LowLatency one. In the future I'm going to use a payload of 31 bit, then I'll put a command in the first 7 bit, and use the other 24 for data. My problem is about performance. I've try StreamFifo and .queue instead of queueLowLatency and StreamFifoLowLatency but it makes not difference. StreamFifo and .queue instead of queueLowLatency and StreamFifoLowLatency makes not difference. Running the SoC at 72Mhz or 12Mhz makes not difference. FPGA/Briey and busses (AXI+APB3) are all running within the same clock domain). Do I miss something? Note for image (here I'm using a payload that contains a command in the first 7 bit, and use the other 24 for data). Writing data back to output 'AXIS->OUT_PAYLOAD = xxx ' makes no difference in timing, that means SoC to FPGA is fast. It's just the input a little too slow for me. Thanks for help. |
Hi, looking at your simulation, it show things from time 0 right ? |
Thank you @Dolu1990 Zoomed in the other image the a load (uint32_t payload = AXIS->IN_PAYLOAD;) + unload (AXIS->OUT_PAYLOAD = data;) timing. Maybe something involving DMA can help? I know I'm asking a lot from this core. My plan is to make this works on VexRiscV (even at slower speed), cause I like this project (portable and customizable), then when I'll be ready maybe moving to an hardware core (xilinx ARM) changing the busses of course. Verilog below contains the actual payload content (signal number + integer), and will clarify it to you:
|
Hmm, one thing to be carefull about aswell, is that the first attempt you will hit i$ d$ refills, so to take mesurements, you realy have to run the code more than once, and then take mesurment of the last execution. Are your picture from the very first execution ? |
Hello,
I'm building a softcore based on Briey.
I've the AxiCrossbar without Sdram and on the APB3Bridge 1 Timer, 1 UartCtrl, 1 Gpio.
On the APB3 I would like to add a custom Ctrl to transfer in and output data stream.
I've to transfer 32x24bit data in + 32x16bit data output, and do some simple (for now) math inside the SoC on that stream.
I've try setting a Vector of Bits and now I'm trying Axi4Stream, based on that code here: #53
In both options (Vector and Axi4Stream), I've a couple of issue, before moving to issues, I would like to ask you which could be a good option.
As far as I understand using Vec means using more LUT cause all the signals have to be synthetized, but this way I can read and drive signals in a few clock. Indeed using the Axi Stream is a bit slower, but use less LUT, am I right?
Depending on your suggestion I'll ask questions, thanks!
The text was updated successfully, but these errors were encountered: