orbtrace : add support for the 1bitsquared icebreaker fpga board about orbuculum

[mubes]

Tom, 17c2b0c should now give you a reasonably strong springboard to start from. I've added some ifdefs etc for the ICEBREAKER so hopefully it'll just be filling in the blanks :-) Good luck.

[mubes]

By all means...had meant to drop you a note to ask you :-) Thanks for all the help. Good result!

[TomKeddie]

@1bitsquared wrote.

@TomKeddie you will get best results using just SPI streaming on the first FTDI interface ... you then don't need to solder any jumpers. The secondary parallel FIFO interface does not support the faster mode so you don't get much of a speed increase using the FIFO vs SPI.

I would implement it using the high speed SPI interface that @tnt developed for the LED matrix data streaming https://github.com/smunaut/ice40-playground/tree/master/cores/spi_slave

(the second FTDI FIFO interface does not support asynchronous? mode... not sure which one of the two modes, but it is the faster one that it does not support)
We could not do that on the first interface because of the requirement to support the proprietary lattice FPGA tools out of the box and some of them just assume that the programming interface is on the first interface of the FTDI chip.

[TomKeddie]

Note that SB_PLL40_CORE is not supported on ICE40UP5K so we might need a new toplevel or at least some restructuring.

[mubes]

Ok, last things first....this would be a great thing to have. Now, I'll cut/paste the discord discussion in here for archival purposes; I don't actually have an icebreaker board but a few days back I did do a build of orb against the 5k part. It reduces the maximum trace speed from 120Mhz DDR to around 46Mhz :-( at that point I stopped, but it would be trivial to add it back in....it's just a different pin config file+PLL. The 5k has a hunk of ram that we could make use of too. I actually have builds that use the spi in a high speed mode (30mhz data rate) but because the ftdi chip was never my final target for Comms I didn't publish that....if it's useful to you I can make it available again? In actual fact I didn't see much speed increase against the uart port, mostly because the data lengths are valuable so I had to overlay a bit of protocol in there. For completeness, the protocol is very simple. Each frame that comes from the chip is 16 bytes long. A frame sync is an explicit value that cannot appear in a frame (fffffff7) that is used to 'reset' the frame counter. We can 'hide' our data in incomplete packets in the flow...so I send a packet that goes A6 HH LL .. .. .. .. .. .. .. .. .. FF FF FF F7 at the end of a block that says (in HH LL) how many frames are now in the buffer. In the next round I then collect that many frames. It minimises the overhead of using the spi since you're only ever requesting frames that you know contain valid data. If there interest in doing this I guess I can grab an icebreaker. I would expect we could support chips running at up to 100Mhz or so using it, unless someone with more serious FPGA chops than me can further improve the speed of the DDR (I got it from 60mhz to 120..130Mhz on the hx8 by means of reading books...more books might result in more speed). The spi code is currently in the 'unused' directory. I'll see if I can pull it back into the build.

…

On Sun, 10 Jan 2021, 03:47 Tom Keddie, ***@***.***> wrote: Note that SB_PLL40_CORE is not supported on ICE40UP5K so we might need a new toplevel or at least some restructuring. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD5A4RSHBPG56JLPRY3SZEPNJANCNFSM4V4C2SSA> .

[mubes]

I have re-added the SPI code. Simply change the two makefiles to reference it rather than the UART code. This is largely untested although it is working on light loads. Good luck! See 17dfc77

[TomKeddie]

@mubes thanks. I'll probably start simple and generate a pr with the thing building and support for the 3 fpga targets in a clean manner. As I mentioned on discord my availability is all over the place, I tend to work in bursts, but I'll probably take weeks to look at this not days.

[mubes]

No problem at all. I'm very conscious that the currency that is in short supply is time, so I just want to make sure you're not wasting any of yours repeating anything that I've already got in place. To get started I would recommend you use the uart interface since that's (slightly) more tested. I'll fold your your pin definition file from above into the make and create a new target this evening....after that I'm afraid you're largely on your own cos I don't have that board. Best of luck! Dave

…

On Sun, 10 Jan 2021, 16:10 Tom Keddie, ***@***.***> wrote: @mubes <https://github.com/mubes> thanks. I'll probably start simple and generate a pr with the thing building and support for the 3 fpga targets in a clean manner. As I mentioned on discord my availability is all over the place, I tend to work in bursts, but I'll probably take weeks to look at this not days. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD4UU6ELIFCNSRAQNCLSZHGRDANCNFSM4V4C2SSA> .

[TomKeddie]

Thanks Dave, if you can add the pin defs and the target that would make sure the style fits your intention. My biggest concern would be doing a bunch of work that doesn't fit your intentions and thus needing to redo it.

Yes, baby steps are the go - I'll get the uart interface going on icebreaker and then we'll have something to put in a PR to talk about. Given the low clock rate it seems like the icebreaker might not be a great place to land but lets see how we go. Perhaps I can move to an ecp5 board next.

[TomKeddie]

@mubes I think we're done here? am ready to close this if you are?