ChipLink isn't an open spec, apparently, or can I see it somewhere?

HiFive Unleashed
1

I remain excited about RISCV and SiFive, in theory. I have the signed HiFive1 and HiFive Unleashed boards. I think I have all the published documentation. (and I’m pretty influential in the industry, after 50 years of contribution to systems architectural research and software product development).

So I’m also quite disappointed. I’d like to work on some hardware (communications, related to SDR and low level signalling/timing) and interface it to the HiFive Unleashed system. And it looks quite feasible.

But I’m running into what seems to be a problem with SiFive (maybe it’s just that they aren’t hiring the right staffing for this). Just as key register settings needed to use their product aren’t really “open” (apparenlty due to IP agreements, if I read their comments right), it seems like their hardware interfaces aren’t really open.

In this case, it is ChipLink. AFAICT, ChipLink is a physical embodiment (PHY) for TileLink. That’s great. There’s a draft spec for TileLink. But the word ChipLink does not appear in that document at all. In the FU540-C000 Manual (a good one, for the most part), it appears only in the block diagram and introduction as a named box.

Now, I have some pretty good experience with using signalling on the FMC interface to connect to cards. (The popular use for labs is the ZedBoard, MicroZed FMC carrier, and other places, and it’s used in a lot of AMC chassis. And ChipLink is carried on the FMC interface - that’s how it connects to HiFive Unleashed’s board from MicroSemi. But I don’t see that board as useful to me (and using Libero seems very expensive, too, even with a 1-year license built in the offer of the very expensive board for my needs.)

So, I’m stuck. I note that MicroSemi’s board doesn’t seem to contain any verilog or other support for the ChipLink in open (published form).

Am I missing something? Or is TileLink going to be open at an abstract level, but completely close and undocumented at the PHY level?

If so, I will stick with ARM. I don’t like ARM as much (especially it’s non-free aspect).

However, I would imagine that, if there is to be a useful community effort around RISCV and SiFive, locking up interfaces as proprietary and undocumented is a bad move.

I’d like to think that the slowness of release of the initialization register documentation (or even just Hex values) and the absence of ChipLink documentation is just arising from a tiny startup’s growing pains. If that is the case, please hire some developer support and start pushing out documentation and answering questions. We out here can help! And make some announcements (here on the forum, or in the press) about your roadmap and priorities.

Or, even better, just point us at the existing documentation (or even HDL source code)

2

I don’t think there’s any intention that ChipLink be secret – quite the opposite, I’d think. I’d say it’s more a matter of the people who know about this being spread thinly and while the company is expanding quickly it takes time to bring new people (like me) up to speed. And I’m not a hardware guy anyway.

As far as I know, the interface to the MicroSemi board is exactly the same as to the VC707 and nothing changes on the HiFive Unleashed side. However I’ve not personally set either one up.

I just tried entering “sifive chiplink” into google and one of the first results was https://github.com/sifive/sifive-blocks/blob/master/src/main/scala/devices/chiplink/ChipLink.scala

You can go up one level and find more.

It’s not documentation, but it is HDL source, albeit not Verilog.

3

I’m also not a hardware guy. My understanding is that TileLink is used for on-chip communication, and ChipLink is used for off-chip communication. The Freedom Unleashed board actually has both. I think ChipLink is a serialized version of TIleLink to make off chip communication work better, but this is way outside my field.

Here is a reference I found by using a google search for "chiplink tilelink"


though it doesn’t actually say much about ChipLink. Maybe that will be covered in next year’s talk.

4

I appreciate the pointer to the scala/chisel source, thanks. I will make a stab at decoding it. Skimming a couple of parts, I can’t figure out exactly where the physical layer gets defined. I assume that is in some common file that defines the external pin parameters and timing.

So, devices/chiplink seems to define the logic of the chiplink endpoint on the chip, going down to the pin signalling level through devices/pinctrl. As do the other devices in sifive-blocks. Studying that subset of the HDL code might be sufficient, once I become proficient in chisel (which probably isn’t that hard). I will have the TileLink spec in hand for that.

Of course, I probably need a TileLink switch in my FPGA code as well, and that isn’t in sifive-blocks. Hopefully, I can find it somewhere.

Anyway, thanks for the pointers, and I hope that documentation will come eventually.

I suspect I will have to create a chiplink bus-analyzer to get clear on the timing and clocking on the real chip. Fortunately, an FPGA is good at creating such things.

5

Also, I had seen the Terpstra slides. And they help with the TileLink spec by giving some good pictures and examples, The slide #24 (and #25) show a pretty good picture of what I would like to put in an FPGA, where “my IP block” is my design, and the external connections from the FPGA are driving ADC’s and DAC’s.

6
1 Like
7

This Makefile will create a complete vc707 image with ChipLink at 200MHz: https://github.com/sifive/freedom/blob/master/Makefile.vc707-iofpga

The protocol is not documented because the current implementation is more of a place holder until we have a serdes. The FMC protocol is 2x35 pins used as a 32-bit-beat packet bus.

3 Likes
8

There is no PHY between ChipLink.scala and the IO pins. The only trickery is that we use PLLs to shift the data relative to the source synchronous clock to close timing. Here are the timing constaints: https://github.com/sifive/fpga-shells/blob/650b45dbf7fe03ff606a92715ae2277e9fde2c28/src/main/scala/shell/xilinx/ChipLinkOverlay.scala#L37

2 Likes
9

We are keen to have TileLink be an open standard, and we also want to have the TileLink protocol be mapped on top of various physical chip-chip links, forming various kinds of open ChipLink standards - though we’re not sure we want to use the ChipLink name instead of TileLink-over-X for example . We’re still sorting out the best way of layering the specifications, but are actively working towards this. We are also working to create a better venue to have open discussions/development around this standard. As Bruce said, the principals are very busy doing many other wonderful things at SiFive so it’s lack of bandwidth, not intent, that has meant the spec is not better documented.

1 Like
10

This is very, very helpful. Not quite a roadmap, but for this area it’s useful to know this stuff.

Will the synthesized (verilog w/pin and IO constraints, or whatever) Polarfire implementation from the HiFive Unleashed Expansion Board be open sourced? That’s what I really think is the minimal way to make a peripheral over TileLink-over-FMC /ChipLink 0.1 release. If so, when can I see that? (I don’t think Chisel has pin/electrical specs).

Now it may not be in the plan to support any external hardware other than the HFU Expansion Card, which is currently “closed source”, or nearly so, AFAICT. I can’t use that for my task, but others may want to know the plans here.

But it does leave me with a question. How did the Microsemi bitstream that supports the FMC get created, without some sort of detailed documentation that may have been distributed under NDA to Microsemi or something.

Anyway, for now you guys have inspired me to become proficient in Chisel, and I suppose that’s a useful takeaway. (however, even setting up the chisel-tutorial has been a nightmare of version incompatibility and sbt difficulties, but that’s an SBT problem, not SiFive’s. Scala is really kind of immature, though a great language.

11

Just a side comment: PCIe is as problematic as the Intel and ARM ISA’s to the hardware industry. Both the patent licensing and the absolute control by an oligopoly driven by Intel makes things a big problem.

If we are going to try to move towards a sea of specialized processing units, we need a far better physical and logical interconnect fabric that is fully “open” in all senses of the world. Licensed free to everybody including startups, not locking you into the ARM or Intel ecosystem for economic control, yet evolvable across technologies.

So please let’s not adopt PCIe because it’s there. It’s a bear trap, brilliantly laid by Intel and controlled by the 1% of the industry.

ChipLink at the physical level could be the RJ45 of specialized processor interconnect. It’s better than PCIe because it has a focus on coherency when you need it (like QPI, which fortunately has not polluted the entire industry with Intel lock-in).

It’s not just the RISCV ISA that matters to folks like me. A fully open interconnect fabric is equally important.

1 Like
12

We fully agree with your points on needing an open on-chip/chip-chip coherent interconnect standard, and are donating TileLink spec and source code for this reason. That said, we do support existing proprietary interface standards such as PCIe because our customers need this for their products today.

2 Likes
13

The freedom repository I linked earlier already has the IO constraints for the Polarfire board from Microsemi. Also, Chisel (or in this case more precisely scala) can specify the pin/electrical constraints as shown in the files I linked to earlier in this thread. I don’t know why you say that the expansion board is “closed source”. I believe the schematics are available from Microsemi and the entire flow needed to create the bitstream is in the freedom repository.

14

I am looking in the freedom repository on github for the flow needed to create the bitstream for the Microsemi expansion board. I don’t see it. I see a polarfire Makefile, but it seems to be building a U500 implementation on a polarfire board. Is it hiding in there somewhere? I confess that I’ve been through the freedom repo looking for something that seems to indicate “expansion board FPGA”, but I would love it if someone could point it out to me.

It might be misinformation, but I also saw on the CrowdSupplysite for the expansion board that one needs a GOLD Libero license just to synthesize a new bitstream. (apparently, you get a time-limited 1-year SILVER license included if you buy the $2,000 expansion board, which is a good deal if you want a Polarfire implementation - sadly I don’t want a time-limited license, but Microsemi is free to price itself out of the research/inventor market, I just won’t buy their stuff).

Again, I’m not trying to get in the way of anything. I’m just lost.

15

Micosemi expansion board project top: https://github.com/sifive/freedom/blob/master/Makefile.veraiofpga

1 Like
16

To be fair to @dpreed, I’m not sure it’s explicitly mentioned anywhere public that Aloe is the HiFive Unleashed and Vera is the expansion board … so it’s probably not easy to intuit that makefile.

2 Likes
17

@terpstra @bruce Thanks! those are the keys to the mystery, now I get to go to the next level of the game. :slight_smile:

HiFive Unblocked!

1 Like
18

@dpreed I think I’m going to unofficially call the next pre-alpha hardware/software release of Linux+Uboot+Scala+Chiplink “HiFive Unblocked”, since I’m running a bitstream on my RiscV desktop that has everything needed for anyone who wants to mess with the Scala code to add new features to the FPGA, which includes all the code to generate veralog for chiplink, pass it to Libero 12, and reliably get something that boots!

19

@tmagik: that sounds cool. Is there a repo I can track for it?