Hi,
Thank you very much Jack.
Is there a documentation regarding the oneGbE and tenGbE packages where
those interactions between the Ethernet blocks and the ROACH2 CPU are
explained?
Just curious, is there any way to send GbE packages without the tap_sart,
using the fabric configuration only? I am trying to learn how these
interfaces work and I feel I am missing something.
thanks,
XB
On Thu, Jun 22, 2017 at 12:46 PM Jack Hickish <jackhick...@gmail.com> wrote:
> Hi Xavier,
>
> Yeah, that's a bug. I'll have a fix shortly, but for now I would just
> leave the RX/TX CPU interfaces enabled. This is probably not a bad idea
> anyway -- the CPU interfaces are distinct from the interfaces which you see
> in simulink -- they allow the core to offload packets that aren't destined
> for your simulink design to the ROACH2's CPU, which can handle things like
> ARP so that you don't need to manually specify the MAC address of whatever
> device you want to send data to.
> In my opinion the only reason not to enable the CPU interfaces is if they
> negatively impact your timing / resource utilization. Sometimes it's nice
> not to worry about things like arp traffic on the network, but even if the
> interfaces are compiled in to your design, they won't send any packets
> unless you do a tap_start call via katcp.
>
> Cheers
> Jack
>
>
> On Thu, 22 Jun 2017 at 11:25 Xavier Bosch <bruixa.aburrid...@gmail.com>
> wrote:
>
>> Hi,
>> I managed to compile and synthesize the project using the one_GbE "yellow
>> block". It worked when I unchecked the "Disable CPU Rx" option, see
>> attached schreenshot. I am using the board only for transmitting so, I
>> thought it was a good idea to disable the receiving part of the block. The
>> same project but with this option enabled it crashes. The first error is:
>>
>>
>>
>>
>>
>>
>> *Mapping design into LUTs...ERROR:MapLib:979 - LUT5 symbol
>> "epb_opb_bridge_inst/epb_opb_bridge_inst/opb_reply1" (output
>> signal=epb_opb_bridge_inst/epb_opb_bridge_inst/opb_reply) has input
>> signal "opb0_OPB_retry" which will be trimmed. See Section 5 of the Map
>> Report File for details about why the input signal will become undriven.*
>>
>> Not sure if that "Disable CPU Rx" option requires further selection in
>> the configuration panel to work properly. i.e.: I am configuring the block
>> wrong, or the "yellow block" has a problem.
>>
>> If it is of any help, I am using mlib_devel master branch commit
>> 225aa9ed21aa914078546d2256c56f77f912c90a from Wed Apr 19 09:49:41 2017
>>
>> Thank you,
>> XB
>>
>>
>>
>> On Tue, Jun 20, 2017 at 2:59 PM Jack Hickish <jackhick...@gmail.com>
>> wrote:
>>
>>> Oh good!
>>>
>>> Which mlib devel repository are you using? If you scroll up through the
>>> errors, can you find the first error message, and does it say anything
>>> useful?
>>>
>>> Cheers
>>>
>>>
>>> Jack
>>>
>>> On Tue, Jun 20, 2017, 2:56 PM Xavier Bosch <bruixa.aburrid...@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>> Thank you Jack for your reply I followed your advice and tested the
>>>> one_gbe "yellow block". It does not give me an error in the compilation but
>>>> it does in the synthesis using XPS.
>>>> At the beginning of the compilation it says that:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *############################### Block objects creation
>>>> ###############################misc_ports = app_clk: {[1] 'in'
>>>> 'sys_clk'} mac_tx_rst: {[1] 'in'
>>>> 'one_geb_xb_one_GbE_app_tx_rst'}misc_ports = app_clk: {[1] 'in'
>>>> 'sys_clk'} mac_tx_rst: {[1] 'in' 'one_geb_xb_one_GbE_app_tx_rst'}
>>>> mac_rx_rst: {[1] 'in' 'one_geb_xb_one_GbE_app_rx_rst'}*
>>>>
>>>> and after a while it gives the following error:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Error found in mapping process, exiting...Errors found during the
>>>> mapping phase. Please see map report file for moredetails. Output files
>>>> will not be written.Design Summary--------------Number of errors :
>>>> 86Number of warnings : 4ERROR:Xflow - Program map returned error code 2.
>>>> Aborting flow execution...gmake: *** [__xps/system_routed] Error 1ERROR:EDK
>>>> - Error while running "gmake -f system.make bits".: XPS failed.*
>>>>
>>>> Any idea what I could be doing wrong?
>>>> Has anyone worked with that "yellow block" recently?
>>>> Is there any example available?
>>>> Thank you,
>>>> XB
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 19, 2017 at 4:43 PM Jack Hickish <jackhick...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Xavier,
>>>>>
>>>>> The ROACH2 (unlike the ROACH1) has a dedicated 1GbE connection
>>>>> straight to the FPGA fabric -- it's the "other" RJ45 connector in addition
>>>>> to the one you're using to talk katcp. You can access it using the one_gbe
>>>>> yellow block -- I think this is probably the way to go.
>>>>>
>>>>> Cheers
>>>>> Jack
>>>>>
>>>>> On Mon, 19 Jun 2017 at 16:39 Xavier Bosch <bruixa.aburrid...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a system that generates ~100 Mbit/s data throughput in a
>>>>>> ROACH2 board.
>>>>>>
>>>>>> Until now I have been using the KATCP and software registers to read
>>>>>> those values at a much smaller data rate. The only option that I found in
>>>>>> the documentation to use the design at full resolution are the 10 GbE
>>>>>> boards, that we already have in hand. The 10 GbE boards look to me that
>>>>>> is
>>>>>> a little overkill for what I would like to do. Is there any other method
>>>>>> to
>>>>>> get data out from a ROACH2 board faster than the software register but
>>>>>> slower than the 10 GbE boards?
>>>>>>
>>>>>> I am thinking in something like an USB 2.0 port (max 480 Mbit/s) or
>>>>>> a 1GbE connection.
>>>>>>
>>>>>> Thank you,
>>>>>> XB
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "casper@lists.berkeley.edu" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to casper+unsubscr...@lists.berkeley.edu.
>>>>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.
