[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Parallella Community • View topic - OH.

OH.

Using Zynq Programmable Logic and Xilinx tools to create custom board configurations

OH.

Postby peteasa » Sat Oct 24, 2015 7:47 pm

I have reviewed the top level code at https://github.com/parallella/oh and have a couple of questions. Thought I would start a new thread to capture any such discussions in the future, thus the simple subject line!

I was particularly interested in the emailbox part of the design and looked for a test to verify the operation of that. My question: is there a set of test.memh files that people have used to test out various parts of the design? The one published in github is for the burst transfers, perhaps there are others not yet published that might make up a design verification test run.

The top level elink verification script seems to have three main paths (test.memh data -> model_fifo -> elink_ref, test.memh data -> axi_fifo -> tx_emaxi -> axi_elink & loopback via emem2, test.memh data -> elink0 -> elink1 & return via emem). Only one of these paths returns dut_packet data to the top level.. not looked yet at the emesh_monitor.. the comments in emaxi tx_emaxi indicate that the txrr return data is not yet monitored. My question: is there a description (ie a paragraph or two) anywhere of the end goal for the tests for these three paths?

The simulation I ran seem to work quite well except that at about 2us into the simulation several of the signals go undefined that then results in things grinding to a halt... Seems to be caused because in erx_io the sampling is not correctly initialized...rx_sample is never zero'ed in reset.. could be fixed by using erx_io_reset to clear the rx_sample... but this type of thing must have been part of the original elink.. so perhaps I have this wrong. Oh! Too many questions I know!

Peter.
User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm

Re: OH.

Postby aolofsson » Wed Oct 28, 2015 12:26 am

Peter,
Thanks for trying the simulation! I realized the testbench is a bit of a mess. I will spend Thursday this week doing some updates to the elink and will add some better descriptions.
Will also check to make sure I checked in all changes. The simulation should work....
Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: OH.

Postby peteasa » Wed Oct 28, 2015 9:04 pm

The latest problem I am having seems to be that etx_core.txrd_wait (txrd_fifo_wait) is synchronised with tx_lclk_div4 but is combined with etx_fifo.txrd_access that is synchronised with sys_clk and because the two clocks are a bit out of sync with each other the txrd_fifo produces rubbish output every now and then! Quick way to work round the problem is to change the tx_io_wait timing in etx_io.. that looked a bit odd because it is not 1:1 (cycle4 and cycle7) rather than 1:1 with cycle3 and cycle7. Better fix would be to get the signals sync'ed with the same clock.
User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm

Re: OH.

Postby peteasa » Fri Oct 30, 2015 4:21 pm

Ah good got the burst simulation working. I reverted back to the original code and re-applied my changes with care, now that I know a bit more about how it works.. and the burst works. The timing on etx.etx_fifo.wait_in being sync'ed with tx_lclk still seems a bit suspicious.. if its a real problem I might have a fix for that.

Also I have managed to get the axi_elink path to work by inserting a dummy read a couple of steps into the test (rather than write * 15.. I did write * 2 read * 1 write * 13) without the additional read transaction the axi_elink path just stops operating and you get nothing out of the s_axi_rdata. Not sure if this is due to the test environment or a real problem.

Now I will try out a few more tests to exercise other bits of the design to see what happens. Started on the mailbox and got it to fill. I cant see in the test environment how to read the mailbox (but I can patch the production code to allow me to see the read in operation). Perhaps the remap part would allow me to test the mailbox without changing the production code?
User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm

Re: OH.

Postby peteasa » Mon Nov 30, 2015 10:39 pm

User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm


Return to FPGA Design

Who is online

Users browsing this forum: No registered users and 7 guests