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.
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)?
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.
Nice, thanks for posting the link.
For the people unfamiliar with the Tiny Tapeout program: everyone that gets a copy of the Tiny Tapeout chip will be getting a copy of all the ASICs on the shuttle.
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.
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.
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. :)
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).
Ethernet frame preemption has been standardized for about 10 years for ultra low latency applications. See 802.1Qbu:
"Defines a class of service for time-critical frames that requests the transmitter in a bridged Local Area Network to suspend the transmission of a non-time-critical frame, and allow for one or more time-critical frames to be transmitted. When the time-critical frames have been transmitted, the transmission of the preempted frame is resumed. A non-time-critical frame could be preempted multiple times."
> 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).
Nope, the argument was exactly if a cut-through switch exists or ever existed
Edit: Actually the conversation came back to me:
He asked me about the frame format. Once I drew that on the board, he asked why is the DST before the SRC. My answer was in order for the switch to start doing the lookups ASAP and that's when I mentioned that a cut-through switch can switch the packet before it even finishes receiving it.
After that we spend the rest of the interview time arguing if cut-through switches actually exist or not. Both he and I having too big of an ego to let it go..
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.
This used the librelane classic flow, so it's a lot of verilator, yosys, openroad, opensta, magic and klayout. :)
I'm surprised you managed to fit something like this in a TT grid square.
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.
[0] https://tinytapeout.com/chips/ttgf26b/tt_um_coffeepot
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.
As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch.
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).
"Defines a class of service for time-critical frames that requests the transmitter in a bridged Local Area Network to suspend the transmission of a non-time-critical frame, and allow for one or more time-critical frames to be transmitted. When the time-critical frames have been transmitted, the transmission of the preempted frame is resumed. A non-time-critical frame could be preempted multiple times."
Nope, the argument was exactly if a cut-through switch exists or ever existed
Edit: Actually the conversation came back to me:
He asked me about the frame format. Once I drew that on the board, he asked why is the DST before the SRC. My answer was in order for the switch to start doing the lookups ASAP and that's when I mentioned that a cut-through switch can switch the packet before it even finishes receiving it.
After that we spend the rest of the interview time arguing if cut-through switches actually exist or not. Both he and I having too big of an ego to let it go..