Crosslink nx ram

[alanvgreen]

I went a slightly different way to you on the RAM. I think this primitive name is more correct. I can pick up your changes tomorrow and rebase the RAM changes.

[davidcorrigan714]

I don't seem to have "radiantc" in my install, maybe a windows vs linux difference?

[davidcorrigan714]

I'm not entirely clear what's happening with the RAM primitives vs the RAM types in the CrossLink-NX. There's EBR and LRAM which gives various combinations of total possible RAM quantities on the two chip sizes but it's not clear what primitive refers to which RAM type, or if it's figuring that out while building. The IP Cores seem to differentiate between the RAM types so that might be one way to figure out how to specify which type of RAM is being used where.

[davidcorrigan714]

On the RAM I tried to implement the wb bus select lines, think I got it right but I'm not entirely sure when/if they get used. edit: the self.bus.sel references

[alanvgreen]

The single port primitives for Crosslink+Radiant appear to be:

SP512K - Single LRAM = 64KB in 32 bit words SP16K - Single BRAM = 2KB in 18, 9, 4, 2 or 1 bit words SPR16X4 - Distributed RAM (i.e flip flops)- 64 bits in 16 bit words

There are dual port and pseudeo dual port variants as well.

I think the two we want are SP512K (LRAM) and SP16K (BRAM). Does that sound right to you?

On IRC, Dave Shah suggested I try letting Radiant infer the LRAMs. It appeared to infer BRAM instead. The resulting design synthesized, but did not fit on the device. However if Radiant could be persuaded to infer the BRAMs sanely, that might be useful.

[alanvgreen]

This is WIP: I have the LED chaser up, but I'm not getting any other response from the SoC. Nothing on the UARTs that I can see.

All out of ideas for the moment but I'll pick it up again on Monday.

[davidcorrigan714]

I'll poke at the UARTs in a bit. Trying to reconcile the RAM stuff at at the moment. Looking at what I did I tried to use the SP16K and it seemed to work but the primitive looks incorrect. I'll sort that out in a bit. Looking at yours though, looks like you kept the 18 bit wide data lines, which then ends up wasting 2/18 bits since we only use it in increments of 4. That also throws off the actual size calcs. My strategy was to do the narrower and deeper 4kx4 data width to fully utilize the ram, just means you end up having to instantiate larger chunks. I'm also wondering though if it's better just to infer EBR so we don't have to write it all out for every variation.

I'm thinking in a bit I'm going to merge everything in and do some rearranging / cleanup to see if we can get to one cohesive set of all this though.

[alanvgreen]

Yeah, the wasted bits bother me too. My understanding of the BRAMs is that they're natively 1Kx18 bits, but using the "extra" 2 bits would require some clever code. As far as I can tell, configuring the BRAMs as 4Kx4bits also only uses 16 out of the native 18 bit width.

I was thinking of merging all the Lattice RAM code into one .py file, with the common structure factored out, but was waiting to get it a Soc working first. I think the right thing to do is to pick one simple RAM implementation (happy for you to choose) and use it until a SoC+UART works.

Here are the all ideas I had about UARTs

• the "built in" UART requires 0-ohm resisters to be soldered in, and I'm not ready to do that, so I was messing about with external USB-UARTs. They've worked well for me in the past on a Xilinx Arty.
• there is a timing error being reported by Radiant which involves the UARTs. It seems to be present no matter what clock speed I choose, and if IIRC, it's on the UART input pin so I doubt it is an actual error, or actually stopping anything from working.
• I was going to bite the bullet and teach myself litescope or Radiant Reveal to try to debug a little more.

Looking forward to seeing what you come up with!

[davidcorrigan714]

Poking at the uart issue it really doesn't seem like the soft cpu is booting. I put my logic analyzer on the flash chip and it seems to be loading data from it over SPI, but this bug suggests that the data might not be making it to the CPU. I've done a few things with reveal so I'll try and capture the loading process with it, and comment on that ticket for any suggestions on debugging. I haven't soldered my board yet, I'm just putting a scope probe on the pads for now. I'll probably solder them at some point, though just getting a nicer place for the probe grabber would be nice at the moment.

[daveshah1]

I can understand the need for instantiating LRAM, but is there really a need to instantiate BRAM?

[alanvgreen]

@daveshah1 I think I understand your concern: the underlying toolchain ought to be able to infer the use of BRAMs to implement static RAM. The alternative would involve a proliferation of static RAM implementations in LiteX or migen, maybe one per chip family, and no one wants that. Is that right?

(Also, I would imagine that a lot of effort has gone into these toolchains to do that inference and avoid this kind of proliferation. We should take advantage of that effort, where possible!)

Unfortunately, my first attempt at letting Radiant infer the BRAMs didn't go so well. Radiant seemed to infer BRAMs but then used too many LUTs and the synthesis failed after taking twice as long as it normally does. I'm expecting that some tweak to Radiant's settings or to migen's implementation might allow Radiant to do this inference properly, but it will require some research.

I'll try to make the BRAM inference work with Radiant. If I can't make it work, will raise an issue over on the LiteX github.

[daveshah1]

Were you using Synplify or LSE? Synplify usually does a lot better but it would be worth trying both. As Synplify in Diamond happily infers RAM using the style LiteX uses I would be surprised if Radiant was that different.

There are lots of other places where LiteX implicitly relies on working memory inference, like caches and register files within the CPU cores.

[alanvgreen]

@daveshah1 I was using Synplify. Will try LSE and will also give Synplify another go once everything else is up.

[davidcorrigan714]

I played the the Radiant core generator when looking at the RAM primitives and it doesn't seem to use them, seemingly relying on inferring the RAM types with a few hints. So it would seem it is possible but I didn't look too closely at how they were doing it especially since the manual says it will do distributed ram & block ram but no notes on inferring LRAM.