<shuffle2>
vivado is erroring with [Synth 8-2914] Unsupported RAM template [Synth 8-5743] Unable to infer RAMs due to unsupported pattern.
<shuffle2>
strangely i have 2 memories used in very similar ways, and this only happens with one of them..
rohitksingh has quit [Quit: Leaving.]
<shuffle2>
the other is correctly inferred as "true dual port ram template"
sb0 has joined #m-labs
<GitHub22>
[artiq] sbourdeauducq commented on issue #854: @gkasprow Still no carrier detected at the media converter. Is the PHY rate-converting and still operating at 1Gbps on the SATA connector? https://github.com/m-labs/artiq/issues/854#issuecomment-353521188
<GitHub133>
[artiq] sbourdeauducq commented on issue #854: And it's not a problem with my media converter or SATA/SFP cable, when I plug the SATA cable into the other Sayma with an unflashed MMC, the link is detected. https://github.com/m-labs/artiq/issues/854#issuecomment-353521338
Gurty has quit [Ping timeout: 272 seconds]
<GitHub31>
[artiq] sbourdeauducq commented on issue #854: Still, I'm no stranger to SATA/SFP cable breakage and I'm getting tired of fixing it. Can we have reliable SATA/SFP adapters? @jbqubit can you fund them? It's going to be a problem for everyone until Metlino is done. We can either make our own PCBs or buy those: https://shop.trenz-electronic.de/en/TE0424-01-SFP-2-SATA-Adapter....https://github.com/m-labs/artiq/issues
Gurty has joined #m-labs
<GitHub191>
[artiq] sbourdeauducq commented on issue #854: Still, I'm no stranger to SATA/SFP cable breakage and I'm getting tired of fixing it. Can we have reliable SATA/SFP adapters? @jbqubit can you fund them? It's going to be a problem for everyone until Metlino is done. We can either make our own PCBs or buy those: https://shop.trenz-electronic.de/en/TE0424-01-SFP-2-SATA-Adapter (don't ask me whether we need the "host" or
<GitHub69>
[artiq] sbourdeauducq commented on issue #854: Still, I'm no stranger to SATA/SFP cable breakage and I'm getting tired of fixing it. Can we have reliable SATA/SFP adapters? @jbqubit can you fund them? It's going to be a problem for everyone until Metlino is done. We can either make our own PCBs or buy those: https://shop.trenz-electronic.de/en/TE0424-01-SFP-2-SATA-Adapter (don't ask me whether we need the "host" or "d
<GitHub119>
[smoltcp] whitequark commented on pull request #98 64108f3: Let's add `pub(crate) const MOCK_IP_ADDRESS_1` in `smoltcp::wire::ip::test` or something like this, it's not good to drop tests in IPv6... https://github.com/m-labs/smoltcp/pull/98#discussion_r158438229
<GitHub20>
[smoltcp] whitequark commented on pull request #98 64108f3: I don't think ICMP sockets should depend on `proto-ipv4`. Sure, right now, since we don't have ICMPv6 at all, they would do nothing, but they should eventually be available, so let's keep them in. https://github.com/m-labs/smoltcp/pull/98#discussion_r158438655
<shuffle2>
is there a better way to force vivado to use bram (an instance?) i'm tired of trying to understand why it wont infer one
<shuffle2>
or, is there a known issue when trying to use > 1 Memory() as dual port rams in the same class when synthesizing with vivado?
<sb0>
no known issue
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
futarisIRCcloud has joined #m-labs
<attie>
I've had problems with vivado not inferring bram, but same class would not be an issue. Given my extremely light-weight example I was suspecting direct connections to i/o buffers... but haven't had time to find out
<shuffle2>
i've tried to merge the memory into 1 object and added some logic to partition it. now vivado complains it cannot create a dual port ram because there are more than 2 write ports...but i only have 2 :( it seems the 3rd has been added by misoc's csr_bus somehow
<sb0>
bb-m-labs, force build --branch=release-3 artiq
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<GitHub160>
[smoltcp] dlrobertson commented on issue #94: Our current implementation and this implementation include `process_ethernet`, `process_ip`, and `process_udp` all in on `trait` or `impl`. At some point we're going to need the `process_ip` and `process_ethernet` implementations to be in different `trait`s or `impl`s right? We shouldn't have layer 2 processing and layer 3 processing in the same trait right?... https
<GitHub149>
[smoltcp] dlrobertson commented on issue #94: Our current implementation and this implementation include `process_ethernet`, `process_ip`, and `process_udp` all in on `trait` or `impl`. At some point we're going to need the `process_ip` and `process_ethernet` implementations to be in different `trait`s or `impl`s right? We shouldn't have layer 2 processing and layer 3 processing in the same trait right?... https
<GitHub71>
[smoltcp] dlrobertson commented on pull request #98 cb6c9de: If we remove this that would mean a build without default features and without `proto-ipv4` but with `proto-ipv6` would fail. If you're okay with that, I can simply remove this. Otherwise we need to make a generic `IcmpRepr`/`IcmpPacket` https://github.com/m-labs/smoltcp/pull/98#discussion_r158510452
<GitHub58>
[smoltcp] whitequark commented on pull request #98 cb6c9de: Hmmm, I've looked at making ICMP sockets work with ICMPv6 but it looks involved, so let's disable them on non-IPv4 builds for now. https://github.com/m-labs/smoltcp/pull/98#discussion_r158512088
<GitHub118>
[smoltcp] whitequark commented on issue #65: You have correctly identified the root cause of the problem however your patch is overly complicated. There is no need to test for wraparound since that is already handled by the `TcpSeqNumber` newtype. You can verify that your testcase works on master. I've merged a simpler version of both your fix and your test as b247f64. https://github.com/m-labs/smoltcp/pull/65#i
<sb0>
WARNING: [DRC PDCN-1569] LUT equation term check: Used physical LUT pin 'A6' of cell i_7 is not included in the LUT equation: 'O6=0'. If this cell is a user instantiated LUT in the design, please remove connectivity to the pin or change the equation and/or INIT string of the LUT to prevent this issue. If the cell is inferred or IP created LUT, please regenerate the IP and/or resynthesize the design to attempt to correct the issue.
<sb0>
in xilinx's bizarro world, the same input to the software produces different output, and this is a perfectly normal situation that should not be corrected and is perfectly OK to inform users about
<cr1901_modern>
bind mount /dev/zero to /dev/random?