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.
