Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Was Claude used?
    by brcmthrowaway
  • No AI was used either for the project itself or for the post.
    by random__duck
  • How much of this is AI?
    by netik
  • No AI was used either for the project itself or for the post. I encourage you to look at the code and the git history.
    by random__duck
  • Make it into a company. Name it Sanfran.
    by effnorwood
  • You might want to make the port index instead a bit mask, that will let you support multicast and also selective broadcast flooding (although if you have limited space you’ll likely make broadcast flooding the default).
    by lukeh
  • That memory constraint is a real killer on the chip, even one that is a first generation toy like this. Only having 4 entries in the forwarding table is going to be an immediate problem if that switch is ever connected to another switch.

    I wonder if it wouldn't make sense for one of the ports to be designated the "uplink" port and if the switch receives a packet destined for something not in the table it forwards it out the uplink port so long as the packet did not arrive via that port. It could even save a bit of memory by not storing entries for the uplink port in the table.

    by jandrese
  • There isn't really a restriction that a downstream device will only have one mac address.

    It might be another switch. Even if it's not; VM/container networking is often implemented by bridging the host's NIC to a virtual switch, exposing the MAC addresses of all VMs/containers to the network.

    by phire
  • On TinyTapeout you can add more tiles up to 16 times the size of this (at which point you likely jump to waferspace)
    by Taniwha
  • Correct ethernet switch behavior forwards a packet to all ports if the destination MAC is unknown
    by inigyou
  • Nice! I've been following waferspace and tiny tapeout loosely but I'm sadly not in a position to be able to work on something right now.

    I'm surprised you managed to fit something like this in a TT grid square.

    by inigyou
  • You can join multiple Tiny Tapeout tiles (grid squares) together to form bigger projects, which is what I did here. It's actually one of the bigger 4 grid projects.

    Also how much you can fit really depends on the node the shuttle is targeting. So I was in luck that this was on Global Foundries 180nm as you can cram in a lot for flip-flops onto a single tile compared with Skywater 130nm. On the other hand the gates are much slower than on Skywater 130nm.

    Hopefully both programs will be around for a while, so if you are still interested when you have more time you can join the shuttle then.

    by random__duck
  • Great project & article. Beyond the use of verilog, I couldn't find a description of the EDA stack. What tooling is used for the physical stages of design: place & route, LVS, DRC, and electrical circuit simulation (SPICE)?
    by roadbuster
  • True, I went over the EDA stack a bit in a previous article here: https://talesonthewire.com/projects/blake2s_hashing_accelera...

    This used the librelane classic flow, so it's a lot of verilator, yosys, openroad, opensta, magic and klayout. :)

    by random__duck
  • This is extremely cool, I've played with FPGA design but never really even looked into custom ASIC design due to budget concerns. I hadn't heard of the tinytapeout project. Any recommended links for getting started?

    I have a (really dumb, kinda meme-y) project involving a dead hakko soldering iron and "Internet of Soldering", a custom ASIC for the actual front-end would be the appropriate level of silly and possibly could fit in the project budget.

    by zrobotics
  • Tiny Tapeout has its own guide for getting started
    by inigyou
  • The tiny tapeout project doesn't really fix the economics either. There's the obvious IO bottleneck, but worse than that, a 1000 LUT FPGA fits bigger designs and costs almost nothing. Like $2.50/FPGA at 1000 units.
    by imtringued
  • As the designer of "an ethernet connected beacon that counts and never overflows until the heat death of the universe" (https://talesonthewire.com/projects/until_heat_death_do_us_p...) I believe you have found the perfect audience for a memeish hardware project. So don't expect anything but my upmost support. :)

    I detailed the roadmap for custom ASIC design a bit here: https://talesonthewire.com/projects/two_weeks_until_tapeout/... and joining the Tiny Tapeout discord community is a great place to reach out for help.

    by random__duck
  • “ Cut-through vs Store-and-Forward”

    I had a Google interview collapse because the last interviewer was a Principle Engineer who just couldn’t accept that a switch will ever forward a frame before reading in full and checking the FCS.

    I was too much of an idiot to go along with it and instead ended up having an argument with him.

    by noncoml
  • "principal"
    by gjvc
  • I remember studying cut-through forwarding in a class and thinking it was obviously going to be used everywhere.

    Then I was disappointed to enter the real world of networking and learn that it wasn’t actually used as often as I had been led to believe due to conflicting with higher priority features.

    So the interview may have been a conflict between textbook learning and the Google engineer’s practical experience. It’s tough to encounter that conflict in interviews because you get two people talking past each other.

    by Aurornis
  • Sounds like they could have used you on that team. Bad luck, but it at least you can walk away proud knowing it was not an issue with your technical skills. :)
    by random__duck
  • I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit.

    Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered.

    Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering required (or drops and throughput reduction).

    Bigger networks start using vlans, mpls, ip routing at switches, and vxlan - requiring more lookups per-packet, larger "minimum chunks of packet seen before port is determined" sizes, etc reducing the value of cut-through.

    And so on.

    But i also struggle to find a scenario where a principle engineer at google is refusing to accept that cut-through switches exist, but rather, was refusing to accept that the scenario they're talking through with you would ever involve an effectively deployed cut-through switch (since that's basically never).

    by sophacles
  • Cut-through is applicable in a minority of scenarios which are sometimes common. The majority of switches, especially the ones that support any advanced features at all, can't use it. Even when you can use it, you still can't use it all the time because of port conflicts.

    As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch.

    by inigyou